Learnincurve

Hi, I have a couple of these boards which I have been using with Armbian and the old, 3.10 kernel. Ideally I would really like to go mainline as later kernels have some functionality that would be useful for my use of the board. The only remaining reason (apart from cpu freq.) for sticking to the 3.10 kernel has been the lack of MIPI DSI support in mainline, but now I see that, despite the Matrix at http://linux-sunxi.org/Linux_mainlining_effort still being red for A64 mipi, some work is being/has been done by Maxime Ripard. I'm just wondering if anyone here knows if a working mainline kernel with DSI for the Pine 64 is starting to look like a possibility and if it might be possible to include in an armbian build. I might be able to do some testing of anyone can guide me in making a build with the necessary patches.

Excellent! Thanks!

Hi, Having successfully installed and configured Armbian on my Orangepiåplus2e, I just installed armbian next (5.34.171020 | armhf | armv7l | 4.13.8-sunxi) to sd card and booted from there Then downloaded the script from http://forum.armbian.com/index.php/topic/1070-install-to-emmc/?p=11374 installed p7zip and tried to run the script, but it looks like all the dialog "--" options are failing with command not found. Eg: ./backup_to_sd.sh: line 228: --gauge: command not found I checked that doalog is installed in the latest version. Google is noth throwing up anythingb useful. I can do an ordinary dd if=/dev/mmcblk1 | gzip > ./image.gz but wondering why dialog is not working in the script. System info at: http://sprunge.us/faZC BR. --Marius--

Please disregard. I managed to interrupt the boot process from uboot and boot from sd.

Hi, I have a OrangePi+ 2E running ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.13.5-sunxi The system is installed and runs well from EMMC, but now that I have it set up more or less as I want it, I tried to boot from sdcard to do a emmc backup as here I tried first plugging the original SD that was nand-installed to emmc, but the system would only boot to emmc, su did a fresh install of armbian next to a new sd card, but the system will still only boot from emmc. Any ideas? BR.

Point taken. I gave no information. Board is Orangepiplus2e running ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.13.5-sunxi Reason I'm using mainline is that I had a lot of trouble with oom errors on this board with the legacy kernel (known issue). Thanks for the suggestion to remove/purge avahi-autoipd. I wasn't sure if that was so tightly integrated into the rest of the networking stuff that it would break the whole network setup. I'll follow the suggestion as dhcp will be available wherever I connect. No further action needed. BR. --M--

Sorry to revive an old thread: The problem (on my system) is that something seems to be constantly monitoring the interfaces and reconfiguring avahi for eth0, even if there is no link. The default route is therefore being assigned to a disconnected interface. Removing the route will only work until the next time the interface comes up. It won't permanently disable Avahi for the interface. I tried doing a ifconfig eth0 down on the disconnected interface, which also kills the route, but a couple of minutes later it's back up and so is the route. What we need is something equivalent to: Johnrego found the standard solutionas follows: I think I was able to solve the problem as follows: Edit the / etc / default / avahi-daemon file Change the line: AVAHI_DAEMON_START = 1 In: AVAHI_DAEMON_START = 0 Sudo update-rc.d -f avahi-daemon remove but on my orangepiplus2e there is no /etc/default/avahi-daemon file. It looks like the whole shabang is being triggered by /etc/avahi/avahi-autoipd.action but I don't see any way to turn it off. As a test I did an ifconfix wlanX up without assigning a wireless network to wlanX. The same think happened. The interface came up with a 169.254 address and was assigned the default route. It looks as if avahi is assigning a 169.254 address to any interface that is brought up, even if no link is available. Any ideas about where the misconfiguration is, or how to cure it? BR. --Marius--

For information, I sorted this using "triggerhappy": Apt installed created a "triggerhappy" system user and modified the init script to use it. crated a trigger configuration for the button press event (BTN_0 1) creted a simple script invoking systemctl poweroff -I modified sudoers accordingly. Tested:. Buttonpress shuts down the system even if users are currently logged in. The system can be started again by pressing the other, rectangular switch by the power intake, which as zador.blood.stained correctly pointed out, is hardwired as reset.

headers were updated this morning

Thanks. Killed the process. The rest of apt appeared to be finished and I did a new apt upgrade just to be sure. Killed the process again and now am doing a dpkg-reconfigure on the header package, to see if it will compile to conclusion.

Hi, I downloaded and installed v. 5.30-next yesterday - kernel 4.11.4-mvebu. The board apppears to run slightly cooler than with v.5.25 and has been stable. This morning an apt upgrade to 5.31 was available and I started running the update. Apt upgrade has now been running for about 4 hours, compiling linux-headers-next-mvebu (5.31), with most cpu time going to cc1. Top is dynamic, with cc1 taking anything from 0% to 100% cpu, so I am guessing that nothing has hung but that header compilation will take a long time on this system. A similar very long linux header update was experienced when I tried to update this system once before. I aborted that update and failed thye next boot, as the kernel was then inconsistent. I'd like to avoid a similar problem now, but am wondering how long I should expect to wait before giving up and taking remedial action. I have not had any problems with linux header updates on other ARMbian systems (orangepi plus2e and Pine64+). Any experience/advice? BR. --Marius--

Thanks for clearing that up. For the record, I haven't added anything to dts, but I guess there's enough there already. BR. --Marius--

Sorry if this is stupid. This is what I found so far: From the dts file link that zador posted: gpio-keys { compatible = "gpio-keys"; pinctrl-0 = <&rear_button_pins>; pinctrl-names = "default"; button_0 { /* The rear SW3 button */ label = "Rear Button"; gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; linux,can-disable; linux,code = <BTN_0>; }; }; }; Then doing cat /sys/kernel/debug/gpio and looking for "Rear Button", I find that that is on pin 44: grep -i "Rear Button" /sys/kernel/debug/gpio gpio-44 (Rear Button ) in hi (act lo) - IRQ edge (clear ) but if I try to export pin 44, I get device or resource busy: root@clearfogbase:~# echo 44 > /sys/class/gpio/export -bash: echo: write error: Device or resource busy I compiled gpio_watch from http://blog.oddbit.com/2014/07/26/gpiowatch-run-scripts-in-respo/ which I though looked like a good way to do what I wanted. What am I doing wrong? BR. --Marius--

Thanks zador.blood.stained

I found the key between the USB port and the Ethernet ports at /dev/input/by-path/platform-gpio-keys-event but the other button, beside the power input is still a mystery. BR. --Marius--