Running the rpmsg demo sample from Renesas¶
To understand how the loading of the firmware works, a deeper knowledge of the RZ/G2L memory is necessary:
SRAM (internal RAM)¶
- The RZ/G2L processors have two banks of internal RAM with 64 kbyte each.
- Both memory banks are accessible from the Cortex®-A55 core, as well as the Cortex®-M33 core.
- The Cortex®-M33 core has different address spaces for Secure- and Non-Secure access.
DRAM (external RAM)¶
- The DDR address space is different for the Cortex®-A55 and Cortex®-M33.
- The Cortex®-M33 can access only the lower 256 MByte of the DRAM.
- The Cortex®-M33 has different address spaces for Secure and Non-Secure accesses.
Default RZ/G2L Memory Map in the BSP¶
There is a reserved area for the CM33 firmware code defined below the Linux area:
Deploying the firmware to the target¶
After building the sample with e² studio, 4 binary files will be generated:
To start the firmware, we have to deploy it first to the target’s memory. That could be basicly, the internal emmc device of the SOM or the SD-card of the base board. The following example shows, how to deploy the firmware to the internal emmc device.
After building the yocto Linux and programming it with the uuu-tool to the target, we can examine the programmed partitions inside u-boot:
mmc dev 0 mmc part
Partition Map for MMC device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000800 0x000107ff "boot" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 69024680-ec4f-4b41-87af-4d3a351a047b 2 0x00010800 0x00747bff "rootfs" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 97e9f2b4-97d3-4fd1-a9ef-195cf30d6b5f
The “boot”-partition contains the Linux- image and device trees. To store the firmware binary into that partition we use the USB Mass Storage u-boot function to mount that partition to our Linux host PC:
ums 0 mmc 0:1
Now you can mount the boot - partition on your local PC and copy the 4 files on it. After unmounting the partition, stop the ums-device with Ctrl-C in the u-boot.
List the contents of the boot-partition from u-boot to check it:
ls mmc 0:1
<DIR> 1024 . <DIR> 1024 .. <DIR> 12288 lost+found 15110152 Image 39041 bl2-txrz-g2l1.bin 24681 bl31-txrz-g2l1.bin 37923 r9a07g044l2-txrz-g2l1-cm33.dtb 42799 r9a07g044l2-txrz-g2l1-mb7.dtb 37240 r9a07g044l2-txrz-g2l1.dtb 736214 u-boot.bin 64 rzg2l_cm33_rpmsg_demo_secure_vector.bin 392 rzg2l_cm33_rpmsg_demo_secure_code.bin 1984 rzg2l_cm33_rpmsg_demo_non_secure_vector.bin 42468 rzg2l_cm33_rpmsg_demo_non_secure_code.bin
Starting the firmware¶
With the firmware files stored in the boot partition of the eMMC, they can be loaded from u-boot with the following commands:
dcache off mmc dev 0 load mmc 0:1 0x0001FF80 rzg2l_cm33_rpmsg_demo_secure_vector.bin load mmc 0:1 0x42EFF440 rzg2l_cm33_rpmsg_demo_secure_code.bin load mmc 0:1 0x00010000 rzg2l_cm33_rpmsg_demo_non_secure_vector.bin load mmc 0:1 0x40010000 rzg2l_cm33_rpmsg_demo_non_secure_code.bin cm33 start_debug 0x1001FF80 0x00010000 dcache on
The CM33 command specifies the addresses of the secure- and not-secure vector files in memory. The command stores them into the SYS_CM33_CFG2 and SYS_CM33_CFG3 registers respectively, before the Cortex®-M33 is started. These are the addresses seen from the Cortex®-M33, not the load addresses from u-boot.