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

[zador.blood.stained]

There is no regulator with that name, at least in DTs that we use (regu@0 node defines the mapping between axp outputs and named regulators).

[dahni]

i'm having problems with video playback after a not-so-recent (i think i did it in october) upgrade.

before that, all video would look normal, and most video would playback with only minimal framedrop.

 

now, most only display like this.
this is with mpv, and its output is something like this - looks ok to me???
but the problems are abundant with all video formats and media players (mplayer too, and i spent a good while playing with VLC's settings).

 

i tried:

 

downgrading kernel back to 3.10.105 version == downgrading packages linux*pine* to version 5.31.
it helped a little - i was able to watch a few very old & lo-res episodes.

 

then i found this: Video playing will break on sunxi legacy unless adding cma=96M to kernel boot parameter, so i undid the downgrade and added that option to /boot/boot.cmd & recompiled, after which i could see those 96M in 'dmesg|grep -i cma' (was 64M before).
but it did not help at all, the situation was just as bad as before the kernel downgrade!

 

what to do?

[xnyle]

Should I worry if A64 reaches 80°C ?

 

got this readout while copying files beween two USB-attached disks (OPI Win, Ubuntu legacy kernel):

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU   PMIC  C.St.
22:13:57: 1152MHz  5.86  53%  16%   7%   0%  29%   0%   79°C   69°C  0/9
22:14:02: 1104MHz  5.87  60%  15%   8%   0%  35%   0%   79°C   69°C  1/9
22:14:07: 1152MHz  6.12  54%  14%   9%   0%  28%   1%   80°C   68°C  0/9
22:14:12: 1152MHz  6.11  47%  11%   5%   0%  29%   0%   77°C   68°C  0/9

 

When it's idle, temp goes down to 56°C @ 480 MHz

 

I already equipped the A64 chip with a heatsink.

 

USB througput is nice though.

[xnyle]

Nobody?

 

I also noticed that temp goes down 5 degrees if I unplug HDMI.

 

Anyone who can make sense of this?

[frederic]

Hi,

 

I'm using Orange Pi Win which is also based on A64

Armbian 5.38 / kernel 3.10.107-pine64 is installed

 

So, about the 1GbE : I read there's now a solution at the firmware level, but 1GbE is still not working for me.

My current work around is to set ethernet at 100Mbps with ethtool...

before:

root@orangepiwin:/home/fr3d# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

=> even if the links is reported Up with 1000Mbps speed, it isn't working (get some replies for ping, but cannot be used for ssh or any other network usage...)

 

For setting the speed to 100Mbps, autoneg need to be set off first:

root@orangepiwin:/home/fr3d# ethtool -s eth0 autoneg off
root@orangepiwin:/home/fr3d# ethtool -s eth0 speed 100

control:

root@orangepiwin:/home/fr3d# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: off
        Link detected: yes

 

Hope this workaround can help...

[andydj]

Hi , i have Pine64 2Gb with Armbian installed . There are a possibility to get working 1.2Ghz & 1.34Ghz speed ? I did in other image without problem but not in this . I placed the heatsink on CPU

[reggie]

Hello,

Ethernet did not for me out of the box for Pine64 A64-DB-V1.1 2G board for mainline. DTS fix with "allwinner,tx-delay-ps" made it work 

 

root@pine64:~# cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=pine64
BOARD_NAME="Pine64"
BOARDFAMILY=sun50iw1
VERSION=5.83
LINUXFAMILY=sunxi64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image 

 

[kapqa]

Hello ,

i am using Armbian Xenial Desktop for Pine64 - it seems stuck with Kernel 3.10.

Is there an way to upgrade easily to achieve HW-acceleration for Video as it seems it is the only thing missing?

 

thanks 

 

 

EDIT:

3.10.107-pine64

 

BOARD=pine64
BOARD_NAME="Pine64"
BOARDFAMILY=sun50iw1
VERSION=5.85
LINUXFAMILY=pine64
BRANCH=default
ARCH=arm64
IMAGE_TYPE=stable
 

Edited June 29, 2019 by kapqa

[Igor]

2 hours ago, kapqa said:

easily to achieve HW-acceleration

https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel

We have too little resources for implementation. Waiting to get upstream - apparently with 5.2.y ... which was just tagged. In development builds once in the middle of the summer time ... or DIY, which will not be simple.

 

2 hours ago, kapqa said:

HW-acceleration for Video as it seems it is the only thing missing?

HW video acceleration works in old stock kernel - that's the only reason its still there. In MPV video player only. Of not in Chromium.

[kapqa]

thanks , i did try with the on-board MPV 0.14 version and compiled through help of here

https://nyxi.eu/compiling-mpv-on-debian.html

an up-to-date mpv version 0.29 but nevertheless it would not playback properly.

maybe i have some wrong armbian xenial (too new?)

[Igor]

5 hours ago, kapqa said:

and compiled through help of here

That will 100% not use any video acceleration. Use our pre-build version ... 

[kapqa]

Thanks, i checked again, mpv 0.14 seems working fine!

Sorry for the fuss.

Would be nice if the HW-acceleration could be enabled as this board seems very good indeed; i tried the rock64 with multimedia script offered for rk3328 but it is just very unstable overall for my taste.

This board is very nice, but i don't now how to contribute beside buying a Pinebook sometime later.

Cheers.

[Igor]

2 hours ago, kapqa said:

how to contribute beside buying a Pinebook

 

This will contribute to hw design and very little if anything to software development. Vendors generally do little on software support, have even less capacity. (good) Software is mainly developed by community and/or paid crews ... Each project, that works something on this, collects contributions by: donations, sells supports or similar. Most of the work with Pinebook was done by http://linux-sunxi.org/Main_Page https://github.com/ayufan-pine64 https://github.com/longsleep/build-pine64-image https://www.armbian.com/ and many other individuals outside those circles.

[psychedup74]

I have a couple of PineA64+'s with the "official" 7" touchscreens. I tried using the mainline Armbian Bionic image and adding "pine64_lcd=on" to /boot/armbianEnv.txt but it doesn't seem to be working. Is the LCD only supported in the old 3.10 kernel?

[psychedup74]

4 minutes ago, psychedup74 said:

I have a couple of PineA64+'s with the "official" 7" touchscreens. I tried using the mainline Armbian Bionic image and adding "pine64_lcd=on" to /boot/armbianEnv.txt but it doesn't seem to be working. Is the LCD only supported in the old 3.10 kernel?

 

Oops nevermind, I see now that the MIPI DSI driver is still WIP. I'll wait patiently.

[p1x3l3d]

On 7/31/2019 at 6:30 AM, psychedup74 said:

 

Oops nevermind, I see now that the MIPI DSI driver is still WIP. I'll wait patiently.

 

Hi psychedup74, as you can see here I'm also attempting to get the Pine64 LCD screen to work, but with the Pine64-LTS instead of the Pine64+. I didn't manage to get it to work either.

 

I was just wondering, where did you find that the MIPI DSI driver is still WIP? Because that might just answer my question as well

 

Regards!

[marek]

 

Hello, after some time I have stated that Linux is the best Linux Armbian for Pine64. I have a question My Pine64 2G only starts with the Armbian 5.75 version only on the newer black screen on TV and that's all

[mudcat]

On 7/31/2019 at 12:30 AM, psychedup74 said:

 

Oops nevermind, I see now that the MIPI DSI driver is still WIP. I'll wait patiently.

 

psychedup74 et al.,

 

1) Where is this issue being tracked?

2) Where is the code for this living?

3) What part of the driver is WIP?

 

Cheers

[PSL]

I have strange problem with IPv6 address received from DHCP server. Two Pine64+ boards have different IPv4 address but they share the same IPv6 address.

I finally installed Armbian "Focal" to Pine64+ from Kickstarter (board with micro USB power connector). I have two such boards. I connected these to a test network where gateway is OpenWrt 19.07.4; there is DHCP server running on OpenWrt. I do not need IPv6 addresses (I do not have IPv6 connectivity enabled) but these were activated by OpenWrt. Problem is that I have found that both Pine64+ boards receive different IPv4 address but IPv6 address is the same. When I try to connect with ssh client and I use "name" (not IP address), ssh client prefers IPv6 over IPv4 and it always connects to just one board. I needed some time to troubleshoot this "magic", to find that problem is that both boards share the same IPv6 address. I think that source of this problem is that both boards use the same DUID. They have different MAC address but DUID is the same and that is why DHCP server assigns the same IPv6 address to both boards. In my case, it is

 

DUID: 00046268261de6497cba3d521a1b6401159c
IPv6 address: fdf4:26f8:bebb::723

 

I am not sure how DUID is constructed. Could be this a bug in Armbian? Or is this a problem of Pine64+ hardware? I put my DUID to this post; could you compare with your DUID? Is it the same?? I do not know how to find DUID in Armbian from CLI but I see DUID at DHCP server in the list of active DHCP clients...

 

I have interesting update to the problem with IPv6 address. I connected Libre LePotato SBC running the same version of Armbian to the same network as Pine64+ but it doesn't receive IPv6 address from DHCP server; it receives only IPv4 address. So it looks like Pine64+ actively asked for IPv6 address (and used the same DUID in the request). Is it possible that image for Potato and Pine64 is configured in different way (dhcpclient)? LePotato board had other problem, two boards had the same IPv4 address, this is because there is no MAC address stored on LePotato board and this is "calculated" and for some reason it was the same on both boards and unique MAC from /file boot/armbianEnv.txt was ignored.

 

One more update. IPv6 was disabled at LePotato. I enabled it in armbian-config and I see that two LePotato boards share the same IPv6 address!! ;-) Well, it is different address than IPv6 of Pine64 boards but it looks like there is the same problem, that LePotato boards sent the same DUID to DHCP server...

DUID: 0004d873f5fba0ec73882e0484e172920173
IPv6 address: fdf4:26f8:bebb::c4a

 

[PSL]

Another update to DUID issue with Arbmian. I connected RPI4 with the latest Raspi OS to the same network. I think that RPI4 do it right, it uses different type of DUID and MAC address is part of DUID, so I assume that each RPI4 will have unique DUID because the last 12 digits in the UUID is MAC address of eth0 interface (RJ45):

 

DUID: 0001000126d11676dca632b75e57
IPv6: fdf4:26f8:bebb::412

 

[Igor]

On 10/5/2020 at 2:45 PM, PSL said:

Could be this a bug in Armbian?

 

Armbian is a build system https://github.com/armbian/build that produces Debian like OS https://docs.armbian.com/#what-is-armbian on various hardware. Since Debian, Ubuntu and Raspi are just some combination of free software its hard to say where the problem is. We use Network manager to deal with networking, armbian-config is just a wrapper. 

Interesting issue.

[PSL]

I just tried with Odroid C4. I use "unsupported" version with legacy kernel" because "supported" version with mainline kernel doesn't boot... I can post log from "serial console" but I cannot see anything usefull there, the last message from U-Boot is "Starting kernel"

 

It is interesting that Odroid C4 with "unsuported" Armbian gets the same IPv6 address as Pine A64 boards, they use the same DUID:

 

DUID: 00046268261de6497cba3d521a1b6401159c
IPv6 address: fdf4:26f8:bebb::723

 

It could be a bug in dhcpd client. Or it could be  HW related, that dhcp client uses some ID from HW and it assumes that it is unique but it is not unique. Maybe it is just configuration issue of dhcp client, and dhcp client has to be forced (with some switch) to use DUID with MAC address.

It is funny, I hear for the last 20 yeas that IPv6 is ready but whenever I touch it I found some implementation issue. And I am not IPv6 expert, I do not like it...

It is possible that this IPv6 issue was missed because to detect it you need at least 2 similar computers on the same network. Most developers probably just run one computer and that is why they cannot see such issue...

I have captured several packets with "wireshark" and I see that DUID is really sent from client to DHCP server, so it is not problem of DHCP server, source of DUID is at client computer...

[Igor]

21 hours ago, PSL said:

It is funny, I hear for the last 20 yeas that IPv6 is ready but whenever I touch it I found some implementation issue. And I am not IPv6 expert, I do not like it...

 

Perhaps this is needed?

https://www.wdiaz.org/enable-ipv6-in-raspberry-pi-with-raspbian/

[PSL]

I checked Raspbian and I think it doesn't use Network manager and DHCP client is responsible for generation of DUID. Armbian uses Network Manager and DUID is created by Network manager, so I think that Network manager is troublemaker here.

 

Good introduction to DUID is this blog post: https://isc.sans.edu/forums/diary/DHCPv6+and+DUID+Confusion/18015/

 

Wikipedia has good overview too and it has link to related RFC document. https://en.wikipedia.org/wiki/DHCPv6#DHCP_unique_identifier

 

Timestamp can be used to generate DUID and this is a problem for these small computers because most of them doesn't have RTC that is backed up with a battery and boards gets time from NTP server, from the network. To connect to the internet after power on, IP address is required, so it means that time cannot be used to generate DUID on these small computers because they just doesn't have RTC with current time; DUID is required to fetch IP address from DHCP server and board doesn't have correct time at that state. I am not sure why timestamp is used to generate DUID, maybe that a random number can do the job.... Well, there are several ways how to generate DUID, and only one of them uses timestamp. Raspberry Pi uses this type of DUID, timestamp + MAC address, so I am not sure how they deal with the timestamp problem.

 

Other interesting point from the blog post is that Microsoft did good job, DUID can be displayed with "ipconfig /all" and it is displayed in good format". I failed to find how to check DUID on Linux, a man has to search for DUID in several files and I think it is not in any file at Armbian. This is not good for troubleshooting on Linux... Another point is that there is a chaos and each system shows DUID in different way, that is confusing and not good for anybody...

[PSL]

NetworkManager is troublemaker. Option "dhcp-duid" configures NM how to generate DUID, see detail in https://developer.gnome.org/NetworkManager/stable/settings-ipv6.html

It looks like NM at Armbian uses file "/etc/machine-id", and it transforms machine-id to DUID. And that corresponds to my observations, several Armbian computers have the same /etc/machine-id, like Odroid C4 has the same machine-id as Pine A64 computers. From my point of view, this is a BUG in Armbian. I think this "machine-id" should be generated during install process to be unique for each computer.

Other possible solution is to configure NM to use different kind of DUID, like DUID based on MAC address.

 

ODROID C4, PINE64:

$ cat /etc/machine-id
b3f9ca546c1448daa2015da905a4e0c1

 

LaPotato:

$ cat /etc/machine-id
741d536ef8864df7bba40409aaf7c63d

 

"machine-id" has man page: https://www.man7.org/linux/man-pages/man5/machine-id.5.html

Info at Debian site: https://wiki.debian.org/MachineId

[mspohr]

I've just installed Armbian 20.08.4 Pinebook-Pro 5.8.11 desktop on my Pinebook Pro.

The installation went well and I'm very happy with the performance. Thanks to the Armbian people for making this available.

I'd like to add an external monitor. The Pinebook Pro doesn't have an HDMI port but relies on an external USB C dongle for HDMI. I have a dongle which I have been using with the factory Debian image which works. Unfortunately, it doesn't work with this Armbian. No HDMI output. It doesn't seem to be recognized.

Any idea how I could add a driver to enable this output? Would this be possible?

[mspohr]

Just an update to my previous post about HDMI through a USB C dongle. I've since purchased another USB C dongle (Anker PowerExpand+ Model A8352) and this dongle works fine with my current installation for HDMI dual monitor display on the PineBook Pro. (My prior dongle was a QGeeM M4V03 and this didn't work.)

[Digitalman1983]

Has anyone had any luck getting the LCD working on newer kernels?

[Learnincurve]

On 11/20/2020 at 8:26 PM, Digitalman1983 said:

Has anyone had any luck getting the LCD working on newer kernels?

Yes. This is working now!  You just need to enable it in armbian-conf and make sure the "goodix" module gets loaded at boot for the touchscreen. Ignore instructions of the download page for now, they are for the older legacy releases.

If you have trouble with the touchscreen failing to load on reboot, see this post: 

 

[Nico1]

Anybody have an issue where the networking breaks after suspending the system? I tried restarting NetworkManager and the applet, but it just displays as disconnected until I restart my system. I'm on the buster version for the pinebook.