• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 552 subscribers
  • Views 255 views
  • Users 0 members are here
Options
Related

RZ/G2M: Recovery mechanism for SWU of BL and u-boot

Sid

Hello Experts,

I am working on RZ/G2M VLP v3.0.6 for the SWU (Software Update) feature for bootloaders (BL) and u-boot.

Steps completed so far:

  • Enabled MTD partitions for each BL and u-boot.
  • Assigned MTD partitions for each stage.
  • Performed SWU on the respective MTD partitions.

SWU works for successful scenarios, it erases the existing image and rewrites a newer one.
However, I am unable to find any documentation for the dual copy approach (recovery mechanism) in cases where the board is powered down and rebooted during SWU.

To better understand the boot process of RZ/G2M, I have studied the trusted-firmware-a source for the RZ/G2M.

Based on my understanding:

The rzg_layout_create folder, located in the tools/renesas directory, is responsible for creating the layout.
A Makefile in this directory compiles two source files: sa0.c and sa6.c.

  • sa0.c generates bootparam_sa0.srec.
  • sa6.c generates cert_header_sa6.srec.

The memory locations for loading BL2, BL31, and BL33 (u-boot) are defined in sa6.c.

By modifying these addresses, the binaries can be instructed to load from the updated locations in QSPI.

I have some queries regarding this and please correct me if I’m wrong:

1. I am still unable to identify where the QSPI flash addresses 0x000000 (for bootparam_sa0.srec) and 0x180000 (for cert_header_sa6.srec) are defined in the source code and how they are fetched from QSPI.

2. How will the bootloader know from which addresses it should be loaded in the case of a successful update and in the case of failure? (It may involve modifying addresses in sa6.c.)

3. Where can I handle the failure and update scenarios in trusted firmware-a?

Parents Reply Children
  • 0 in reply to PT_Renesas

    Hii  

    Thanks for the quick reply.

    PT_Renesas said:
    1. From this table you can see the QSPI and execution addresses. 

    I have checked the table in the attached link. It appears to be for RZ/G2L, while I am working on RZ/G2M.


    PT_Renesas said:
    3. Do you want to update BL2, BL31 and u-boot?

    The updates for BL2, BL31, and U-Boot were performed successfully by following the steps mentioned in the "Update Trusted Firmware and U-Boot Under Linux".

    However, how can I implement dual copies for BL2, BL31, and U-Boot ?

    For example:

    If BL2 is stored at location X and, after an update it is saved at location Y, how can we configure the system to jump to location Y so that BL2 is loaded from there ?
    Additionally, if BL2 cannot be loaded from location Y, it should automatically fall back to load from location X.
    Is it possible to do ?