nuttx
nuttx copied to clipboard
apache
Multiple improvements for stm32wl5 board nucleo-stm32wl5jc
Summary
This pull requests contains multiple commits with improvements for stm32wl5 chip and nucleo-stm32wl5jc board. In short it adds:
- fixes unbuffered IPCC communication
- fixes potential system deadlocks in certain situations when using IPCC
- adds support to boot second CPU during nuttx startup
- adds support to enable IPCC in stm32wl5jc board
- simplifies makefile
- splits Kconfig files into separate files to enhance maintanability and readability of these
More information can be found in commit messages.
Impact
stm32wl5 chip and nucleo-stm32wl5jc - which are work in progress.
Testing
Compilation and running.
@mlyszczek your original Kconfig wasn't too big to motivate split it. Almost all Kconfig inside arch/ is way bigget than these.
@mlyszczek your original Kconfig wasn't too big to motivate split it. Almost all Kconfig inside arch/ is way bigget than these.
@acassis Yes, that is true, for now that Kconfig is not big, and Kconfig in other archs are way bigger. That is exactly why I splitted it now - to avoid a lot of work later. Also, maybe someone will got after my example and will also split these huge Kconfigs in other archs too. Maybe I did split it too much - not much argument from me here I admit. But I strongly belive in splitting these kconfig files. The sooner it's done, the better as less work will be needed later to split it. This Kconfig file will grow, and eventually will be as big as other archs.
You could treat it as proof of concept and kinda like standard proposition for future kconfigs in board/ and arch/
I don't think that splitted Kconfig is a good idea at the moment. STM32 ports are already a complete mess, the maintenance and keeping changes between STM32 ports in sync is a nightmare. If we decide that all STM32 ports should follow this way, then it is OK. Otherwise we should avoid this change. The consistency between STM32 ports should be more important, even if the current solutions are not good.
I could see the benefit for splitting the Kconfig to share IP. Without that gain, it is just more name space that could be subject to misinterpretation and create a bigger problem as it is grown by people with different points of view.
If you can't share the code, the benefit is small to share Kconfig.
I don't think that splitted Kconfig is a good idea at the moment. STM32 ports are already a complete mess, the maintenance and keeping changes between STM32 ports in sync is a nightmare. If we decide that all STM32 ports should follow this way, then it is OK. Otherwise we should avoid this change. The consistency between STM32 ports should be more important, even if the current solutions are not good.
This is not a breaking change. All defines stay the same. Testing it seems simple as well, cat+sort and diff should show only blanks and added "source" lines. There is also not much work, especially if we go with flat structure (at most one kconfig.d/ directory, no extra directories in kconfig.d/), which I start thinking is better anyway - structure of these configs is simple enough and there is no added benefit of extra dirs. I'm still convinced single kconfig.d is better then keeping kconfigs in same dir as C files.
That said, I could split Kconfigs in other stm32 ports.
And I don't really think there will be any order in stm32 ports :) There are too much small changes between chips, even stm32wl5 which is supposed to be stm32l4 + cm0 had differences. I agree, it would be cool to have single and do-not-repeat-yourself drivers for stm32, but there would be tons of #ifdefs, changing anything would trigger anxiety to anyone - because it could break other stm32 ports.
These drivers are written by hobbysts or company that uses specific chip. Both of these groups (and especially the company group) don't want to read stm32f4 and stm32l5 (and tens of other chips) documentation, when they want to fix a bug in stm32f0.
I think it's simply to scary.
And I don't really think there will be any order in stm32 ports :) There are too much small changes between chips, even stm32wl5 which is supposed to be stm32l4 + cm0 had differences. I agree, it would be cool to have single and do-not-repeat-yourself drivers for stm32, but there would be tons of #ifdefs, changing anything would trigger anxiety to anyone - because it could break other stm32 ports.
I don't agree on this. ST uses several versions of IP cores, but the differences within the same IP core version are negligible and usually don't affect the driver implementation. Some amount of #ifdefs still seems better than maintaining 9 separate directories and this number will definitely grow.
These drivers are written by hobbysts or company that uses specific chip. Both of these groups (and especially the company group) don't want to read stm32f4 and stm32l5 (and tens of other chips) documentation, when they want to fix a bug in stm32f0.
That's right and it's understandable, but it isn't good for the project. This approach is also contrary to the INVIOLABLES.md:
90 │ ### No Short Cuts 91 │ 92 │ - Doing things the easy way instead of the correct way. 93 │ - Reducing effort at the expense of Quality, Portability, or 94 │ Consistency. 95 │ - Focus on the values of the organization, not the values of the Open 96 │ Source project. Need to support both. 97 │ - It takes work to support the Inviolables. There are no shortcuts.
Fixing a bug for the same IP core version should be easy and not consuming a lot of time, but the current ST ports organization doesn't help. Personally, I still think that the approach similar to ChibiOS (https://github.com/ChibiOS/ChibiOS/tree/master/os/hal/ports/STM32) or RIOT-OS (https://github.com/RIOT-OS/RIOT/tree/master/cpu/stm32/periph) is a right way to go. But this is a topic for another discussion ;]
but there would be tons of #ifdefs, changing anything would trigger anxiety to anyone - because it could break other stm32 ports.
It already is this way and it is the wrong approach. The code is littered with idef rash and can have endless fix-it-break-it cycles.
The correct approach is versioned IP blocks that can be shared. By using HAS_XXXXX to enable the features not a chip list types. Have a look at https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_sim.h#L35-L57 Having a separate Kconfig dir not a good idea. If it were done correctly the Kconfig lives with driver and is included by the layer above's Kconfig to aggregate the SoC. It is composition.
When the F7 an H7 were added there was a conscious decision to reduce coupling at the expense of code duplication. This is preferred over the mess that the stm32 has grown into.
@mlyszczek could you split Kconfig to a new patch? So, we can merge the uncontested change.