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 1: Line 1:
== Introduction of the two updating methods ==
== Introduction of the Two Updating Methods ==
There are two ways to update the Trusted-firmware(TF) and U-boot.
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 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 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.
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.


== Customer support ==
== Using an External SPI Flash Board for Temporary Linux Boot ==
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.
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:
Typical usage steps:
Line 19: Line 19:
# The main board is ready.
# 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.
Of course the images in the QSPI flash can also be updated if necessary at step 5, self-update. Developers can also update an empty QSPI flash board's content 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 detail in the second way ==
== Updating using Linux Running on the Board ==
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. These offsets are just the requirements of the Boot ROM or TF.
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 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. These offsets are just the requirements of the Boot ROM or TF.


=== RZ/G2L: QSPI flash updating ===
=== RZ/G2L: QSPI flash updating ===
Line 39: Line 39:
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.
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.


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


Line 46: Line 47:


flashcp -v boot.img /dev/mtd0
flashcp -v boot.img /dev/mtd0
</pre>


=== RZ/G2L: eMMC updating ===
=== 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.
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:  Setupt the EXT_CSD registers using mmc-utils(an open source tool). Execute once because the register area is non-volatile memory type.
* 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.


<pre>
mmc bootpart enable 1 0 /dev/mmcblk0  # enable the first boot-area 0 for boot, no ack
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  # setupt the boot bus config
mmc bootbus set single_backward x1 x8 /dev/mmcblk0  # setup the boot bus config
</pre>


* Step 2:  Write binary to the boot area
* Step 2:  Write binary to the boot area
 
<pre>
echo 0 > /sys/block/mmcblk0boot0/force_ro  # disable the soft write-protect based on Linux, reset after reboot
echo 0 > /sys/block/mmcblk0boot0/force_ro  # disable the soft write-protect based on Linux, reset after reboot


Line 63: Line 67:


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


=== RZ/G2E|M|N|H: ===
=== 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.
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.

Revision as of 19:37, 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 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(the kernel, dtb and rootfs/initrd 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. Developers can also update an empty QSPI flash board's content 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 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. 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).

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

Retrieved from "https://renesas.info/w/index.php?title=RZ-G/RZ-G2_Update_Trusted-firmware_and_U-boot_Under_Linux&oldid=951"