-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #710, Specify ProcessorID in targets.cmake #773
Fix #710, Specify ProcessorID in targets.cmake #773
Conversation
640f84c
to
fe47a3e
Compare
Ping @excaliburtb - this is a very minimalist approach to start with - if you like this we can potentially merge it. Going forward I'm starting to like the idea of going fully name-based and remove the index numbers from targets.cmake. something like:
Obviously this is a bigger change to do, but it would actually clean up a bunch of implementation aspects if we did it this way, and it would probably be more logical from a user perspective too. |
yes, that works and addresses my immediate problem. When we were doing our own cmake script mods, we basically took the approach of, if a cpu list of names exists, process the list, otherwise use the index approach so the read_targetconfig function would look like:
something like that would keep it backwards compatible but, as you say, may end up keeping up some of the implementation aspects you were hoping to get rid of without names. |
Add support for a TGTx_PROCESSOR_ID directive, which allows one to set the default value returned by CFE_PSP_GetProcessorId() function, rather than assuming the index value from CMake.
77e5a06
to
2868acc
Compare
Thanks! So if this at least is a step in the right direction I've squashed it and marked at as CCB ready. I can't foresee this breaking anything. In the meantime I will work on the name-based approach. |
Note to reviewers - This is related to #710 and #265, but does not fully address either one of them, so I intentionally did NOT link this PR to those issues because it doesn't address all aspects of either issue, this just addresses the ability to set a processor ID explicitly rather than assuming the sequential number. |
thanks for the support! |
@astrogeco Could you merge this into IC? Priority. |
See also follow-on PR in #776 - this takes a stab at name-based config described above - seems to work nicely. |
Describe the contribution
Allow explicitly setting of the processor ID in
targets.cmake
Testing performed
Build and sanity-check CFE
Build and run all unit tests.
Confirm that
CFE_PSP_GetProcessorId()
now returns the expected value.Expected behavior changes
The
TGTx_PROCESSOR_ID
setting intargets.cmake
will be passed to the final build/link of CFE core as the CPU ID. If unspecified then the CMake index value is used instead (backward compatible).System(s) tested on
Ubuntu 20.04
Additional context
Minimal/simple fix that at least should address part of the problem. Note this value isn't passed to
elf2cfetbl
for table builds at the moment, this only affects the CFE runtime value of processor ID.At least on pc-linux one can still provide the value on the command line which takes precedence over anything in the build.
Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.