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.
../../../_images/SRAM.png

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.
../../../_images/DRAM.png

Default RZ/G2L Memory Map in the BSP

There is a reserved area for the CM33 firmware code defined below the Linux area:

../../../_images/memory-map.png

Deploying the firmware to the target

After building the sample with e² studio, 4 binary files will be generated:

  • rzg2l_cm33_rpmsg_demo_non_secure_code.bin
  • rzg2l_cm33_rpmsg_demo_non_secure_vector.bin
  • rzg2l_cm33_rpmsg_demo_secure_code.bin
  • rzg2l_cm33_rpmsg_demo_secure_vector.bin

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

please note:

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.