Armbian for OrangePi PC2, AllWinner H5

[Christos]

Did another build with latest commits.

 

Non-booting problem again.

Latest commit that was working ok was commit dc6f9d9, with commits after that it stopped booting properly and go into endless reboots.

 

 

Obviously something was wrong before here, so did another build and changed SD card just in case.

All are ok now, tested up to latest commit 3d8fce2.

 

 

BTW, very nice HDMI behaviour! everything works properly automagically!

[willmore]

I'm not sure how much of the data you want to see, but it ran fine until 932MHz and there it stayed at 80-82C. As the max clock settings kept going up, the processor did not follow.

 

So, for a stock board with middling/poor ventilation and no HS, that's the limit. Oh, power meter said 625mA at that point. Idle is around 250 and cpuminer was a little over 500.

 

Anything else I can do?

[zador.blood.stained]

I'm not sure how much of the data you want to see, but it ran fine until 932MHz and there it stayed at 80-82C. As the max clock settings kept going up, the processor did not follow. So, for a stock board with middling/poor ventilation and no HS, that's the limit. Oh, power meter said 625mA at that point. Idle is around 250 and cpuminer was a little over 500. Anything else I can do?

If you tested the prebuilt nightly then idle consumption numbers still can change since this one didn't go below 792MHz due to a wrong number in the DT.

[willmore]

@zador.blood.stained: Yes, I started with the 27 nightly and did an apt-get update;apt-get upgrade and rebooted, so I have the most recent kernel as of 6 hours ago (plus any mirror sync offset). If there is a better way to report kernel version, I'll be glad to do it.

 

I'll keep running tests and reporting stuff until someone tells me to stop. Every time I see a new kernel, I'll redo things.

 

Oh, and please don't see my reporting of the idle power use as a complaint, it's just an observation. I am very impressed with everything. Thank you all!

[zador.blood.stained]

Oh, and please don't see my reporting of the idle power use as a complaint, it's just an observation. I am very impressed with everything. Thank you all!

I just saw it as an intermediate data point, so it shouldn't be used to compare this to other boards yet (same for the performance and temperatures, I'm not sure that THS calibration is included into this kernel tree so temperature sensor readings may not be accurate enough).

[willmore]

I just saw it as an intermediate data point, so it shouldn't be used to compare this to other boards yet (same for the performance and temperatures, I'm not sure that THS calibration is included into this kernel tree so temperature sensor readings may not be accurate enough).

Understood.  Any board to board comparison at this point would be for the purpose of "are we there, yet?" or "I think we can do better."

 

FWIW, it still idles colder than my OpiZ--which is in a box and also does not have a heatsink.  So, even without tuning, we're doing quite well on temps.  That box uses 100 to 120mA at idle.  Though I'm sure a box with 100BT and no HDMI is not a fair comparison.

[znoxx]

Hi Everyone!

 

First of all - thanks for this Armbian developer version - works flawlessly.

 

Here is my stability test result (temperature was about 71 - I'm using passing heatsink).

Done testing stability:
Frequency: 792000	Voltage: 1000000	Success: 1	Result:        0.0048034
Frequency: 816000	Voltage: 1000000	Success: 1	Result:        0.0048034
Frequency: 864000	Voltage: 1040000	Success: 1	Result:        0.0048034
Frequency: 912000	Voltage: 1050000	Success: 1	Result:        0.0048034
Frequency: 936000	Voltage: 1060000	Success: 1	Result:        0.0048034
Frequency: 960000	Voltage: 1080000	Success: 1	Result:        0.0048034
Frequency: 1008000	Voltage: 1100000	Success: 1	Result:        0.0048034
Frequency: 1056000	Voltage: 1150000	Success: 1	Result:        0.0048034
Frequency: 1080000	Voltage: 1160000	Success: 1	Result:        0.0048034
Frequency: 1104000	Voltage: 1170000	Success: 1	Result:        0.0048034
Frequency: 1152000	Voltage: 1200000	Success: 1	Result:        0.0048034
Frequency: 1200000	Voltage: 1240000	Success: 1	Result:        0.0048034

Also, may be you will find interesting some benchmarking results.

 

I started with "OrangePiLibra" kernel, this 3.x one from SDK. Results were pretty disappointing... RPI3 was not even close.

 

http://znoxx.me/2017/01/22/epic-battle-rpi-3-vs-opi-pc-vs-opi-pc2/

 

Site is in Russian, but there is a "Translate" button in Menu. Feel free to use

 

And finally I repeated tests for Armbian, and they are much better:

 

http://znoxx.me/2017/01/27/epic-battle-2-armbian-orangepi-pc2-vs-raspbian-rpi3/

 

RPI3 almost defeated, especially in 7Z benchmarks. Actually other results are close, and, since my SD card in OPi  PC2 is extremely slow (and good one was used in RPi3) - this may be an explanation. Also Raspbian is build with some optimisations, as far as I remember.

 

 

By the way, here is my heatsink:  http://znoxx.me/content/images/2017/01/opi_pc2_heatsing.jpg

 

Regarding the cpuminer - here it is in "benchmark" mode:

[2017-01-27 19:07:21] thread 2: 4579 hashes, 0.93 khash/s
[2017-01-27 19:07:21] thread 0: 925 hashes, 0.94 khash/s
[2017-01-27 19:07:21] thread 1: 918 hashes, 0.93 khash/s
[2017-01-27 19:07:27] thread 3: 4632 hashes, 0.87 khash/s
[2017-01-27 19:07:27] Total: 3.66 khash/s

It was 3.77 in the very beginning, may be throttling ?

 

Flags, used to build: 

~/cpuminer-2.4.5$ ./configure CFLAGS="-O3 -mtune=cortex-a53 -mcpu=cortex-a53+crypto"

Not sure it is correct, but, well, they were accepted by compiler.

 

Regarding "Reboot issue", mentioned somwhere earlier - I made 3 or 4 reboots - everything is fine. Also, as I said, my mSD is old one 4 class from the box of old electronic guts. And it works without any issues except, well.. speed .

 

One GREAT thing - my 1Gb router is pretty old and some devices were not able to communicate with it. OPi PC2 with 3.x kernel from China also failed. But this 4.9.0 works like charm! Only one thing - for some reasons DNS server, which should be "pushed" by DHCP is not used and I still see 8.8.8.8 in /etc/resolv.conf (and it does not work for me because of provider I guess). So i had only LAN connectivity, but after resolv.conf manual update everything was fine. Not a big deal, but worth mentioning I think.

 

So thanks again! 

 

[znoxx]

Also I installed Java8 for AArch64.

Script for install is here : https://github.com/znoxx/torbox/blob/master/scripts/install/java8inst.sh

 

Just replace "trusty" with "xenial" - worked fine for me.

 

I've compiled "Hello World", then executed. Appears to be working. Thing from Oracle, not a default OpenJDK. 

root@orangepipc2:~# java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
root@orangepipc2:~# which java
/usr/bin/java
root@orangepipc2:~# ls -la /usr/bin/java
lrwxrwxrwx 1 root root 22 Jan 27 18:10 /usr/bin/java -> /etc/alternatives/java
root@orangepipc2:~# ls -la /etc/alternatives/java
lrwxrwxrwx 1 root root 39 Jan 27 18:10 /etc/alternatives/java -> /usr/lib/jvm/java-8-oracle/jre/bin/java

[znoxx]

Shutdown issue, i think...

 

My board is connected via wall USB PSU@2A, which is plugged to WattMeter (Kill-A-Watt or whatever it called).

When system is booted/working - WattMeter shows 2 watts/3 watts.

 

When I proceed with shutdown -h now or shutdown -H now (which should not actually turn power off) - in both cases green light goes off... 

 

But I see 4 watts consumption on watt meter.

 

U-boot from OrangePiLibra showed some messages about sleeping and waiting for keyboard/ir interrupt.

 

I'm using build 5.24.170128

[ErwinH]

OOOOoooops!!

As I was typing this message and left the board at its current setting (turned off supposedly), it sudenly rebooted by its own and reached 132 degrees!!

But I see 4 watts consumption on watt meter.

I think I can explain the reason why this happend. It's because during shutdown the cpu core voltage stays at the last setting before the driver was unloaded. The same reason why the u-boot failed at a reboot, the core voltage was to low when to run stable at the bootfrequency. In your case the voltage was high reaching thermal shutdown before the regulatordriver was loaded.

 

The patch that enabled the regulatordriver in uboot should have fixed the thermal overheat at boot.

[znoxx]

I think I can explain the reason why this happend. It's because during shutdown the cpu core voltage stays at the last setting before the driver was unloaded. The same reason why the u-boot failed at a reboot, the core voltage was to low when to run stable at the bootfrequency. In your case the voltage was high reaching thermal shutdown before the regulatordriver was loaded.

 

The patch that enabled the regulatordriver in uboot should have fixed the thermal overheat at boot.

 

Pardon my ignorance, is this patch already exist ? Or "to be done" ?

If no, may be it makes sense to send some command setting kernel to minimal frequency manually before "shutdown -h now" ? 

[ErwinH]

The patch is applied and should ne in the latest nightly.

[znoxx]

Thanks, ErwinH!

Unfortunately, I will put my hands on it only on Tuesday .

Hope someone will check it earlier.

But I promise to use "usb doctor" and post some pics of consumption anyway .

[hojnikb]

Guys, are there any additional patches for rpi-monitor to use with PC2 ?

 

I'd like to plot temps, cpu load and online cores on the same graph, bu i can't seem to do it.

 

Also, have o get a TIM, because thermal pads plus a small heatsink covering H5 and a small 60mm fan at 12V just doesn't cut it. Throttles at 1.1Ghz. I'd really like to test through all of the frequecy points for as long as possible (the longer the better chance to detect errors).

[hojnikb]

Btw, if anyone needs a taskbar cpu temp, genmon-plugin and a simple shell script does the trick.

#!/bin/bash
#Displays H5 CPU temparature in *C
cat /sys/class/thermal/thermal_zone0/temp|cut -c1-2

[Christos]

@zador.blood.stained @jernej

 

The HDMI operation in PC2 looks absolutely brilliant, it is automagically discovering monitor resolution and there are no artifacts shown while booting, trully great.

 

If the H5 and H3 share common HDMI code can you guys put that too in H3?

 

Tried a new (H3) build, up to and including commit "Update H3 HDMI driver in u-boot  for a "OPi+2E and these things miss, still some artifacts during boot and no auto resolution discovery, is it possible to put them there too?

[zador.blood.stained]

@Christos

 

I'm assuming you are talking about the BSP driver? I don't know about the boot artifacts (they shouldn't be there - it was fixed before and hopefully today's changes didn't break anything), but as for automatic resolution handling - everything is possible, but even @jernej lost any interest in digging up the BSP code, and amount of work required to make it done just is not worth the result since most developers here don't see these boards as desktop replacement and multimedia players, and for everything else display output is not essential.

 

 

 

I had an idea that it's relatively easy to pass the data from u-boot to the kernel via custom ATAG, and while it's relatively easy to insert the data into para_tab and disp_video_timings, there are still questions about pll_video, and DVI compatibility (CTS/HPD), and I'm not sure if any other changes are needed to define a video mode with resolution unknown at compile-time

 

 

[Christos]

Ok, just thought that it would be easy if H5 and H3 share common hdmi code and since PC2 now is really working great.

If its too much then obviously we can live with the current situation which is very good.

Regarding artifacts, in H3 there is a bit at some point, definitively not the full screen as it was before the fix, just a momentary noise-stripe artifact (it is there in all recent H3 builds), but in PC2 there was nothing at all !!

[zador.blood.stained]

@Christos

<slightly off-topic>

Again you are comparing the legacy kernel on H3 with the mainline kernel on H5. Legacy kernel uses its own configuration so momentary artifacts are expected. Current mainline both on H3 and H5 uses video mode and framebuffer provided by the u-boot, so there is no mode/FB switching and no visual glitches.

[Christos]

@Christos

<slightly off-topic>

Again you are comparing the legacy kernel on H3 with the mainline kernel on H5. Legacy kernel uses its own configuration so momentary artifacts are expected. Current mainline both on H3 and H5 uses video mode and framebuffer provided by the u-boot, so there is no mode/FB switching and no visual glitches.

 

Ooops..  sorry, yes you are right.

I'm always doing that mistake..

 

[znoxx]

Hi!

Just installed build from "30th Jan", and looks like shutdown issue is still here...

 

This is with mainline kernel, HDMI, USB keyboard connected.

I've made "shutdown -h now" and recorded the "usb-doctor"

 

http://imgur.com/kqjZiSh

 

 

It starts on 0.38A and raises to 0.58A when green light goes off.

May be I waited too short ? But heatsink was quite hot, I was afraid of loosing my board .

 

 

And here is a recording of "legacy" kernel - no hdmi connected, no usb keyboard, only the usb -> serial converter.

 

http://imgur.com/a/XwMHZ 

 

It starts at about 0.20A, and in the end goes to 0.10..0.12A, when a message "waiting for interrupt" appears.

[Bart]

Ok i do some performance check with copper plate ~30/30 mm and some small radiator ...

 

 

 

 

 

Now i need to think how to put there 40x40x30 mm radiator

 

After half hour with old cpu fan for lga 775

 

[TAKCuCT]

Can not mount my NAS on Armbian OPiPC2. I've edit

/etc/fstab -

 //192.168.1.245/video/new  /media/new  cifs  guest,uid=1000,iocharset=utf8  0  0 

but got error

dvas@orangepipc2:~$ sudo mount -a
mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

On other ubuntu's i'd made without problems.

[Bart]

Can not mount my NAS on Armbian OPiPC2. I've edit

/etc/fstab -

 //192.168.1.245/video/new  /media/new  cifs  guest,uid=1000,iocharset=utf8  0  0 

but got error

dvas@orangepipc2:~$ sudo mount -a
mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

On other ubuntu's i'd made without problems.

 

 

Hym i have also problem with "file system"

 

i cant create raid from two hdd;s:

 

 

Hymm maybe someone will know how to fix it

[tkaiser]

Can not mount my NAS on Armbian OPiPC2.

 

https://github.com/igorpecovnik/lib/blob/644cdbd293f3cdb8e0ee8bb142e9c37825e4617d/config/kernel/linux-sun50i-dev.config#L3729

 

maybe someone will know how to fix it

 

Forget about mdraid, it's 2017 already. Use google powered search (see signature below) for 'mkfs.btrfs raid1 raid0' (you want to use 'mkfs.btrfs -m raid1 -d raid0 /dev/sda /dev/sdb' and 'compress=lzo' added to mount options)

[Bart]

https://github.com/igorpecovnik/lib/blob/644cdbd293f3cdb8e0ee8bb142e9c37825e4617d/config/kernel/linux-sun50i-dev.config#L3729

 

 

Forget about mdraid, it's 2017 already. Use google powered search (see signature below) for 'mkfs.btrfs raid1 raid0' (you want to use 'mkfs.btrfs -m raid1 -d raid0 /dev/sda /dev/sdb' and 'compress=lzo' added to mount options)

 

ty

/dev/sda        932G   17M  930G   1% /mnt

 

 

Hmm some performance testing from PC2 on two hdd 500 GB usb3 connected to usb2

 

1. 400 MB file read & write

 

2. 1000 MB file

 

3. 5000 MB file

[willmore]

I printed a case for my PC2 today and reran the thermal soak using cpuminer.  Old score (stock board, mainline kernel, no enhanced airflow) was around 3.2KH/s.  Now, in the case it's running 2.6KH/s and is around 5 degrees cooler.

 

So, it looks like the DVFS/thermal budget cooling code works pretty well.  Shall I tape up the box so there's no airflow?

[tkaiser]

Hmm some performance testing from PC2 on two hdd 500 GB usb3 connected to usb2

 

Hmm... please keep in mind that stock Samba settings on any SBC show not the best performance results. A quick web search for 'smb.conf performance tuning arm' or something like that should show how to tune settings to achieve better performance.

 

In case you re-test please think about using Helios LanTest instead (unlike most other benchmarks used at least some information what this tool does is available: http://www.helios.de/web/EN/support/TI/157.html )

[znoxx]

Forget about mdraid, it's 2017 already.

I'd like to forget, but the issue with raid 5 is still here I guess...

 

https://btrfs.wiki.kernel.org/index.php/RAID56

[tkaiser]

I'd like to forget, but the issue with raid 5 is still here I guess...

 

Yep, but RAID5 is no good idea for various reasons anyway (and we're getting horribly off-topic). The main mistake is thinking RAID would increase data safety which it can't. It's just about availability (who really needs this at home?) and when trying this with unrealiable components it's even a design fail.

 

With the usual HDD disk sizes today you don't want to use single redundancy any more (RAID6 needed or raidz2) especially not with block based RAID implementations like mdraid (that have to rebuild always the whole array and will stop on the first error they find and leave you with your whole storage being gone unlike more modern approaches like raidz/raidz2 where only the blocks used have to be rebuild after a failure).

 

To try to remain on topic: You can connect 4 disks maximum to an OPi PC2 (slightly lower performance on the Micro USB port due to this port being OTG used in host mode) and with RAID6 or raidz2 you get a usable capacity that is exactly as large as when using btrfs' RAID1 (half the real capacity). RAID1 with btrfs is different compared to mdraid's mode since btrfs can combine any number of different devices (even with different sizes) to a RAID1 and takes care that every block written will be kept redundant by making at least 2 copies on different devices.

 

BTW: If data is important I would always use filesystems that ensure data integrity (btrfs or ZFS to name those freely available) and then ECC RAM is mandatory too. And by looking at the external requirements to play RAID with 3 or 4 HDDs connected to an SBC replacing the whole mess of cables, PSUs, external disk enclosures and unreliable setup with a single HP Microserver with raidz2 or a ZFS mirror looks obvious (to me )

 

Anyway: this is really off-topic, I just wanted to point out that if redundancy is needed btrfs when used with a recent mainline kernel (which we fortunately can use already on OPi PC2) can do some amazing things, eg. create a RAID array out of a bunch of disks with different size. But I won't recommend such setups (especially don't do this with Xunlong OS images, relying on outdated 3.10.65 kernel!) and if more than one disk is used then better set up some sort of backup. Here btrfs is also great due to snapshot capabilities and 'btrfs send/receive' functionality to transfer snapshots to different disks or even devices (whoa, a lot of google search terms in a single post )

 

Edit: Since I mentioned RAID-6 above: with mdraid there was an undetected bug (for 5 years) present that could lead to data corruption as soon as the R in RAID would ne needed: https://lwn.net/Articles/608896/ (so please don't think about mdraid with RAID6 when not using Armbian and mainline kernel. The chances that this bug is present in almost all SBC OS images around except of maybe Raspbian and Armbian or Bananian with mainline kernel should be close to 100 percent). But RAID6 with SBC is more or less useless anyway (no, please also don't think about combining A20/R40 boards with SATA port multipliers)