-
Notifications
You must be signed in to change notification settings - Fork 2.1k
boards/stm32-based: model Kconfig #17374
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
Conversation
|
||
source "$(RIOTBOARD)/common/stm32/Kconfig" | ||
source "$(RIOTBOARD)/stm32f429i-disc1/Kconfig" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this is not the normal way we do it, usually this would be factored into a common board or something instead of just taking another board... This is what is done in the makefile and TBH, we should probably deprecate this board as it is super obsolete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aabadie do you have the old or new version?
|
||
# This configuration enables modules that are only available when using Kconfig | ||
# module modelling | ||
ifeq (1, $(TEST_KCONFIG)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #17376
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can rebase after that gets in.
fabd4c3
to
a68f53b
Compare
with #17376 the picolib issues can be resolved and I can add the nucleo-l011k4 and stm32f030f4-demo to the passing list. |
a68f53b
to
f7e8f23
Compare
Hmmm it seems that the current forcing of
in |
I think the choice thing is the way to go. I now override the libc_implementation in the nucleo-l011k4 and stm32f030f4-demo and got rid of the hardcoding in the cortex common. I am running the CI to see all failing stm boards, some I know will fail I just want an overview. Maybe I can get a few more in this PR but it might also be worth fixing what we have now and doing a follow-up later. Possibly after another check on all boards. |
OK, another round. I think I got all obvious things (only binary diffs with the same modules are left). In the murdock file I indicated them with 2 spaces in front, but I guess this will be testing all boards anyways. Many of these are due to clock configurations which will be a different PR. If everything is passes as expected I will clean things up, run another limited build and record the blacklisted boards and hopefully get this acked (then remove the limiting build commit) |
9289c75
to
1a81a2e
Compare
OK rebased and now I am only checking the boards that should pass. After the review/ack I will squash and remove the murdock change (though I may add some boards to the list). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, looks good, please squash if murdock passes the limited build
All green please squash! |
1a81a2e
to
637e91a
Compare
OK, squashed and added a few boards to the regular testing. There may still be some errors in the few boards that were added as I only check a subset of apps. We will see. |
It seems like some |
637e91a
to
475c63f
Compare
Everything looks good if we want to merge? |
Gooo! |
Contribution description
Fixes modelling in many (but not all) stm32 boards:
Some boards will require more attention but any relevant modeling is done:
Some drivers needed to be touched to allow saul_default to select them:
Testing procedure
Green CI and a look over if it makes sense
Issues/PRs references
Part of #16875
Depends on #17376