On Fri, Mar 26, 2021 at 4:26 AM David Sidrane <david.sidr...@nscdg.com> wrote: > As you have noted checking at build time only works for in tree > configurations. The quick fix to add an CONFIG_..._EXCLUDE_SRAM4... (naming > TBD) and light it in things that select BDMA to SRAM4 would a good to > addition, and help in some cases, but selecting it just on BDMA could be > wasteful. > Maybe that is just a warning if SRAM4 is added to the heap when BDMA is > enabled. > > These more complex muti-power domain Soc, require more floor planning of > resource allocation on the board designer and users part. > > I think a more flexible approach is would be to rework the heap addition > logic to be selectable and orderable. > > Then a board designer can choose to add the RAM blocks to the heap and order > them as desired. > > CONFIG_...ADD_ORDER_SRAM > CONFIG_... ADD_ORDER _SRAM12.. > CONFIG_... ADD_ORDER _ SRAM3.. > CONFIG_... ADD_ORDER _SRAM4.. > CONFIG_... ADD_ORDER _DTCM.. > > (naming TBD) > > 0 is not used. 1 first added, N last added. > > This gets defined into an array with the start addresses and lengths. The > code then processes them in a loop until all are added.
In concept, I like this idea. Before implementing it, I'd like to try the linker/sram_reserve idea discussed with Greg, and create a PR for that, to solve the immediate problem. Afterwards, we should talk about reworking the heap logic to allow better customization of the order and include/exclude options through Kconfig. > I spent quite a bit of time mulling over using the granual allocator and > placing the buffers in the drivers. My conclusion was this: > For the granual allocator you have to give it the static memory large enough > to meet ALL demand. (this creates a runtime size dependency the user has to > manage) After init, the memory will be given out to the drives and that is > dependent on device messages sizes (i.e MAX SPI payload which is for the > most part static, unless you have PNP SPI) So once the memory is allocated > out, it is the same as the static allocation of buffers in the drivers. It > is more code, more complexity, can fail at run time for out of memory or > DMA/Dcache alignment reasons. The compiler telling you SRAM4 is full is a > lot easier to debug :) Agreed; failing as early as possible is best. I consider myself very lucky that my overlapping heap/buffers crashed NSH right at the start and made me aware of the problem right away. Having the compiler or linker tell you at build time is even better. :-) Cheers, Nathan
