Add MG_ETH_RAM to MG_ARCH_CUBE

[cpq]

No description provided.

[cpq]

Gentle nudge !

[scaprile]

I remember commenting on this, though I can't find that here nor in the chat (?)
This can't be done, there is no .eth_ram section in the Cube linker files; in fact, they don't use a linker section for that at all.
I also remember grepping Cube stuffs and pasting the proof for that...
Cube simply does not work this way.
My suggestion was to simply drop this PR.

EDIT: then I went on to submit a review and there it was... maybe I forgot to send and changed computers... sorry about that.

[scaprile]

I suggest to close this PR, it will break all Cube code

• eth_ram is not a standard Cube stuff, it is our invention for special circumstances under special conditions in certain scenarios, it does NOT exist in the Cube linker files. but in our README, where we suggest how to do that.
• Cube DOES NOT have a standard allocation, that is the reason why we haven't done this before, and why we instruct to use mongoose_config

$ grep -Rl eth_ram back/templates/*/CubeIDE/*/*
back/templates/f207/CubeIDE/baremetal/README.md
back/templates/f207/CubeIDE/FreeRTOS/README.md
back/templates/f429/CubeIDE/baremetal/README.md
back/templates/f429/CubeIDE/FreeRTOS/README.md
back/templates/f439/CubeIDE/baremetal/README.md
back/templates/f439/CubeIDE/FreeRTOS/README.md
back/templates/f746/CubeIDE/baremetal/README.md
back/templates/f746/CubeIDE/FreeRTOS/README.md
back/templates/f756/CubeIDE/baremetal/README.md
back/templates/f756/CubeIDE/FreeRTOS/README.md
back/templates/f767/CubeIDE/baremetal/README.md
back/templates/f767/CubeIDE/FreeRTOS/README.md
back/templates/h563/CubeIDE/baremetal/README.md
back/templates/h563/CubeIDE/FreeRTOS/README.md
back/templates/h573/CubeIDE/baremetal/README.md
back/templates/h573/CubeIDE/FreeRTOS/README.md
back/templates/h723/CubeIDE/baremetal/README.md
back/templates/h723/CubeIDE/FreeRTOS/README.md
back/templates/h735/CubeIDE/baremetal/README.md
back/templates/h735/CubeIDE/FreeRTOS/README.md
back/templates/h743/CubeIDE/baremetal/README.md
back/templates/h743/CubeIDE/FreeRTOS/README.md
back/templates/h745/CubeIDE/baremetal/README.md
back/templates/h745/CubeIDE/FreeRTOS/README.md
back/templates/h753/CubeIDE/baremetal/README.md
back/templates/h753/CubeIDE/FreeRTOS/README.md
back/templates/h755/CubeIDE/baremetal/README.md
back/templates/h755/CubeIDE/FreeRTOS/README.md
back/templates/h7s3l8/CubeIDE/baremetal/README.md
back/templates/portenta-h7/CubeIDE/baremetal/README.md
back/templates/u5a5/CubeIDE/baremetal/README.md

[scaprile]

Built with that change.
As there is no reference to .eth_ram anywhere in the linker file, it gets caught (somehow) into .bss

F746
$ arm-none-eabi-objdump -x f746/Debug/f746.elf | grep s_rxdesc
200003dc l     O .bss	00000040 s_rxdesc
$ arm-none-eabi-objdump -x f746/Debug/f746.elf | grep s_rxbuf
2000045c l     O .bss	00001810 s_rxbuf
$ arm-none-eabi-objdump -x f746/Debug/f746.elf | grep s_txno
2000347c l     O .bss	00000001 s_txno
H563
$ arm-none-eabi-objdump -x h563/Debug/h563.elf | grep s_rxdesc
200003a0 l     O .bss	00000080 s_rxdesc
$ arm-none-eabi-objdump -x h563/Debug/h563.elf | grep s_rxbuf
200004a0 l     O .bss	00001880 s_rxbuf
$ arm-none-eabi-objdump -x h563/Debug/h563.elf | grep s_rxno
200035a8 l     O .bss	00000004 s_rxno
H723
$ arm-none-eabi-objdump -x h723/Debug/h723.elf | grep s_rxdesc
240003a0 l     O .bss	00000080 s_rxdesc
$ arm-none-eabi-objdump -x h723/Debug/h723.elf | grep s_rxbuf
240004a0 l     O .bss	00001880 s_rxbuf
$ arm-none-eabi-objdump -x h723/Debug/h723.elf | grep s_rxno
240035a8 l     O .bss	00000004 s_rxno
H743
$ arm-none-eabi-objdump -x h743/Debug/h743.elf | grep s_rxdesc
240003a0 l     O .bss	00000080 s_rxdesc
$ arm-none-eabi-objdump -x h743/Debug/h743.elf | grep s_rxbuf
240004a0 l     O .bss	00001880 s_rxbuf
$ arm-none-eabi-objdump -x h743/Debug/h743.elf | grep s_rxno
240035a8 l     O .bss	00000004 s_rxno

• For the F7, Eth buffers are placed in DTCM, OK
• For the H5, we should be using SRAM3 (320K@0x20050000) , but Cube uses SRAM1; can't test if it actually works
• For the H7, we must use SRAM1 (16K@0x30000000) or SRAM2 (contiguous) , we're not; Cube places Eth buffers and descriptors in AXI RAM, not reachable by the Eth controller.

[scaprile]

What I've been trying to state is that

• defining a memory region name is worse than useless (misleading) unless that region is also defined in the linker file.
• Cube has no specific memory region for Eth buffers, they don't work that way
• the linker file is generated at build time from the config

[cpq]

"defining a memory region name is worse than useless (misleading) unless that region is also defined in the linker file." - I don't agree with that at all.

By NOT defining it, we expect users (who are mostly totally clueless - see plenty of questions on st.com that stem from that linker script issue) to define both.

By defining it, we state that the buffers are assigned to that named section which by default it not placed anywhere, and must be placed in the linker script. So users should to one thing, not two.

[scaprile]

By defining it, we state that the buffers are assigned to that named section which by default it not placed anywhere, and must be placed in the linker script. So users should to one thing, not two.

That is a very good point if there is some place where we say so. Otherwise I bet people will most likely assume it has been already setup. (that's why I hold that it is misleading)
Where can we add such a notice ?