mcuboot
mcuboot copied to clipboard
mcu-tools
Fix nordic boards
Not doubting this fixes the issue of these 3 boards, but it doesn't seem like it resolves the root issue. Put another way, if I duplicated the board with a new name the same issue would appear again.
If the bootloader is failing to compile because USB requires multithreading, doesn't that mean either MCUboot shouldn't be disabling multithreading OR the board shouldn't always be enabling USB?
Put another way, if I duplicated the board with a new name the same issue would appear again.
That's the same as if you duplicated any board for any sample in the whole of zephyr that has an overlay and you didn't copy the overlay. If you duplicate a board and want to run a sample that worked on the original board, you need to copy the overlay. The bug here was that there boards should have had overlays to begin with which this PR addresses.
If the bootloader is failing to compile because USB requires multithreading, doesn't that mean either MCUboot shouldn't be disabling multithreading OR the board shouldn't always be enabling USB?
The USB only refers to thingy53 since the rest are GPIO/SPI NOR drivers, and for thingy53 the configuration was added originally then it was removed and moved to ncs:
https://github.com/mcu-tools/mcuboot/pull/1122 https://github.com/mcu-tools/mcuboot/pull/1515
The original addition was wrong because it never worked in zephyr anyway and should have contained the overlay in this PR.
That's the same as if you duplicated any board for any sample in the whole of zephyr that has an overlay and you didn't copy the overlay. If you duplicate a board and want to run a sample that worked on the original board, you need to copy the overlay.
Agreed.
The bug here was that there boards should have had overlays to begin with which this PR addresses.
IMO this comes down to which situation we prefer:
MULTITHREADING=n, every board that has external flash requires a patch tomcubootMULTITHREADING=y, boards don't need patches to work, optimizations can still be enabled for those who want them.
I am just making the argument that already exists on the option: https://github.com/mcu-tools/mcuboot/blob/9ae634f3bfeb99111b0ceda26f4b4ba6f87d4c12/boot/zephyr/Kconfig#L745-L748
We are not in the first situation. We are instead sure that hardware does NOT work, as evidenced by the issue existing. If individual boards want to disable multithreading to get ROM savings, it is trivial to do so in the board definition.
The actual issue is that some drivers need semaphore/mutexes which thus need multithreading, some can use them optionally if the option is enabled, and some don't use it at all. Drivers started selecting things instead of depending upon them, so the question really should be why do drivers that require multithreading not select it?