RZ-G/RZ-G2 BSP Porting
RZ/G2 BSP Porting This page is to highlight important things to consider when porting the Renesas BSP to your own custom board.
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.
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 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.
Finally you can use Flash Writer to program the bootloaders: Arm Trusted Firmware (ATF) BL2 (aka IPL, Initial Program Loader), BL31 (Secure Monitor) and 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 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.
-------------------------------
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.
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.
Flash Writer
Cloning repository
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
git clone https://github.com/renesas-rz/rzg2_flash_writer
Then what you may want to do is to create a new branch for your own experiments, e.g.:
git checkout -b my_custom_board_branch
SoC: RZ/G2L, RZ/V2L
git clone https://github.com/renesas-rz/rzg2_flash_writer git checkout origin/rz_g2l
Then what you may want to do is to create a new branch for your own experiments, e.g.:
git switch -c my_custom_board_branch
Add New DDR Settings
SoC: RZ/G2N, RZ/G2M, RZ/G2H
Flash Writer version: v1.50+
- DDR settings for each board are stored in a "struct _boardcnf" that is used by the DDR initialization code.
- For Renesas evaluation boards, the Flash writer source contains an array of all the possible evaluation boards.
- When porting Flash Writer to your own custom board, you will need to create your own "struct _boardcnf" that matches the DDR memory on your board.
- In general, only the structure is needed (no DDR init executable code needs to be modified).
- In Flash Writer, the function boardcnf_get_brd_type() is declared as '__attribute__((weak))' such that you can provide your own version of this function and gcc will ignore the function provided in the Flash Writer code that is specific for Renesas evaluation boards. This method allows you to not modify source files that might be updated later by Renesas as new evaluation boards are added and might cause merge conflicts with your local modification.
- A sample DDR configuration structure has been provided. Please refer to file ddr/lpddr4/boot_init_dram_config-preset.c for example configurations used by Renesas evaluation boards.
Instructions:
1. Make a copy of the template file ddr/lpddr4/my_boot_dram_config.c
$ cp ddr/lpddr4/my_boot_dram_config.c ddr/lpddr4/xyz_boot_dram_config.c
2. Add your new file to the build system by editing the makefile ddr/lpddr4/ddr.mk
SRC_FILE += ddr/lpddr4/boot_init_dram.c ddr/lpddr4/boot_init_dram_config-preset.c # SRC_FILE += ddr/lpddr4/my_boot_dram_config.c SRC_FILE += ddr/lpddr4/xyz_boot_dram_config.c <<<<<<<<<<<< Example <<<<<<<<<<
3. Edit your new file and adjust the settings for your DDR memory on your board.
SoC: RZ/G2E
Flash Writer version: TBD
Content: DDR3L instead of LPDDR4.
SoC: RZ/G2L-V2 L
Flash Writer version: 1.0+
Unless the DDR RAM you have on the custom board, connection and topology is exactly the same of the reference board, you have to adapt the parameters. In order to do so, please get from Renesas the RZ/G2L DDR configuration generation tool (RZ-G2L_DDR_config_generation_tool_Rev.X.YZ_rN.xlsm). Using this excel sheet you can generate two files (param_mc.c and param_swizzle.c) that have to be added to Flash Writer.
Copy param_swizzle.c in the ddr/common folder and param_mc.c in the ddr/g2l (or ddr/v2l) folder.
Add the following lines at the beginning of ddr.c in the ddr/common folder:
#if (BOARD == CUSTOM) #include "param_mc.c" #include "param_swizzle.c" #endif
And comment out the error clauses "Unknown size" and "Unknown swizzle".
Add Support for New SPI Flash
SoC: All
- Flash writer version: All
Flash Writer will read the device ID of the SPI flash device in order to determine what SPI commands it should use as well as the flash block size. Therefore, the specific ID of your flash device needs to be part of the flash writer source code.
The RZ/G2 Flash writer code is posted here. Please review the following files and code and modify as needed.
include/dgmodul4.h
- Confirm that the Manufacture ID for your flash devices is listed. For example, you will see these vendors already listed:
#define CYPRESS_MANUFACTURER_ID 0x01 /* Cypress */ #define WINBOND_MANUFACTURER_ID 0xEF /* Winbond */ #define MACRONIX_MANUFACTURER_ID 0xC2 /* Macronix */ #define MICRON_MANUFACTURER_ID 0x20 /* Micron */
- Confirm if the Device ID for your flash devices is listed. If not, then add it.
#define DEVICE_ID_S25FS128S 0x2018
dgmodul4.c
- If you added a new SPI flash in dgmodule4.h, then you must add it to function CheckQspiFlashId()
- Add new case statement using your DEVICE_ID_xxx that you created in dgmodule.h
- Print out the part number of your SPI Flash using PutStr()
- Set the Flash sector erase size as gQspi_sa_size
- Set the address of the last Flash sector as gQspi_end_addess
case DEVICE_ID_S25FS512S: PutStr("S25FS512S", 1); gQspi_sa_size = SA_256KB; gQspi_end_addess = TOTAL_SIZE_64MB - 0x8000 - 1; break;
🎈 If you successfully added a new SPI Flash device, please let us know so we can update the code for everyone 🧑🤝🧑. You can submit a new issue on the github site, or send an email to renesas-rz@renesas.com. Thank you.
Building and debugging
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
You can build Flash Writer by following the Readme, the only difference is that you have to use BOARD=CUSTOM (or the name you chose) as per these instructions.
You can also use Eclipse to build and debug Flash Writer using OpenOCD as documented here. Obviously there is always the possibility to debug using the good old printf (PutStr function in Flash Writer).
Arm Trusted Firmware
Cloning repository
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
git clone https://github.com/renesas-rz/rzg_trusted-firmware-a/ git checkout remotes/origin/v2.5/rzg2
Then what you may want to do is to create a new branch for your own experiments, e.g.:
git checkout -b my_custom_board_branch
SoC: RZ/G2L, RZ/V2L
git clone https://github.com/renesas-rz/rzg_trusted-firmware-a/ git checkout remotes/origin/v2.5/rzg2l
Then what you may want to do is to create a new branch for your own experiments, e.g.:
git switch -c my_custom_board_branch
DDR configuration
SoC: RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2E
Content: TBD
SoC: RZ/G2L, RZ/V2L
The DDR configuration files (param_mc.c and param_swizzle.c) to be used with ATF are the same as Flash Writer.
First of all create a new folder for your custom board in the platform folder:
mkdir -p plat/renesas/rz/board/custom
Copy one of the existing .mk files as template:
cp plat/renesas/rz/board/smarc_2/rz_board.mk plat/renesas/rz/board/custom/rz_board.mk
Edit the content of this newly created file:
# # SPDX-License-Identifier: BSD-3-Clause # DDR_SOURCES += plat/renesas/rz/soc/${PLAT}/drivers/ddr/param_mc.c \ plat/renesas/rz/common/drivers/ddr/param_swizzle.c DDR_PLL4 := 1600 $(eval $(call add_define,DDR_PLL4))
Note that DDR_PLL4 define have to match the DDR type (e.g. 1600 for DDR4 and 1333 for DDR3L).
Copy param_mc.c and param_swizzle.c in the folders pointed by the .mk just edited.
Non-volatile memories
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Quad SPI Flash Read Command Configuration
- After RESET, the internal Mask-ROM inside the device will read BL2 from SPI flash into internal memory. This process should work for almost all SPI flash devices and no code changes are needed.
- When BL2 runs, it will copy additional binaries into DDR (BL31, BL33, FIP, u-boot, etc..). However, the BL2 software will first reconfigure the SPI Flash controller to run in a memory mapped (XIP) mode in order to make the operation faster.
- Quad SPI flash devices from different vendors behave differently. Therefore, code changes will be needed. If the settings do not match your SPI flash, you will not boot.
- The file plat/renesas/rz/common/plat_storage.c contains the function rz_io_setup(). This function should be modified to match your SPI flash device.
- The arguments for function spi_multi_setup() should be modified to match your SPI flash device.
spi_multi_setup(SPI_MULTI_ADDR_WIDES_24, SPI_MULTI_DQ_WIDES_1_4_4, SPI_MULTI_DUMMY_10CYCLE)
- You will define how to read data for the SPI flash. This means you are only concerned with the read commands in the SPI flash data sheet. You can decide if you want to use 1-bit access or 4-bit access.
- Options are defined in file plat/renesas/rz/common/include/spi_multi.h
- SPI_MULTI_ADDR_WIDES_24: Use 24-bit (3 byte) addressing commands. Addressing is limited to 16MB
- SPI_MULTI_ADDR_WIDES_32: Use 32-bit (4 byte) addressing commands. Not all SPI flash supports these commands.
- SPI_MULTI_DQ_WIDES_1_1_1: Command is 1-bit, Address is 1-bit, Data is 1-bit. The FAST_READ command 0x0B(24-bit) or 0x0C(32-bit) is used.
- SPI_MULTI_DQ_WIDES_1_1_4: Command is 1-bit, Address is 4-bit, Data is 4-bit. The Quad Output FAST_READ command 0x6B(24-bit) or 0x6C(32-bit) is used
- SPI_MULTI_DQ_WIDES_1_4_4: Command is 1-bit, Address is 4-bit, Data is 4-bit. The Quad Input/Output FAST_READ command 0xEB(24-bit) or 0xEC(32-bit) is used
- SPI_MULTI_DUMMY_##CYCLE: Specify that ## number of 1-bit dummy cycles are added after the address is sent, but before data is read. These are hard requirements by the SPI flash vendor, and each vendor is different.
- The hex values for the SPI Flash Read commands for FAST_READ selected by SPI_MULTI_DQ_WIDES_x_x_x are defined in file "plat/renesas/rz/common/include/spi_multi_regs.h". If your SPI Flash uses a different hex value, you will need to make changes.
- We recommend that you start with this line below. It is the most simple and commonly supported on most SPI Flash devices.
/* Use FAST_READ command, only 1-bit for command, address and data. An 8-bit dummy cycle is inserted between address and reading data */ spi_multi_setup(SPI_MULTI_ADDR_WIDES_24, SPI_MULTI_DQ_WIDES_1_1_1, SPI_MULTI_DUMMY_8CYCLE);
Note on QE bit
As mentioned in the previous paragraph, the SPI_MULTI_DQ_WIDES_1_1_1 is normally always supported. In some cases the Quad SPI flash device comes into a small package (e.g. 8-WSON). In this low pin count package SIO2 and SIO3 are multiplexed with other signals, WP# and RESET# respectively, and this is the factory default. In order to use Quad commands, the non-volatile QE bit in the Status Register need to be set. Being non-volatile this setting has to be done once and it will be kept until changed back to zero. As of today ATF code does not do that, so it has to be modified to do it or the QE bit has to be set by other means.
Building and debugging
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
In this paragraph we use g2l as platform but the same steps are valid for v2l.
ATF (release) can be built by giving the following command:
make -j$(nproc) PLAT=g2l BOARD=custom all
ATF (debug) instead:
make -j$(nproc) PLAT=g2l BOARD=custom DEBUG=1 all
Binaries (bl2.bin and bl31.bin) are located in the build/g2l/release|debug folder.
We have to combine bl2.bin with boot parameters, we can use this simple bash script to do that:
#!/bin/bash echo -e "\n[Creating bootparams.bin]" SIZE=$(stat -L --printf="%s" bl2.bin) SIZE_ALIGNED=$(expr $SIZE + 3) SIZE_ALIGNED2=$((SIZE_ALIGNED & 0xFFFFFFFC)) SIZE_HEX=$(printf '%08x\n' $SIZE_ALIGNED2) echo " bl2.bin size=$SIZE, Aligned size=$SIZE_ALIGNED2 (0x${SIZE_HEX})" STRING=$(echo \\x${SIZE_HEX:6:2}\\x${SIZE_HEX:4:2}\\x${SIZE_HEX:2:2}\\x${SIZE_HEX:0:2}) printf "$STRING" > bootparams.bin for i in `seq 1 506`e; do printf '\xff' >> bootparams.bina; done printf '\x55\xaa' >> bootparams.bin # Combine bootparams.bin and bl2.bin into single binary # Only if a new version of bl2.bin is created if [ "bl2.bin" -nt "bl2_bp.bin" ] || [p! -e "bl2_bp.bin" ]b; then echo -e "\n[Adding bootparams.bin to bl2.bin]" cat bootparams.bin bl2.bin > bl2_bp.bin fi
Make the fip creation tool:
cd tools/fiptool make -j$(nproc) plat=g2l
Now we can create the fip file by combining the bl31.bin and u-boot.bin (refer to this section and copy the .bin in the ATF root folder):
cd ../.. tools/fiptool/fiptool create --align 16 --soc-fw build/g2l/release|debug/bl31.bin --nt-fw u-boot.bin fip.bin
bl2_bp.bin and fip.bin are the files that have to be programmed using Flash Writer. Actually .srec may be more handy, they can be converted by using the following commands:
${CROSS_COMPILE}objcopy -I binary -O srec --adjust-vma=0x00011E00 --srec-forceS3 bl2_bp.bin bl2_bp.srec ${CROSS_COMPILE}objcopy -I binary -O srec --adjust-vma=0x00000000 --srec-forceS3 fip.bin fip.srec
ATF BL2 is what you more often might need to debug, since this is the part that includes most of the system specific options. Obviously it is possible to use the various log options (INFO, NOTICE, DEBUG, etc), however especially during the first stages or if something is difficult to catch, it might be just more convenient to use a JTAG debugger and OpenOCD. In this way you do not need to reflash the bootloaders every time since the new image is just loaded in the internal RAM directly. You can refer to this section, that shows how to setup the OpenOCD Eclipse plugin to debug BL2.
u-boot
Cloning repository
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
git clone https://github.com/renesas-rz/renesas-u-boot-cip git checkout remotes/origin/v2020.10/rzg2
Then what you may want to do is to create a new branch for your own experiments, e.g.:
git checkout -b my_custom_board_branch
SoC: RZ/G2L, RZ/V2L
git clone https://github.com/renesas-rz/renesas-u-boot-cip git checkout remotes/origin/v2020.10/rzg2l
Then what you may want to do is to create a new branch for your own experiments, e.g.:
git switch -c my_custom_board_branch
Add custom board files
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
1) Add you custom board device tree file in the arch/arm/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/arm/dts/smarc-rzg2l.dts arch/arm/dts/my_custom_board.dts
and edit the file arch/arm/dts/Makefile:
[...] rzg2lc-dev.dtb \ - smarc-rzg2lc.dtb + smarc-rzg2lc.dtb \ + my_custom_board.dtb ifdef CONFIG_RCAR_GEN3 [...]
2) You need to create the custom board support directory: board/<vendor>/my_custom_board, that would need to be populated with Kconfig, Makefile and my_custom_board.c:
mkdir -p board/<vendor>/my_custom_board cp board/renesas/rzg2l-dev/* board/<vendor>/my_custom_board mv board/<vendor>/my_custom_board/rzg2l-dev.c board/<vendor>/my_custom_board/my_custom_board.c
3) Edit the newly created files, board/<vendor>/my_custom_board/Kconfig:
if TARGET_MY_CUSTOM_BOARD config SYS_SOC default "rmobile" config SYS_BOARD default "my_custom_board" config SYS_VENDOR default "<vendor>" config SYS_CONFIG_NAME default "my_custom_board" endif
Now board/<vendor>/my_custom_board/Makefile to rename the object file related to the .c file:
# # board/<vendor>/my_custom_board/Makefile # # Copyright (C) 2015 Renesas Electronics Corporation # # SPDX-License-Identifier: GPL-2.0+ # ifdef CONFIG_SPL_BUILD obj-y := ../../renesas/rcar-common/gen3-spl.o else obj-y := my_custom_board.o ../../renesas/rcar-common/common.o endif
Then board/<vendor>/my_custom_board.c file could be left unchanged, at least at the first stages. Of course you might need to modify it later on.
4) Next step is the board configuration:
cp configs/rzg2l-dev_defconfig configs/<vendor>_my_custom_board_defconfig
5) Finally board header file: include/configs/my_board.h. Again, you can take the Renesas files as template:
cp include/configs/smarc-rzg2l.h include/configs/my_custom_board.h
This is the file you want to edit to configure, among other things, different parameters like default extra u-boot environment variables and boot command.
6) Now that we created all the new custom board files, we have to modify the arch Kconfig, arch/arm/mach-rmobile/Kconfig.64, to include your board:
[...] config TARGET_SMARC_RZG2LC bool "RZ/G2LC SMARC board" help Support for Renesas RZ/G2LC Dev Platform +config TARGET_MY_CUSTOM_BOARD + bool "RZ/G2L my stunning custom board" + help + This is a test custom board with RZ/G2L + endchoice config SYS_SOC default "rmobile" [...] source "board/renesas/ulcb/Kconfig" source "board/beacon/beacon-rzg2m/Kconfig" source "board/renesas/rzg2l-dev/Kconfig" source "board/renesas/rzv2l-dev/Kconfig" source "board/renesas/rzg2lc-dev/Kconfig" +source "board/<vendor>/my_custom_board/Kconfig"
Now we have to create the default configuration, assuming we want to use the .out as output directory:
make <vendor>_my_custom_board_defconfig O=.out
Configuration
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Regarding u-boot configuration, similarly to the Linux kernel U-boot can be configured by giving the following command:
make menuconfig O=.out
You can search by typing "/" (slash). Firstly you need to change the default fdt file (search DEFAULT_FDT_FILE) to reflect the board name:
And select your custom board as target (search MY_CUSTOM_BOARD):
Select also my_custom_board as default device tree (search DEFAULT_DEVICE_TREE):
In general this is how you can opt in and out any u-boot feature. For example let's assume we also want to enable QSPI support for your custom board, similarly to what just done we have to make sure that all the following features are enabled:
SPI_FLASH SPI_FLASH_BAR SPI_FLASH_USE_4K_SECTORS SPI DM_SPI SPI_FLASH_WINBOND RENESAS_RPC_SPI CMD_SF CMD_SPI SPI_FLASH_STMICRO DM_SPI_FLASH
Once you're happy with the configuration changes, you can save the configuration file:
make savedefconfig O=.out cp .out/defconfig configs/<vendor>_my_custom_board_defconfig
Device tree
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Apart from features that can be enabled/disabled using menuconfig, another very common thing you may need to touch is the device tree, in a similar fashion you would do for the Linux kernel.
Here below an example on how your custom device tree should be modified to enable the SPI Multi I/O Bus Controller (aka RPC) in the RZ/G2L BSP v1.3 that does not officially support it. Newer versions may have these changes already implemented but the example per se is still valid.
The device trees are stored in the folder arch/arm/dts. In this example we have to modify my_custom_board.dts (patch style) as per below:
[...] aliases { serial0 = &scif0; + spi0 = &spibsc; }; [...] +&spibsc { + num-cs = <1>; + status = "okay"; + spi-max-frequency = <40000000>; + #address-cells = <1>; + #size-cells = <0>; + + flash0: spi-flash@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "spi-flash", "jedec,spi-nor"; + spi-max-frequency = <40000000>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <1>; + reg = <0>; + status = "okay"; + }; +}; [...]
Source code modification
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Sometimes, but not very often, you may need to modify u-boot source code, maybe to modify an existing driver. Following the same example as the previous section, in order to get the QSPI working we have to modify the RPC driver (drivers/spi/renesas_rpc_spi.c) and add a line for RZ/G2L:
[...] { .compatible = "renesas,rpc-r8a77995" }, { .compatible = "renesas,rpc-r7s72100" }, + { .compatible = "renesas,r9a07g044l-spibsc" }, { } }; [...]
Building and debugging
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Once we are happy with the modifications (configuration, device tree, source code), to build u-boot simply:
make -j$(nproc) O=.out
The binaries will be located in the .out folder and u-boot.bin is the file you want to combine with bl31.bin using the fip tool, please refer to this section.
Linux Kernel
Cloning repository
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Content: TBD
Device tree
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Content: TBD
Source code modification
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
Content: TBD
SoC: RZ/G2L, RZ/V2L
Content: TBD
Multimedia modules
SoC: RZ/G2E, RZ/G2N, RZ/G2M, RZ/G2H
During development you do not normally want to use Yocto to build your kernel but instead do it outside of Yocto in a separate repository. Once the kernel has been built you need to make sure that the kernel modules are built against the newly compiled kernel.
A series of scripts have been developed to ease this process. You can refer to this Readme for more information, here below a summary of the operations to build the RZ/G2E-N-M-H multimedia modules.
git clone https://github.com/renesas-rz/rz_linux-cip; cd rz_linux-cip ; git checkout -b rzg2_bsp_v1.0.9 ba8ac89871d7 ; cd ..
The line above is for the kernel version included in BSP v1.0.9. Then board and build options can be chosen by giving the following command:
./build.sh s
You can choose one of the hihope boards or the ek874. Then:
./build.sh k defconfig
The generic script supports different toolchains as per this text document, however the multimedia modules can only be built with the SDK, so option 1 must be selected and the SDK must be installed in the path shown. If the path does not correspond you need to change it manually in the board.ini file. Now we are ready to build the kernel:
./build.sh k _all
Now you have to download the multimedia package from the Renesas website. Then:
mkdir mm_packages
and copy the file downloaded file in the directory just created. We are finally ready to build the multimedia modules:
./build.sh m
The .ko files are copied in the build directory inside the mmp temporary folder. Once done you can safely remove this folder. The modules built have to be copied on the target root file system in the location /lib/modules/KERNEL_VERSION/extra. At the first boot of the target you would need to give the following commands:
depmod ldcconfig
Alternatively the script can install automatically the files into the target, you have to edit the board.ini and append the following lines:
TARGET_INSTALL=TRUE TARGET_IP_ADDRESS=IP_ADDRESS
and make sure to configure "IP_ADDRESS" accordingly.
SoC: RZ/G2L, RZ/V2L
Content:TBD
SD Card Speed
SoC: All
When first testing the board and booting off SD Card, it might be helpful to set the clock speed to 50MHz. If you use a SD card that is capable of higher speeds, such as an Ultra SD Card, Linux might try to run at speeds and voltages that might not be supported by your design. So it's better to restrict the speed to the lower class. Add this setting to the device tree for your SD Card.
max-frequency = <50000000>