RZ-G/RZ-G2L Flash Programming: Difference between revisions

Revision as of 11:21, 7 March 2022

RZ/G2L boot modes are summarized in the table below.

Selection of RZ/G2L boot modes
MD_BOOT2 to MD_BOOT0			Boot Mode	Interface Module	Connected Device
0	0	0	Boot mode 0	SDHI0	eSD (3.3 V at startup)
0	0	1	Boot mode 1	SDHI0	1.8-V eMMC
0	1	0	Boot mode 2	SDHI0	3.3-V eMMC
0	1	1	Boot mode 3	SPIBSC	1.8-V Single Quad or Octal serial flash memory
1	0	0	Boot mode 4	SPIBSC	3.3-V Single or Quad serial flash memory
1	0	1	Boot mode 5	SCIF0	Downloading through SCIF

In most of the Linux applications covered by the RZ/G2L, when it comes to non-volatile memory there are two main use cases:

QSPI and eMMC. QSPI is normally used for firmware / boot loaders (i.e. ATF and u-boot) whereas eMMC for kernel and rootfs.
eMMC only. In this case one of the two eMMC boot partitions is used for boot loaders and the user partition is then used for rootfs and kernel.

There might be other special cases but we can confidently state that these cover the great majority. We can also reasonably say that being the RZ/G2L a low-end device, there is the tendency to remove the QSPI to save money on the BOM.

At the end of the production line of course non-volatile memories are virgin (with a notable exception explained later) and need to be programmed. Usually firmware and bootloaders are relatively small (less than 1MB in total), kernel is instead in the tens of megabyte range and rootfs can go up to several hundreds of megabytes. To transfer this amount of data a fast interface is indeed required.

RZ/G2L cannot boot from USB, so at the end-of-line there are a few real viable options:

Boot from SCIF (UART)
Use JTAG
It is worth to mention that, in general, if a QSPI FLASH is present on the custom board, it can also be bought preprogrammed
Use a temporary QSPI flash card
Booting from SD-card (TO BE CONFIRMED, specs officially allow eSD only)

In any of the cases above the goal is to have U-Boot up and running, then there are plenty of options to program the rootfs: ethernet, USB as host, USB with Mass Storage gadget, fastboot or even boot Linux kernel + initramfs.

With option 1, you can download Flash Writer and program the bootloaders, Arm Trusted Firmware (ATF) and U-Boot, into QSPI / eMMC boot partition, then reset and run U-Boot.

With option 2, you can download ATF and U-Boot via JTAG and then run the boot loaders without having to initially program them. Once U-Boot runs, you can program both bootloaders and rootfs.

With option 3, QSPI has already bootloaders pre-programmed, so U-Boot is already available.

With option 4, a QSPI flash card is somehow attached to the board that needs to be programmed. The QSPI flash contains ATF and U-Boot and potentially also the root file system to be programmed, depending on the size of both. More details are available here.

TO BE CONFIRMED. Option 5 may be complicated. Assuming the final goal is to boot from eMMC, since RZ/G2L can only boot from SDHI0, the system should implement a HW mechanism to switch from SD to eMMC during runtime.

All the options above may not require any human intervention and can be to a certain extent automatized.

In the rest of this page follow some examples on how to implement a fully atomized flash programming. More in particular we will focus on option 1, where ATF and U-Boot are programmed using the SCIF (Step 1). At the reboot U-Boot loads and boots kernel and the initramfs from USB. Then a custom init script is used of program the root file system stored on the USB thumb to the eMMC and eventually U-Boot is replaced, mainly to have a new set of environment variables to boot the final kernel / rootfs. It is assumed that all binaries to be programmed are already available, for example as result of the porting of the BSP.

Step 1 - Programming ATF and u-boot via SCIF

The main tool that can assist in performing external non-volatile memory (QSPI and eMMC) is Flash Writer. Depending on the host PC used, you can either use a bash script or a TeraTerm macro. In both cases you would need two files:

bl2.bin
fip.bin

The file names may vary a bit. These are either the output of Yocto or generated by combining ATF and U-Boot binaries. Actually the first one is generated by ATF directly whereas the second is the generated by the Firmware Image Package (FIP) utility by combining BL3x binaries (BL31 secure monitor, BL32 OP-TEE and BL33 u-boot).

Linux script

A Linux bash script is available here. Please refer to the README for help on the usage.

Windows TeraTerm macro

Usually dealing with this type of devices a Linux host PC is normally available. However sometimes it might be convenient to have a quick way to program the bootloaders using Windows. Especially during production, a Windows PC may be more convenient than a Linux PC.

Instead of using an ad-hoc tool developed only for the RZ/G2L the idea is to use a generic terminal utility. Tera Term is an open source tool that has some nice scripting capabilities embedded: a Tera Term script is called MACRO. The developed macro "replaces" the user and provides inputs to Flash Writer, whose binary is also downloaded automatically. There are just a couple of parameters that you would need to change, stuff like COM port or the name of the Flash Writer binary to be used and whether the target is QSPI or eMMC. The "UNATTENDED" parameter suppresses all the user interaction apart from errors.

It is assumed that MD_BOOTx pins are already configured for the final boot mode. However, if the target flash is virgin, the boot mode selected fails over to SCIF download, allowing the Flash Writer bin to be downloaded.

Use JTAG

TBD

@@ Line 81: / Line 81: @@
 All the options above may not require any human intervention and can be to a certain extent automatized.
-In the rest of this page follow some examples on how to implement a fully atomized flash programming. More in particular we will focus on option 1, where ATF and U-Boot are programmed using the SCIF. At the reboot U-Boot loads and boots kernel and the initramfs from USB. Then a custom init script is used of program the root file system stored on the USB thumb to the eMMC and eventually U-Boot is replaced, mainly to have a new set of environment variables to boot the final kernel / rootfs.
+In the rest of this page follow some examples on how to implement a fully atomized flash programming. More in particular we will focus on option 1, where ATF and U-Boot are programmed using the SCIF (Step 1). At the reboot U-Boot loads and boots kernel and the initramfs from USB. Then a custom init script is used of program the root file system stored on the USB thumb to the eMMC and eventually U-Boot is replaced, mainly to have a new set of environment variables to boot the final kernel / rootfs. It is assumed that all binaries to be programmed are already available, for example as result of the [[RZ-G/RZ-G2 BSP Porting|porting of the BSP]].
-== Boot from SCIF ==
+== Step 1 - Programming ATF and u-boot via SCIF ==
-The main tool that can assist in performing external non-volatile memory (QSPI and eMMC) is [https://github.com/renesas-rz/rzg2_flash_writer/tree/rz_g2l Flash Writer]. Depending on the host PC used, you can either use a script (link to be added) or a [https://ttssh2.osdn.jp/index.html.en TeraTerm] macro. In both cases what you would need are two files:
+The main tool that can assist in performing external non-volatile memory (QSPI and eMMC) is [https://github.com/renesas-rz/rzg2_flash_writer/tree/rz_g2l Flash Writer]. Depending on the host PC used, you can either use a [https://github.com/renesas-rz/rzg2_bsp_scripts/tree/master/flash_writer_tool bash script] or a [https://ttssh2.osdn.jp/index.html.en TeraTerm] macro. In both cases you would need two files:
-* bl2_bp-smarc-rzg2l.bin
+* bl2.bin
-* fip-smarc-rzg2l.bin
+* fip.bin
-These are either the output of Yocto or generated by combining ATF and U-Boot binaries. Actually the first one is generated by ATF directly whereas the second is the generated by the Firmware Image Package (FIP) utility by combining BL3x binaries.
+The file names may vary a bit. These are either the output of Yocto or generated by combining ATF and U-Boot binaries. Actually the first one is generated by ATF directly whereas the second is the generated by the [https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/tools-build.html Firmware Image Package (FIP)] utility by combining BL3x binaries (BL31 secure monitor, BL32 OP-TEE and BL33 u-boot).
 === Linux script ===
-A Linux bash script is available [https://github.com/seebe/rzg_stuff/tree/master/boards/rzg2l_smarc here]. Please refer to the README for help on the usage.
+A Linux bash script is available [https://github.com/renesas-rz/rzg2_bsp_scripts/tree/master/flash_writer_tool here]. Please refer to the README for help on the usage.
 === Windows TeraTerm macro ===
-Usually dealing with this type of devices a Linux host PC is normally available. However sometimes it might be convenient to have a quick way to program the bootloaders using Windows.
+Usually dealing with this type of devices a Linux host PC is normally available. However sometimes it might be convenient to have a quick way to program the bootloaders using Windows. Especially during production, a Windows PC may be more convenient than a Linux PC.
-Instead of using an ad-hoc tool developed only for the RZ/G2L the idea is to use a generic terminal utility. [https://ttssh2.osdn.jp/index.html.en Tera Term] is an open source tool that has some nice scripting capabilities embedded: a Tera Term script is called [https://ttssh2.osdn.jp/manual/4/en/macro/index.html MACRO]. The [https://ttssh2.osdn.jp/manual/4/en/macro/index.html developed macro] "replaces" the user and provides inputs to Flash Writer, whose binary is also downloaded automatically. However the macro alone cannot work, it needs the Flash Writer binary and the files to be programmed (ATF BL2 and [https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/tools-build.html FIP]).
+Instead of using an ad-hoc tool developed only for the RZ/G2L the idea is to use a generic terminal utility. [https://ttssh2.osdn.jp/index.html.en Tera Term] is an open source tool that has some nice scripting capabilities embedded: a Tera Term script is called [https://ttssh2.osdn.jp/manual/4/en/macro/index.html MACRO]. The [https://github.com/seebe/rzg_stuff/blob/master/boards/rzg2l_smarc/rzg2l_smarc-rzg2l_flash_writer.ttl developed macro] "replaces" the user and provides inputs to Flash Writer, whose binary is also downloaded automatically. There are just a couple of parameters that you would need to change, stuff like COM port or the name of the Flash Writer binary to be used and whether the target is QSPI or eMMC. The "UNATTENDED" parameter suppresses all the user interaction apart from errors.
-Since Windows users are typically lazy, a PowerShell script ('''''press ALT and then click''''' '''''on [https://github.com/seebe/rzg_stuff/raw/master/boards/rzg2l_smarc/rzg2l_smarc-rzg2l_flash_writer.ps1 this link]''''' to download it) was developed to:
+It is assumed that MD_BOOTx pins are already configured for the final boot mode. However, if the target flash is virgin, the boot mode selected fails over to SCIF download, allowing the Flash Writer bin to be downloaded.
-* Check if Tera Term is installed and retrieve the installation path;
-* Download in a temporary folder the needed files;
-* Retrieve the PC COM ports and ask the user to confirm the one used to communicate with the RZ/G2L board;
-* Create a Windows shortcut to call the Tera Term macro executer using the right parameters;
-* Launch the macro to program the RZ/G2L boot loaders.
-Once executed the first time the user can simply double click on the shortcut created by the macro script to relaunch the programming. The macro programs automatically the files present in the "Binaries" folder and it can handle both SREC and BIN. Binary is normally faster to be programmed since files are smaller. The file names should start with ''bl2'' and ''fip'' respectively but the rest can be arbitrary. Users can replace the default files with custom files and launch the programming. There can be many files in the folder, the first  in alphabetical order are used. You can also mix SREC and BIN files, i.e. program a BL2 SREC and a FIP BIN or vice versa.
-It is worth noticing that the macro and the PowerShell script can be easily modified to remove any user intervention, something that may be useful for an unattended flash programming.
-=== Flash Writer binary chip / board dependency ===
-Even though RZ/G2L and RZ/V2L are brother chips (the only functional difference is the DRP-AI), there are some subtle changes that lead to have a different DDR register configuration. [https://github.com/renesas-rz/rzg2_flash_writer/tree/rz_g2l Flash Writer] does initialize the DDR so, the binaries to be used are different for RZ/G2L and RZ/V2L. On top of that there are several slightly different variant of the SMARC SOM due to the different DDR chips / topology. Below a summary:
-* SMARC RZ/G2L WS1 (only discrete) DDR config is 2x1GB;
-* SMARC RZ/G2L WS2 discrete DDR config is 2x1GB but there are some HW changes between WS2 and WS1 hence different DDR init code;
-* SMARC RZ/V2L discrete DDR config is 2x2GB;
-* SMARC RZ/G2L WS2 - RZ/V2L PMIC DDR config is 1x2GB.
-For the last variant, the only difference is the chip but as said the DDR init code is different so different binaries are needed.
 == Use JTAG ==
 TBD