Armbian for OrangePi PC2, AllWinner H5

[houldsg]

21 hours ago, bschwehn said:

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.

Looks promising!

 

My scenario doesn't look exactly like znoxx's. Mine idles at around 45-50 degrees. I have heatsinks attached and the case is the one sold on aliexpress with the removable top removed. It has bad airflow design but I'm not running it in a sealed box or anything.

 

It's set up to use SPI to boot from an ssd. The uboot version in SPI is from "/usr/lib/linux-u-boot-next-orangepipc2_5.75_arm64" (using instructions from here)

Hardware log is here: http://ix.io/1FUF

 

And here's a test with the fan disconnected (I stopped the test at 80 degrees because I'm not at home at the moment and I don't want it to become unresponsive.):

Spoiler

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

09:03:24:  240MHz  0.34   3%   1%   1%   0%   0%   0% 44.3°C  0/15
09:03:31: 1368MHz  0.31  38%   1%  37%   0%   0%   0% 56.5°C  0/15
09:03:37: 1368MHz  0.61 100%   0%  99%   0%   0%   0% 63.8°C  0/15
09:03:44: 1368MHz  1.20 100%   0%  99%   0%   0%   0% 64.6°C  0/15
09:03:51: 1104MHz  1.43  99%   0%  99%   0%   0%   0% 64.4°C  7/15
09:03:58: 1104MHz  1.90 100%   0%  99%   0%   0%   0% 65.3°C  7/15
09:04:05: 1104MHz  2.07 100%   0%  99%   0%   0%   0% 66.2°C  0/15
09:04:12: 1104MHz  2.22 100%   0%  99%   0%   0%   0% 67.2°C  7/15
09:04:19: 1104MHz  2.57 100%   1%  98%   0%   0%   0% 68.8°C  7/15
09:04:26: 1104MHz  2.68 100%   0%  99%   0%   0%   0% 68.3°C  7/15
09:04:33: 1104MHz  2.96 100%   0%  99%   0%   0%   0% 69.0°C  7/15
09:04:40: 1104MHz  3.04 100%   0%  99%   0%   0%   0% 70.6°C  7/15
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
09:04:47: 1104MHz  3.12 100%   0%  99%   0%   0%   0% 70.2°C  7/15
09:04:55: 1104MHz  3.33 100%   0%  99%   0%   0%   0% 72.7°C  7/15
09:05:02: 1104MHz  3.38 100%   0%  99%   0%   0%   0% 72.9°C  7/15
09:05:09: 1104MHz  3.63 100%   0%  99%   0%   0%   0% 74.6°C  7/15
09:05:16: 1104MHz  3.90 100%   0%  99%   0%   0%   0% 74.5°C  7/15
09:05:23: 1104MHz  3.90 100%   0%  99%   0%   0%   0% 74.7°C  7/15
09:05:29: 1104MHz  3.99  89%   0%  88%   0%   0%   0% 75.9°C  7/15
09:05:35: 1104MHz  3.99  94%   0%  93%   0%   0%   0% 75.4°C  7/15
09:05:42: 1104MHz  4.00 100%   0%  99%   0%   0%   0% 77.7°C  7/15
09:05:49: 1104MHz  4.07 100%   0%  99%   0%   0%   0% 78.2°C  7/15
09:05:56: 1104MHz  4.06 100%   0%  99%   0%   0%   0% 79.4°C  7/15

 

[bschwehn]

In case anyone missed it, Mikaey posted a workaround that does not require a new armbian image / kernel. Perhaps a viable workaround?

 

I am not sure what the best fix is for armbian itself (so that it will be fixed in some upcoming release), so I don't feel confident submitting a pull request, but time permitting I will have another look this weekend.

[znoxx]

22 minutes ago, bschwehn said:

In case anyone missed it, Mikaey posted a workaround that does not require a new armbian image / kernel. Perhaps a viable workaround?

 

I am not sure what the best fix is for armbian itself (so that it will be fixed in some upcoming release), so I don't feel confident submitting a pull request, but time permitting I will have another look this weekend.

 

I've already tried on my "probaly fried" OpiPC2 described earlier. It works. And it's funny. Since my temperature is about 80C due to h/w fault - Opi is throttled to 120Mhz permanently . Atmega MCU can even compete with this. Anyway, workaround works. Not sure it will survive kernel update via apt (in case it won't be included into).

[houldsg]

I totally missed it. Thanks.

And it looks like I don't have to reinstall a new image, which is awesome.

[Igor]

On 4/10/2019 at 5:30 PM, bschwehn said:

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:

https://github.com/armbian/build/commit/8f4ab52b6ea806a69eec3f4ad7adbaeb5cd0f1b4
It should be fixed now. Thanks for help.

[houldsg]

I applied the workaround outlined by Mikaey and can confirm that throttling now works properly for me too.

Thanks Everyone

[bschwehn]

On 4/12/2019 at 9:59 AM, Igor said:

https://github.com/armbian/build/commit/8f4ab52b6ea806a69eec3f4ad7adbaeb5cd0f1b4
It should be fixed now. Thanks for help.

Thanks Igor, works fine for me with nightly.

[lopau]

Is H5 actually safe to operate close to 105C? I see that the CPU shuts down only at 105C https://github.com/armbian/build/blob/8f4ab52b6ea806a69eec3f4ad7adbaeb5cd0f1b4/patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch Is it not a bit too adventurous to allow operation at such a high temperature?

[Igor]

On 4/15/2019 at 6:45 PM, lopau said:

Is H5 actually safe to operate close to 105C? I see that the CPU shuts down only at 105C https://github.com/armbian/build/blob/8f4ab52b6ea806a69eec3f4ad7adbaeb5cd0f1b4/patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch Is it not a bit too adventurous to allow operation at such a high temperature?

It should be fine.

https://linux-sunxi.org/images/a/a3/Allwinner_H5_Manual_v1.0.pdf
"For reliability and operability concerns, the absolute maximum junction temperature of H5 has to be below 125°C"

[lopau]

On 4/18/2019 at 4:06 PM, Igor said:

It should be fine.

https://linux-sunxi.org/images/a/a3/Allwinner_H5_Manual_v1.0.pdf
"For reliability and operability concerns, the absolute maximum junction temperature of H5 has to be below 125°C"

 

Thanks!

[Magnets]

The latest update on my OPI pc2 has reduced the max cpu freq from 1.3ghz to 1.01ghz.

 

I believe the old minfreq was 120mhz?

 

linux-stretch-root-next-orangepipc2_5.85_arm64.deb

 

/etc/default/cpufrequtils

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

[Igor]

9 hours ago, Magnets said:

The latest update on my OPI pc2 has reduced the max cpu freq from 1.3ghz to 1.01ghz.

 

Use armbian-config and adjust those values.

 

9 hours ago, Magnets said:

I believe the old minfreq was 120mhz?

Which was there by mistake. Going below 480 has a drastic impact on performance, while consumption is virtually unchanged.

[Narly9999]

Hope you like the photo and idea of modifying for a fan.  It's gruesome but effective.  There are several Pi-FAN for sale but for some reason none of them, i found, have the CFM the ones from the acrylic case I bought from DIYzone store on ALIExpress.  Been meaning to ask them if they sell just the fans he obtains.  Other PI-FAN(Manufacture label), I have bought, are inferior and the CFM is less then the breath of a Kitten in a full slumber and about as quiet.  8-/  Maybe they just need to break in?  https://www.aliexpress.com/item/32621151739.html 

 

These acrylic cases need to be hot to the touch before assembly. Very stiff acrylic.  They have powerful loud fans though!

 

 

Edited December 26, 2019 by Narly9999

[balbes150]

Perhaps someone will be interested in using USB drives to quickly test different systems. Details in this topic. If this information is not relevant here, moderators can delete it immediately. 

 

 

[balbes150]

Funny situation. When I tested running different systems from USB media on H5 (Orangepi PC2), I tried an image with LibreELEC with 5.5 core for H6, and surprisingly KODI started normally and works with HW decoding similarly to H6.

 

[Chris Rupnik]

I have updated to Armbian 20.02.1 from 20.02.0-rc1 on the orangepi PC2 and can happily report that the issues with the wireless autentication failures present in RC1 have been resolved for .1 and now function correctly as it was in the past. 

 

CPU temp and Frequency displays in HTOP also working correctly. 

 

Very pleased to also see the lima drivers in the kernel - will be reviewing how to test. 

 

Thank you for all the hard work - it is appreciated!

[Hummel95]

On 1/11/2019 at 8:49 PM, Magnets said:

 

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

 

 

Great find - I also have some instability issues with my OrangePi PC2 (especially in load situations (like extracting an archive)).

How can I check the current DRAM PLL value so I know if this fix would help me?

Until now only reducing the clock speed seems to work.

 

Thanks!

[Ehsan Vahab]

Hi everyone

I've been following the comments for H264 HW Encoder on Allwinner H5.

it seems it isn't supported by recent mainline kernel any more. 

any body knows there is a driver for H264 Hardware Encoding on Allwinner H5 or it is still in progress ?

[manuti]

I don't know if is part of the bootlin effort included in past crowd funding related to H3 encoding.

[Ehsan Vahab]

13 hours ago, manuti said:

I don't know if is part of the bootlin effort included in past crowd funding related to H3 encoding.

 

Thanks for your comment @manuti.

I've read the report of the last crowd funding of booltin. it seems the encoder part of Allwinner H5 remains undone.

so then I haven't found any other news expect that uboborov's sunxi cedar mainline for Allwinner H3 on legacy kernel.

Now I don't know whether there is an hardware encoder driver for H5 or not?

[jernej]

4 hours ago, Ehsan Vahab said:

I haven't found any other news expect that uboborov's sunxi cedar mainline for Allwinner H3 on legacy kernel.

Now I don't know whether there is an hardware encoder driver for H5 or not?

H3 and H5 have same encoder, so H3 encoder should also work on H5, but I didn't test.