RZ-Five/RZ-Five-BSP Porting: Difference between revisions

From Renesas.info
(RZ/Five BSP porting guide initial (copy RZ/G2))
 
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''RZ/Five BSP Porting'''
This page is to highlight important things to consider when porting the Renesas BSP to your own custom board.
This page is to highlight important things to consider when porting the Renesas BSP to your own custom board.
The steps explained in this page are similar to what described for the Arm based devices (RZ/G2).
The steps explained in this page are similar to what described for the Arm based devices (RZ/G2).
To avoid duplications, the focus is on the differences, then you can refer to the RZ/G2 pages for anything common.
To avoid duplications, the focus is on the differences, then you can refer to the RZ/G2 pages for anything common.


== Overview ==
== Overview ==
One preliminary point to underline is that you may NOT want to use Yocto at the beginning, rather clone the repositories, modify the code and build it using a cross toolchain.
One preliminary point to underline, true also for Arm based devices, is that you may NOT want to use Yocto at the beginning, rather clone the repositories, modify the code and build it using a cross toolchain.
 
The toolchain itself is a point to discuss a bit more in depth, since RISC-V ecosystem is still not as mature as Arm's.
 
The paragraph order in this page is intentional. Similarly to what explained for Arm based device, they represent the steps you normally do when you want to port the Renesas BSP, i.e. you absolutely want to start from [https://github.com/renesas-rz/rzg2_flash_writer Flash Writer]. When you get your first custom board samples the non-volatile memories are virgin and the first goals is to program them with bootloaders. One of the first thing you need to do is to adjust the DDR configuration to your own. Debugging DDR may be tricky but have it working is a major step toward success. You can test the DDR using some hidden [[RZ-G/RZG hardware#DDR test routines|Flash Writer commands]]. After that you may need to change the SPI configuration.
 
Then you can use Flash Writer to program the bootloaders: [https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc u-boot SPL] (Secondary Program Loader), [https://github.com/renesas-rz/rz_opensbi Open SBI] (Supervisor Binary Interface and [https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc u-boot]. Bootloaders can be programmed into QSPI FLASH or eMMC, then of course the boot mode of the SoC shall be adjusted accordingly. u-boot-spl may also need to be configured depending on the non-volatile memory type. Normally you do not need to program separately (e.g. different files for each boot loader), only two files, u-boot-spl and u-boot.itb, are needed but the Open SBI binary has to be included before building u-boot.  


The paragraph order in this page is intentional. They represent the steps you normally do when you want to port the Renesas BSP, i.e. you absolutely want to start from [https://github.com/renesas-rz/rzg2_flash_writer Flash Writer]. When you get your first custom board samples the non-volatile memories are virgin and the first goals is to program them with bootloaders. One of the first thing you need to do is to adjust the DDR configuration to your own. Debugging DDR may be tricky but have it working is a major step toward success. You can test the DDR using some hidden [[RZ-G/RZG hardware#DDR test routines|Flash Writer commands]]. After that you may need to change the SPI configuration.  
Some modifications may be needed in u-boot-spl. One of the first things spl does is to configure the DDR. You would need to use the same (working) configuration used with Flash Writer, so there should be no surprise here, if the DDR works with Flash Writer then it will work with ATF as well.


Finally you can use Flash Writer to program the bootloaders: [https://github.com/renesas-rz/rzg_trusted-firmware-a Arm Trusted Firmware] (ATF) BL2 (aka IPL, Initial Program Loader), BL31 (Secure Monitor) and [https://github.com/renesas-rz/renesas-u-boot-cip u-boot] (BL33). BL32 is not strictly needed at the beginning, since it is the Trusted OS (optional). Bootloaders can be programmed into QSPI FLASH or eMMC, then of course the boot mode of the SoC shall be adjusted accordingly. ATF may also need to be configured depending on the non-volatile memory type. You may need to program separately (e.g. different files for each BL) or you can have a BL2 file and a FIP (Firmware Image Package) that includes all BL3x.


You do not normally need to modify many things in ATF and in any case only what is in the "plat/renesas/rz" folder. One of the first things ATF BL2 does is to configure the DDR. You would need to use the same (working) configuration used with Flash Writer, so there should be no surprise here, if the DDR works with Flash Writer then it will work with ATF as well.




[[File:sci-usb boot.png|frameless]]-------------------------------        [[File:RISC-V boot flow.png|alt=|600x600px]]


[[File:sci-usb boot.png|frameless]]-------------------------------[[File:boot2.png|alt=|682x682px]]






Then ATF loads BL31(image id=3), BL32 (again optionally, image id=4) and BL33 (u-boot, image id=5) from either QSPI or eMMC. Assuming everything goes fine u-boot prompt is finally reachable.
Then u-boot-spl loads Open SBI and u-boot, from either QSPI or eMMC. Assuming everything goes fine u-boot prompt is finally reachable.


The next step is to port the [https://github.com/renesas-rz/rz_linux-cip Linux CIP Kernel], by "porting" we mainly mean that the reference board device tree gets modified to reflect the HW available on the custom board.
The next step is to port the [https://github.com/renesas-rz/rz_linux-cip Linux CIP Kernel], by "porting" we mainly mean that the reference board device tree gets modified to reflect the HW available on the custom board.


Finally you can use Yocto to generate the root file system including all the bits and bobs you need to run your custom application.
Finally you can use Yocto to generate the root file system including all the bits and bobs you need to run your custom application.
= Toolchain =
The RISC-V toolchain is what is needed to cross-build everything, most likely it is going to be installed on a x86 machine and this is what is taken for granted in this section.
There are different toolchain that can be used:
* Ubuntu 20.04 native apt package
* Official RISC-V toolchain, to be build from sources
* Andes customized toolchain, to be build from sources
* SDK built using Yocto for RZ/Five
== Ubuntu 20.04 native apt package ==
This option is very convenient for people using Ubuntu, the cross toolchain can be simply installed using apt:
sudo apt install gcc-riscv64-linux-gnu
Please note that in this case the cross gdb is not installed and in general the solution would be to install gdb-multiarch:
sudo apt-get install gdb-multiarch
However this multi-architecture gdb does not work perfectly with RZ/Five, so it is not recommended to use it.
== Official RISC-V toolchain ==
Another option is to build the toolchain directly from the official RISC-V sources, available on [https://github.com/riscv-collab/riscv-gnu-toolchain github along with detailed instructions].
== Andes customized toolchain ==
The core implemented in RZ/Five is an IP coming from Andes: AX45MP Single. Therefore their toolchain, also [https://github.com/andestech/nds-gnu-toolchain available on github], can be used successfully. It is enough to follow the instructions, making sure that the build script is edited to reflect the ''nds64le-elf-newlib-v5d'' or ''nds64le-linux-glibc-v5d'' settings. Note that these are not the default settings.
== SDK for RZ/Five ==
The last possibility is to build the SDK using Yocto and install it on the host machine. Just follow the instructions available in the RZ/Five Board Support Package Release Note.


=Flash Writer=
=Flash Writer=
* [[RZ-G/RZ-G2_BSP_Porting_FlashWriter]]
Porting Flash Writer to RZ/Five is almost identical to RZ/G2L. Please refer to [[RZ-G/RZ-G2 BSP Porting FlashWriter|this page]] for more details. Of course some of the steps need to be adapted:
 
* The branch to be selected is different:
 
git checkout origin/rz_five
 
* ''param_mc.c'' should be copied in the ''ddr/five'' folder
 
= u-boot-spl / u-boot =
Porting u-boot to RZ/Five is similar to [[RZ-G/RZ-G2 BSP Porting uboot|RZ/G2L]]. The major difference resides in SPL (Secondary Program Loader) that is enabled only in RZ/Five, since most of the time in Arm based devices the Arm Trusted Firmware BL2 performs all the low-level initialization needed.
 
Given the similarities, in this section only the differences are described. The github project to be cloned is the same (renesas-u-boot-cip), then the branch to be selected is different:
git checkout v20xx.xx/rzf-smarc
Replace the xx with the latest branch, or anyway the version you want to use.
 
Referring to the steps in [[RZ-G/RZ-G2 BSP Porting uboot#SoC: RZ.2FG2L.2C RZ.2FV2L 2|this section]], step 1 is slightly different:


= Arm Trusted Firmware =
1) Add you custom board device tree file in the arch/riscv/dts folder: my_custom_board.dts. You do not need to create this file from scratch, you can copy the Renesas board file as template:
* [[RZ-G/RZ-G2_BSP_Porting_ATF]]
cp arch/riscv/dts/smarc-rzf.dts arch/arm/dts/my_custom_board.dts
and edit the file arch/riscv/dts/Makefile:
[...]
dtb-$(CONFIG_TARGET_SMARC_RZF) += smarc-rzf.dtb
+dtb-$(CONFIG_TARGET_MY_CUSTOM_BOARD) += my_custom_board.dtb
 
targets += $(dtb-y)
[...]
Step 2 is almost identical, the only difference is that you want to start from a different board file:
mkdir -p board/<vendor>/my_custom_board
cp board/renesas/rzf-dev/* board/<vendor>/my_custom_board
mv board/<vendor>/my_custom_board/rzf-dev.c board/<vendor>/my_custom_board/my_custom_board.c
Step 3 is also very similar, edit the newly created files, board/<vendor>/my_custom_board/Kconfig:
if TARGET_MY_CUSTOM_BOARD
config SYS_CPU
        default "rzfive"
config SYS_BOARD
        default "my_custom_board"
config SYS_VENDOR
        default "vendor"
config SYS_SOC
        default "rzmpu"
config SYS_CONFIG_NAME
        default "my_custom_board"
[...]


= u-boot =
= Open SBI =
* [[RZ-G/RZ-G2_BSP_Porting_uboot]]
* RZ-Five/RZ-Five BSP_Porting_SBI


= Linux Kernel =
= Linux Kernel =
Line 42: Line 118:
=Memory Map=
=Memory Map=
* This section explains how DDR Memory is divided and configured.
* This section explains how DDR Memory is divided and configured.
* [[RZ-G/RZ-G2_BSP_MemoryMap]]
* TBD


=Github Repositories=
=Github Repositories=
* This section explains the purpose of each github repository and branch.
* This section explains the purpose of each github repository and branch.
* [[RZ-G/RZ-G2_BSP_GithubRepos]]
* [[RZ-G/RZ-G2_BSP_GithubRepos]]

Latest revision as of 09:42, 24 May 2022

This page is to highlight important things to consider when porting the Renesas BSP to your own custom board.

The steps explained in this page are similar to what described for the Arm based devices (RZ/G2). To avoid duplications, the focus is on the differences, then you can refer to the RZ/G2 pages for anything common.

Overview

One preliminary point to underline, true also for Arm based devices, is that you may NOT want to use Yocto at the beginning, rather clone the repositories, modify the code and build it using a cross toolchain.

The toolchain itself is a point to discuss a bit more in depth, since RISC-V ecosystem is still not as mature as Arm's.

The paragraph order in this page is intentional. Similarly to what explained for Arm based device, they represent the steps you normally do when you want to port the Renesas BSP, i.e. you absolutely want to start from Flash Writer. When you get your first custom board samples the non-volatile memories are virgin and the first goals is to program them with bootloaders. One of the first thing you need to do is to adjust the DDR configuration to your own. Debugging DDR may be tricky but have it working is a major step toward success. You can test the DDR using some hidden Flash Writer commands. After that you may need to change the SPI configuration.

Then you can use Flash Writer to program the bootloaders: u-boot SPL (Secondary Program Loader), Open SBI (Supervisor Binary Interface and u-boot. Bootloaders can be programmed into QSPI FLASH or eMMC, then of course the boot mode of the SoC shall be adjusted accordingly. u-boot-spl may also need to be configured depending on the non-volatile memory type. Normally you do not need to program separately (e.g. different files for each boot loader), only two files, u-boot-spl and u-boot.itb, are needed but the Open SBI binary has to be included before building u-boot.

Some modifications may be needed in u-boot-spl. One of the first things spl does is to configure the DDR. You would need to use the same (working) configuration used with Flash Writer, so there should be no surprise here, if the DDR works with Flash Writer then it will work with ATF as well.



sci-usb boot.png-------------------------------



Then u-boot-spl loads Open SBI and u-boot, from either QSPI or eMMC. Assuming everything goes fine u-boot prompt is finally reachable.

The next step is to port the Linux CIP Kernel, by "porting" we mainly mean that the reference board device tree gets modified to reflect the HW available on the custom board.

Finally you can use Yocto to generate the root file system including all the bits and bobs you need to run your custom application.

Toolchain

The RISC-V toolchain is what is needed to cross-build everything, most likely it is going to be installed on a x86 machine and this is what is taken for granted in this section.

There are different toolchain that can be used:

  • Ubuntu 20.04 native apt package
  • Official RISC-V toolchain, to be build from sources
  • Andes customized toolchain, to be build from sources
  • SDK built using Yocto for RZ/Five

Ubuntu 20.04 native apt package

This option is very convenient for people using Ubuntu, the cross toolchain can be simply installed using apt:

sudo apt install gcc-riscv64-linux-gnu

Please note that in this case the cross gdb is not installed and in general the solution would be to install gdb-multiarch:

sudo apt-get install gdb-multiarch

However this multi-architecture gdb does not work perfectly with RZ/Five, so it is not recommended to use it.

Official RISC-V toolchain

Another option is to build the toolchain directly from the official RISC-V sources, available on github along with detailed instructions.

Andes customized toolchain

The core implemented in RZ/Five is an IP coming from Andes: AX45MP Single. Therefore their toolchain, also available on github, can be used successfully. It is enough to follow the instructions, making sure that the build script is edited to reflect the nds64le-elf-newlib-v5d or nds64le-linux-glibc-v5d settings. Note that these are not the default settings.

SDK for RZ/Five

The last possibility is to build the SDK using Yocto and install it on the host machine. Just follow the instructions available in the RZ/Five Board Support Package Release Note.

Flash Writer

Porting Flash Writer to RZ/Five is almost identical to RZ/G2L. Please refer to this page for more details. Of course some of the steps need to be adapted:

  • The branch to be selected is different:
git checkout origin/rz_five
  • param_mc.c should be copied in the ddr/five folder

u-boot-spl / u-boot

Porting u-boot to RZ/Five is similar to RZ/G2L. The major difference resides in SPL (Secondary Program Loader) that is enabled only in RZ/Five, since most of the time in Arm based devices the Arm Trusted Firmware BL2 performs all the low-level initialization needed.

Given the similarities, in this section only the differences are described. The github project to be cloned is the same (renesas-u-boot-cip), then the branch to be selected is different:

git checkout v20xx.xx/rzf-smarc

Replace the xx with the latest branch, or anyway the version you want to use.

Referring to the steps in this section, step 1 is slightly different:

1) Add you custom board device tree file in the arch/riscv/dts folder: my_custom_board.dts. You do not need to create this file from scratch, you can copy the Renesas board file as template:

cp arch/riscv/dts/smarc-rzf.dts arch/arm/dts/my_custom_board.dts

and edit the file arch/riscv/dts/Makefile:

[...] 

dtb-$(CONFIG_TARGET_SMARC_RZF) += smarc-rzf.dtb
+dtb-$(CONFIG_TARGET_MY_CUSTOM_BOARD) += my_custom_board.dtb
 
targets += $(dtb-y)

[...]

Step 2 is almost identical, the only difference is that you want to start from a different board file:

mkdir -p board/<vendor>/my_custom_board
cp board/renesas/rzf-dev/* board/<vendor>/my_custom_board
mv board/<vendor>/my_custom_board/rzf-dev.c board/<vendor>/my_custom_board/my_custom_board.c

Step 3 is also very similar, edit the newly created files, board/<vendor>/my_custom_board/Kconfig:

if TARGET_MY_CUSTOM_BOARD

config SYS_CPU
        default "rzfive"

config SYS_BOARD
        default "my_custom_board"

config SYS_VENDOR
        default "vendor"

config SYS_SOC
        default "rzmpu"

config SYS_CONFIG_NAME
        default "my_custom_board"

[...]

Open SBI

  • RZ-Five/RZ-Five BSP_Porting_SBI

Linux Kernel

Yocto

Memory Map

  • This section explains how DDR Memory is divided and configured.
  • TBD

Github Repositories