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


Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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 

 

Link to post
Share on other sites

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 by kapqa
Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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!

Link to post
Share on other sites
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

Link to post
Share on other sites

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

 

Link to post
Share on other sites

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

 

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
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
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...