RZ-G/RZG2 kernel

RZ/G2 Kernel and Linux FAQ

= 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.

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: Here are some commands to check frequency value and frequency governor in linux:
 * 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.
 * Check available CPU frequency:


 * Check available CPU frequency governor:


 * Change to other governor:


 * Check current frequency:

= 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.

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  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:

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