Jump to content

Armbian for OrangePi PC2, AllWinner H5


Christos

Recommended Posts

11 hours ago, znoxx said:

My armbian "cluster" works 24x7 with full load

Znoxx, What is your Armbian cluster? and what does it do?

 

I have been seriously thinking about the FUN of building a cluster but I can not think of a use or purpose that ?

 

 

PS have you bench-marked your Orange Pi PC2 and or cluster?

 

Seasalt

Link to comment
Share on other sites

@Seasalt, not sure I've got the question "What is your cluster" -- link I posted do have some pics :) and there is a "translate" button in menu (better than nothing).

About cluster purpose -- currently it it mining some Verium crypto.

Before I tried Apache Spark, for example. But not really successfull due to faulty microSDs and large number of read/write.

Regarding benchmark - in mining (hashrate) it is comparable to e.g. core i5..i7, but well -- it consumes much less energy.  E.g. 60..70 watts vs 150..200.

I was inspired by this guy http://picocluster.com -- but my setup is much more cool :)). I'm using custom PCB to drive ATX PSU and fans.

 

Link to comment
Share on other sites

@znoxx

Nice job! I like the way how it looks, handmade devices have their own charm! :)

 

So the debug proccess is still in process. I tried u-boot 2017.11 but got unfortunately no success.

Would you please check "dmesg" of one of yours OPI PC2? Thank you in advance.

The problem is it's almost impossible to notice the crash when there's no serial cable attached nor display as system recovers it but also notices in dmesg.

Spoiler

[  219.123436] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
[  219.132368] Mem abort info:
[  219.135292]   ESR = 0x96000004
[  219.138419]   Exception class = DABT (current EL), IL = 32 bits
[  219.144427]   SET = 0, FnV = 0
[  219.147569]   EA = 0, S1PTW = 0
[  219.150830] Data abort info:
[  219.153734]   ISV = 0, ISS = 0x00000004
[  219.157667]   CM = 0, WnR = 0
[  219.160744] user pgtable: 4k pages, 48-bit VAs, pgdp = 0000000022abd91e
[  219.167460] [0000000000000088] pgd=0000000000000000
[  219.172458] Internal error: Oops: 96000004 [#1] SMP
[  219.177346] Modules linked in: zstd zram sun8i_codec_analog snd_soc_hdmi_codec snd_soc_simple_card sun8i_adda_pr_regNmap sun4i_i2s sun4i_codec snd_soc_simple_card_utils snd_soc_core snd_pcm_dmaengine snd_pcm cpufreq_dt snd_timer sun4i_gpadc_iio industrialio thermal_sys sunxi_cir rc_core snd w1_therm soundcore w1_gpio wire lima sy8106a_regulator gpu_sched ttm dw_hdmi_i2s_audio dw_hdmi_cec uas realtek
[  219.212663] CPU: 2 PID: 2473 Comm: grep Not tainted 4.19.8-sunxi64 #5.67.181213
[  219.219971] Hardware name: Xunlong Orange Pi PC 2 (DT)
[  219.225120] pstate: 00000005 (nzcv daif -PAN -UAO)
[  219.229945] pc : _get_random_bytes+0xac/0xe8
[  219.234255] lr : _get_random_bytes+0xac/0xe8
[  219.238547] sp : ffff00000d26bbc0
[  219.241876] x29: 0000000000000000 x28: ffff80002a676100
[  219.247203] x27: 0000000000000002 x26: ffff80002ff85780
[  219.252527] x25: ffff80003634f000 x24: ffff800033e2e900
[  219.257848] x23: 0000000000000010 x22: ffff000008d688c8
[  219.263176] x21: ffff00000d26bc08 x20: 0000000000000010
[  219.268494] x19: ffff00000d26bd58 x18: 0000000000000000
[  219.273811] x17: 00000000cf0ed6af x16: 000000009759a261
[  219.279135] x15: 00000000846c09cb x14: 00000000e1321b33
[  219.284464] x13: 00000000ab8ed928 x12: 00000000e3b80007
[  219.289786] x11: 000000005ceb0788 x10: 000000003ce02806
[  219.295107] x9 : 00000000c61535a9 x8 : ffff00000d26bc48
[  219.300427] x7 : 0000000000000000 x6 : ffff00000d26bc08
[  219.305757] x5 : ffff800033d5e400 x4 : 0000000000000008
[  219.311088] x3 : 0000000000000030 x2 : 0000000000000008
[  219.316408] x1 : 0000000000000000 x0 : ffff00000d26bc08
[  219.321738] Process grep (pid: 2473, stack limit = 0x000000004c1dba41)
[  219.328266] Call trace:
[  219.330732]  _get_random_bytes+0xac/0xe8
[  219.334662] Code: d2800801 aa1503e0 912322d6 940ed73a (f94047a1)
[  219.340765] ---[ end trace 71540e1e95143ba8 ]---

I tried ATX power supply as well - so got same problem and also soldered 1000uF 10v capacitor directly to power supply connector to be sure there's no power fluctuation because of long cables but the problem still persists.

Link to comment
Share on other sites

@svts

Here is dmesg from 2 nodes.

One bought long time ago:

 

https://pastebin.com/Q0As9JTh

 

And second from node which was recently replaced due to dead Ethernet (still not sure, that I picked right node, but anyway -- 2 dmesgs better than one):

 

https://pastebin.com/8s91VAuU

 

Hope it will help you. I still have a strong feeling, that the problem is inside hardware (RAM). May be it makes sense to order new one from official store@Aliexpres ? Just to be sure. I can bet, it will arrive faster, than you will debug the thing...

 

Link to comment
Share on other sites

@znoxx
Thank you. Well actually I did just what you said. When I started expecting some issues I ordered a new board and when it arrived I confimed that the problem did persist. Technically it's possible that the board I ordered has the same buggy parts but... it's almost unbelievable you know :)

Link to comment
Share on other sites

@Seasalt, thanks! :) I'm working on new version, with OpiOne+ (faster!! newer :)) and fitted into standard microATX case. Want something more standard and reproducible.

 

@svts Hmm... You are right. I even upgraded whole bunch of board to latest armbian to check if it is an issue of latest builds. But looks like no. ~1 hour 100% load, no "mayday mayday"

 

zno@cluster:~$  for i in `seq 0 9`; do ssh node$i uptime; done
 10:47:44 up  1:02,  0 users,  load average: 4.01, 4.03, 4.00
 10:47:45 up  1:01,  0 users,  load average: 4.08, 4.02, 4.01
 10:47:46 up  1:01,  0 users,  load average: 4.18, 4.06, 4.02
 10:47:47 up  1:00,  0 users,  load average: 4.00, 4.01, 4.00
 10:47:48 up  1:00,  0 users,  load average: 4.00, 4.00, 3.99
 10:47:50 up 59 min,  0 users,  load average: 4.02, 4.05, 4.00
 10:47:51 up 59 min,  0 users,  load average: 4.00, 4.00, 3.98
 10:47:52 up 58 min,  0 users,  load average: 4.16, 4.09, 4.02
 10:47:54 up 58 min,  0 users,  load average: 4.00, 4.05, 4.00
 10:47:55 up 57 min,  0 users,  load average: 4.00, 4.01, 4.00

 

Consider "yet another lame idea". Can you try to power stuff via GPIO pins, not via barrel connector ? I used 2 wires from standard Ethernet patch cord. Just as experiment.

Link to comment
Share on other sites

@znoxx

Maybe it depends on what it is running... Would you please to run my test script there if it's possible?

Spoiler

#!/bin/bash

while true; do
  date +%H:%M:%S | tr -d '\n'
  for I in `seq 5 10`; do
    timeout $(($I/2)) cat /dev/zero > /dev/null &
    timeout $(($I/2)) cat /dev/zero > /dev/null &
    cat /sbin/`ls -S /sbin | head -n1` | grep 123 > /dev/null &
  done
  top -d0 -n2 | grep 'Cpu' | tail -n1 | sed 's/%Cpu(s)\://' | tr -d '\n'
  echo -n " $(($((`cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_cur_freq 2>/dev/null`+0))/1000))MHz"
  echo -n " $(($((`cat /sys/class/thermal/thermal_zone0/temp 2>/dev/null`+0))/1000))C"
  echo -n " "
  ps -eF | grep -E '[0-9]{2} cat' | awk '{print $7}' | tr -d '\n'
  wait

  echo -n " b>"
  read -t1 BREAK
  echo "B"

  if dmesg | tail -n20 | grep '\---\[ end trace'; then break; fi
  if [ ! -z "$BREAK" ]; then break; fi
done

This script breaks the system in like 5 to 15 minutes usually. Thank you!

Link to comment
Share on other sites

@svts

 

see results here:

https://pastebin.com/5CXyyuQm

 

Script runned for approx. 10 minutes, giving message presented in the paste (I've added only last 3 minutes I guess because "screen" truncated it - hope it's enough)

 

Also dmesg has swap/oom errors and I see docker container is restarting, but it was done during high load to ram/swap/cpu.

 

Note to myself: invest into better microsd cards :).

 

Link to comment
Share on other sites

So the problem was solved!

sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

The reason of crashes was DRAM PLL value which seems too high for the boards I have.

Default DRAM_PLL value set by u-boot 2017.05+ is 624MHz. It seems not all board support this value.

I changed it to 600MHz by setting 0x01c20020 register to 0x1810 value (instead of 0x1910 set by u-boot) and there's no any crash anymore.

 

The script adds "mw.l 0x01C20020 0x80101810" line to boot.cmd and then compiles boot.scr.

After that u-boot will change DRAM_PLL value to a bit lower one to avoid crashes.

 

Thanks everybody who helped me to find a solution.

Special thanks to @znoxx for testing and logging :)

 

Link to comment
Share on other sites

@svts, u digged great thing.

U told me, that boards were bought not from Xunlong shop, but from some third-party guys.

 

Good thing for Xunlong -- their products are being copied =) with cheaper components (which is sooo aliexpress -typical). 

Bad things for most of us -- when you buy a board from a "local supplier" or cheaper than in official store, most probably you can bump into a "fake one". Because supplier cares about margin/income/whatever, not about the quality of product. Probably in Europe/US the situation is better, but in countries like Russia it's pretty typical.

 

So time to say "beware of fake Orange Pi's " ?

Link to comment
Share on other sites

On 12/17/2018 at 5:35 AM, svts said:

So the problem was solved!


sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

The reason of crashes was DRAM PLL value which seems too high for the boards I have.

Default DRAM_PLL value set by u-boot 2017.05+ is 624MHz. It seems not all board support this value.

I changed it to 600MHz by setting 0x01c20020 register to 0x1810 value (instead of 0x1910 set by u-boot) and there's no any crash anymore.

 

The script adds "mw.l 0x01C20020 0x80101810" line to boot.cmd and then compiles boot.scr.

After that u-boot will change DRAM_PLL value to a bit lower one to avoid crashes.

 

Thanks everybody who helped me to find a solution.

Special thanks to @znoxx for testing and logging :)

 

 

Great work! I have the same problem with a PC 2 which came direct from the manufacturer

 

Your script has some unicode characters so I removed them:

sed -i -e '1imw.l 0x01C20020 0x80101810\' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

 

Link to comment
Share on other sites

On 3/24/2018 at 5:28 PM, Igor said:


This feature cost 30.000 EUR and will be implemented free of charge when it is delivered :) You can find detail info on that page.

Does anyone know if Armbian will include the new Allwinner H5 video Unit enhancements in Linus's Mainline Kernel 5.0 "AKA 4.21" that came out last week.

 

If so what would the time line be to have the enhancements in Armbian Orange pi PC2?.

 

Currently I believe the Orange Pi PC2 Armbian OS is at version 4.19 mainline kernel.

Link to comment
Share on other sites

4 hours ago, Seasalt said:

that came out last week.


... and my task list tells me that I can check on this once by the end of this year. Perhaps not even this year. But perhaps somebody will solve this sooner - project is open. You can do this or you can do something to lower the pressure on our small resources: https://www.armbian.com/get-involved

Link to comment
Share on other sites

Hi

I've noticed that thermal throttling doesn't work on the OPi PC2. I'm on 5.75. I've tried armbianmonitor -m but it doesn't give me the CPU frequency:

 

$ armbianmonitor -m
Running unprivileged. CPU frequency will not be displayed.
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

14:45:40:   ---      0.11  12%   0%  11%   0%   0%   0% 54.9°C  0/15
14:45:45:   ---      0.10   0%   0%   0%   0%   0%   0% 55.3°C  0/15
14:45:50:   ---      0.09   0%   0%   0%   0%   0%   0% 55.2°C  0/15^C

Nonetheless, I get the frequency using cpufreq-info. It remains at 1.1GHz even when the temperature is around 88C. The board just shuts down when it hits 90C. Shouldn't it thermal throttle? My /etc/default/cpufrequtils looks like this:

 

# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
MIN_SPEED=120000
MAX_SPEED=1400000
GOVERNOR=ondemand

Anyone know why thermal throttling isn't working?

 

Thanks

Link to comment
Share on other sites

1 hour ago, martinayotte said:

It seems that you are not running "armbianmonitor -m" as root ...

 

You're right. Here's the new output:

 

$ sudo armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

16:55:19: 1368MHz  0.82   4%   0%   4%   0%   0%   0% 58.2°C  0/15
16:55:25:  240MHz  0.76   0%   0%   0%   0%   0%   0% 58.8°C  0/15
16:55:30:  240MHz  0.70   4%   1%   1%   0%   2%   0% 63.2°C  0/15
16:55:35:  120MHz  0.64   1%   0%   0%   0%   0%   0% 60.1°C  0/15
16:55:41: 1104MHz  0.99  70%   1%  69%   0%   0%   0% 75.1°C  7/15
16:55:48: 1104MHz  1.23 100%   0%  99%   0%   0%   0% 81.6°C  7/15
16:55:55: 1104MHz  1.73 100%   0%  99%   0%   0%   0% 86.9°C  7/15Connection to 192.168.100.134 closed by remote host.

It's clear that the CPU frequency isn't being throttled down even when the temperature was approach 90C. Is this normal for the PC2?

Link to comment
Share on other sites

14 hours ago, lopau said:

It's clear that the CPU frequency isn't being throttled down even when the temperature was approach 90C. Is this normal for the PC2?


That isn't normal and thermal throttling could be broken / not tuned well. armbianmonitor -u would give us better picture over the problem without trying to replicate.

Link to comment
Share on other sites

On 3/27/2019 at 5:54 PM, Igor said:


That isn't normal and thermal throttling could be broken / not tuned well. armbianmonitor -u would give us better picture over the problem without trying to replicate.

 

Can I ask at what temperature should thermal throttling start to kick in? I'm now using a more powerful PSU (5V 3A) and it's still the same. Here's my output: http://ix.io/1EHF

 

Cheers

Link to comment
Share on other sites

I paste my log since I'm having also this issue. I'm trying to compile something and the CPU is crazy, every 5 minutes restart.

 

http://ix.io/1EJ4

 

Armbian 5.75 Stretch, last build just installed today in a fresh microsd.

 

Can these lines be the source of the problem?

 

[ 4.404838] thermal thermal_zone1: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-17

[ 4.576372] thermal thermal_zone0: failed to read out thermal zone (-110)

[ 4.576424] OF: /thermal-zones/cpu-thermal: arguments longer than property

[ 4.576435] thermal thermal_zone2: failed to read out thermal zone (-110)

 

I hope this gets fixed as soon as possible.

 

Thanks for your hard work! :)

Link to comment
Share on other sites

I'm having the same issue as well. I had to stick a small fan on the case for now.

Under load, the frequency never drops below 1104MHz.

I'm a bit of a noob but I've been trying to investigate (so let me know if I'm way off).

houldsg@orangepipc2:~$ uname -a
Linux orangepipc2 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 aarch64 aarch64 GNU/Linux
houldsg@orangepipc2:~$ cat /sys/devices/virtual/thermal/thermal_zone0/
available_policies  cdev0_weight        k_d                 k_pu                policy              subsystem/          trip_point_0_hyst   trip_point_1_hyst   type
cdev0/              emul_temp           k_i                 mode                power/              sustainable_power   trip_point_0_temp   trip_point_1_temp   uevent
cdev0_trip_point    integral_cutoff     k_po                offset              slope               temp                trip_point_0_type   trip_point_1_type
houldsg@orangepipc2:~$ cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp
65000
houldsg@orangepipc2:~$ cat /sys/devices/virtual/thermal/thermal_zone0/trip_point_1_temp
90000

65 degrees is when the frequency drop to 1104. Does trip point 0 trigger a particular frequency (1104)? Should there be more trip points or is the throttling handled by another mechanism?

 

Link to comment
Share on other sites

It didn't happen to me on the previous image I was running (ARMBIAN 5.32.170803 nightly Ubuntu 16.04.5 LTS 4.11.10-sun50iw2)

When I have some time, I'll put an older version on an sd card and prove it with data.

Can anyone else identify the version they noticed the change in behavior?

Link to comment
Share on other sites

Looks like I also bumped this issue... But only on one PC2 from 12(!)

 

First things first:

http://ix.io/1FMV - armbian log

 

Here is my armbianmonitor -m output:

 

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
21:11:03:  120MHz  0.21   1%   0%   0%   0%   0%   0% 67.2°C  7/15
21:11:08:  120MHz  0.19   1%   0%   0%   0%   0%   0% 69.0°C  7/15
21:11:13:  120MHz  0.17   1%   1%   0%   0%   0%   0% 69.4°C  7/15
21:11:19:  120MHz  0.16   1%   0%   0%   0%   0%   0% 70.6°C  7/15
21:11:24:  120MHz  0.15   1%   0%   0%   0%   0%   0% 70.8°C  7/15
21:11:29:  120MHz  0.13   1%   0%   0%   0%   0%   0% 71.6°C  7/15
21:11:34:  120MHz  0.12   1%   0%   0%   0%   0%   0% 71.4°C  7/15
21:11:39:  120MHz  0.11   0%   0%   0%   0%   0%   0% 70.9°C  7/15
21:11:45:  120MHz  0.10   0%   0%   0%   0%   0%   0% 70.4°C  7/15

The only difference from my other 11 boards -  it assembled in 2017. 

I strongly suspect the hardware. I have same heatsink applied with same thermal grease. When I put microSD in another board - temperature is about 35..39 when idle.

This board shows about 70 when idle!! 

 

May be some voltage regulator is fried ? 

 

I also tried svts's magic command to reduce dram speed, but things are worse. Now I see 80C when idle :(

What else to add:

 

C.St is permanently 7/15. On other boards it is mostly 0/15 on idle. 

 

I have seen only one faulty board before (except ones I accidentally fried with 12v :) ) - Ethernet was dying during a week, then just stopped working. But It works with usb ethernet and usb wifi in another project.

 

Any ideas so far ? And thanks in advance for your help.

 

 

 

 

Link to comment
Share on other sites

11 hours ago, znoxx said:

May be some voltage regulator is fried ? 


Yes, it looks like some hardware malfunction. If only this one is behaving this way, simply throw it away and move on.

Link to comment
Share on other sites

3 hours ago, Igor said:

If only this one is behaving this way, simply throw it away and move on.

Yeah, already did and ordered a replacement.

But 2 things still are still curious here:

 

1) My "symptoms" a really look like lopau's case. 

2) This board may be one not from manufacturer, but bought locally.

Link to comment
Share on other sites

On 3/28/2019 at 4:36 PM, nobitakun said:

[ 4.404838] thermal thermal_zone1: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-17

[ 4.576372] thermal thermal_zone0: failed to read out thermal zone (-110)

[ 4.576424] OF: /thermal-zones/cpu-thermal: arguments longer than property

[ 4.576435] thermal thermal_zone2: failed to read out thermal zone (-110)

 

 

FWIW, these messages seem to go away when building the dev branch without patch /patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch

 

Not sure if this patch is compatible with the changes already done in the megous branch (like this patch)

 

Still, throttling is done only down to 1104 MHz (not an issue for me personally, for me this throttle is enough for mine to not go above 81C @100% CPU usage for 10 minutes).

 

Edit: Looks like I have it working now. I have basically added the patch ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch directly to linux-mainline/orange-pi-5.0/arch/arm/boot/dts/sunxi-h3-h5.dtsi (instead of

/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi)


 

Spoiler

thermal-zones {
        cpu-thermal {
            /* milliseconds */
            polling-delay-passive = <250>;
            polling-delay = <1000>;
            thermal-sensors = <&ths>;

            trips {
                cpu_warm: cpu_warm {
                    temperature = <55000>;
                    hysteresis = <2000>;
                    type = "passive";
                };

                cpu_hot_pre: cpu_hot_pre {
                    temperature = <60000>;
                    hysteresis = <2000>;
                    type = "passive";
                };

                cpu_hot: cpu_hot {
                    temperature = <70000>;
                    hysteresis = <2000>;
                    type = "passive";
                };

                cpu_very_hot_pre: cpu_very_hot_pre {
                    temperature = <80000>;
                    hysteresis = <2000>;
                    type = "passive";
                };

                cpu_very_hot: cpu_very_hot {
                    temperature = <85000>;
                    hysteresis = <2000>;
                    type = "passive";
                };

                cpu_crit: cpu_crit {
                    temperature = <90000>;
                    hysteresis = <2000>;
                    type = "critical";
                };
            };

            cooling-maps {
                cpu_warm_limit_cpu {
                    trip = <&cpu_warm>;
                    cooling-device = <&cpu0 THERMAL_NO_LIMIT 2>;
                };

                cpu_hot_pre_limit_cpu {
                    trip = <&cpu_hot_pre>;
                    cooling-device = <&cpu0 2 3>;
                };

                cpu_hot_limit_cpu {
                    trip = <&cpu_hot>;
                    cooling-device = <&cpu0 3 4>;
                };

                cpu_very_hot_pre_limit_cpu {
                    trip = <&cpu_very_hot_pre>;
                    cooling-device = <&cpu0 5 6>;
                };

                cpu_very_hot_limit_cpu {
                    trip = <&cpu_very_hot>;
                    cooling-device = <&cpu0 7 THERMAL_NO_LIMIT>;
                };
            };
        };
    };

 

 

 

Not sure why that should make a difference, but throttling now seems to take the trips I have configured (though it seems to use a different cooling map:

 

ramp up:

 

Spoiler

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
18:26:30: 1368MHz  0.86  13%   1%   3%   0%   8%   0% 48.9°C  0/15
18:26:36: 1296MHz  1.12 100%   0% 100%   0%   0%   0% 56.0°C  2/15
18:26:43: 1296MHz  1.35 100%   0% 100%   0%   0%   0% 58.4°C  2/15
18:26:49: 1296MHz  1.83 100%   0% 100%   0%   0%   0% 60.7°C  5/15
18:26:56: 1296MHz  2.00 100%   0% 100%   0%   0%   0% 60.7°C  5/15
18:27:02: 1200MHz  2.16 100%   0% 100%   0%   0%   0% 60.8°C  5/15
18:27:09: 1200MHz  2.52 100%   0%  99%   0%   0%   0% 61.6°C  5/15
18:27:15: 1200MHz  2.64 100%   0% 100%   0%   0%   0% 62.4°C  5/15
18:27:22: 1200MHz  2.75 100%   0% 100%   0%   0%   0% 63.1°C  5/15
18:27:28: 1200MHz  3.01 100%   0%  99%   0%   0%   0% 63.7°C  5/15
18:27:35: 1200MHz  3.09 100%   0%  99%   0%   0%   0% 64.1°C  5/15
18:27:41: 1200MHz  3.17 100%   0% 100%   0%   0%   0% 64.9°C  5/15
18:27:48: 1200MHz  3.23 100%   0% 100%   0%   0%   0% 66.0°C  5/15
18:27:54: 1200MHz  3.43 100%   0% 100%   0%   0%   0% 66.3°C  5/15
18:28:01: 1200MHz  3.47 100%   0% 100%   0%   0%   0% 66.8°C  5/15
18:28:07: 1200MHz  3.51 100%   0%  99%   0%   0%   0% 67.4°C  5/15
18:28:14: 1200MHz  3.66 100%   0% 100%   0%   0%   0% 67.9°C  5/15
18:28:20: 1200MHz  3.69 100%   0%  99%   0%   0%   0% 68.7°C  5/15
18:28:27: 1200MHz  3.72 100%   0% 100%   0%   0%   0% 69.4°C  5/15
18:28:33: 1104MHz  3.83 100%   0% 100%   0%   0%   0% 69.5°C  5/15
18:28:40: 1200MHz  3.85 100%   0% 100%   0%   0%   0% 70.0°C  5/15
18:28:46: 1200MHz  3.86 100%   0%  99%   0%   0%   0% 70.0°C  5/15
18:28:53: 1200MHz  3.87 100%   0% 100%   0%   0%   0% 70.0°C  5/15
18:28:59: 1200MHz  3.97 100%   0% 100%   0%   0%   0% 70.2°C  7/15
18:29:06: 1104MHz  3.97 100%   0%  99%   0%   0%   0% 70.2°C  7/15
18:29:13: 1104MHz  3.97 100%   0% 100%   0%   0%   0% 70.2°C  7/15
18:29:19: 1104MHz  4.05 100%   0%  99%   0%   0%   0% 70.7°C  7/15

 

after insulating the board to get the temperature up:

 

Spoiler

18:59:31:  960MHz  8.43 100%   0%  99%   0%   0%   0% 84.8°C  10/15
18:59:39:  960MHz  8.39 100%   0%  99%   0%   0%   0% 85.2°C  12/15
18:59:49:  960MHz  8.41 100%   0%  99%   0%   0%   0% 84.6°C  10/15
18:59:57:  960MHz  8.42 100%   0%  99%   0%   0%   0% 84.8°C  10/15
19:00:05:  960MHz  8.38 100%   0%  99%   0%   0%   0% 85.1°C  10/15
19:00:15:  648MHz  8.40 100%   0%  99%   0%   0%   0% 85.1°C  12/15
19:00:24:  960MHz  8.41 100%   0%  99%   0%   0%   0% 84.4°C  10/15
19:00:33:  960MHz  8.42 100%   0%  99%   0%   0%   0% 83.8°C  10/15
19:00:42:  960MHz  8.43 100%   0%  99%   0%   0%   0% 85.3°C  12/15
19:00:51:  960MHz  8.44 100%   0%  99%   0%   0%   0% 84.8°C  10/15
19:01:00:  648MHz  8.41 100%   0%  99%   0%   0%   0% 84.7°C  10/15

 

removing insulation lets temp drop again, and freq rise:

 

Spoiler

19:05:19:  960MHz  6.03  90%   0%  89%   0%   0%   0% 83.8°C  10/15
19:05:28:  960MHz  6.40 100%   0% 100%   0%   0%   0% 82.5°C  10/15
19:05:37:  960MHz  6.72 100%   1%  98%   0%   0%   0% 80.7°C  7/15
19:05:45:  960MHz  6.83 100%   0%  99%   0%   0%   0% 80.1°C  10/15
19:05:53: 1104MHz  7.08 100%   0%  99%   0%   0%   0% 74.5°C  7/15
19:06:02: 1104MHz  7.30 100%   0% 100%   0%   0%   0% 72.0°C  7/15

 

Edited by bschwehn
Link to comment
Share on other sites

14 hours ago, bschwehn said:

Looks like I have it working now.

This is great.

Any chances to see this functionality in stable version of Armbian in visible period of time ?

Thanks!

P.S. Is this applicable for Allwinner H6 boards ? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines