Device Tree Memory Layout

[KozhinovAlexander]

Currently there is only one SRAM of type "mimo-sram" defined in each *.dts file of each board.
Is it possible to create multiple SRAM segments in SoC and then choose one of them or multiple at same time from *.dts file accordingly?
One of the application fields would be SRAM implementation in STM3H7 series with it's axi-sram, sram0, sram1, sram2... - each of them placed at own (not necessarily comsequtiv) memory address.

[erwango]

@galak what is your point view? How should we start adding new sram areas ?

[KozhinovAlexander]

There are my ideas listed below:

• Each SoC must define at least one SRAM region (e.g. sram0)
• Each SoC can define more than one SRAM regions additionally to sram0 (e.g. sram1, sram2, sram3,...)
• Each board ( BSP ) have to choose at least one SRAM region (e.g. sram0 or sram1 or else). This region must be defined as zephyr,sram in corresponding BSP *.dts file. This SRAM region is obligatory, since at least one SRAM region needed for functionality of Zephyr. The other regions could be defined as zephyr,sram1, zephyr,sram2 etc. in Zephyr device tree.
• Each BSP can choose more than one SRAM region additionally to sram0 (e.g. sram1, sram2,...). This regions must be defined in corresponding SoC.
• The linker script names this regions accordingly and provides linking against sram0 or sramx as name by __attribute((section("sramx"))) for example.

Thus each board can define it's memory as splitter pieces of SRAM's for Zephyr (as sram0) and additional special purposes. This is especially important for STM32H7, where multiple SRAM regions from different domains (D1, D2, D3) are presented and depending on usage can have impact on performance/implementation.

[galak]

There are examples already like the nxp_lpc55S6x_common.dtsi in which we have multiple SRAM regions defined in the DTS. That is pretty straight forward to support. We can select which memory region to use via zephyr,sram & optionally (zephyr,code-partition).

the more complicated scenarios come into play if we want to utilize multiple regions and how that would work. Less from a DTS point of view, but more on how we interpret the data.

[KozhinovAlexander]

There are examples already like the nxp_lpc55S6x_common.dtsi in which we have multiple SRAM regions defined in the DTS. That is pretty straight forward to support. We can select which memory region to use via zephyr,sram & optionally (zephyr,code-partition).

the more complicated scenarios come into play if we want to utilize multiple regions and how that would work. Less from a DTS point of view, but more on how we interpret the data.

Does Zephyr already has documentation for zephyr,code-partition usage?

[galak]

Does Zephyr already has documentation for zephyr,code-partition usage?

there's a little bit of docs at https://docs.zephyrproject.org/latest/reference/devicetree/index.html

[erwango]

@galak txs for feedback, I though this was blocked for some reason.

[KozhinovAlexander]

@galak What do you mean under data interpretation?
As a first step I would suggest just named sections in splitted SRAM regions for use as a named section in code.
Then they can be used as __attribute(section("sectionName")) in code.

[galak]

@galak What do you mean under data interpretation?
As a first step I would suggest just named sections in splitted SRAM regions for use as a named section in code.
Then they can be used as __attribute(section("sectionName")) in code.

I just mean we already produce defines for the various memory regions.

If there are more than one SRAM region, how would you like to utilize them?

[KozhinovAlexander]

If there are more than one SRAM region, how would you like to utilize them?

Using scenario:

1. Giving a name to each SRAM region (e.g. "my_sram_region_name_1" )
2. Using it within __attribute(section("my_sram_region_name_1")) for static variables.
3. Placing complete *.o files there should stay optional.

I just mean we already produce defines for the various memory regions.

Do I understand it right that my using scenario from above can be covered by produced defines?

@galak What are your ideas for more than one SRAM regions utilization?

[SpooniSpoon]

@Nukersson Could you solve this issue? I try to use SRAM3 of H743 to solve D cach issues.

Thank you for your question. Take a look here. This is solution currently not merged into main branch, cause there are multiple additional improvement suggestions how to handle it in Zephyr. But the code seems to work.

[SpooniSpoon]

Thanks for the hint I will give it a try

[KozhinovAlexander]

Thanks for the hint I will give it a try

Please feel free to point on needed improvements and add your own commits.