XFer012

Ok, setting 1.8/2.4 is still OK and completes the test, but real clockspeed is 2276 MHz. That's OK since my A76 pvtm-volt-sel is 5 not 7 (max silicon quality). Geekbench scores are satisfying https://browser.geekbench.com/v5/cpu/21182824 Issue closed I'd say.

Switched to 150balbes' "Lunar" image (kernel 6.2.0 rc1) and now I can successfully complete Geekbench 5.5.1 @ 1.8 A55 / 2.2 A76 Scores are better as well: https://browser.geekbench.com/v5/cpu/21182173 , expecially considering 2.2 GHz (true speed = 2.246 GHz according to "mhz")

Many people run GB without issues @2.4, was wondering where to look for, since mine cannot run over 2.0 which is quite a difference.

Hello, I am running Armbian 23.05 "minimal" (with the provided kernel 5.10.110) on my OrangePI 5 4GB. Upgraded all packets to latest. When trying to run GeekBench 5.5.1 ARM Preview, it reboots when approaching the end of multicore tests, with "performance" governor and default speed range (0.4 - 2.4 GHz for A76). Same goes if I drop the max clock speed to 2.2 for A76. After dropping to 2.0 GHz max, it runs fine; but this hurts performances quite a bit. I tried various power sources, including a bench PSU which can reliably supply up to 30A (but I only see a few spikes over 2A). The board has a large heatsink installed with thin 3M thermal pad; temperatures stay under 54 C under full load. I suspected a bad silicon, but it does not look bad, should ad least reach 2.2 GHz: root@orangepi5:~# dmesg | grep pvtm [ 6.624098] rockchip-pvtm fda40000.pvtm: pvtm@0 probed [ 6.624154] rockchip-pvtm fda50000.pvtm: pvtm@1 probed [ 6.624207] rockchip-pvtm fda60000.pvtm: pvtm@2 probed [ 6.624270] rockchip-pvtm fdaf0000.pvtm: pvtm@3 probed [ 6.624321] rockchip-pvtm fdb30000.pvtm: pvtm@4 probed [ 7.352652] cpu cpu0: pvtm=1487 [ 7.352872] cpu cpu0: pvtm-volt-sel=4 [ 7.362528] cpu cpu4: pvtm=1723 [ 7.366667] cpu cpu4: pvtm-volt-sel=5 [ 7.376888] cpu cpu6: pvtm=1731 [ 7.381119] cpu cpu6: pvtm-volt-sel=5 [ 7.561843] mali fb000000.gpu: pvtm=881 [ 7.563822] mali fb000000.gpu: pvtm-volt-sel=3 [ 7.612340] RKNPU fdab0000.npu: pvtm=896 [ 7.617305] RKNPU fdab0000.npu: pvtm-volt-sel=4 Any suggestion? Thanks!

Necroposting, I know, but just in case someone else googles up this thread as I did. The MPI3508 3.5" screen is cheap and sold a ton apparently. So the problem is, the display is actually 480x320 but identifies itself as 1024x768 (!), which is not correct as size and not even as aspect ratio (4:3 vs. actual 3:2) Trying to force 480x320 in armbianEnv.txt does not work, the display shows nothing; probably there are no proper timings in the kernel/DTB/whatever for such low an HDMI resolution. So the trick is using 720x480, which is 1.5x the actual resolution. The aspect ratio is correct, the timings are there, and after all it's even quite readable. So in /boot/armbianEnv.txt add: extraargs=video=HDMI-A-1:720x480@60 disp_mode=720x480 and then recompile boot.scr: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Display should run fine. fbset reports: mode "720x480" geometry 720 480 720 480 32 timings 0 0 0 0 0 0 0 accel true rgba 8/16,8/8,8/0,0/0 endmode which may be added to /etc/fb.modes Hope this helps, despite not being optimal.

Nice!! Is it stock Armbian, or did you have to patch something/rebuild kernel/rebuild uboot / etc?

I would test it gladly. Is it OK to install it on an Armbian Unstable? It's what I have now. If you advice against it, no problem, will reinstall.

You may try with the latest Unstable kernel (based upon 5.11.x), but I don't think WiFi works even with that one.

I think hexdump added some DTS patches to: https://github.com/jernejsk/linux-1/tree/h616-hdmi Me, I was unable to "integrate" that kernel into mainline. But I'm a newbie.

I think he was referring to Armbian, which does not reboot even with genuine Sandisk cards. I seem to remember that at a certain point, amid various kernel reconfig/rebuilds, I had it rebooting properly by disabling "Enable suspend to disk" and disabling "Enable hibernate" in kernel Power Management section. But I'm not 100% sure.

Confirmed. At some point, rebuilding the latest mainline kernel from the Unstable branch, I managed to have the board rebooting properly; but it was in the middle of many tests and never managed to succeed again.

Indeed. For example, my Rock64 and my Neo3 are stable at 1.3 GHz with -25mV and -50mV respectively vs. default OPP values. Silicon lottery. It's still strange that H6 DTS lacks a proper OPP. Maybe with Unstable kernel, based upon 5.11 mainline? Some patches for H6 were included in 5.11 and accompaining DTS.

The OP asked for undervolting, not underclocking. @hcacIt's strange that the DTS lacks the OPP with the microvolts for each frequency step. Could you post it?

Maybe my problem is a bit different then. My Rock64 (with both Armbian Stable and Unstable) does not reboot after "sudo poweroff": it performs the shutdown sequence, but does not really "power off". It is halted, does not respond to login or ping, but the peripherals are still powered and the board still draws the typical idle current (about 220 mA); the heatsink stays warm too.

This sounds like good news!! Maybe poor little H616 is going to get some love by mainline kernel? Fingers crossed!! Arm updates in Linux 5.12 Removal of several obsolete 32-bit Arm platforms – efm32, picoxcell, prima2, tango, u300, zx, and c6x, as well as associated device drivers. Allwinner Allwinner H616 and H616-R – Initial support including pin controllers, clocks Allwinner/sunxi power management Various DTS changes ...