Deploying on the Xilinx Ultrascale+ RPU

Architecture ARM
1

Hi there!
I’ve been trying and failing to deploy to the Ultrascale+ RPU.
I built rtems 6.2 with the Xilinx ZynqMP RPU BSP, specifically the zynqmp_rpu_split_0 variant.
I’m running U-boot on the Cortex-A53 and have been able to use it to load and run u-boot on the Cortex-R5. My goal is to deploy the hello world program built using the Quick Start workflow with waf.
Currently, booting the RTEMS executable from memory fails, even with a disabled dcache.
On the A53 U-Boot I am running the following steps:

ZynqMP> dcache off
ZynqMP> cpu 4 disable               
ZynqMP> tftpboot 20300000 129.247.51.3:hello.exe    
Using ethernet@ff0e0000 device
TFTP from server 129.247.51.3; our IP address is 10.28.11.8; sending through gateway 10.28.11.254
Filename 'hello.exe'.
Load address: 0x20300000
Loading: #################################################################
         #################################################################
         ####
         2.2 MiB/s
done
Bytes transferred = 1954320 (1dd210 hex)
ZynqMP> env set autostart no
ZynqMP> bootelf -p 20300000
ZynqMP> cpu 4 release 40 split                          
Using TCM jump trampoline for address 0x40
R5 split mode

Now the doc on the ZynqMP RPU BSP says to move program sections at ZYNQMP_RPU_RAM_INT_0_ORIGIN and ZYNQMP_RPU_RAM_INT_1_ORIGIN to the TCM:

Note that if the RPU image is started by the Cortex-A53 u-boot, the program sections located at ZYNQMP_RPU_RAM_INT_0_ORIGIN and ZYNQMP_RPU_RAM_INT_1_ORIGIN must be manually relocated from DDR to TCM since the TCMs are not directly available to the Cortex-A53 cores at their Cortex-R5 internal addresses. This can be accomplished by disabling dcache in u-boot and using u-boot’s “cp” command.

However, I cannot find these section names or symbols in the executable using rtems6-nm.
I have additionally made sure that I am able to write to memory using the A53 that is readable to the R5 by disabling dcache. But I cannot figure out what sections I am supposed to move?
I appreciate any input on this ^^

2

In general, there isn’t really a good reason to be running u-boot on the R5 cores. You can do everything you need to from u-boot on the A53 cores.

As far as identifying those sections, they may have changed names recently and the docs may not have gotten the same update.

Here are the u-boot variables I use (or something like what you’d need, tailoring may be necessary):

r5copysections="dcache off; cp.b 0x20000 0xffe20000 0x10000; cp.b 0x0 0xffe00000 0x10000"
r5start="cpu 4 disable; cpu 4 release 0x0 split;"
3

thanks for answering so fast! I really appreciate it.

I think I have managed to identify the new section names: zynqmp_memory_atcm_begin and zynqmp_memory_btcm_begin

Follow up question: do you move the sections of the image before, after or even instead of the bootelf command?

4

In general the flow is:

  • load packed binary into memory somehow (tftp, sd, emmc, nand, nor, etc.) at a high address
  • unpack the packed binary into memory
    • unzip for a raw gz compressed binary
    • bootelf for an elf32 packed application (this requires extra settings, see below)
  • copy sections to TCMA/B
  • start CPU at 0x0

Let me give you the full set of variables I use for booting:

r5start="cpu 4 disable; cpu 4 release 0x0 split"
r5copysections="dcache off; cp.b 0x20000 0xffe20000 0x10000; cp.b 0x0 0xffe00000 0x10000"
r5getbin="tftpboot 0x0 rtems.bin"
r5getelf="tftpboot 0x40000 rtems.exe; setenv autostart no; bootelf -p 0x40000"
r5getgz="tftpboot 0x55000000 rtems.bin.gz; unzip 0x55000000 0x0"
r5tftpsetup="setenv autoload no; dhcp; setenv serverip 192.168.1.89"
r5binboot="run r5tftpsetup; run r5getbin; run r5copysections; run r5start"
r5gzboot="run r5tftpsetup; run r5getgz; run r5copysections; run r5start"
r5elfboot="run r5tftpsetup; run r5getelf; run r5copysections; run r5start;  sleep 0.015; bootelf -p 0x40000; run r5start"

The last 3 commands at the end are the ones you run directly.

I would recommend against the elf boot because it’s quirky for reasons I don’t understand. The uncompressed raw binary boot takes a long time to transfer into memory. That leaves the gz-compressed raw binary boot as the preferred method right now.

1 Like
5

I was able to get it running with your boot variables, thank you so much again!

6

Was there a particular piece you were missing that needs to go in the BSP documentation?

7

I think I was mostly thrown by the different section names (and me trying to use bootelf), so if you want to add something to the docs, I’d adjust/add the new names

8

I’ve created a MR to improve the documentation: Improve ZynqMP RPU documentation (!256) · Merge requests · RTEMS / Documentation / Documentation · GitLab