Jump to content

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

tkaiser

By tkaiser
in Pine A64

 Share

Recommended Posts

tkaiser

tkaiser

Posted
  • Author
Posted
  On 9/13/2016 at 7:51 AM, Davey Darko said:

And now he kicked me out of chat, I never even said anything in the chat. LOL. Man those forum rep points must be like water for him.

 

Well, let's stop speculating about motives and focus on the real problem again (him being a huge part of though). He closed the thread, censored the advise to measure voltages away and even discourages users to do so ('I have proven that the VDD33 voltage is not the problem').

 

So all we have now are Zador's measurements on his board where no problem occurs, we have @androsch's board where I can not measure since I sent it back to @androsch yesterday before new schematic release and Zador came up with the PHY_VDD33 suggestion and we now have to rely on others taking notice (quite unlikely given the weird situation in pine64 forum). So let's see what happens when @-L0thar-'s gear arrives and he's able to compare his two boards.

1
kometchtech

kometchtech

Posted
Posted

@tkaiser

 

As far as I tried measured in iperf it seems out speed.
However, perhaps because of Packet loss, it takes a very time situation to apt-get update.
kometch@pine64:~$ iperf3 -c 192.168.122.223                                     
Connecting to host 192.168.122.223, port 5201                                   
[  4] local 192.168.122.171 port 42206 connected to 192.168.122.223 port 5201   
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd                
[  4]   0.00-1.01   sec  46.6 MBytes   386 Mbits/sec  130    215 KBytes         
[  4]   1.01-2.00   sec  34.7 MBytes   295 Mbits/sec   70   90.5 KBytes         
[  4]   2.00-3.00   sec  45.6 MBytes   382 Mbits/sec   10    173 KBytes         
[  4]   3.00-4.00   sec  55.9 MBytes   468 Mbits/sec   94    164 KBytes         
[  4]   4.00-5.00   sec  56.0 MBytes   470 Mbits/sec  120    191 KBytes         
[  4]   5.00-6.01   sec  57.7 MBytes   480 Mbits/sec   55    245 KBytes         
[  4]   6.01-7.00   sec  45.0 MBytes   381 Mbits/sec   59    141 KBytes         
[  4]   7.00-8.01   sec  45.4 MBytes   377 Mbits/sec   17    178 KBytes         
[  4]   8.01-9.02   sec  53.9 MBytes   447 Mbits/sec  120    133 KBytes         
[  4]   9.02-10.00  sec  56.5 MBytes   484 Mbits/sec   38    198 KBytes         
- - - - - - - - - - - - - - - - - - - - - - - - -                               
[ ID] Interval           Transfer     Bandwidth       Retr                      
[  4]   0.00-10.00  sec   497 MBytes   417 Mbits/sec  713             sender    
[  4]   0.00-10.00  sec   496 MBytes   416 Mbits/sec                  receiver  
                                                                                
iperf Done.  
zador.blood.stained

zador.blood.stained

Posted
Posted
  On 9/13/2016 at 1:51 PM, kometchtech said: 
 - - - - - - - - - - - - - - - - - - - - - - - -                               
[ ID] Interval           Transfer     Bandwidth       Retr                      
[  4]   0.00-10.00  sec   497 MBytes   417 Mbits/sec  713             sender    
[  4]   0.00-10.00  sec   496 MBytes   416 Mbits/sec                  receiver  

Well, there are retransmissions and speed is relatively low. Is this legacy kernel or mainline? How do you power your board (microUSB or GPIO pins, power supply characteristics)?

tkaiser

tkaiser

Posted
  • Author
Posted
  On 9/13/2016 at 1:51 PM, kometchtech said:

apt-get update

 

This is the other direction. Please have a look at posts #33 and #34. With @androsch's board by powering through the Euler pins I was able to immediately increase the throughput in the direction you tested now but not in the other. Please test again, this time from 192.168.122.171 to 192.168.122.223. I would assume numbers will be terribly low then.

 

Do you have a Multimeter and are able to measure PHY_VDD33 as Zador outlined yesterday?

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 9/13/2016 at 2:09 PM, tkaiser said:

Do you have a Multimeter and are able to measure PHY_VDD33 as Zador outlined yesterday?

First we need to check if we can reproduce both very low and normal results on the same board, otherwise we will get "numbers without meaning"

kometchtech

kometchtech

Posted
Posted

@zador.blood.stained

 

This data is the result of running with microUSB powered by mainline kernel.

 

@tkaiser

 

Because I do not own a multi-meter, it will not be able to measure the data.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 9/13/2016 at 2:12 PM, zador.blood.stained said:

First we need to check if we can reproduce both very low and normal results on the same board, otherwise we will get "numbers without meaning"

 

Hmm... just to document what I did (still noobie needing your help to understand electronics basics):

post-7-0-76842800-1473779910_thumb.jpg

  • In post #33 I started with the USB PSU on the right using an 'average' (crappy) USB cable and powered through Micro USB. Tested in the same direction as @kometchtech and got pretty bad results.
  • Then I replaced immediately USB PSU cable with the dual voltage PSU next to it and powered through Euler pins 4 and 6. In TX direction I got close to 900 Mbits/sec but in RX direction (apt-get update|upgrade ;) ) everything remained bad.
  • After I found my '5.5/2.1 to Micro USB' adapter (in the lower middle of the picture) I could use the next 2 PSUs. The larger one is rated 5V/3A (came IIRC as part of the 'UP Board' package) and the small one is cheap chinese crap rated 5V/2A and also the PSU showing 'best GbE performance' (since it provides 5.25V?). When I did tests with mainline kernel then using the larger dual voltage PSU with screw terminal (jumper wires connecting to Euler pins) I ended up with 'no PHY found' (PSU only providing 4.97V) and when using the small chinese crap connected to Micro USB connector GbE worked but showed still heavy symptoms in RX direction (TX being fine, I got the 470 Mbits/sec that can be expected with mainline kernel running at 408 MHz)
  • On friday I bought the large PSU on the left and re-tested with different voltages but got only results I don't understand and that were not that reproducable (at least it seems obvious to me that we're not only talking about voltage but instead about other PSU characteristics I have no idea of :)

I don't really trust in the large PSU since when I did tests with the Wandboard Quad on weekend testing through SATA and USB performance with i.MX6 using this PSU led reproducable to no Ethernet (not even PHY leds blinking). I wasted two hours testing through all different Wandboard OS images (could've ported Armbian to Wandboard in the same amount of time  :wacko: ) just to realize that I had to use a different PSU. But that's a different story and needs more time/investigation.

 

So I still find it hard to give any advice how to reproduce 'getting better numbers'. I only know that heavy undervolting (using a crappy USB cable) resulted in pretty bad TX numbers while providing almost 5V cured that. And I also know that I got strange voltage drops measured on the USB ports depending on how I powered @androsch's board. So it seems to be PSU related and I would already be happy if we're able to collect voltage numbers (measuring DC-IN, pins 4/6 on RPi and Euler headers and on the USB ports and of course also PHY_VDD33).

 

I hope I didn't forget anything relevant.

stepw

stepw

Posted
Posted
  On 9/12/2016 at 5:09 PM, zador.blood.stained said:

Currently I don't see any significant differences in PHY power part, but I think I found a point where the voltage can be measured, at least on my board, and running iperf3 test shows that voltage drops by 0.02V

 

Edit: I mean PHY 3.3V voltage (PHY_VDD33)

 

I have a 'bad' PINE64+ board, running armbian with legacy kernel, powered via micro-USB AC adapter. NIC and UART0 serial are the only active peripherals. 100Mbps is perfectly fine, but there's a major packet loss at 1Gbps, no need for iperf to tell there's an issue.

 

VDD33 voltage is between 3.26V and 3.27V, regardless of

- 1Gbps or 100Mbps or 10Mbps link speed

- CPU idle (/sys/class/thermal/thermal_zone0/temp @ 42 degrees) or busy (/sys/class/thermal/thermal_zone0/temp @ 65 degrees)

- 3 different microUSB AC 5V adapters and cables

 

That voltage is within tolerance range of 2.97V to 3.63V for PHY VDD33 (per PHY DS). PMIC AC input tolerance range is 3.5V to 7V (per PMIC DS), so PHY should be getting conditioned ~3.3V consistently, even when microUSB AC source is used. Unfortunately I don't have a scope to monitor continuously, but if AC-IN voltage drops were affecting 1Gbps communications, I'd expect them to equally affect 100Mbps communications and that is not the case. So the issue with my board doesn't seem to be caused by PHY input voltage fluctuations.

 

However, there is a noticeable difference in the amount of packet loss with different power sources:

1. laptop USB, so <500mA, 2 feet USB cable

PC -> SBC: 30% loss
SBC -> PC: 36% loss
 

2. AC 5V/2A adapter, 6 feet USB cable

PC -> SBC: 5% loss
SBC -> PC: 11% loss

 

3. AC 5V/3A adapter, 3 feet USB cable

PC -> SBC: 15% loss
SBC -> PC: 31% loss

 

I'd speculate that there's possibly another element sensitive to AC input inconsistencies that might not be conditioned by the PMIC or that may have a narrow tolerance range. Alternatively, PINE64+ PCB layout might not be strictly following guidelines for RTL8211E IC as set forth in PHY DS, resulting in EMI affecting its operation or VDD10 conditioned input being outside of a narrow 0.95V to 1.06V tolerance range.

 

References:

PHY DS - http://files.pine64.org/doc/datasheet/pine64/rtl8211e(g)-vb(vl)-cg_datasheet_1.6.pdf

PMIC DS - http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf

stepw

stepw

Posted
Posted

So I've fiddled around with EMAC IC and its RGMII interface to PHY IC.

 

Some findings:

1. MII RXERC = 0 in mii-tool reg dump, supposedly that indicates PHY is not receiving erroneous frames

#mii-tool -vvv
  registers for MII PHY 0:
    1140 796d 001c c915 01e1 cde1 000d 2001
    6801 0300 7800 0000 0000 0000 0000 3000
    016e acc2 9f01 0000 8040 1006 4100 2100
    0000 8c00 0040 0106 21fc 8038 0123 0000 

2. EMAC reports RGMII speed/duplex and clock is consistent with PHY link type

 

1Gbps/full:
EMAC BASIC_CTL_0: 
#devmem2 0x1c30000 w

0x1 = 1Gbps/full

EMAC RGMII_STA:

#devmem2 0x1c300d0 w

0xD = 0b1101 - 1Gbps, 125MHz clock

MII PHY:

#mii-tool -vvv
  registers for MII PHY 0:
    1140 796d 001c c915 0001 cde1 000f 2001
    6801 0200 7800 0000 0000 0000 0000 3000
    016e acc2 9f01 6c52 8040 1006 4100 2100
    0000 8c00 0040 0106 21fc 8038 0123 0000
100Mbps/full:
EMAC BASIC_CTL_0: 
#devmem2 0x1c30000 w

0xD = 100Mbps/full

EMAC RGMII_STA:

#devmem2 0x1c300d0 w

0xB = 0b1011 - 100Mbps, 25MHz clock

MII PHY:

#mii-tool -vvv
  registers for MII PHY 0:
    1140 796d 001c c915 01e1 cde1 000d 2001
    6801 0300 7800 0000 0000 0000 0000 3000
    016e acc2 9f01 0000 8040 1006 4100 2100
    0000 8c00 0040 0106 21fc 8038 0123 0000

 

3. EMAC is using internal clock for 1Gbps/125MHz

A64 EMAC_CLK_REG:

#devmem2 0x1c00030 w

clock 0b01 = GMII/RGMII external
clock 0b10 = GMII/RGMII internal (default) 
This said, there could be a problem with 125MHz clock sync, required for proper RGMII communication between EMAC and PHY at 1Gbps rate. Judging by latest PCB diagrams, PHY CLK125 is attached to EMAC, presumably to supply 125MHz clock to EMAC, however EMAC's internal clock is enabled (by the EMAC driver?), so EMAC and PHY clocks are not synchronized. However, switching to external clock (supplied by PHY?) results in even higher packet loss, upwards of 80%
 
I was trying to dump EMAC DMA TX/RX descriptors and buffers to get an idea of whether frames received by PHY make it to EMAC over RGMII and vice versa, but so far didn't manage to access them from userland. I guess it would take to debug EMAC driver to monitor them and accumulate TX/RX frames and errors statistics.
1
kometchtech

kometchtech

Posted
Posted
in the mainline kernel, and I get the data in power from the GPIO.

The output of the power supply adapter is 5V/3A is written. 



kometch@pine64:~$ iperf3 -c 192.168.122.223

Connecting to host 192.168.122.223, port 5201

[  4] local 192.168.122.176 port 38366 connected to 192.168.122.223 port 5201

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd

[  4]   0.00-1.00   sec  57.6 MBytes   483 Mbits/sec   17    253 KBytes       

[  4]   1.00-2.00   sec  56.2 MBytes   471 Mbits/sec  127    253 KBytes       

[  4]   2.00-3.00   sec  55.9 MBytes   469 Mbits/sec  129    247 KBytes       

[  4]   3.00-4.00   sec  55.8 MBytes   468 Mbits/sec  194    180 KBytes       

[  4]   4.00-5.00   sec  56.2 MBytes   471 Mbits/sec  183    167 KBytes       

[  4]   5.00-6.00   sec  56.4 MBytes   473 Mbits/sec    0    256 KBytes       

[  4]   6.00-7.00   sec  56.4 MBytes   473 Mbits/sec  165    236 KBytes       

[  4]   7.00-8.00   sec  55.7 MBytes   468 Mbits/sec  208    180 KBytes       

[  4]   8.00-9.00   sec  55.7 MBytes   467 Mbits/sec   80    181 KBytes       

[  4]   9.00-10.00  sec  56.8 MBytes   476 Mbits/sec    0    256 KBytes       

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth       Retr

[  4]   0.00-10.00  sec   563 MBytes   472 Mbits/sec  1103             sender

[  4]   0.00-10.00  sec   561 MBytes   471 Mbits/sec                  receiver



iperf Done.
pfeerick

pfeerick

Posted
Posted

So, I know it isn't comparing apples with apples, but I just have to post this as it shows the GbE on the pine64 can indeed move when it wants too... 

 

I finally reformatted my USB flash drive as btrfs, and made a zeroed 1G file as you suggested earlier (with compression on). I'd started armbian up again a youtube upload for tonight, so thought I'd make that file first,and then see what the transfer speed was like. I'm copying to the same desktop computer as before, but it's booted in to windows (I know, you won't like it) this time (dual-boot), and it was... fast... damn near missed getting the screenshot! 

 

post-2100-0-36288500-1474016397_thumb.png

 

 

1
tkaiser

tkaiser

Posted
  • Author
Posted
  On 9/16/2016 at 9:02 AM, pfeerick said:

it shows the GbE on the pine64 can indeed move when it wants too... 

 

 

Well, it has been already known that Pine64+ is capable of exceeding 80 MB/s based on 'raw' iperf3 numbers (only one person needed to be convinced, thanks for doing the job). It would be great if you could grab 'Helios LanTest' (available at http://webshare.helios.de user 'tools', pwd 'tools') and run each 3 times with the settings for 'Very fast' and 'Enterprise' networks.

 

And while this sort of test using btrfs compression is somewhat useless since it only demonstrates what's possible if storage isn't the bottleneck (but most of the time disk IO will be the bottleneck since we're limited by USB 2.0) it gives also a nice preview of what will be possible later when mainline kernel is ready (and EMAC driver further improves) or when Pine64+ runs completely from fast network storage (since GbE is the fastest interface available on A64 this makes perfectly sense)

1
pfeerick

pfeerick

Posted
Posted

Indeed... if we were always transferring zero byte files... I'd be very worried that we have nothing better to do with our time ;)

 

This what you wanted?

 

post-2100-0-43532900-1474028835_thumb.png

 

post-2100-0-64673100-1474028847_thumb.png

tkaiser

tkaiser

Posted
  • Author
Posted
  On 9/16/2016 at 12:30 PM, pfeerick said:

This what you wanted?

 

Exactly, I was especially interested in those little orange arrows (in case you ever test again with LanTest please mouse over a bar with huge variations and see what happens). Thanks!

 

BTW: Reasons why Explorer is capable of sucking more out of Pine64's Ethernet port here: http://www.helios.de/web/EN/support/TI/157.html

pfeerick

pfeerick

Posted
Posted

lol... sound about right... another file management tool I use does exactly the same thing... uses multiple I/O threads, and also uses larger buffers for certain transfers (i.e. drive to drive, or via network IIRC). I'll throw that in just for fun... and also the reverse direction file copy... the 1gb of zeros TO the pine64 this time... looks like the brtfs is pretty happy to compress that puppy down as it goes... so happy in fact that I don't see the USB lighting up much during the transfer :-) So it will be interesting to see what happens once the dual USB opens up. I will say that after transferring of the the more typical data types (for me anyway - some 270MB of uni assessments and notes, and about 250MB worth of PDF datasheets)... it processed very quickly...  It it understandably fell over the zillions of small files that were in a 2.1GB datasheet... (there were a heck of a lot of small c files in it) and was dropping to 10MB/s speeds... but picking up again when hitting some big files (bottom sceenshot).

 

And on a repeat run of LanTest on GbE, the measurement with the biggest swing was the 'write 300MB to file' test again, with a AVG as 52.7 MB/s, and the min and max in the tooltip were 51.2MB/s and 67.4MB/s. The read 300MB/s test only had about a 2MB/s swing... (65.0 - 67.4), and all the others really didn't have too much separation ether.

 

post-2100-0-43706700-1474071520_thumb.png

 

post-2100-0-10792200-1474071531_thumb.png

 

post-2100-0-86028400-1474072766_thumb.png

tkaiser

tkaiser

Posted
  • Author
Posted

Small note: Since TL Lim said he will send an LCD to me, I just had a look what seems to be necessary to support the LCD in Linux (ayufan's commits from Sep 11, 2016 here). Looks like the usual adjustments we know from Allwinner BSP since ages (this time in DT and not in fex any more):

            screen0_output_type = <0x00000001>;
            screen0_output_mode = <0x00000004>;
            screen1_output_type = <0x00000003>;
            screen1_output_mode = <0x00000004>;
			...
            lcd_used = <0x00000001>;
Of course in boot_disp section also switching from HDMI to LCD necessary:
            output_type = <0x00000001>;
            output_mode = <0x00000004>;

And for the touch:

        ctp {
            device_type = "ctp";
            compatible = "allwinner,sun50i-ctp-para";
            status = "okay";
            ctp_used = <0x00000001>;
            ctp_name = "gt911_DB2";
            ctp_twi_id = <0x00000000>;
            ctp_twi_addr = <0x00000040>;
            ctp_screen_max_x = <0x00000400>;
            ctp_screen_max_y = <0x00000258>;
            ctp_revert_x_flag = <0x00000001>;
            ctp_revert_y_flag = <0x00000001>; 

When I played around with NanoPI M3 I realized that FriendlyARM uses code in u-boot to detect a connected LCD and then configures the kernel correctly (via cmdline there). Wonder whether this is also possible with Pine64...

tkaiser

tkaiser

Posted
  • Author
Posted

Nice, just discovered the Azpen Hybrx A64 laptop starting at $69: http://hybrxpc.com/about-hybrx/(combining an A64 board with cheap and most probably ultra glossy 1366x768 LCD and starting with 1 GB DRAM and 16 GB flash). In case it's eMMC it should be possible to flash Armbian to it through USB/FEL...

 

LOL, the same person (Charbax) showcases Allwinner's reference design and 5 months later the very same device in pink (known as Azpen Hybrx now).

1
tkaiser

tkaiser

Posted
  • Author
Posted

Update: TL Lim from Pine64 sent out a couple of hardware: 3 Pine64+ 2GB, WiFi/BT modules, one 7" LCD and a camera module.

 

I only had time to check for the GbE issue (only one Pine64+ affected so two are working!) and LCD. Works flawlessly with Android 7.0 (checked only whether Android on Pine64 now behaves like Armbian and resizes the image on first boot -- check!) but not with Linux in my few tests with Armbian legacy build, the board simply freezes or even powers down with LCD connected. It seems we have an AXP803 PMIC problem with legacy u-boot/kernel here since this occurs even without DT modifications.

 

Edit: Below first our legacy image freezing (with DT modification to activate LCD) and then most recent Android 7.0 image booting:

 

  Reveal hidden contents

 

 

Edit: Due to lack of time I only tested shortly with the LCD and maybe I suffered from bad PSU or anything else.

androsch

androsch

Posted
Posted

Also received a replacement board, but same basic problems with GbE, so unfortunately no further help from my side possible

Gesendet von meinem XT1032 mit Tapatalk

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/6/2016 at 3:58 PM, androsch said:

Also received a replacement board, but same basic problems with GbE, so unfortunately no further help from my side possible

 

Please get back to TL Lim and ask what to do. I can send you one of the working boards but need it here for some time to do a few tests before.

 

They really should start with a quick QA round at least for the replacement boards (they sent 4 boards out to us and 2 are defective -- huh?). But it seems they really don't care that much about what's happening...

 

BTW: Had a short look into pine64 forums after weeks. Unbelievable that a specific person is still moderator and now tries to tell @ssvb about Mali -- too funny (if I would ever have a question regarding Mali I would always ask Siarhei first)

1
androsch

androsch

Posted
Posted

For me this is fine, will be in hospital till beginning of November, so don't need a new board till that time.

 

Will also check with tllim the next steps, but it seems they didn't even test those boards they sent out and still they have no real idea whats wrong with their boards....

 

Its a real pain board.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/6/2016 at 4:49 PM, androsch said:

Its a real pain board.

 

Well, a few hardware flaws (shitty Micro USB, no custom led, the GbE issue, the HDMI drama, now the LCD mess) combined with pretty careless after-sales behaviour (still no real 'getting started guide', moderators enabled to act as censors, no wiki updates, a clueless 'moderator elite' responsible for the moronic Mali hype, no QA at least for hardware replacements and so on) and Pine64 turns into Pain64. Everything as expected ;)

 

BTW: this poor guy here also suffers from the GbE issue and now the PoE adapter (from Pine64 only capable of Fast Ethernet) masks the symptoms: http://forum.pine64.org/showthread.php?tid=1068&pid=20973#pid20973(and now the poor guy buys a new PSU for no reason or let's say it more clear: since the forum over there and documentation of well known issues still so much sucks)

 

Get well soon!

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/6/2016 at 5:49 PM, jernej said:

tkaiser, I have to ask, what HDMI drama?

 

Please see post #1 here or N°4 there. Given the similarities of HDMI drivers in H3 and A64 BSP I still wonder why there were so many issues with no display output at all but maybe that's just because the majority of Pine64 users had no idea about the SBC concept at all or simply believed in the marketing claims to get a '$15 supercomputer'?

jernej

jernej

Posted
Posted

If I understand correctly, those issues also exists on H3, due to same HDMI IP and basically the same driver code?

 

From my experience, A64 HDMI blob can be reproduced from H3 HDMI source + one function, which I published in OrangePi forum. So if anyone would like to play with it, it's possible, but license issues still remain. Currently I'm trying to port most HDMI patches from linux-sunxi repo to H3 kernel with some of my own fixes, so EDID negotiation and non 16:9 resolutions would be possible. It will take some time, though. I imagine that it would solve most of those issues?

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/6/2016 at 9:06 PM, jernej said:

It will take some time, though. I imagine that it would solve most of those issues?

 

To be honest: while testing with A64 a few hundred hours (unattended of course) I might have connected a display to the Pine64+ I had here maybe one or two times. IIRC I tried out whether the HDMI-to-DVI fixes known from A83T and H3 also match with A64 BSP kernel.

 

So I'm definitely the wrong person to ask for display issues. But I highly appreciate that you look into. It can't be overestimated what you've done for H3 already. Do you have access to A64 hardware already?

1
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept