kv260_r5 build has strange memory output

[wmamills]

@tnmysh I am building the kv260_r5 board from examples/zephyr/examples/zephyr/rpmsg_multi_services

There are a few things that look strange to me. Can you please investigate.

[138/143] Linking C executable zephyr/zephyr_pre0.elf
/home/bill/top/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: warning: **orphan section .resource_table' from zephyr/libzephyr.a(resource_table.c.obj)' being placed in section .resource_table'** [143/143] Linking C executable zephyr/rpmsg_multi_services.elf /home/bill/top/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: warning: orphan section .resource_table' from zephyr/libzephyr.a(resource_table.c.obj)' being placed in section .resource_table'
Memory region Used Size Region Size %age Used
FLASH: 0 GB 32 MB 0.00%
RAM: 43524 B 64 MB 0.06%
OCM: 0 GB 256 KB 0.00%
IDT_LIST: 0 GB 2 KB 0.00%

1. Is the resource table being placed somewhere reasonable? Why the warning? I don't get that warning on stm32mp157c_dk2

2. Those FLASH and RAM sizes should be KB not MB. I presume FLASH and RAM are TCM right now correct? I would think they would be 64K and 64K in the universal binary case or for either split mode. For lockstep they should be 128K and 128K.
   This assumes TCM A is used for code and TCM B is used for RAM which would be a reasonable default. (Might have the specifics of the TCM names wrong but hopefully you understand.)

[tnmysh]

@wmamills I looked into this.

1. For resource table:

ST has this linker script: soc/arm/st_stm32/stm32mp1/linker.ld. It explicitly mentions resource table section. On Xilinx similar script is available -> soc/arm/xilinx_zynqmp/linker.ld. If I copy over resource table part from ST linker script, I don't see above warning. I think if I don't put that code in linker script, compiler does that for us and generates warning. I checked objdump of final elf file and found out that compiler puts resource table at 0xa758 address, I think it should be fine. I will create patch to avoid warning for any zynqmp platforms.

2. About RAM and FLASH memory.

I think the way zynqmp dts files are created that has problem. There are few dtsi files:

zynqmp.dtsi: ./dts/arm/xilinx/zynqmp.dtsi
zynqmp_rpu.dtsi: ./dts/arm/xilinx/zynqmp_rpu.dtsi

I believe zynqmp.dtsi was designed for cortex-A cores. Ideally zynqmp_rpu.dtsi should have been independent include file that should contain its own flash and RAM nodes. But instead in current zephyr, zynqmp_rpu.dtsi includes zynqmp.dtsi and derives flash and RAM nodes.

So, when r5 overlay in system-reference includes zynqmp_rpu.dtsi it has flash and RAM sizes in MB.

I don't know why it was designed like that, but I thought I might break current compatibility for anyone using in this format. So, I didn't change it.

I believe this requires its own PR and separate patch.
I wanted to resolve this in a way where each Xilinx board has its own independent base dtsi for cortex-A, and cortex-R in lockstep and split mode. But that is something I will take care later.

[wmamills]

@uLipe you added kv260_r5 to upstream zephyr. Did flash and RAM show as MB then?

I have looked at the final map and FLASH is running from TCM A at 0 and is shown as 64KB in the map.
The RAM is using some high address (not TCM B) and is 256KB.
I don't know where west / cmake is getting the MB sizes from.

FLASH 0x0000000000000000 0x0000000000010000 xr
RAM 0x0000000010000000 0x0000000000040000 xw

I have to reboot my computer before I can see where that RAM address is ...

[tnmysh]

flash0 and sram0 labels are defined in zynqmp.dtsi. Probably from there.

[wmamills]

@tnmysh
So the RAM address that is used (0x1000_0000) is the 256MB offset in DDR with a size of 256K.
That area of DDR is NOT reserved in the DTS files checked into openamp-system-reference.
What are you testing this with?

[tnmysh]

That dts is tested with kv260 qemu. I am trying with hardware now.

[wmamills]

@tnmysh what have you found? Can I get the DTB you are using for kv260 please? You can check it into your fork of openamp-system-reference if you wish. We will want it there evetually in one form or another like we have for zcu102.

So if what you are saying is true then the memory carve outs for zcu102 and kv260 are very different. That is unfourtunate as from the R5 POV they should be much the same if you ignore which UART to use etc. W/O UART we could make R5 images that would work for both zcu102 AND kv260 if the memory careouts were similar.

[tnmysh]

@wmamills memory carveouts are same. This is rpu0_ipc_shm: memory@3ed40000 { where I mention memory carveouts.

I have opened another issue to discuss zcu102 and kv260 dts: #27

[wmamills]

@tnmysh yes that is the rpmsg related carve out and that is good.

I was talking about the definition of RAM at the zephyr level. I see now that I had confused myself over the weekend.
The zephyr definitions for FLASH and RAM are still problematic but at least I now see they are consistent.

For both qemu_cortex_r5 and for kv260_r5 the memory looks like this:
FLASH 32MB at 0xc000_0000 QSPI XIP (SHOULD NOT BE USED)
RAM 64MB at 0 (Mix of TCM and DDR based on R5 mode and size used)

Right now a build of rpmsg_multi_protocol or zephyr's hello_world are < 64K so will fit in TCM in all modes.

If we only consider lock step mode the TCM limit is 256K. Anything bigger than that will start using DDR and could interfere with Linux's use of DDR.

The limit for split mode is much smaller at just 64K.

This needs to be fixed upstream in Zephyr but we could make a local fix in rpmsg_multi_protocol in the DTS overlay for now.
I will take a look at this.

[wmamills]

I have added PR #29 for this.