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 built-in commands of the 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 using the SCIF Download Mode boot mode of the device. 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 method is that it can be used for any board, especially for the new boards with empty bootable devices. But there are disadvantage for this method. For example, it's very slow because when using SCIF Download Mode, data is transferred via UART port at 115200bps. And, the user must manually input some data or select some files for each board during updating process.

The second method will be described in detail in this page. This method is updating the TF and U-boot images (.bin, raw binary format only) under Linux. It's accomplished using 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 disadvantage is that this method cannot work with new boards with an empty bootable device. For these kinds of boards, you must use the first method described above.

Using an External SPI Flash Board for Temporary Linux Boot

Users do not want to use the first method only because of the disadvantages of this method (speed or programming). They prefer to use the two methods at the same time. RZ/G series MPUs support the use of QSPI flash and eMMC as boot devices. Typically the eMMC is used as the main boot device for products. Product developers can make a small board with only a QSPI flash mounted on it. This small board can be plugged into the main product board. Using this type of temporary boot device is similar to how a PC can boot from a bootable USB flash drive and then be used to install used to install the whole OS system to an PC's hard disk.

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.
  3. Switch to SPI boot mode.
  4. Boot into U-boot command line.
  5. Download kernel, dtb and initrd to RAM or set to nfs boot mode.
  6. Boot into Linux by proper U-boot command.
  7. Update QSPI flash with proper kernel/dtb/rootfs images if users do not want to use nfs boot each time. This rootfs image should contain all the images for an empty eMMC.
  8. Reset and boot into U-boot command line and set boot parameters properly.
  9. Reset and boot into Linux.
  10. 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 images had been compressed and stored in QSPI flash in step 7. Or user can load these images from SD/USB/network for the small capacity QSPI flash(low cost).
  11. Switch to eMMC boot mode.
  12. The main board is ready.

After step 8, the QSPI flash board is ready. Developers can also update an empty QSPI flash boards after boot into Linux from eMMC boot mode. So developers only need to use the first method to update an empty QSPI flash board once, then every board can be updated under Linux.

Updating using Linux Running on the Board

After booting into Linux, you should prepare the binary format of TF and U-boot. We cannot use the srec format because the common Linux based commands cannot interpret or recognize s-record format unlike the built-in commands inside Flashwriter. We only need to know the offset inside the boot device to store the binary file and then write the binary from the offset. These offsets are just the requirements of the Boot ROM or TF.

RZ/G2L: QSPI flash updating

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


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

Note:

The u-boot environment variables are stored into eMMC Boot1 partition(the 2nd Boot partition) by default. If you want to store them into the QSPI Flash, please refer to this link: RZ-G/RZG uboot#Use SPI Flash for Env Variables.

RZ/G2L: eMMC updating

From the Release Note document include in the BSP, 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: Setup 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 0 for boot, no ack

mmc bootbus set single_backward x1 x8 /dev/mmcblk0  # setup 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.

  • No labels

Site Policy