-
Notifications
You must be signed in to change notification settings - Fork 0
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
fixture: review proposal for #30594 #2
Conversation
a751a35
to
fec465f
Compare
@@ -1,5 +1,36 @@ | |||
tests: | |||
drivers.gpio.2pin: | |||
platform_exclude: nucleo_f091rc nucleo_l476rg nucleo_l073rz nucleo_f401re stm32mp157c_dk2 nucleo_f030r8 nucleo_g071rb nucleo_l053r8 nucleo_g474re nucleo_f334r8 nucleo_wb55rg rv32m1_vega nucleo_f746zg mimxrt1050_evk frdm_k64f disco_l475_iot1 nrf52840dk_nrf52840 nucleo_l4r5zi lpcxpresso55s69 nucleo_f429zi mimxrt1060_evk hifive1_revb nucleo_l152re |
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.
IMO this is unmaintainable, but we can discuss it in dev-review.
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.
compared to 20 duplicated files ?
I think I prefer adding a single board name here, instead of duplicating identical files everywhere.
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.
of course it might be possible to adjust testcase.yml scheme, so that if a platform in specifically mentioned further down, then it is automatically exclude here, but that would be an extension, but probably a valuable one.
Note, the reason I didn't line break, is because I'm unsure if the testcase yaml shema allows it, and / or if a proper yml sequence is allowed. So this was a quick way, to show the principle.
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.
The problem is, instead of inheriting support for all existing tests that use fixtures by simply adding a fixtures include to the board, you have to edit every test that supports a specific fixture and add the board into the appropriate build option, trying not to corrupt the existing list when you do so.
Also the board-specific overlays providing support for fixtures aren't in the boards directory where people can find them, they're down under tests/common, are separate for each fixture, and do not indicate in the overlay what boards they apply to.
And if you want to change the pins associated with one fixture on one board, you have to change all the test configurations that use that fixture.
None of that is insurmountable, but I don't consider it an improvement over the current content of zephyrproject-rtos#30594.
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.
update.
It is possible to make new lines, which help on the long lines, but doesn't solve the issue with having to specify the board both in platform_exclude, and then a platform_allow.
But would like your opinion on this, if there can be an platform_allow_exclude_others
kind of entry.
fa30d77
to
3d91fb0
Compare
This is the main part of the proposal. Keeping test fixture overlays under tests, in structure similar to what is described in: https://docs.zephyrproject.org/ latest/guides/dts/howtos.html#set-devicetree-overlays by using: > create a boards/<BOARD>.overlay file in the application folder, for > the current board Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
3d91fb0
to
9f97764
Compare
Added function to calculate channel identifier value required for Channel Selection Algorithm #2. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
The fatal log now contains - Trap type in human readable representation - Integer registers visible to the program when trap was taken - Special register values such as PC and PSR - Backtrace with PC and SP If CONFIG_EXTRA_EXCEPTION_INFO is enabled, then all the above is logged. If not, only the special registers are logged. The format is inspired by the GRMON debug monitor and TSIM simulator. A quick guide on how to use the values is in fatal.c. It now looks like this: E: tt = 0x02, illegal_instruction E: E: INS LOCALS OUTS GLOBALS E: 0: 00000000 f3900fc0 40007c50 00000000 E: 1: 00000000 40004bf0 40008d30 40008c00 E: 2: 00000000 40004bf4 40008000 00000003 E: 3: 40009158 00000000 40009000 00000002 E: 4: 40008fa8 40003c00 40008fa8 00000008 E: 5: 40009000 f3400fc0 00000000 00000080 E: 6: 4000a1f8 40000050 4000a190 00000000 E: 7: 40002308 00000000 40001fb8 000000c1 E: E: psr: f30000c7 wim: 00000008 tbr: 40000020 y: 00000000 E: pc: 4000a1f4 npc: 4000a1f8 E: E: pc sp E: #0 4000a1f4 4000a190 E: #1 40002308 4000a1f8 E: #2 40003b24 4000a258 Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
Reorder Channel Selection Algorithm #2 and Minimum Number of Used Channels Procedure bits. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Proposal.
Signed-off-by: Torsten Rasmussen Torsten.Rasmussen@nordicsemi.no