STM32H745 SRAM Sections Definition

[KozhinovAlexander]

Define multiple SRAM sections within sram0. With this PR each stm32h745 based board can use either whole sram0 (choose zephyr,sram = &sram0;) or only parts of it (choose zephyr,sram = &ahb_sram1; for example).
This step is necessary toward whole SRAM utilization for projects.

Same behavior for SRAM realized in linux kernel.

[gmarull]

These changes do not follow Linux Kernel docs. In their model, SRAM entries are children with relative addresses, I can't see this structure here neither updated bindings. A use case should also be provided.

[KozhinovAlexander]

@gmarull Thank you for your review. I've prepared changes. Please take a look.

These changes do not follow Linux Kernel docs. In their model, SRAM entries are children with relative addresses, I can't see this structure here neither updated bindings.

Fixed. Please see dts/arm/st/h7/stm32h745.dtsi within latest push.

A use case should also be provided.

You cane take a look at boards/arm/nucleo_h745zi_q/nucleo_h745zi_q_m4.dts for sample usage.

But generally following use case are possible now:

1. Choose whole sram0 with 864KiB size for stm32h745:

chosen {
zephyr,sram = &sram0;
};

2. Choose whole ahb_sram2 with 128KiB size for stm32h745 as part of sram0:

chosen {
zephyr,sram = &ahb_sram2;
};

Other use cases are similar to 1 and 2. Both were tested with my nucleo_h745zi_q board and civetweb/websocket_server sample and working fine for me.

[ABOSTM]

LGTM

[galak]

For now i'd suggest carving out the sram region for ethernet and putting a phandle property in the ethernet node that references that sram region.

As far as the other regions go, are you trying to treat them as on large system memory pool? If so, for now we have to fake that out in DTS.

[KozhinovAlexander]

@galak Thak you for your review

For now i'd suggest carving out the sram region for ethernet and putting a phandle property in the ethernet node that references that sram region.

I would prefer to wait with merge instead, untill we're done wit MPU SRAM #30403 configuration for ethernet. I will be able update this PR continuously.

As far as the other regions go, are you trying to treat them as on large system memory pool? If so, for now we have to fake that out in DTS.

Yes, the purpose of this PR to give access to all SRAM regions of the Zephyr application, if it needs it. Do you have an example, how to fake it out in DT?

[KozhinovAlexander]

@erwango Can you confirm this memory model works on your board (for example with hello_world and/or civetweb webscoket server)?

[KozhinovAlexander]

@gmarull Please review

[gmarull]

mmio-sram compatible does not specify ranges as a property nor child bindings (here we have a parent and a child with the same compatible). I think this needs more discussion as well as proper support in Zephyr, not just definitions.

[KozhinovAlexander]

mmio-sram compatible does not specify ranges as a property nor child bindings (here we have a parent and a child with the same compatible). I think this needs more discussion as well as proper support in Zephyr, not just definitions.

Where can it be better discussed?

[gmarull]

@Nukersson #dev-review meeting

[galak]

Is there a need to have these as one node v separate nodes for each SRAM ?

[KozhinovAlexander]

Is there a need to have these as one node v separate nodes for each SRAM ?

With this approach I am able to use all SRAM sections of H7 together.

[galak]

My initial feeling is that I'd suggest that be done as a board specific setting of CONFIG_SRAM_SIZE/CONFIG_SRAM_BASE_ADDRESS. I'm concerned about the precedence set of describing multiple SRAM regions this way and what assumptions one can really make.

What are you pointing zephyr,sram at in the case you are using all the SRAM sections together?

[KozhinovAlexander]

My initial feeling is that I'd suggest that be done as a board specific setting of CONFIG_SRAM_SIZE/CONFIG_SRAM_BASE_ADDRESS. I'm concerned about the precedence set of describing multiple SRAM regions this way and what assumptions one can really make.

What are you pointing zephyr,sram at in the case you are using all the SRAM sections together?

Compiling samples/hello_world with zephyr,sram = &axi_sram; gives:

[129/136] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       16580 B         1 MB      1.58%
            DTCM:          0 GB       128 KB      0.00%
            SRAM:        4512 B       512 KB      0.86%
        IDT_LIST:         120 B         2 KB      5.86%
[136/136] Linking C executable zephyr/zephyr.elf

and with zephyr,sram = &sram0; gives:

[129/136] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       16580 B         1 MB      1.58%
            DTCM:          0 GB       128 KB      0.00%
            SRAM:        4512 B       864 KB      0.51%
        IDT_LIST:         120 B         2 KB      5.86%
[136/136] Linking C executable zephyr/zephyr.elf

Especially see difference in Region Size of SRAM section.

Thus my approach still allows using of each separate SRAM section within the whole SRAM.

[galak]

Thanks.

I still see this as an application specific need and not a generic solution. It just happens that all the SRAM regions are contiguous so things work out that way.

In addition, the way you are using ranges + reg is technically in violation of DTS. If you have a range the node that has that shouldn't have a reg that overlaps that range region. Since you are effectively claiming 2 different device nodes for the same reg region than.

[KozhinovAlexander]

Ok. I see your point. Thank you very much. But how would you put different memory banks of some SoC with non-consequtive memory addresses together? Would you use device-tree or linker skript?
The application would be best utilization of all memory banks of some SoC like stm32h743/5

[galak]

Current solution is not generic enough. Makes assumptions about SRAM regions being contiguous which may not be valid on all platforms with multiple SRAM regions.

Would rather see something on the linker side that tries to take all the 'mmio-sram' regions from DTS and coalesce them. Or support multiple different memory regions in the core of Zephyr.

[KozhinovAlexander]

Closed since not generic