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:
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.
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?