Jump to content

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

tkaiser

By tkaiser
in Pine A64

 Share

Recommended Posts

jernej

jernej

Posted
Posted
  On 10/6/2016 at 9:34 PM, tkaiser said:

Do you have access to A64 hardware already?

 

No, I was thinking about buying it, but then I said to myself that I should concentrate on one platform and try to squeeze the max. One very unatractive feature of A64 is U-Boot. I started to hate BSP U-Boot as soon as I integrated it first time in OpenELEC. While there is some mainline support for A64, AFAIK it is not meant to boot BSP kernel. I guess some work would be needed for that. Second issue is mali driver, but probably it is also solvable.

 

However, I'm looking forward for H5, despite high probability of above issues.

tkaiser

tkaiser

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

However, I'm looking forward for H5, despite high probability of above issues.

Hehe, I've other issues with H5 (no PMIC --> no battery --> no UPS support). Anyway: Please get in touch with Igor, IIRC he talked to Tsvetan/Olimex about Olinu..A64 samples. One of those on your desk seems the best use case. If that's not happening I would love to send one of the fresh Pine64+ to you.

 

BTW: I really hope that Allwinner is not too innovative and all the community work done now on A64 can be used for H5 later.

 

Edit: small parcel with Pine64+, Wi-Fi/BT module and LCD on the way to @jernej, I'm not able to answer any LCD related questions any more

tkaiser

tkaiser

Posted
  • Author
Posted
  On 9/19/2016 at 6:18 AM, tkaiser said:

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)

 

In the meantime the 'breaking news' that using an LCD together with an Allwinner device requires defining how to use it the usual way also arrived at Pine64 forum (really great news since just a few weeks ago they've been told by the 'moderator elite' to get the LCD working first 'the Mali' would be needed and it would take at least 2 weeks of hard work and other BS).

 

I added some suggestions: https://github.com/MackPI/Pine64LinuxLCD/issues/1

1
pfeerick

pfeerick

Posted
Posted
  On 10/7/2016 at 12:49 PM, tkaiser said:

In the meantime the 'breaking news' that using an LCD together with an Allwinner device requires defining how to use it the usual way also arrived at Pine64 forum

 

Don't you mean the news that had been previously broken by you a month or five earlier, and had been promptly ignored and ridiculed? :-O What can I say... things take a while in pine64 land? :-D

 

You'll be unsurprised to hear that the Ethernet problem with that other user was indeed masked by the PoE adapter... so he seems to have that curse-ed GbE gremlin.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/8/2016 at 2:22 AM, pfeerick said:

Don't you mean the news that had been previously broken by you a month or five earlier, and had been promptly ignored and ridiculed? :-O What can I say... things take a while in pine64 land? :-D

 

The problem is that the 'moderator elite' over there (a couple of them at least) created their own micro reality not taking into account that A64 is one of many tablet SoCs from the same vendor called Allwinner. Using Allwinner's BSP (board support package, an awful mix of Linux and Android sources and ugly scripts to combine everything to a smelly 'LiveSuit image' with broken partition map) with A64 is nearly the same as with A83T or A20 or A10 and of course LCD configuration is also the same (look at the timestamps here -- if anyone ever wants to use a different LCD with Pine64 there you get the idea how to calculate values).

 

With A64 BSP Allwinner still supported defining everything in fex files (I put an example online when the first A64 BSP variant was leaked 10 months ago) but since they're using kernel 3.10 starting with A64 they alternatively allow also defining all this stuff as DT (device tree). Logic/behaviour is the same as known since ages. Why shouldn't a tablet SoC not be able to use a f*cking LCD?! It's made for no other reason!

 

Longsleep was the first who tried to get this horrible BSP stuff working with 'generic Linux' and for obvious reasons he chose to get rid of the fex stuff right away. But LCDs connected to Pine64 can be used with BSP kernel since he published his first simpleimage approaches (and that means almost half a year ago). By defining parameters as it has been done from day one (nothing has changed here since 2013).

 

BTW: At the same time longsleep also looked into HDMI situation and decided to develop sunxi-disp-tool for A64 to switch between different HDMI modes on the fly. Thankfully he also added a mode to configure HDMI resolution as it is done on the older sunxi SoCs (A10, A20). By adding disp.screen0_output_mode and/or disp.screen1_output_mode (most Allwinner tablet SoCs support more than 1 display) to kernel cmdline and calling sunxi-disp-tool in the boot process which reads /proc/cmdline and then sets HDMI resolution before a desktop environment would be started.

 

What happened with this knowledge? It's gone since the way to adjust HDMI resolution is mentioned in longsleep's description for his own original Ubuntu image but missing in every other 3rd party image or the crappy ones made available through wiki.pine64.org. Supressing documentation means destroying developer's work. And this happened with every OS image available on wiki.pine64.org or pine64.pro (see also the bottom of this rant)

 

And now people think they have to get rid off sunxi-disp-tool to be able to use an LCD instead of using the tool correctly (defining the LCD as display 0 in .dtb and optionally use HDMI as display 1 -- simply remove/adjust disp.screenX_output_mode in uEnv.txt or boot.scr and you're done). The whole 'history' of dealing with simple 'problems' is just absurd when looking over at pine64.org due to lack of documentation, clean instructions and allowing strange people to spread BS all the time while also allowing them to censor others posts (especially those mentioning that these guys are part of if not the problem).

 

Why did they provide crappy Linux images and still do not even mention longsleep's original Ubuntu image? Why do they provide so called 'DD images' for RemixOS/Android in several sizes (all too large since they don't fit on every SD card of the specific size) instead of providing small Android/RemixOS images that expand their data partition on first boot (as the community Android 7.0 implements it now -- these guys are great!). Why do they provide different Android images for HDMI and LCD? It's just adding a TS driver and adjusting settings! And checking for the I2C connected touchscreen controller in u-boot and then use this or that .dtb afterwards like it's already done depending on DRAM size and choosing the correct .dtb for Pine64 or Pine64+ (different Ethernet config).

 

I would love to know the answer.

 

Anyway: If there's some progress regarding HDMI (we still have to deal with the libhdmi blob here!) we will think about A64 HDMI situation with Armbian (maybe using Simon's sunxi-disp-tool in exactly the same way -- then on H3 too where it should work with minor tweaks -- and then on all supported sunxi SoCs display resolution can be defined in a consistent way again). But at the moment Pine64+ is clearly a headless device for us (and there it can really shine if you're not unfortunate enough to got a broken board suffering from the GbE issue)

1
tkaiser

tkaiser

Posted
  • Author
Posted

I just wanted to try out installation of Firefox 32-bit on Pine64 to give Igor feedback on this commit using the following 'script':

 

  Reveal hidden contents

 

 

But unfortunately I get no display output at all. I also defined 'hdmi_cts_compatibility = <0x1>;' to try it out with a 2nd screen (DVI) and did an additional

sed -i '1isetenv fdtfile pine64-plus-dvi.dtb' /boot/boot.cmd
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

but to no avail. Any ideas?

 

Edit: 'armbianmonitor -u' output: http://sprunge.us/PObS

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/9/2016 at 6:47 PM, zador.blood.stained said:

Are you talking about DVI compatibility issue, fbturbo or display in general?

 

The latter. I tried 1080p and 720p and display always reported this specific mode but I get not a single bit of real graphic display. Not even kernel messages while booting.

zador.blood.stained

zador.blood.stained

Posted
Posted

I built an image today (Pine64 default xenial desktop) and display worked for me (default 1080p via HDMI-VGA converter). There were no boot messages at all (I guess they are on serial console), but I did get a command line prompt and desktop after that.

 

Did you test with sunxi-disp-tool installed? Maybe it didn't work properly in your case?

tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/9/2016 at 10:16 PM, zador.blood.stained said:

Did you test with sunxi-disp-tool installed?

 

I disabled it but to no avail. Then let a desktop image build that not even booted (problem with partition map or maybe just burning process, I wasn't able to mount the partition on another Linux box too):

 

  Reveal hidden contents

 

 

Then back to the interesting stuff (KERNELSOURCE='https://github.com/Icenowy/linux-sunxi/KERNELBRANCH=branch:a64/test/pine64-usb-v3')just to realize that now Ethernet isn't working. Ok, too much hassles already for today! Back in the drawer ;) I'll look into it in a couple of days again...

 

Edit: Re-burning the desktop image was successful! After initial setup and creating a normal user account the DE started :)

 

Edit 2: And as expected adding longsleep's ppa works and stuff like that also:

systemctl stop nodm && sunxi-disp-tool switch -name 720p && systemctl start nodm

Edit 3: And now Pine64+ feels like my RPi 2 and 3 (also running Ubuntu Mate):

apt-get remove nodm
apt-get install xserver-xorg-video-fbturbo libvdpau-sunxi1 libump libcedrus1 ubuntu-mate-core ubuntu-mate-desktop ubuntu-mate-lightdm-theme ubuntu-mate-wallpapers-xenial lightdm

Of course Firefox performance sucks unless settings are tweaked (see also here).

 

Edit 4: Forgot to mention: 2D acceleration needs something like this also:

cat >/etc/X11/xorg.conf.d/02-fbturbo.conf <<EOF
Section "Device"
        Identifier      "Allwinner A10/A13 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb0"
        Option          "SwapbuffersWait" "true"
EndSection
EOF
tkaiser

tkaiser

Posted
  • Author
Posted

Small update: We started documenting board specific details. Currently only Pine64 is covered and we have not yet decided how to link this stuff from within docs.armbian.com or the download pages. Therefore I simply post the link here: https://github.com/igorpecovnik/lib.docs/blob/master/docs/board_details/pine64.md

 

Edit: Setting up the Pine64+ as access point was pretty straightforward and given that 2.4 GHz band is nearly dead here (way too overcrowded -- +50 Wi-Fi networks) the values aren't that bad (read out from a MacBook in the next room and using default antenna):

          Current Network Information:
            Armbian Test AP:
              PHY Mode: 802.11n
              BSSID: 36:c3:d2:e5:19:a6
              Channel: 13
              Country Code: US
              Network Type: Infrastructure
              Security: WPA2 Personal
              Signal / Noise: -59 dBm / -93 dBm
              Transmit Rate: 39
              MCS Index: 4

This is with wlan0 configured as client and managed through NetworkManager and wlan1 used for Armbian's own hostapd (Pine64's Wi-Fi module comes with 2 interfaces). I added the stuff to board documentation above.

tkaiser

tkaiser

Posted
  • Author
Posted

Another update: the trick to install an armhf Plex Media Server package (made for Synology NAS boxes) works of course also with Armbian:

wget -O - https://dev2day.de/pms/dev2day-pms.gpg.key'>https://dev2day.de/pms/dev2day-pms.gpg.key | apt-key add -
echo "deb [arch=armhf] https://dev2day.de/pms/ jessie main" >/etc/apt/sources.list.d/pms.list
dpkg --add-architecture armhf
apt-get update
apt-get install binutils:armhf
apt-get install --no-install-recommends plexmediaserver-installer  

Plex Media Server is then available at http://Pine64-IP-Address:32400/web/ and can be configured (especially creating 'optimized versions' since Pine64 is too slow to transcode most video formats on the fly).

 

BTW: Installation will provide an informative message:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://dev2day.de/pms jessie InRelease' doesn't support architecture 'arm64' 

But this is not an error message and can simply be ignored. The goal is to install the armhf version since no arm64 flavour is available.

 

Edit: Updated pms.list contents based on Zador's suggestion.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 10/11/2016 at 8:31 AM, tkaiser said:

BTW: Installation will provide an informative message:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://dev2day.de/pms jessie InRelease' doesn't support architecture 'arm64' 

But this is not an error message and can simply be ignored. The goal is to install the armhf version since no arm64 flavour is available.

There is a syntax for sources.list to tell which architectures to use for the repository:

deb [arch=armhf] https://dev2day.de/pms/ jessie main
2
tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/11/2016 at 8:51 AM, zador.blood.stained said:

 

There is a syntax for sources.list to tell which architectures to use for the repository:

deb [arch=armhf] https://dev2day.de/pms/ jessie main

 

Thanks! Did a purge, re-tried it and now it works flawlessly!

1
zador.blood.stained

zador.blood.stained

Posted
Posted

Now setting display resolution in uEnv.txt is supported for Pine64 default kernel:

root@pine64:~# cat /boot/uEnv.txt
ethaddr=ca:17:10:f7:2b:29
disp_mode=720p60

Available modes are listed in boot script. Al least 720p60 works for me in addition to default 1080p60

2
tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/11/2016 at 1:17 PM, zador.blood.stained said:

I also added DVI compatibility option (disp_dvi_compat=on), untested.

 

Tested (works!), documentation adapted and your defaults change fixed :)

 

Thanks a lot! Now we have a device we officially regard headless with best out-of-the-box support regarding connected displays (ah, not true: LCD support and auto-detection is fortunately missing ;) )

tkaiser

tkaiser

Posted
  • Author
Posted

Meanwhile in Pine64 land: http://forum.pine64.org/showthread.php?tid=1166&pid=21382#pid21382

 

HW accelerated video decoding is available since this commit (2D acceleration works also since half a year) but one moderator still denies that 'HW acceleration' would be available. If you're a Pine64 user and rely on the forum over there you're still simply lost :(

 

(but maybe the Mali hype just caused serious brain-damage?)

 

BTW: first question was about HW accelerated video encoding. @lex, one of our great community members, provides this here: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/

1
vintagewaffle

vintagewaffle

Posted
Posted

Hey guys, I have a question in regards to the pine64 build.

 

I have created some patches to modify the dts (in sources/u-boot-pine64/master/blobs) to include the changes for the LCD and touch panel. 

And the u-boot job goes sucessfully and build correct dtbs, but when the actual image is generated, it still ends up having the default dtb's without my changes.

 

What am I missing?

1
martinayotte

martinayotte

Posted
Posted
  On 10/29/2016 at 6:56 PM, @lex said:

I have M64 which has similar Gbe issue as Pine64 if not the exact same issue, unfortunately this possible fix did not work on M64.

 

Oh ! this is bad news !

So, maybe it won't work for Pine64 too ...

pfeerick

pfeerick

Posted
Posted
  On 10/29/2016 at 7:09 PM, martinayotte said:

Oh ! this is bad news !

So, maybe it won't work for Pine64 too ...

 

I think from an update that TL gave a few days ago about progress on identifying the issue that this fixes some of the cases, may not fix all. There may be an issue of either poor soldering or faulty PHY chips in the mix as well - but it seems like they are starting to identify all the different factors that trigger those similar symptoms. I know that for at least one person fiddling with the TX and RX registers in the PHY had no effect for them... so this fix won't help them.

 

I may be wrong, but I think that the Android 5.1.1 just got a similar fix, and at least one report indicated that GbE was now working (where it hadn't been before), but the download speeds were ... poor ... so they'd gone to the previous build (and probably a Fast Eth hack).

@lex

@lex

Posted
Posted

In my case, Fast Ethernet works as usual and a very basic analysis on GbE issue suggest RX does not work most of the times. And i can't say it is a faulty chip or poor soldering even looking at it.

1
tkaiser

tkaiser

Posted
  • Author
Posted
  On 10/28/2016 at 2:51 PM, vintagewaffle said:

I have created some patches to modify the dts (in sources/u-boot-pine64/master/blobs) to include the changes for the LCD and touch panel.

 

Please be aware that we started to discuss the stuff here. Please join the party and simply refer to the necessary changes left, it should then be easy to add a switch to /boot/armbianEnv.txt to switch on LCD/TS when needed.

UnixOutlaw

UnixOutlaw

Posted
Posted

Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!).

 

I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777...  Can't believe the amount of bullshit information that "A" hole has steered me wrong with!

 

Thanks for all the insiteful info from contributors on this forum and this thread!

3
pfeerick

pfeerick

Posted
Posted
  On 11/1/2016 at 12:55 PM, tkaiser said:

By comparing with TL Lim's statement here I start to wonder how 'phydev, 0x28, 0xd591' and 'phydev, 0x1c, 0xd591' match (only a hex --> dec conversion glitch -- 0x1c == 28 -- or wrong address)?

 

I think it was a conversion glitch - it was supposed to be 0x1C (dec 28).

tkaiser

tkaiser

Posted
  • Author
Posted
  On 11/11/2016 at 1:41 AM, pfeerick said:

I think it was a conversion glitch - it was supposed to be 0x1C (dec 28).

 

Whatever, it's still a hardware issue that affects a relevant number of boards and Pine Inc's information policy (same with their 'who is allowed to play censor/moderator and fool users in a forum' policy) is a desaster. Such a madness over there, people still struggling with problems known/fixed since decades, still people complaining about Android being broken while it's just that no one informs them that only a few SD cards out there will work correctly with Android (which is the reason every normal Android device out there is shipped with NAND or eMMC -- random IO matters and most SD cards fail here horribly!) and so on. I get a headache the moment I open forum.pine64.org.

 

On a related note: dev samples for the first H5 device around reached linux-sunxi devs yesterday and the day before. This is Orange Pi PC 2 already booting with mainline u-boot and kernel: https://gist.github.com/apritzel/c128b29c601d180d32d68ee4c9ed8f47 Kudos to linux-sunxi devs!

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