RZ-G/RZG kernel

← RZ-G

CPU Hotplug

You can enable and disable CPU cores by writing to a sysfs value.
This is helpful for when you want to experiment with the performance of your application if you were to use a processor with less CPU cores.

For example, this command will disable the 2nd core.

$ echo 0 > /sys/devices/system/cpu/cpu1/online

More detailed information can be found here: https://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu

Power Saving

• In Linux, this is a mechanism that is generally supported by all kernels.(it may depend on the version)
• The Renesas kernel has support them.

About power consumption in RZ/G2 series, we have some supported features to save power cost in default environment:

• CPUHotplug: Turn on/off CPU in runtime.
• CPUIdle: Support 2 modes to turn off clock or power domain of CPU when CPU is idle (nothing to do).
  • Sleep mode: put in sleep state.
  • Core standby mode: put in shutdown state. It is described in devicetree of each SoC => It has deeper state than sleep mode so that save more power.
• CPUFreq: there are 6 governors to support "Dynamic Frequency Scaling":
  • Performance: The frequency is always set maximum => It is using as default in our current environment.
  • Powersave: The frequency is always set minimum.
  • Ondemand: If CPU load is bigger than 95%, the frequency is set max. If CPU load is equal to or less than 95%, the frequency is set based on CPU load.
  • Conservative: If CPU load is bigger than 80%, the frequency is set one level higher than current frequency. If CPU load is equal to or less than 20%, the frequency is set one level lower than current frequency.
  • Userspace: It sets frequency which is defined by user in runtime.
  • Schedutil: Schedutil governor is driven by scheduler. It uses scheduler-provided CPU utilization information as input for making its decisions by formula: freq_next= 1.25 * freq_max* util_of_CPU.
• Power Domain: it is supported as default by Linux Power Management Framework. If a module is not use, system will disable its clock and power domain automatically.

Therefore, select proper method will be based on user's purpose. Here are my examples:

• Want to use with best performance: disable CPUIdle + use performance frequency governor.
• Want to use less power: enable CPUIdle + use powersave frequency governor.
• Want to balance performance and power: we can use schedutil.
• Want to modify frequency as user's purpose: use userspance frequency governor.
• If user is running realtime environment, I suggest using performance governor to ensure the minimum latency.

Here are some commands to check frequency value and frequency governor in linux:

• Check available CPU frequency:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies

• Check available CPU frequency governor:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors

• Change to other governor:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor (performance/userspace/schedutil/...)

• Check current frequency:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

PMIC Access from Linux

The easiest way to access the PMIC registers from command line would would be to use i2ctools. Add the following line to your local.conf.

IMAGE_INSTALL_append = " i2c-tools"

However the PMICs are connected to a I2C (IIC for PMIC or I2C_DVFS) that is not enabled in the default kernel device tree. For the HiHope boards, you can edit the file arch/arm64/boot/dts/renesas/hihope-common.dtsi and add the following lines at the very bottom of the file.

&i2c_dvfs {
	status = "okay";
};

Once booted in Linux, the corresponding device should be /dev/i2c-7

You can query the connected slaves by giving the following command:

i2cdetect -y -r 7 

that on the RZ/G2E board produces the output:

0 1 2 3 4 5 6 7 8 9 a b c d e f 
00: -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e 1f 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  

So two slaves, at address 0x1e and 0x1f. Finally you can read registers by simply using the i2cget command, for example:

i2cget -y 7 0x1e 0x1 
0x02 
i2cget -y 7 0x1e 0x16 
0x00 
i2cget -y 7 0x1e 0x17 
0xc4 

If you don't want (or can't) update the device tree blob, you could use u-boot to do it temporarily. The procedure below is valid for RZ/G2M but it works also with RZ/G2E-N-H by simply modifying the device tree blob and/or kernel image names.

1) Interrupt the normal kernel boot

2) Once in u-boot, enter the follow commands (after each RESET)

=> fatload mmc 0:1 0x48080000 Image; fatload mmc 0:1 0x48000000 Image-r8a774a1-hihope-rzg2m-ex.dtb;  
=> fdt addr 0x48000000 
=> fdt set /soc/i2c@e60b0000 status "okay"

and finally boot the kernel:

=> booti 0x48080000 - 0x48000000 

Create a uImage

In the kernel, there is no make target to make a uImage for the 64-bit ARM architecture like there is for 32-bit ARM. However, you can manually make one from the file Image.gz that is created by the kernel build system by using the following command on your host machine.

$ cd arch/arm64/boot
$ mkimage -A arm64 -O linux -T kernel -C gzip -a 0x48080000 -e 0x48080000 -n "Linux Kernel Image" -d Image.gz uImage

Below is an example of booting this image on a RZ/G2 HiHiope board from u-boot.

=> fatload mmc 0:1 0x88000000 uImage
=> fatload mmc 0:1 0x48000000 Image-r8a774e1-hihope-rzg2h-ex.dtb
=> bootm 0x88000000 - 0x48000000

Building mainline / LTS Linux kernel for RZ/G2E-N-M-H (LTS 5.x.y)

The Verified Linux Package (VLP) includes the CIP kernel (v4.19.x) and this is the only official way to build a kernel that has all the features in. However it is possible to build a working kernel directly from mainline. The kernel built in this way does not provide most of the multimedia functionalities (e.g. GPU, codec, etc).

A recent Linaro toolchain is needed to build the kernel. The instructions below are for v5.10.x, newer kernel versions can be built as well in a similar way.

git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/

git checkout tags/v5.10.42

or anyway the latest minor revision including bug fixes.

Copy Renesas default kernel build into .out/.config:

cp arch/arm64/configs/renesas_defconfig .out/.config

or, if not present, get from the repository:

wget -O .out/.config https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/plain/arch/arm64/configs/renesas_defconfig

If you want to be able to build modules:

echo CONFIG_MODULES=y >> .out/.config

echo CONFIG_MODULE_UNLOAD=y >> .out/.config

Run kernel configuration:

make O=.out menuconfig

Exit and save. Then launch the build:

make O=.out all -j$(nproc)