This is the Wiki for the U-Boot on Renesas R-Car Gen3 SoCs and boards . Refer to the R-Car page for information about Renesas' R-Car SoC family.
As of U-Boot 2019.04, the following boards are supported:
|Board||U-Boot defconfig||Update procedure|
|R8A7795 H3 ULCB||r8a7795_ulcb_defconfig||Flashing firmware|
|R8A7796 M3 ULCB||r8a7796_ulcb_defconfig||Flashing firmware|
|R8A7795 H3 Salvator-X/XS ES2.0+||r8a7795_salvator-x_defconfig||N/A|
|R8A7796 M3-W Salvator-X/XS||r8a7796_salvator-x_defconfig||N/A|
|R8A77965 M3-N Salvator-X/XS||r8a77965_salvator-x_defconfig||N/A|
|R8A77970 V3M Eagle||r8a77970_eagle_defconfig||N/A|
|R8A77990 E3 Ebisu||r8a77990_ebisu_defconfig||N/A|
|R8A77995 D3 Draak||r8a77995_draak_defconfig||N/A|
! WARNING: R-Car R8A7795 H3 ES1.x is NOT supported!
Building U-Boot manually
Building U-Boot can be done manually by using the U-Boot sources. This process does NOT produce IPL/ATF/BL binaries, only U-Boot binary is produced.
- Running mainline U-Boot is only supported with IPL/ATF/BL revision 2.23 and newer.
- ARM cross-compiler is mandatory to build U-Boot.
Debian and Ubuntu includes an ARM cross-compiler in its standard package feed. You can install it as follows:
apt-get install gcc-aarch64-linux-gnu
Other distributions likely also provide ARM cross-compilers. Consult distro-specific documentation for details.
Obtain U-Boot sources
The preferred method of obtaining U-Boot sources is through git VCS, using git protocol:
git clone git://gitlab.denx.de/u-boot.git
or via HTTPS:
git clone https://gitlab.denx.de/u-boot/u-boot.git
Finally, check out the version of U-Boot that will be used for the build:
cd u-boot git checkout -b my_working_branch v2019.10
U-Boot git tags also provides snapshots.
Prepare build environment
Before building U-Boot for R-Car Gen3 system, the following environment variables need to be configured:
export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu-
The later variable must match the prefix of the Aarch64 cross-toolchain installed on your system, the example above is valid for Debian and Ubuntu,
The U-Boot sources must be configured for a particular supported platform. List of supported platforms and matching U-Boot defconfigs is available at supported boards.
for example to configure U-Boot sources for R8A7795 H3 ULCB board:
Once configured, U-Boot sources can be compiled to produce u-boot.bin and u-boot-elf.srec:
To speed up build process, -jN option can be passed to make to start multiple jobs at the same time, this is beneficial especially on SMP systems. The following example starts up to (number of CPUs in a system + 1) jobs, which is the recommended amount:
make -j`expr \`nproc\` + 1`
Each platform has a slightly different process for updating the content of the flash. The list of supported boards contains links to instructions for updating each supported board.
U-Boot recovery SPL
Mainline U-Boot supports generating SPL binary which can be uploaded in SCIF loader mode and used e.g. to recover a blank system. During standard U-Boot build, the recovery SPL is generated in "spl/u-boot-spl.scif" .
The recovery SPL itself uses Ymodem upload to quickly download additional blobs and execute them on the system, namely ATF BL2 and U-Boot proper. It is thus required to have a terminal program capable of Ymodem upload.
The recovery SPL uses patched ATF BL2 to initialize the system and then jump back to Ymodem upload. It is thus required to build an ATF with patch rcar_gen3: plat: Add support for jumping to U-Boot SPL from BL2 for use with the recovery SPL. The patch makes the BL2 jump back into the U-Boot SPL instead of continuing with the regular boot. This is necessary to make it possible to load U-Boot via Ymodem upload as the next step. The resulting ATF binary must be wrapped into U-Boot uImage format to work with the SPL:
mkimage -A arm -O arm-trusted-firmware -T firmware -C none -a 0xe6304000 -e 0xe6304000 -n "BL2" -d build/rcar/release/bl2.bin bl2.uimage
U-Boot binary must be wrapped in a similar way. However, it is recommended to compress the U-Boot binary first, to further speed up the Ymodem upload. The decompression on the SPL side is much faster, while the Ymodem upload is the bottleneck here.
gzip -9 u-boot.bin mkimage -A arm -T firmware -C gzip -O u-boot -a 0x50000000 -e 0 -n "U-Boot" -d u-boot.bin.gz u-boot.gz.img
The result of this preparation are three files, "spl/u-boot-spl.scif", "bl2.uimage" and "u-boot.gz.img", which are required for the recovery.
The first step is to put the system into SCIF loader mode, e.g. by flipping MD pins or erasing the first HF/QSPI NOR erase block. After reset or power cycle, the system will enter the SCIF loader mode:
SCIF Download mode (w/o verification) (C) Renesas Electronics Corp. -- Load Program to SystemRAM --------------- please send !
Next, send the "u-boot-spl.scif" file via ASCII upload. U-Boot SPL will start and request Ymodem upload.
U-Boot SPL 2019.07-rc4-00155-gb02ecd04f5 (Jun 15 2019 - 15:27:14 +0200) Trying to boot from UART CCC
At this point, send the "bl2.uimage" file. ATF BL2 will start, perform the system initialization and drop back into the U-Boot SPL Ymodem upload.
Loaded 128765 bytes INFO: ARM GICv2 driver initialized ... NOTICE: BL2: Normal boot U-Boot SPL 2019.07-rc4-00155-gb02ecd04f5 (Jun 15 2019 - 15:27:14 +0200) Trying to boot from UART CCC
At this point, send the "u-boot.gz.img" file. U-Boot proper will start and the user is free to update the system via any supported method, e.g. ethernet, USB, serial and so on.
Loaded 414300 bytes U-Boot 2019.07-rc4-00155-gb02ecd04f5 (Jun 15 2019 - 15:27:24 +0200) CPU: Renesas Electronics R8A7795 rev 2.0 Model: Renesas Salvator-X board based on r8a7795 ES2.0+ DRAM: 3.9 GiB MMC: sd@ee100000: 0, sd@ee140000: 1, sd@ee160000: 2 Loading Environment from MMC... OK In: serial@e6e88000 Out: serial@e6e88000 Err: serial@e6e88000 Net: eth0: ethernet@e6800000 Hit any key to stop autoboot: 0 =>
Once the system has been updated, power cycle the system.