Jump to content
  • 0

Armbian running on Pine64 (and other A64/H5 devices)


tkaiser
 Share

Question

We have initial support for Pine64/Pine64+ for a long time in our repository but not released any official images yet. Since this will change soon a sneak preview what to expect.

 

Hardware related issues:

 

Please don't blame Armbian for the few design flaws Pine64 and Pine64+ show:

  • These boards use Micro USB for DC-IN which is the worst possible decision. Most USB cables have a resistance way too high and are responsible for severe voltage drops when consumption increases, then the tiny Micro USB contacts have also a pretty high contact resistance and also maximum amperage for this connector is limited to 1.8A by USB specs. So in case you want to do heavy stuff immediately look into linux-sunxi wiki page for Pine64 to get the idea how to use the pins on the so called Euler connector to power the board more reliably. If you think about buying a Pine now consider ordering their PSU  too since there cable resistance shouldn't be a problem (should also apply to the Micro USB cables they sell)
  • The only led on this board is a power led that immediately lights when power is provided. Pre-production samples had a green led, on the normal batches this has been replaced with a red led. So there's no way for an OS image to provide user feedback (activate an led when u-boot or kernel boots) and the red light has often been interpreted as 'something is wrong'
  • USB: you find 2 USB type A receptacles on the board but only one is a true USB host port, the other/upper is A64's USB OTG port exposed not as Mini/Micro USB (with ID pin to be able to switch roles) but as a normal type A port. Expect performance to be lower on this port. I've also never been able to do disk benchmarking on the upper port but that might have changed in the meantime (I only have a pre-production developer sample here). Please note also that the maximum amperage available on the USB port is 650mA so connecting bus-powered USB disks might already exceed this so be prepared to use a powered USB hub in between
  • A64 is prone to overheating but unfortunately the Pine64 folks do not sell the board with an effective heatsink by default (compare with ODROID-C1+ or ODROID-C2 for example how it looks like if the vendor cares about heat dissipation). They promised to provide a good heatsink as option but at least I'm not able to find one in their online store. But a heatsink is mandatory if you plan to run this device constantly with high loads, otherwise throttling will occur (when we tested an unrealistic heavy workload without a heatsink -- cpuburn-a53 -- A64 had to throttle down to as less as 600 MHz (for some numbers see IRC log from a while ago)
  • Not a real hardware issue but a problem anyway: the HDMI driver in Allwinner's BSP does not negotiate any display output with a lot of displays that are connected with a HDMI <--> DVI converter or use non-common resolutions. Better do not expect any display output if your display is neither connected directly using HDMI nor capable of 1080p (we can't do anything here since Allwinner's driver uses closed source blobs and no documentation or code with useable license exists)
  • On a couple of Gbit equipped Pine64+ users report that they're not able to negotiate Gbit Ethernet reliably and have to force the connection to Fast Ethernet (since we know that the RTL8211E PHY used on the boards needs an additional ~350 mW when negotiating a Gbit Ethernet connection this might be related to power problems or maybe different PHY batches or something else). Confirmed in the meantime to be a hardware issue.

Now combine Micro USB encouraging users to combine this SBC with crappy phone chargers, 'smart' hubs/chargers that do only provide 500mA since Pine64 isn't able to ask for more and crappy USB cables leading to voltage drops (all sorts of power related issues 'by design' due to crappy Micro USB connector) with a missing custom led able to be used to provide user feedback while booting and the inability to use a lot of displays then you might already get what a support nightmare this device is.

 

The only reliable DOA detection method without a serial console is to ensure you have a working SD card (test it before using either F3 or H2testw as outlined in our docs), then check download integrity of the Armbian image (again see the documentation), then ensure you burn the image correctly to SD card (see docs), insert SD card, power on the board and wait 20 seconds. If then the leds on the Ethernet jack start to flash randomly at least the kernel boots and after waiting an additional 2 minutes you'll be able to login with SSH or serial console (for the latter better choose the EXP header over the Euler connector -- reason here)

 

Anyway: In case you run in booting or stability problems with Armbian on Pine64/Pine64+ be assured that it's not an Armbian issue. You run into any of the problems above therefore please try to resolve them on your own and send your complaints to Pine64 forum and not ours: http://forum.pine64.org/forumdisplay.php?fid=21  (really, we don't do hardware and these issues are all related to hardware design decisions)

 

3245dc9c-e90c-11e5-9bb9-a0bfab2f3e4d.jpg

 

Expectations:

 

The Pine64 folks did a great job raising expectations to the maximum. They advertised this board as 'first $15 64-Bit Single Board Super Computer', promised an average consumption of just 2.5W, the SoC remaining at 32°C and a few other weird things while they already knew that reality differs a lot (the journey started here last Dec).

 

Pine64 is not a 'Super Computer' but most probably the slowest 64-bit ARM board around due to A64 being limited regarding maximum cpufreq and overheating issues (40nm process being responsible for) and lack of fast IO interconnections (only one real USB 2.0 host port present, no eMMC option possible, no SD card implementation using the faster modes). If you then combine the high expectations with a rather clueless kickstarter crowd (many of them not even getting that they did not buy products but backed a project) and the hardware flaws it's pretty obvious why their forums are full of complaints and why they receive so much boards as being DOA that work flawlessly in reality.

 

So why bringing Armbian to Pine64? Since for some (headless) use cases these boards are really nice and also cheap, A64 support is progressing nicely thanks to our awesome linux-sunxi community and also a few more A64 devices will be available soon.

 

What do you get with Armbian on Pine64?

 

User experience will not be much different compared to longsleep's minimal Ubuntu image. If you prefer Debian then at least you can be assured that our images do not contain bad settings and silly bugs like the one's from official Pine64 downloads section (since they fiddle around manually with their OS images for example all Pine boards running these have the same MAC address by default which will cause network troubles if you've more than one board in the same collision domain).

 

We use the same thermal/throttling settings like OS images based on longsleep's kernel (since we helped developing them back in March), we use the same BSP kernel (patched by Zador up to the most recent version back in May) and share a few more similarities since our modifications were sent back to longsleep so all OS images for Pine64 might be able to benefit from.

 

Differences: You don't need to execute longsleep's various platform scripts since kernel and u-boot updates are done using the usual apt-get upgrade mechanism in Armbian. You also don't need (and should not use) scripts like pine64_tune_network.sh since they decrease network performance with Armbian (stay with our defaults unless you're an expert). And a few more tweaks might result in better performance and at least by using Armbian you have the usual Armbian experience with some additional tools at the usual location, automatic fs resize on first boot and so on.

 

We already provide a vanilla image currently based on kernel 4.7 but that's stuff for developers only, see below.

 

Performance with legacy Armbian image:

 

'Out of the box' CPU performance with A64 is not that great unless you are able to benefit from the new CPU features: A64 uses Cortex-A53 CPU cores that feature 64-bit capabilities (which are not that interesting since A64 devices are limited to 2 GB DRAM anyway at the moment) but more interestingly ARMv8 instruction set can be used which might increase performance a lot when software will be compiled for this platform. Best example: the commonly mis-used sysbench cpu test: When running an ARMv6 'optimized' sysbench binary on an ARMv8 CPU then performance will be 15 times slower than necessary (applies to the RPi 3 or the upcoming Banana Pi M64 when used with their OS images)

 

But as soon as ARMv8 optimized code is used A64 can really shine in some areas. I used the default sysbench contained in Ubuntu Xenial's arm64 version, tried it with 20000 settings and got less than 8 seconds execution time (an RPi 3 running Raspbian has the faster CPU cores but here it will take 120 seconds -- just due to different compiler switches!). Then I tried whether I can optimize performance building sysbench from source using

export AM_CFLAGS="-march=armv8-a -mtune=cortex-a53"

and got 11 seconds execution time, so optimized code led to a huge performance loss? Not really, I checked out sysbench version 0.5 by accident and there for whatever reasons execution with ARMv8 optimization or in general takes longer (great! benchmark version influences execution time, so one more reason to never trust in sysbench numbers found on the net!). Using the '0.4' branch at version 0.4.12 I got an execution time of less than 7.5 seconds which is a 10 percent increase in performance for free just by using appropriate compiler flags:

 

 

 

 


root@pine64:/# /usr/bin/sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          7.9788s
    total number of events:              10000
    total time taken by event execution: 31.8939
    per-request statistics:
         min:                                  3.17ms
         avg:                                  3.19ms
         max:                                  8.74ms
         approx.  95 percentile:               3.19ms

Threads fairness:
    events (avg/stddev):           2500.0000/3.54
    execution time (avg/stddev):   7.9735/0.00

root@pine64:/# /usr/local/src/sysbench-0.4.12/sysbench/sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Random number generator seed is 0 and will be ignored


Doing CPU performance benchmark

Primer numbers limit: 20000

Threads started!
Done.


General statistics:
    total time:                          7.4608s
    total number of events:              10000
    total time taken by event execution: 29.8223
    response time:
         min:                                  2.96ms
         avg:                                  2.98ms
         max:                                  8.51ms
         approx.  95 percentile:               2.99ms

Threads fairness:
    events (avg/stddev):           2500.0000/3.67
    execution time (avg/stddev):   7.4556/0.00

root@pine64:/# /usr/local/src/sysbench/sysbench/sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4
sysbench 0.5:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4
Random number generator seed is 0 and will be ignored


Prime numbers limit: 20000

Initializing worker threads...

Threads started!


General statistics:
    total time:                          11.0451s
    total number of events:              10000
    total time taken by event execution: 44.1223s
    response time:
         min:                                  4.38ms
         avg:                                  4.41ms
         max:                                 27.34ms
         approx.  95 percentile:               4.41ms

Threads fairness:
    events (avg/stddev):           2500.0000/6.36
    execution time (avg/stddev):   11.0306/0.01

 

 

 

Another great example how using CPU features or not (NEON in this case) influences performance and 'benchmarking gone wrong' numbers are Linpack's MFLOPS scores. By choosing the package your distro provides instead of using one that makes use of your CPU's features you loose at lot of performance, ruin every performance per watt ratios and behave somewhat strange :)

 

Someone sent me Linpack MFLOPS numbers generated with Debian Jessie which is known for horribly conserative compiler settings when building packages -- if you switch your distro from Jessie to Ubuntu Xenial for example you get a 30 percent improvement in sysbench numbers, yeah that's the 'benchmark' we already laughed at above.

 

With Jessie's/Raspbian's hpcc package, Pine64+ gets a score of 1625 MFLOPS and RPi 3 just 1035. So is Pine64 1.6 times faster than RPi 3? Nope, that's just 'benchmarking gone wrong' since these numbers are the result of a joke: Using tools for 'High performance computing' with standard settings (no one interested in HPC would ever do that). By using the correct Linpack version that makes use of NEON optimizations on both CPUs we end up with 3400 MFLOPS (Pine64 at 1.3 GHz) vs 3600 MFLOPS (RPi 3 at 1.2 GHz).

 

So if we're talking about this use case (HPC -- high performance computing) RPi 3 easily outperforms A64 (please keep in mind that the 3400 MFLOPS I got are the result of overclocking/overvolting at 1296 MHz, Pine64 is limited to 1152 MHz by default so we're talking about 3000 MFLOPS for A64 vs. 3600 MFLOPS for RPi 3's SoC. So it's not Pine64 being 1.6 times faster but RPi 3 being more suited for Linpack numbers and this type of benchmarks only shows how wrong it is to use distro packages that are built using conservative settings (which is a must if the distro wants to support a wide range of different SoCs!)

 

Anyway: I's obvious that in case you want to use Pine64 for number crunching or performance stuff in general evaluating whether compiling packages from source might improve performance is a great idea (at least it's obvious that from a performance point of view using an ARMv6 distro with ARMv8 SoCs is stupid -- reality with Raspbian running on RPi 3 and BPi M64). ARMv8 also provides crypto extensions that might be used with OpenSSL for example. Didn't look into it yet but maybe huge performance gains when using a Pine64 as HTTPS enabled web server or VPN endpoint are possible just like we've already seen with sysbench.

 

Network performance: Pine64+ combines the SoC internal GbE MAC implementation (the same as in H3 and A83T SoCs from Allwinner) with an external RTL8211E PHY as used on most GbE capable SBC. Default iperf performance with Armbian/Xenial: +900 MBits/sec in both directions (920/940 MHz) so no need for further tuning (please read through this explanation here why blindly trusting in iperf numbers is always stupid and why it's neither necessary nor useful to further tune network settings to get better iperf numbers).

 

 

 

 


root@armbian:/var/git/Armbian# iperf3 -c 192.168.83.64
Connecting to host 192.168.83.64, port 5201
[  4] local 192.168.83.115 port 60392 connected to 192.168.83.64 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   112 MBytes   938 Mbits/sec    0    356 KBytes       
[  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    376 KBytes       
[  4]   2.00-3.00   sec   112 MBytes   943 Mbits/sec    0    376 KBytes       
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    376 KBytes       
[  4]   4.00-5.00   sec   112 MBytes   938 Mbits/sec    0    376 KBytes       
[  4]   5.00-6.00   sec   113 MBytes   947 Mbits/sec    0    376 KBytes       
[  4]   6.00-7.00   sec   112 MBytes   940 Mbits/sec    0    395 KBytes       
[  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec    0    395 KBytes       
[  4]   8.00-9.00   sec   112 MBytes   942 Mbits/sec    0    395 KBytes       
[  4]   9.00-10.00  sec   112 MBytes   942 Mbits/sec    0    395 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

root@pine64:~# iperf3 -c 192.168.83.115
Connecting to host 192.168.83.115, port 5201
[  4] local 192.168.83.64 port 39363 connected to 192.168.83.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0   1.05 MBytes       
[  4]   1.00-2.00   sec   110 MBytes   922 Mbits/sec    0   1.24 MBytes       
[  4]   2.00-3.01   sec   110 MBytes   918 Mbits/sec    0   1.24 MBytes       
[  4]   3.01-4.00   sec   109 MBytes   917 Mbits/sec    0   1.24 MBytes       
[  4]   4.00-5.01   sec   110 MBytes   918 Mbits/sec    0   1.24 MBytes       
[  4]   5.01-6.01   sec   110 MBytes   923 Mbits/sec    0   1.24 MBytes       
[  4]   6.01-7.00   sec   109 MBytes   918 Mbits/sec    0   1.24 MBytes       
[  4]   7.00-8.00   sec   110 MBytes   923 Mbits/sec    0   1.24 MBytes       
[  4]   8.00-9.00   sec   109 MBytes   912 Mbits/sec    0   1.24 MBytes       
[  4]   9.00-10.00  sec   110 MBytes   923 Mbits/sec    0   1.24 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.07 GBytes   923 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.07 GBytes   920 Mbits/sec                  receiver

 

 

 
Please keep in mind that for yet unknown reasons a couple of Pine64+ are reported to not reliably work at Gbit Ethernet speeds. Please also keep in mind how settings might matter. If you run a standard iperf test in 'passive benchmarking' mode you might get throughput numbers 200-250 Mbits/sec lower than ours maybe just due to a wrong cpufreq governor. Ethernet throughput scales linearly with CPU clockspeed with most cheap ARM SoCs (our only known exception from this is Solid-Run's Clearfog which uses a SoC optimized for IO and network throughput) so by using the ondemand governor with wrong/default settings for example you ensure that an idle SBC will only slowly increase clockspeed when you start your iperf test. This is Armbian switching from interactive to ondemand governor now being below 700 Mbits/sec just due to adjusting CPU clockspeed too slow:
 
 

 

root@pine64:~# iperf3 -c 192.168.83.115
Connecting to host 192.168.83.115, port 5201
[  4] local 192.168.83.64 port 39365 connected to 192.168.83.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.02   sec  47.9 MBytes   395 Mbits/sec    1   99.0 KBytes       
[  4]   1.02-2.02   sec  55.0 MBytes   459 Mbits/sec    0    132 KBytes       
[  4]   2.02-3.01   sec  60.3 MBytes   511 Mbits/sec    0    151 KBytes       
[  4]   3.01-4.01   sec  91.2 MBytes   769 Mbits/sec    0    170 KBytes       
[  4]   4.01-5.01   sec  96.2 MBytes   804 Mbits/sec    0    182 KBytes       
[  4]   5.01-6.01   sec  96.2 MBytes   806 Mbits/sec    0    191 KBytes       
[  4]   6.01-7.01   sec  96.2 MBytes   808 Mbits/sec    0    195 KBytes       
[  4]   7.01-8.01   sec  96.2 MBytes   808 Mbits/sec    0    197 KBytes       
[  4]   8.01-9.00   sec  95.0 MBytes   805 Mbits/sec    0    198 KBytes       
[  4]   9.00-10.00  sec  97.5 MBytes   815 Mbits/sec    0    199 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   832 MBytes   698 Mbits/sec    1             sender
[  4]   0.00-10.00  sec   832 MBytes   698 Mbits/sec                  receiver

 

 

 

The other stuff normally 'benchmarked' is not worth mentioning/testing it so just as quick notes:

  • A64 is showing the same SDIO limitation as most other SoCs limiting sequential transer speeds to/from SD card to ~23MB/s (do the math yourself: SDIO with 4 bit @ 50 MHz minus some overhead is 23 MB/s) -- fortunately that's rather uninteresting since random IO matters on SBCs and there it's your choice to choose between crappy cards that horribly suck or follow our recommendations and choose a really fast card. But Pine64 can not use the faster eMMC interface so if you really need high IO bandwidth and high IOPS better choose a different device
  • USB is USB 2.0 so expect ~35MB/s with BSP kernel and ~40MB/s with mainline kernel and UASP capable disk enclosures for individual USB connections (UASP + mainline kernel might show high random IO numbers if used together with an SSD!)
  • HW accelerated video decoding is already possible (see here for the codec matrix) and situation with HW accelerated video encoding looks promising too: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/

In case one is interested in performance testing on SBCs monitoring what's happening is mandatory. Currently our armbianmonitor tool does not install the necessary templates on A64 so still my script to install this stuff on A64 should be used: http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-a64.sh (read the script's header how to install)

 

Performance with vanilla Armbian image:

 

Not interesting at all at the time of this writing since while Pine64 happily boots mainline u-boot/kernel it's way too early to do tests in this area. Currently there's no access to the AXP803 PMIC from mainline kernel so not even VDD_CPUX voltage regulation works and as a result cpufreq scaling is also not working and the SoC is clocked pretty conservative. Since most performance relevant stuff running on cheap ARM SoCs depends on (switching as fast as possible to) high CPU clockspeeds benchmarking is absolutely useless now.

 

You should also keep in mind that many core features still not work with mainline kernel so this is really stuff for developers (who normally prefer their own way to boot their freshly compiled kernels). So please don't expect that much from vanilla images for A64 boards now, better choose the legacy variant.

 

The future?

 

A few more A64 boards are announced or already available as dev samples, for example the aforementioned BPi M64 (possible advantages over Pine64: sane DC-IN, real USB OTG, more USB host ports behind an internal USB hub, eMMC available and custom leds being able to provide user feedback, everything else is more or less the same as the 2 GB Pine64+) or Olimex working on both an SBC and an A64 based Laptop.

 

And then Xunlong announced 2 new SBC based on Allwinner's H5. H5 (product brief) seems to be A64's bigger sibling providing video/GPU enhancements, 3 true USB host ports in addition to one USB OTG (just like H3 where we can use all 4 USB ports that do not have to share bandwidth), integrating a Fast Ethernet PHY (just like H3) but lacks PMIC support (again just like H3, so no mobile useage, no battery support out of the box and it gets interesting how VDD_CPUX voltage regulation will work there -- maybe 'just like H3' again).

 

Since A64 shares many/most IP blocks with H3 and A83T from Allwinner I still hope that H5 will be just a mixture of A64 and H3 and we will get full support based on what we now have for these 2 other SoCs pretty fast. But that's 100 percent speculation at this moment :)

 

Update regarding longsleep's pine64_tune_network.sh script. Benchmark results don't get automatically worse when applying the tweaks from his script but the result variation gets huge (730 - 950 Mbits/sec, exceeding 940 Mbits/sec is already an indication that buffers are invoked):

 

 

 


root@pine64:/home/tk# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50002
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50004
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  90.7 MBytes   759 Mbits/sec                  
[  5]   1.00-2.00   sec  92.2 MBytes   774 Mbits/sec                  
[  5]   2.00-3.00   sec  92.5 MBytes   776 Mbits/sec                  
[  5]   3.00-4.00   sec  92.5 MBytes   776 Mbits/sec                  
[  5]   4.00-5.00   sec  92.6 MBytes   777 Mbits/sec                  
[  5]   5.00-6.00   sec   106 MBytes   889 Mbits/sec                  
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   7.00-8.00   sec   111 MBytes   927 Mbits/sec                  
[  5]   8.00-9.00   sec   101 MBytes   847 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec                  
[  5]  10.00-10.02  sec  1.66 MBytes   931 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec  1007 MBytes   843 Mbits/sec    9             sender
[  5]   0.00-10.02  sec  1004 MBytes   841 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50006
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50008
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  88.4 MBytes   740 Mbits/sec                  
[  5]   1.00-2.00   sec  91.9 MBytes   771 Mbits/sec                  
[  5]   2.00-3.00   sec   109 MBytes   918 Mbits/sec                  
[  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   5.00-6.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   6.00-7.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   7.00-8.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
[  5]  10.00-10.02  sec  1.89 MBytes   928 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec  1.05 GBytes   904 Mbits/sec    0             sender
[  5]   0.00-10.02  sec  1.05 GBytes   902 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50010
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50012
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  87.7 MBytes   734 Mbits/sec                  
[  5]   1.00-2.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   2.00-3.00   sec  92.2 MBytes   773 Mbits/sec                  
[  5]   3.00-4.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   4.00-5.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   5.00-6.00   sec   102 MBytes   859 Mbits/sec                  
[  5]   6.00-7.00   sec  93.1 MBytes   781 Mbits/sec                  
[  5]   7.00-8.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   8.00-9.00   sec  92.1 MBytes   773 Mbits/sec                  
[  5]   9.00-10.00  sec  94.9 MBytes   796 Mbits/sec                  
[  5]  10.00-10.02  sec  1.62 MBytes   740 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec   936 MBytes   783 Mbits/sec    0             sender
[  5]   0.00-10.02  sec   933 MBytes   781 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.83.115, port 50014
[  5] local 192.168.83.76 port 5201 connected to 192.168.83.115 port 50016
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  87.1 MBytes   729 Mbits/sec                  
[  5]   1.00-2.00   sec  92.1 MBytes   774 Mbits/sec                  
[  5]   2.00-3.00   sec  91.8 MBytes   769 Mbits/sec                  
[  5]   3.00-4.00   sec  90.4 MBytes   759 Mbits/sec                  
[  5]   4.00-5.00   sec  96.4 MBytes   808 Mbits/sec                  
[  5]   5.00-6.00   sec  90.2 MBytes   758 Mbits/sec                  
[  5]   6.00-7.00   sec   113 MBytes   951 Mbits/sec                  
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec                  
[  5]   8.00-9.00   sec   112 MBytes   942 Mbits/sec                  
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec                  
[  5]  10.00-10.02  sec  1.83 MBytes   932 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.02  sec  1003 MBytes   840 Mbits/sec    0             sender
[  5]   0.00-10.02  sec  1000 MBytes   837 Mbits/sec                  receiver

 

 

 

So better enjoy defaults unless you really know what you do since network performance tuning works in different directions. Stuff that might increase throughput might negatively affect latency and vice versa. So if you start to tune, tune for your specific use case!

Link to comment
Share on other sites

Recommended Posts

Donate and support the project!

  • 0

OK, I've added the missing kernel parameters (by merging the config-4.9.0-pine64 shipped with the Armbian install image) and built a 4.9 kernel with USB and Docker support. You can find the defconfig here.

Is there a reason why the linux-pine64-dev.config cannot be found here?

Because it is called linux-sun50i-dev.config (it is shared with Orange Pi PC2)

Link to comment
Share on other sites

  • 0

I found a strange bug and seen it twice in a week :

 

After few days running, my PineA64 had wrong date, some thing like "Tue Mar 13 20:50:11 EDT 2153".

Trying to restart NTP didn't fix it. Trying to set it manually give me an error :

root@pine64:~# date -s "2017-02-03 00:00:01"
date: cannot set date: Invalid argument

Doing an "strace" with it reveal that it can not write system clock :

settimeofday({1486098000, 0}, NULL)     = -1 EINVAL (Invalid argument)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3

Doing search on the net, I've found http://nerdbynature.de/s9y/2009/07/22/cannot-set-date-Invalid-argumentand http://www.mail-archive.com/bug-coreutils@gnu.org/msg14103.html, but not real answers other than it is really the kernel that are f*k*ing up with the system clock. And the issue is gone if I simply reboot the board. Really strange ... Especially that it happened only on PineA64 ...

 

As someone got the similar issue ?

Link to comment
Share on other sites

  • 0

Is there support for the hardware RTC in mainline (assuming you are testing the mainline)? If yes, then it may be related to wrong RTC settings like external or internal oscillator. If not - then maybe it's related to the arch timer bug? https://github.com/longsleep/linux-pine64/issues/44#issuecomment-263060276
 

Doing an "strace" with it reveal that it can not write system clock :

settimeofday({1486098000, 0}, NULL)     = -1 EINVAL (Invalid argument)

I think kernel just prevents unsafe date/time changes, there are several -EINVAL returns in the date/time changing code.

Link to comment
Share on other sites

  • 0

I was just looking at DT about this, because if I remember, I didn't had the issue up until recently.

I'm seeing that in the old longsleep DT, it was using 'sun50i-rtc' and in the current it is using 'sun6i-a31-rtc'.

Since I kept also several A64 armbian previous images, I will look into them too.

(I will also check what is the frequency of the occurence, because maybe it happen every 24hrs by reading wrong value from a sync service call. Let see tomorrow ...)

(Another thing I found : the H3 has /dev/rtc and clear trace in dmesg, but not with H5 or A64, no trace at all. But why I don't have the same issue with H5 ?)

Link to comment
Share on other sites

  • 0

Oh ! you received a SoPine ? Lucky guy ! ;)

  • LPDDR3 support is hacky and experimental (and even worse - made by me from memory dumps and A83T/Banana Pi M3 code)
  • now looks like MMC has different card detect polarity or something worse
  • Also since the SoM is small and there is not heat transfer to the baseboard the SoC easily heats up to 85-90°C w/o a heatsink on legacy kernel and performance governor

So even though it has improvements over the old Pine64 like eMMC slot, SPI flash, proper power supply connector (though 3.5mm barrel plug and not 4.0 like on Oranges and Cubietruck), it still needs work to be done to consider myself "lucky"  :)

Link to comment
Share on other sites

  • 0

Also since the SoM is small and there is not heat transfer to the baseboard the SoC easily heats up to 85-90°C w/o a heatsink on legacy kernel and performance governor

 

Just curious: what's your strategy to deal with this running mainline kernel now (BTW: Kudos! You got it working!)? Sounds like having 'safety headroom' in mind we must limit clockspeed to 480 MHz as long as there's no working throttling? Did you test how lot cpufreq goes with legacy when running cpuburn-a53?

Link to comment
Share on other sites

  • 0

Just curious: what's your strategy to deal with this running mainline kernel now (BTW: Kudos! You got it working!)?

My strategy - put a heatsink on it and trying not to accidentally burn the fingers  :)

 

Sounds like having 'safety headroom' in mind we must limit clockspeed to 480 MHz as long as there's no working throttling?

As long as there is working DVFS or at least DFS we should think about it, and I have some other concerns in mind too.

 

Did you test how lot cpufreq goes with legacy when running cpuburn-a53?

For me it went to 80+°C in idle (and performance governor), I'm not sure I should attempt cpuburn with our settings from the "big" Pine64 without active cooling or at least a normal heatsink and not a stack of coins that I'm using now.

Link to comment
Share on other sites

  • 0

For me it went to 80+°C in idle (and performance governor)

 

Wow, that's an awful lot. :(

 

TL Lim talked about a 'Graphene nano technology heatsink' (sent you an email regarding this just now) but obviously you didn't get one? They also wanted to explore other heatsink options and based on your observations it seems that's mandatory to do anything with SoPine at least if it's about the use cases this module has been designed for in the first place.

Link to comment
Share on other sites

  • 0

TL Lim talked about a 'Graphene nano technology heatsink' (sent you an email regarding this just now) but obviously you didn't get one?

No, only SoPine, baseboard (with no eMMC) and a 5V/3A power supply with US type plug  :)

 

They also wanted to explore other heatsink options and based on your observations it seems that's mandatory to do anything with SoPine at least if it's about the use cases this module has been designed for in the first place.

Well, these temperatures are not a surprise given the SoM board size and type of CPU cores. It should be fine with an adequate heatsink or any kind of other thermal interface.

Link to comment
Share on other sites

  • 0

I also have one of the new SOPine now (with eMMC port and SPI Flash) and trying to come up with a 3D printable heat sink spacer that mechanically supports the SO module and allows clip-on mounting of some standard heatsink with thermal pads...

 

If someone needs a SOPine for development purposes please tell me, I can probably forward requests to Tl...

 

I also got a prototype 11inch Pinebook from Tl during the linux-sunxi meeting at FOSDEM, I will try to make an Armbian build target for it once ayufan and me figured out all the bits to have proper u-boot and a patches for longsleep's BSP kernel. Currently ayufan has boot-tools on his github using FEL to expose the eMMC on Pine or Pinebook as USB mass storage which makes writing images a lot easier.

Link to comment
Share on other sites

  • 0

Currently ayufan has boot-tools on his github using FEL to expose the eMMC on Pine or Pinebook as USB mass storage which makes writing images a lot easier.

 

I've seen this already and wonder how fast writes are? Based on tests with other Allwinner SoCs it seems u-boot currently provides pretty low sequential write speeds in this mode. After some discussions Mikhail came up with a similar approach half a year ago (using sun8i legacy kernel's USB mass storage gadget mode which provides ~20 MB/s write speeds IIRC): https://github.com/zador-blood-stained/fel-mass-storage (would be great if other SoCs could be added there too)

 

Regarding the eMMC connector on SoPine's baseboard: looks similar to the ones Hardkernel uses on some ODROIDs. Do you have any information (to share) on this?

 

BTW: Since I sent Mikhail the wrong boot0 blob for SoPine in the beginning (not useable with LPDDR3) I would believe Pinebook also uses DDR3(L) now? Can you or Kamil confirm?

Link to comment
Share on other sites

  • 0

&amp;amp;amp;amp;nbsp;

I've seen this already and wonder how fast writes are? Based on tests with other Allwinner SoCs it seems u-boot currently provides pretty low sequential write speeds in this mode. After some discussions Mikhail came up with a similar approach half a year ago (using sun8i legacy kernel's USB mass storage gadget mode which provides ~20 MB/s write speeds IIRC):&amp;amp;amp;amp;nbsp;https://github.com/zador-blood-stained/fel-mass-storage&amp;amp;amp;amp;nbsp;(would be great if other SoCs could be added there too)

&amp;amp;amp;amp;nbsp;

Regarding the eMMC connector on SoPine's baseboard: looks similar to the ones Hardkernel uses on some ODROIDs. Do you have any information (to share) on this?

&amp;amp;amp;amp;nbsp;

BTW: Since I sent Mikhail the wrong boot0 blob for SoPine in the beginning (not useable with LPDDR3) I would believe Pinebook also uses DDR3(L) now? Can you or Kamil confirm?

&amp;amp;amp;amp;nbsp;

 

I did write some images to the internal Pinbeook eMMC yesterday and got speed between 50-60MB/s , reading was around 80MB/s as reported by dd but that seems a little high for USB2.0... ayufan did some measurements too https://gist.github.com/ayufan/caf1a581a53e3d16772ee363f7f5b075

 

I think Tl said the pinout is compatible to the hardkernel modules, but I can verify that with the schematics maybe...

 

As far as I know (from the schematics and looking at the boot output of the stock AW Android images) it is LPDDR3 ... I should probably start a wiki entry on linux-sunxi...

 

Pinebook schematic seems to be on the shop page now: http://files.pine64.org/doc/pinebook/pinebook_mainboard_schematic_1.0.pdf

Link to comment
Share on other sites

  • 0

I did write some images to the internal Pinbeook eMMC yesterday and got speed between 50-60MB/s , reading was around 80MB/s as reported by dd but that seems a little high for USB2.0... ayufan did some measurements too https://gist.github.com/ayufan/caf1a581a53e3d16772ee363f7f5b075

 

I came already across his iozone test and linked to it on CNX. :) And 80MB/s through USB2.0 is not just a 'little high' but simply impossible (the best you could get with UASP which isn't implemented by u-boot on a single connection is 41 or maybe 42 MB/s).

 

Regarding LPDDR3 vs. DDR3 please see post #237 and #238 of this thread. I wonder why the specific boot0 blob works for ayufan. Anyway: would be great if you can try to clarify this and correct my sentence here if it's LPDDR3: http://linux-sunxi.org/Pine64#Variants (just added link to schematic a minute ago)

Link to comment
Share on other sites

  • 0

I just took a closer look at my Pinebook PCB and the DRAM chips are https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-m x 4

 

1.35V DDR3L-RS SDRAM with D9QLJ stamp code

 

256 Meg x 16 256M16

 

96-ball 9mm x 14mm FBGA

 

tCK = 1.25ns, CL = 11

 

1600 11-11-11 13.75 13.75 13.75

 

This PCB is a V1.1 Version from september 2016, so they could have changed DRAM for the next version as the schematic states... 2017-01-10 on page 4 for the DRAM

Link to comment
Share on other sites

  • 0

 

 

I just took a closer look at my Pinebook PCB and the DRAM chips are https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-m x 4

 

1.35V DDR3L-RS SDRAM with D9QLJ stamp code

 

256 Meg x 16 256M16

 

96-ball 9mm x 14mm FBGA

 

tCK = 1.25ns, CL = 11

 

1600 11-11-11 13.75 13.75 13.75

 

This PCB is a V1.1 Version, so they could have changed DRAM for the V2.0 as the schematic states...

 

 

Where did you get your pinebook ???

 

edit: nevermind, i see you got a prototype... Can you write more about it (quality, battery ,screen etc) ?

Edited by tkaiser
Hide stupid fullquote again
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
Answer this question...

×   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...
 Share

×
×
  • Create New...