Jump to content

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

tkaiser

By tkaiser
in Pine A64

 Share

Recommended Posts

hojnikb

hojnikb

Posted
Posted

I enabled building accelerated video decoding related stuff for arm64 sunxi configuration (which currently includes only Pine64). Works for me, so we may provide beta desktop images (but we need to provide related packages first).

 

this is  for h5 or a64 ?

0
tkaiser

tkaiser

Posted
  • Author
Posted

this is  for h5 or a64 ?

 

H5 just booted, Zador's changes were a simple switch to enable GUI stuff not only for 32-bit sunxi platforms but 64-bit too. As soon as H5 support is in a better shape we have to make a decision how to deal with this platform (that's mostly just a matter of naming schemes) but if/when H5 gets a proper HDMI driver we'll provide a desktop image too since 2D and video acceleration seem similar/solvable.

 

In fact with OPi PC 2 the situation now is much better than with Pine64 9 months ago since

  • it seems H5 is pretty close to H3 and A64 so software efforts can be reused
  • Some progress has been made regarding HDMI driver just recently (EDID support so maybe no more just a few fixed resolutions supported but nearly everything every display out there is able to announce/display)
  • OPi PC 2 is not broken by design regarding powering and led, this was/is Pine64's biggest problem from a support point of view. So many 'Pine64 is DOA' cases were just people connecting crappy phone chargers to Pine64's Micro USB port that led to insufficient power and the only led on Pine64 is just a power and not a custom led. This is way better now with OPi PC 2 since there the crappy Micro USB connecter can not be used to power the board at all and we have 2 custom leds on the PCB that can be used for feedback. Pine64 is a support nightmare, Orange Pi's aren't.
  • It seems there are Mali blobs for H5's Mali450 floating around so in case these are re-distributable OPi PC 2 will get also 3D acceleration from the beginning (not that important or important at all, but there was some moronic 'the Mali' hype generated over at Pine64 forum)

But please don't expect 'H5 desktop experience' in 2016. It all depends on linux-sunxi community now and if Armbian team learned a bit from the past we can H5 support make a test case how we improve with delegating testing efforts. Currently core team wastes too much time/nerves on testing but also failed to get more users into.

1
hojnikb

hojnikb

Posted
Posted

>crappy Micro USB connecter can not be used to power the board at all and we have 2 custom leds on the PCB that can be used for feedback. Pine64 is a support nightmare, Orange Pi's aren't.

 

You technically can use microusb to power up the board, you just need to bridge the SY6280 chip

0
tkaiser

tkaiser

Posted
  • Author
Posted

You technically can use microusb to power up the board, you just need to bridge the SY6280 chip

 

Yeah, but fortunately no one knows that. It's not about what's possible but what people do. If you know the problems associated with USB in general (crappy cables leading to voltage drops) and Micro USB connector (crappy connector, high contact resistance, max. 1.8A) and how 'smart chargers' work (not providing more than 500 mA to dumb devices like SBCs who can not 'speak' any of the USB power delivery dialects) then you can use Micro USB. Otherwise it's the root cause of stability issues (look in pine64.org forum -- it's still one of the top issues there)

 

The average user has simply no clue and fails to properly power the board. And since on Pine64 there's no custom led not even a bootloader can give a hint what's going on. Average users also don't know Ohm's law and are surprised that the problem is called undervoltage and not that much related to amperage ratings of their PSU.

 

We should be very very thankful to Xunlong that they do not allow to power the more beefy Oranges through the Micro USB port (or only by people knowing what they do)

0
zador.blood.stained

zador.blood.stained

Posted
Posted
  • It seems there are Mali blobs for H5's Mali450 floating around so in case these are re-distributable OPi PC 2 will get also 3D acceleration from the beginning (not that important or important at all, but there was some moronic 'the Mali' hype generated over at Pine64 forum)

AFAIK redistributable blobs for Mali 450 do exist, but only armhf X11 version: https://github.com/NextThingCo/chip-mali-userspace

0
pfeerick

pfeerick

Posted
Posted

You technically can use microusb to power up the board, you just need to bridge the SY6280 chip

 

Ssssh! You weren't supposed to tell everyone... now they'll all be doing it so they can use their crappy glow in the dark microUSB cables!!! :-P

1
tkaiser

tkaiser

Posted
  • Author
Posted

H5 just booted [...] But please don't expect 'H5 desktop experience' in 2016.

 

Well, I stand corrected since yesterday I bootet in Zador's new and shiny Pine64 desktop image... on Orange Pi PC 2: https://forum.armbian.com/index.php/topic/1762-new-oranges-with-h5-and-h2/?p=19663

 

This is far away from 'full Armbian support' but at least it demonstrates what's already available: 2D desktop acceleration already works by transplanting the userland/rootfs from our Pine64 image to OPi PC 2. Video acceleration didn't work for me even after increasing CMA but maybe it's just another simple tweak. Please remember that all that was needed to get HW accelerated video decoding with Pine64 was this commit (since all the work was already done for H3 by jemk before and A64 is pretty close to H3... it seems it's the same with H5 again).

 

Regarding 3D acceleration some bits can be read above (most probably redistributable 64-bit Mali450 blobs available). But to get OPi PC 2 fully up and running other stuff is more important: Getting voltage regulation to work to be able to use higher CPU clockspeeds and of course patching the BSP kernel a lot (I would assume we can most if not all stuff for A64 re-use also for H5 now).

 

Since I've been asked via PM how to fiddle around with some missing bits with Pine64 and BSP kernel like battery calibration: Probably the best way to start with device tree stuff is searching online for 'device tree for dummies' (not kidding, this is a good reading from a Free Electrons fellow and freely available!) and then you simply have to remember that Pine64 is nothing special at all but just another device using just another Allwinner SoC from the A series. Only differences: Now it's 64-bit and now DT has to be used where fex files have been used before.

 

We have several battery calibration related threads in the forum (all dealing with A20/AX209 but that shouldn't matter), simply read this, check linux-sunxi wiki for parameters if in doubt (not that much has changed regarding Allwinner specific bits) and ask back in 'Other boards' forum if you don't succeed.

 

The best base for such experiments is our new Pine64 desktop (beta) image: http://image.armbian.com/betaimages/ since Armbian ships with the stuff needed (git, gcc, dtc, whatever) and also Armbian is the only Linux offer for Pine64 so far that makes dealing with hardware/DT stuff as easy as with ayufan's Android 7.0 now. By setting/replacing DT contents from within u-boot -- just check boot script and documentation.

1
pfeerick

pfeerick

Posted
Posted

Since I've been asked via PM how to fiddle around with some missing bits with Pine64 and BSP kernel like battery calibration...

 

Thanks for that tkaiser.... Very much appreciated. It looks like there is a nice 70 odd minute video on youtube to go with that, so that will be some interesting reading/watching on the weekend. Just want to try and get my heard around the whole DTS stuff as my previous dealings were with fex and that was only rudimentary - strictly copy and paste to do something like disable the blinding blinking lights on the Cubietruck. Never went any further with that, and I see the RPi and other boards have moved the DTS way. I'll certainly be sticking with Armbian on the pine64 as my primary OS, and I have made the jump to Armbian on my cubietruck also and am pretty happy with the performance/stability there also. ;)

0
@lex

@lex

Posted
Posted

In case anyone affected by the GbE issue (the worst case when you can't connect to a GbE network or the ethernet is extremely slow) is interested i found a workaround, though not a solution.

This seems to be a known issue for the A80 and is activated on Opi PC2 for some reason.

 

This workaround just put the link in a 100M mode when connected to a GbE network and everything works as expected (Fast Ethernet).

 

Here is the relevant code to change:

#if 1
		/* Fix the A version chip mode, it not work at 1000M mode */
		// if (sunxi_get_soc_ver() == SUN9IW1P1_REV_A
		if (		priv->speed == SPEED_1000
				&& phydev->link == 1){
			priv->speed = 0;
			priv->link = 0;
			priv->duplex = -1;
			phydev->speed = SPEED_100;
			phydev->autoneg = AUTONEG_DISABLE;
			phydev->advertising &= ~ADVERTISED_Autoneg;
			phydev->state = PHY_UP;
			new_state = 0;
		}
#endif
0
tkaiser

tkaiser

Posted
  • Author
Posted

In case anyone affected by the GbE issue (the worst case when you can't connect to a GbE network or the ethernet is extremely slow) is interested i found a workaround, though not a solution.

This seems to be a known issue for the A80 and is activated on Opi PC2 for some reason.

 

This workaround just put the link in a 100M mode when connected to a GbE network and everything works as expected (Fast Ethernet).

Huh? When I tested yesterday I had GbE speed with Xunlong's Debian server image (though not the greatest throughput in TX direction but both TX and RX delay seems to be Allwinner defaults and not matching the board's traces). Also what's different compared to using ethtool instead to disable the GbE PHY? And then I would assume you're talking about this here, right? https://github.com/OrangePiLibra/OrangePi_H5SDK/blob/master/external/patch/0001-PATCH-Ethernet-1000Mbs-go-to-100Mbs.patch

0
@lex

@lex

Posted
Posted

The issue is about NOT having a stable connection to a GbE network or the impossibility to even connect to a GbE network (my case with M64 and i have GbE network only). To be able to use the ethernet i had to find a Fast Ethernet Hub, connect to the hub and the hub to my GbE network.

 

And Yes, that patch but this issue seems to be a well know issue for the A80.

0
tkaiser

tkaiser

Posted
  • Author
Posted

Sorry but why not installing ethtool and then adding simply

ethtool -s eth0 autoneg off speed 100 duplex full
to /etc/rc.local? Does exactly the same. And why do you expect working GbE on BPi M64? This is a totally different board but the vendor (famous for not knowing his own hardware) uses EVERYTHING from/for Pine64 for whatever reasons. At least this was the case when I looked at one of their OS images for the M64 a few weeks ago. Can't work this way since TX/RX settings alone (100 percent board specific).
0
@lex

@lex

Posted
Posted

Just because i had to install ethool and to install ethtool i needed ethernet connection, to have ethernet connection i needed a fix, not finding a fix i found a workaround....  :)  I don't use their images... and i think they all use AW reference board that is why the issues are replicated.

0
tkaiser

tkaiser

Posted
  • Author
Posted

I don't use their images... and i think they all use AW reference board that is why the issues are replicated.

Hmm... I already thought about adding ethtool to our default package list. Zador, in case you've no objections please simply add it the next time you touch default installation stuff.

 

The problem with GbE is that you need board specific TX/RX delay settings. These must match trace routing on the PCB and are part of the DT. Therefore using a .dts/.dtb for board A on board B that has a different layout simply can not work. This is device specific. But of course there might be different GbE PHY issues add to this problem.

 

TX/RX delay settings for Pine64 have been tested by me and longsleep (and maybe other community members) in March. I'm almost sure none of the vendors (also of more recent A64 or H5 devices) has done this also. But neither using Allwinner defaults nor Pine64 settings can work properly on other boards.

0
@lex

@lex

Posted
Posted

Well, i will let this for the HW guys but for me if the boards have the same RTL chip they must have the same trace route equal, surely a bad design can have some influence.

There is a new contender coming soon with a different layout and we will see if this issue can affect others.

 

Can you please post the relevant part of the TX/RX in the DTS you have tested/changed?

0
@lex

@lex

Posted
Posted

In fact changing the TX/RX has improved the situation, far from perfect yet. Maybe it was my fault. 

 

@tkaiser, can you please post the script you used to validate the TX value? I am still believe my problem here is RX and i can see TX = 3 on Pine64.

0
tkaiser

tkaiser

Posted
  • Author
Posted

@tkaiser, can you please post the script you used to validate the TX value?

 

There is (was) none. IIRC longsleep did some tests and me as well and results looked promising back then. But now there is, I'm currently testing OPi PC 2: https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/039ab08730f38bcff328ffd5bac59fb64aece327#commitcomment-19845562

 

All you would've to adjust are paths to source .dts and target .dtb and you need a second GbE equipped host on the same switch running iperf3 -s

0
tkaiser

tkaiser

Posted
  • Author
Posted

EDIT: New script version only checking RX delays 0-7 (since everything above doesn't work anyway) and implementing timeout behaviour (since iperf3 in situations with almost no connection might hang forever). Script requires a 2nd GbE capable host on the same switch that is able to exceed 900 Mbits/sec and runs 'iperf3 -s'.

 

Update: @lex, please take this script instead. It's more reliable since iperf3 will be sent to 2nd CPU core and IRQ processing happens on the 4th. Therefore execution time could be reduced from 120 seconds each to 20 seconds. So it will only take hours and not days any more ;)

#!/bin/bash
#
# script intended to test through TX/RX parameters. Should be called from
# eg. /etc/rc.local with a short delay to ensure network is already up, eg.
# sleep 5 && /usr/local/bin/test-tx-rx.sh

TestPartner=192.168.83.146			# here 3 x 'iperf3 -s' must be running
TimeToTest=20						# how long should iperf3 run each
TX_File=/var/log/tx-value			# file containing actual tx value
RX_File=/var/log/rx-value			# file containing actual rx value
LogFile=/var/log/tx-rx.log			# result log
SourceDTS=/boot/new.dts				# source, must contain rx/tx set to 0!
TargetDTB=/boot/pine64-plus.dtb 	# target .dtb

Main() {
	CheckPrerequisits
	read TX <"${TX_File}"
	read RX <"${RX_File}"
	TX_Result=$(timeout -k $(( ${TimeToTest} + 2 )) $(( ${TimeToTest} + 1 )) ${TestScript} | awk -F" " '/sender$/ {printf ("%0.1f",$7/1000); print "\t"$9}' | sed 's/sender/0/')
	RX_Result=$(timeout -k $(( ${TimeToTest} + 2 )) $(( ${TimeToTest} + 1 )) ${TestScript} -R | awk -F" " '/sender$/ {printf ("%0.1f",$7/1000); print "\t"$9}' | sed 's/sender/0/')
	LoadAverage=$(uptime | awk -F" " '/average/ {print $9}' | tr -d ',')
	echo -e "$(printf "%2s" ${TX})/$(printf "%2s" ${RX}):\t${TX_Result}\t${RX_Result}\t${LoadAverage}" >>"${LogFile}"
	IncrementAndReboot
} # Main

CheckPrerequisits() {
	export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
	echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
	echo 1-2 >/proc/irq/$(awk -F":" "/1c30000.eth/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity_list
	echo 1 > /sys/class/net/eth0/queues/rx-0/rps_cpus
	echo 1 > /sys/class/net/eth0/queues/tx-0/xps_cpus
	echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
	which iperf3 >/dev/null 2>&1 || apt-get -f -qq -y install iperf3
	which ethtool >/dev/null 2>&1 || apt-get -f -qq -y install ethtool
	which dtc >/dev/null 2>&1 || apt-get -f -qq -y install device-tree-compiler
	[[ -f "${TX_File}" ]] || echo -n 0 >"${TX_File}"
	[[ -f "${RX_File}" ]] || echo -n 0 >"${RX_File}"
	[[ -f "${LogFile}" ]] || echo -e "TX/RX\tTX\t\tRX\t\tload\ndelay:\tMb/s\tretry\tMb/s\tretry\t avg" >"${LogFile}"
	TestScript=$(mktemp /tmp/${0##*/}.XXXXXX)
	echo '#!/bin/bash' >${TestScript}
	echo -e "taskset 8 iperf3 -f k \$1 -c ${TestPartner} -t ${TimeToTest}" >>${TestScript}
	chmod 755 ${TestScript}
} # CheckPrerequisits

IncrementAndReboot() {
	let RX++
	if [ ${RX} -eq 8 ]; then
		RX=0
		let TX++
	fi
	if [ ${TX} -lt 8 ]; then
		# write stuff to files, patch .dtb, reboot
		echo -n ${TX} >"${TX_File}"
		echo -n ${RX} >"${RX_File}"
		HexTX="$(printf '<0x%x>;' ${TX})"
		HexRX="$(printf '<0x%x>;' ${RX})"
		sed -e "s/tx-delay = <0x0>;/tx-delay = ${HexTX}/" \
			-e "s/rx-delay = <0x0>;/rx-delay = ${HexRX}/" \
			<"${SourceDTS}" | dtc -I dts -O dtb -o "${TargetDTB}"
		sync
		reboot
	fi
} # IncrementAndReboot

Main $@

Since @androsch sent back my 1st Pine64 sample (with green led and 1 GB DRAM) I'll test this out on both Pine64+ currently lying here around the next days. Or maybe someone else will try. It's only important that the test run against a GbE equipped device that is known to exceed 930 Mbits/sec.

0
@lex

@lex

Posted
Posted

Please take note (AW doc):

tx-delay    --  transmit clock delay: 0~7                                  
rx-delay    --  receive clock delay:  0~31                                
0
tkaiser

tkaiser

Posted
  • Author
Posted

 

Please take note (AW doc):

tx-delay    --  transmit clock delay: 0~7                                  
rx-delay    --  receive clock delay:  0~31                                

 

Great, then it takes even less time. Also I checked wrong value, now corrected: 'if [ ${TX} -lt 8 ]; then'

0
tkaiser

tkaiser

Posted
  • Author
Posted

Small update: I let it ran over night but results look questionable: https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/039ab08730f38bcff328ffd5bac59fb64aece327#commitcomment-19857448

 

Try now again against a virtualized Linux living inside an ESXi host (there's another virtual switch in between) since when I started testing yesterday I got at least differences regarding retransmits. This will run the next few hours:

tk@orangepipc2:~$ cat /var/log/tx-rx.log
TX/RX	TX		RX	
delay:	Mb/s	retry	Mb/s	retry
 0/ 0:	547	0	942	0
 0/ 1:	549.4	0	939	65
 0/ 2:	557.4	0	940	88
 0/ 3:	543.2	0	932	159
 0/ 4:	556.4	229	942	0
 0/ 5:	551	0	941	67
 0/ 6:	556	0	941	0
 0/ 7:	551	0	940	61
 0/ 8:	553.8	0	940	0
 0/ 9:	551	0	941	0
 0/10:	556.8	181	940	211

But at least with H5 BSP kernel there seems to be a few more tweaks (kernel) needed.

0

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept