zador.blood.stained Posted October 25, 2017 Share Posted October 25, 2017 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). 0 Quote Link to comment Share on other sites More sharing options...
dahni Posted December 29, 2017 Share Posted December 29, 2017 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? 0 Quote Link to comment Share on other sites More sharing options...
xnyle Posted February 4, 2018 Share Posted February 4, 2018 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. 0 Quote Link to comment Share on other sites More sharing options...
xnyle Posted February 12, 2018 Share Posted February 12, 2018 Nobody? I also noticed that temp goes down 5 degrees if I unplug HDMI. Anyone who can make sense of this? 0 Quote Link to comment Share on other sites More sharing options...
frederic Posted March 8, 2018 Share Posted March 8, 2018 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... 0 Quote Link to comment Share on other sites More sharing options...
andydj Posted March 17, 2018 Share Posted March 17, 2018 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 0 Quote Link to comment Share on other sites More sharing options...
reggie Posted May 20, 2019 Share Posted May 20, 2019 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 0 Quote Link to comment Share on other sites More sharing options...
kapqa Posted June 29, 2019 Share Posted June 29, 2019 (edited) 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 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 29, 2019 Share Posted June 29, 2019 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. 0 Quote Link to comment Share on other sites More sharing options...
kapqa Posted June 30, 2019 Share Posted June 30, 2019 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?) 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted June 30, 2019 Share Posted June 30, 2019 5 hours ago, kapqa said: and compiled through help of here That will 100% not use any video acceleration. Use our pre-build version ... 0 Quote Link to comment Share on other sites More sharing options...
kapqa Posted July 1, 2019 Share Posted July 1, 2019 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. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted July 1, 2019 Share Posted July 1, 2019 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. 0 Quote Link to comment Share on other sites More sharing options...
psychedup74 Posted July 31, 2019 Share Posted July 31, 2019 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? 0 Quote Link to comment Share on other sites More sharing options...
psychedup74 Posted July 31, 2019 Share Posted July 31, 2019 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. 0 Quote Link to comment Share on other sites More sharing options...
p1x3l3d Posted August 1, 2019 Share Posted August 1, 2019 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! 0 Quote Link to comment Share on other sites More sharing options...
marek Posted August 3, 2019 Share Posted August 3, 2019 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 0 Quote Link to comment Share on other sites More sharing options...
mudcat Posted July 13, 2020 Share Posted July 13, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
PSL Posted October 5, 2020 Share Posted October 5, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
PSL Posted October 14, 2020 Share Posted October 14, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted October 14, 2020 Share Posted October 14, 2020 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. 0 Quote Link to comment Share on other sites More sharing options...
PSL Posted October 16, 2020 Share Posted October 16, 2020 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... 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted October 17, 2020 Share Posted October 17, 2020 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/ 0 Quote Link to comment Share on other sites More sharing options...
PSL Posted October 17, 2020 Share Posted October 17, 2020 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... 0 Quote Link to comment Share on other sites More sharing options...
PSL Posted October 17, 2020 Share Posted October 17, 2020 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 0 Quote Link to comment Share on other sites More sharing options...
mspohr Posted November 17, 2020 Share Posted November 17, 2020 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? 0 Quote Link to comment Share on other sites More sharing options...
mspohr Posted November 20, 2020 Share Posted November 20, 2020 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.) 0 Quote Link to comment Share on other sites More sharing options...
Digitalman1983 Posted November 20, 2020 Share Posted November 20, 2020 Has anyone had any luck getting the LCD working on newer kernels? 0 Quote Link to comment Share on other sites More sharing options...
Learnincurve Posted January 21, 2021 Share Posted January 21, 2021 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: 0 Quote Link to comment Share on other sites More sharing options...
Nico1 Posted March 29, 2021 Share Posted March 29, 2021 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. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.