RZ-G/RZ-G2 Update Trusted-firmware and U-boot Under Linux: Difference between revisions

From Renesas.info
No edit summary
No edit summary
Line 27: Line 27:
From the release note document, we can get the offset information(the '<nowiki/>'''Address to save to ROM'''' column).
From the release note document, we can get the offset information(the '<nowiki/>'''Address to save to ROM'''' column).
[[File:g2l-qspi-offset.png|left|thumb|795x795px]]
[[File:g2l-qspi-offset.png|left|thumb|795x795px]]





Revision as of 11:01, 4 January 2022

Introduction of the two updating methods

There are two ways to update the Trusted-firmware(TF) and U-boot.

The first way is using the builtin commands of flashwriter-tool to download TF and U-boot images(.srec format only) to RAM and then write them to the bootable devices(eMMC or QSPI-Flash). It works at SCIF download mode. This way is introduced in the startup guide inside BSP release's documents, which will not be described in detail in this page. The advantage of this way is that it can be used for any board, especially for the new board with empty bootable device. But there are disadvantage for this way. For example, it's very solw because in the SCIF download mode, data is transferred via UART port with 115200bps. And user must manually input some data or select some files for each board during updating process.

The second way will be described in detail in this page. This way is updating the TF and U-boot images(.bin, raw binary format only) under Linux. It's accomplished via very common commands such as dd, flash_eraseall, cat and so on. So it's very fast and the commands can be written into a shell script which can be run automatically after boot into Linux. But the disadvange is that this way can't work for the first new board with an empty bootable device. For these kinds of boards, you must use the first way described above.

Customer support

Customers don't want to use the first way only because of the disadvantages of this way. They prefer to use the two ways at the same time. RZ/G series MPUs support to use QSPI flash and eMMC as boot devices. Typically the eMMC is used as the main boot device for customer's products. Customer can make a small board with a QSPI flash only. This small board can be plugged into or out from the main board(board for end user). It just acts as a bootable USB disk whic can be used to install the whole system to an PC's harddisk.

Typical usage steps:

  1. Plug in the empty QSPI flash board into main board and switch to SCIF download mode.
  2. Use the first way to update the empty QSPI flash board(the kernel, dtb and rootfs should also be written under U-boot).
  3. Switch to SPI boot mode.
  4. Boot into Linux.
  5. Update the eMMC boot device on the board. Everything needed by the eMMC can be updated, including TF/U-boot/kernel/dtb/rootfs because the real boot device now is the QSPI flash and these files can be compressed and stored into QSPI flash first.
  6. Switch to eMMC boot mode.
  7. The main board is ready.

Of course the images in the QSPI flash can also be updated if necessary at step 5, self-update. Customer can also update an empty QSPI flash board's content after boot into Linux from eMMC boot mode. So customer only need to use the first way to update an empty QSPI flash boad once, then every board can be updated under Linux.

Updating detail in the second way

After boot into Linux, you should prepared the binary format of TF and U-boot. We can't use the srec format because the common Linux based commands can't interpret or recognize s-record format unliky the builtin commands inside Flashwritter. We only need to know the offset inside the boot device to store the binary file and then write the binary from the offset. The boot ROM only needs the offset inside the boot device.

RZ/G2L: QSPI flash updating

From the release note document, we can get the offset information(the 'Address to save to ROM' column).

g2l-qspi-offset.png






The 0x00000 and 0x1D200(=512x233) are the offsets from the QSPI flash memory base. We can make an image first and then write the image into /dev/mtd0.

dd if=/dev/zero of=boot.img bs=1024 count=1024

dd if=bl2_bp.bin of=boot.img conv=notrunc

dd if=fip-smarc-rzg2l.bin of=boot.img conv=notrunc bs=512 seek=233

flashcp -v boot.img /dev/mtd0

RZ/G2L: eMMC updating

From the release note document, we know that the TF and U-boot are written into Boot0 area of eMMC. The sector offsets are 1 and 256 with sector size 512. The EXT_CSD registers are also needed to be setup according to the document.

  • Step 1: Setupt the EXT_CSD registers using mmc-utils(an open source tool). Execute once because the register area is non-volatile memory type.

mmc bootpart enable 1 0 /dev/mmcblk0 # enable the first boot-area for boot, no ack

mmc bootbus set single_backward x1 x8 /dev/mmcblk0 # setupt the boot bus config

  • Step 2: Write binary to the boot area

echo 0 > /sys/block/mmcblk0boot0/force_ro # disable the soft write-protect based on Linux, reset after reboot

dd if=bl2_bp.bin of=/dev/mmcblk0boot0 bs=512 skip=0 seek=1

dd if=fip-smarc-rzg2l.bin of=/dev/mmcblk0boot0 bs=512 skip=0 seek=256

RZ/G2E|M|N|H:

The basic scheme for these MPU types is the same as RZ/G2L. The differences are that the TF may contain several binary files with different offsets or boot areas.