DVFS

[ThomasKaiser]

Did you ever try out to specify the upper 1.3V dvfs operating points the 'usual' way: 11300 vs. 1100?

dvfs_table {
	compatible = "allwinner,dvfs_table";
	max_freq = <0x3c14dc00>;
	min_freq = <0x1c9c3800>;
	lv_count = <0x8>;
	lv1_freq = <0x44aa2000>;
	lv1_volt = <0x2c24>;
	lv2_freq = <0x41cdb400>;
	lv2_volt = <0x2c24>;
	lv3_freq = <0x3c14dc00>;
	lv3_volt = <0x2c24>;
	lv4_freq = <0x30a32c00>;
	lv4_volt = <0x44c>;
	lv5_freq = <0x1c9c3800>;
	lv5_volt = <0x44c>;
	lv6_freq = <0x0>;
	lv6_volt = <0x44c>;
	lv7_freq = <0x0>;
	lv7_volt = <0x44c>;
	lv8_freq = <0x0>;
	lv8_volt = <0x44c>;
	device_type = "dvfs_table";
};

(please don't forget to allow/add 2 more states above 1008 MHz in cpu_budget_cool too). I would believe there's a test point on the board to measure and at least cpuburn-a53 should be able to confirm reliability.

BTW: In case that works, then please check situation with all H3 boards too -- at least all images I tried so far from Xunlong's download section were broken here and specified the upper voltage wrong. For details please see: https://forum.armbian.com/index.php/topic/724-quick-review-of-orange-pi-one/

[ThomasKaiser]

Hmm... feeling somewhat stupid now since I forgot that OPi PC 2 isn't equipped with SY8113B (switching between 1.1V and 1.3V only) but comes with SY8106A instead (fine grained voltage adjustments). So my proposed values for OPi PC 2 above are all more or less nonsense (but the basic principle might help cure OS images for the smaller H3 Oranges).

But already as a reference for all those guys eagerly trying to 'overclock' H5. Simply take the two hours and read carefully through longsleep/build-pine64-image#3 first.

H5 has a way more capable GPU than A64 so thermal issues are even more an issue. And undervoltage is always a nice way to decrease stability/reliabity and great for data corruption.

[BuddyZhang1]

@ThomasKaiser
Thanks for your advice, I will do some test about this issue.

[ThomasKaiser]

Anyone already tried this out (pmuic_type = <0x2>;):

dvfs_table {
	compatible = "allwinner,dvfs_table";
	pmuic_type = <0x2>;
	max_freq = <0x44aa2000>;
	min_freq = <0x1c9c3800>;
	lv_count = <0x8>;
	lv1_freq = <0x44aa2000>;
	lv1_volt = <0x514>;
	lv2_freq = <0x41cdb400>;
	lv2_volt = <0x4ec>;
	lv3_freq = <0x3c14dc00>;
	lv3_volt = <0x4b0>;
	lv4_freq = <0x30a32c00>;
	lv4_volt = <0x44c>;
	lv5_freq = <0x269fb200>;
	lv5_volt = <0x410>;
	lv6_freq = <0x0>;
	lv6_volt = <0x44c>;
	lv7_freq = <0x0>;
	lv7_volt = <0x44c>;
	lv8_freq = <0x0>;
	lv8_volt = <0x44c>;
	device_type = "dvfs_table";
};

At least with A64 it was necessary to make this change already within u-boot since DVFS settings were ignored when only adjusting the values in the .dtb lying around.

Voltage values adjusted to comments here.

[ThomasKaiser]

@ehoutsma @tkggithub @sv1eia this needs some testing (and I can't test any more since I sent my board to the person who did mainline u-boot support for H5 weeks ago)

[sv1eia]

@ThomasKaiser
What exactly is the test you would like on that?
What do you need to test now that we got dtb with user changes working?

[ThomasKaiser]

No, it's not about this .dtb stuff in the filesystem!!

At least with A64 it was necessary to make this change already within u-boot since DVFS settings were ignored when only adjusting the values in the .dtb lying around.

[ehoutsma]

I'll run a few tests in the morning. If it isn't overwritten the fdt commands are helpfull.

[ThomasKaiser]

@ehoutsma Hmm... can't work anyway (was just a thought since with H3 legacy kernel it's just like that). Maybe the magic is contained somewhere here: axpdummy or https://github.com/OrangePiLibra/OrangePi_H5SDK/tree/master/u-boot/drivers/arisc

[ehoutsma]

The arisc seems to load the dvfs from fdt. But we'll find out tomorrow.

[ThomasKaiser]

Hmm... AXP_TWI_USED seems to be related to 'real' PMICs (but maybe it has to be set to let axpdummy driver talk to SY8106A via I2C?) but POWER_SUPPLY_DEBUG=y could be helpful...

[tkggithub]

The initial dvfs table is loaded in the binary scp's header by the update_scp tool.

Then it is also loaded from u-boot and transferred to scp (arisc, ar100, or cpu-s however you prefer to name it), I would also not rule out the arisc code from the kernel that could interact with dvfs.
See for instance the kernel/drivers/arisc folder.

Regarding u-boot:
The arisc_dvfs_cfg_vf_table is one place to load the table and that is called from sunxi_arisc_parse_cfg which is called from sunxi_arisc_probe which is called from power_source_init which is called based on the init_sequence_r array.
Given that these calls are happening before the main u-boot interpreter is run, I would say the information used is the one stored in the dtb that is placed after the u-boot and merged together with bl31 and scp into the main firmware package later flashed as uboot.
I would also note that the configuration from arisc_dvfs_cfg_vf_table is also possibly transferred to bl31 through dts_cfg_64.

How the table is actually (mis)used :) within the arisc core ... still remains unknown at least for me as I have only seen the binary.

I still have few questions about the scp binary as at least the version it reports seems to be for an a33 and not h5.
See for instance the arisc version message from a pastebin I have posted few days ago:

SCP] :arisc version: [sun8iw5_v0.03.00-244-gb750b8e]

[ThomasKaiser]

Well, now that @ehoutsma confirmed that mainline H3 ths patches work in a similar way with H5 I won't spend any more time on this BSP mess.

Small note: https://github.com/igorpecovnik/linux/search?utf8=%E2%9C%93&q=pmuic_type

Not a single reference to pmuic_type in H3 legacy kernel sources but there it is key to success. Maybe the whole definition is solely handled by arisc. So why on earth not simply trying it out to see what happens?

And I know I'm repeating myself: but dvfs stuff has to happen in u-boot already so please don't fiddle around with dtc in Linux but use the appropriate definition that's used by u-boot+spl (be it DT or sys_config.fex or whatever).

[ThomasKaiser]

Again wrong (my search in H3 legacy kernel was in empty master branch instead of sun8i branch). In H3 legacy kernel pmuic_type is used in drivers/arisc/interfaces/arisc_dvfs.c. Ok, I finally give up :)

[ehoutsma]

@ThomasKaiser I altered the dvfs_table, changing the max_freq from 1008MHz to 816MHz in the user dtb, and that is reflected in the cpufreq_max_freq and the max freq is limited to 816MHz. Max_freq still seems to be limited to 1008MHz.

I can't test wether changing the freq/voltage combination is applied since I can't read the sy8106a at the moment and I haven't seen proof that the sy8106a is used anyway.

Altering the budget cooling works as well from user dtb.

[tkggithub]

@ehoutsma
I think that the trend is to let the arisc core handle the dvfs and therefore not the kernel directly.
The kernel has its selected governor that attempts to schedule a specific freq, but in the end that freq can be passed to the arisc core and the arisc core can decide on the voltage to use from its dvfs table and make it happen using calls to the voltage generator chip.

The kernel has calls to the monitor (BL31) to request a specific freq.
BL31 forwards these calls to the arisc core.
Also please be aware that there is also a cooling budget and if you try to set a freq that has no cooling budget entry, that freq can be ignored even if your dvfs table has a match for it.

I tried for instance setting 1.2Ghz as scaling_max and that was clamped to 1.08Ghz.
If you try to do that and check dmesg you should see a message from "CPU Budget" that 1.08Ghz is max that it knows. Obviously you can modify the cooling states (another table separate from dvfs), and this is my point that there are more things that go hand in hand to ensure you reach a specific freq/volt combination.

One way to check if voltage is taken into consideration would be to modd the 480Mhz voltage. On idle the cpu sits mostly there. With an external power meter you can see if there is any significant diff from changing the voltage for instance from 1.1V to 1,3V. If there is one then you know that your dvfs voltage table is used.
Again I think the table used by the arisc core is the one from the dtb appended to the u-boot.
Also as there are calls to set the table in the BL31 source (from lichee SDK), I would think that that table could be modified also by the kernel if somebody really wants it. I also find it strange that u-boot has a call (towards BL31) to let the arisc core that a new table has been loaded commented out. It only has the call to set the table.
Maybe because a reset for arisc comes later, arisc still loads this table.

I still need to adapt a suitable plug for my usb power meter and maybe I'll be able to test it over the weekend.

[ehoutsma]

Adapting the DVFS table, changing max_freq to 816MHz works from the start, to increase the speed, I had to change the cooling_budget_table as well, but that worked like a charm. Enter 1152 in both the max_freq and cooling_budget_table makes it run at 1152 MHz, but still at 1100mV, changing lv1_volt doesn't help.

[tkggithub]

@ehoutsma
How did you checked that the voltage is still 1100mV?

[ehoutsma]

Measure the voltage at the 1V1C point.

[tkggithub]

@ehoutsma
That should be the proper point to measure it.
I was hoping that maybe you succeeded to get scp to output some debug messages but measuring it directly on the board is good enough for me. :)

[tkggithub]

Having investigated a bit more the issue, I think there is at least some redesign of dvfs from the lichee SDK.
Basically the call to parse the dvfs table from dtb has been obliterated. More exactly the call for arisc_dvfs_cfg_vf_table has been removed from sunxi_arisc_parse_cfg.
This seems to have been the case from the beginning of the u-boot source commit in github.
The BL31 code receives a totally empty dvfs configuration table. :(
Later on, in the kernel there is some code to parse the table in sunxi_cpufreq.c but I don't know if it is used.

The more interesting part is that arisc_axp.c from kernel/drivers/arisc/interfaces does have functions that issue BL31 calls (that should end-up in the arisc core) to set some voltages.
I saw those calls arriving to BL31.

Look for the ARM_SVC_ARISC_SET_PMU_VOLT define for more info. Whether those calls are for cpu voltages or other peripherals I don't know yet. :)

Anyway, the short story is that the dvfs table is no longer (properly) loaded by uboot.
Somebody can look what the kernel does with it w.r.t voltages. :)
I would have expected to see a call using ARM_SVC_ARISC_CPUX_DVFS_CFG_VF_REQ in the kernel but there seems to be none.

[tkggithub]

I decided to dig a bit on the hardware side and at least for my setup (using a slightly modded BL31 from the lichee SDK) I could see no trace of any activity on the TWI (I2C) bus going to SY8106A during normal run of OPI PC2.
I do see that the scl and sda signals are going low when the device is powered off, and they come up to about 3.28V once the pull-ups get active but that is all.
I suspect the scp code is not really talking with the SY8106A voltage regulator.
Maybe it does not have the proper pinout set?.
Anyway I was able to talk to the voltage regulator using an external device (bus pirate) and I could read registers 1,2, and 6 mentioned in the voltage regulator data sheet and then later on to modify reg 1 (set it to 0xB4) and the voltage got changed to 1.2V.
On the initial reading of register 1 it was 0 (no I2C voltage control set),
Also if the system is powered down using "sudo poweroff" it reboots to u-boot and waits for a power key or ir key .... Yeah right ... :)
Well in this state the voltage regulator I2C interface is off and the output voltage from the regulator is 0.

[tkggithub]

I succeeded to finally get some very limited output from arisc. The missing bit for me was that arisc uses a separate uart for debug (using pins PL02(tx) and PL03(rx)). PL03 does not seem to be even routed but at least PL02 is available as it is also used to set usb0 voltage. I did took out for now R41 so that when enabling PL02 for serial not to toggle usb0 power and I enabled the arisc serial.

This is for instance some output:

[0000.00] pmu is not exist
[0000.00] para :
[0000.00]
0x4000     : 48105000 1000     40020000 800
0x4010     : 1        0        0        0
0x4020     : 1        0        0        2309621
0x4030     : 32       10       57       9F00
0x4040     : 1A       FB04     14       7F80
0x4050     : 15       7F80     B        F708
0x4060     : 3        EF       DC       4CB3
0x4070     : A        7748     45       BD02
0x4080     : 4D       DE21     18       FE01
0x4090     : 57       FF00     4D       FF40
0x40A0     : 88       DD22     D        BC00
0x40B0     : D        2A0      3        3B3BF9
0x40C0     : 1        10F410F4 4000000  1C70
0x40D0     : 40       18       0        48A192
0x40E0     : 1B1B18D  76051    B4787896 0
0x40F0     : 0        64       1E08A1E0 0
0x4100     : 0        2535     23330000 8897
0x4110     : 4006913  4002910  44AA2000 44C
0x4120     : 0        41CDB400 44C      0
0x4130     : 3C14DC00 44C      0        30A32C00
0x4140     : 44C      0        25317C00 44C
0x4150     : 0        0        44C      0
0x4160     : 0        44C      0        0
0x4170     : 44C      0        0        0
0x4180     : 0        0        0        0
0x4190     : 0        0        0        0
0x41A0     : 0        0        0        0
0x41B0     : 0        0        0        0
0x41C0     : 0        0        0        0
0x41D0     : 0        0        0        0
0x41E0     : 0        0        0        0
0x41F0     : 0        0        0        0
0x4200     : 0        0        0        0
0x4210     : 0        0        0        0
0x4220     : 0        0        1        1
0x4230     : 1        0        0        0
0x4240     : 0
[0005.00] ------------------------------
[0005.00] stack free:608byte
[0010.00] ------------------------------
[0010.00] stack free:608byte
[0015.00] ------------------------------
[0015.00] stack free:608byte
[0020.00] ------------------------------
[0020.00] stack free:608byte
[0025.00] ------------------------------
[0025.00] stack free:608byte
[0030.00] ------------------------------
[0030.00] stack free:608byte
[0035.00] ------------------------------
[0035.00] stack free:608byte

Maybe the "pmu is not exist" is relevant as it seems to claim that there is a missing configuration.
There is also a related "pmu is exist" message in the scp binary (probably for when the pmu is properly configured) or maybe it just looks for a proper axp power manager and then indeed no axp chip is present on OPI PC2.
Another interesting thing is that when I poweroff ("sudo poweroff") and the board reboots to uboot and then enters into a standby state, the main cpu voltage regulator is disabled but the arisc seems to be powered from vcc-rtc and keeps going. It even prints a few error messages (at a strange baudrate around 60000) if I press a button on an ir remote. :)

Does anyone know what this "pmu is not exist" from arisc really means?

[tkggithub]

Hi @BuddyZhang1,
is anyone (you or someone from orangepi) investigating the DVFS issue?

Or at least can someone confirm that the SCP binary has code to handle SY8106A?
The kernel seems to call BL31 and from there the SCP.

[ThomasKaiser]

Call for testers. In the meantime due to kind souls continually improving things (thanks @ehoutsma !) we have DVFS running with latest mainline kernel. So any board owners involved here wanting to help please feel free to try it out, do some stress tests and report back then: https://forum.armbian.com/index.php/topic/2869-armbian-for-orangepi-pc2-allwinner-h5/?p=23975