guidol

find at https://www.armbian.com/download/ all downloads
 
- Alwinner /banana Pi A 20
https://redirect.armbian.com/bananapi/Buster_current 

- Udoo Quad Makerboard Rev. D.
https://redirect.armbian.com/udoo/Buster_current

- Orange PI Prime rev 1.0 
https://redirect.armbian.com/orangepiprime/Buster_current_xfce

Info on Reddit
 
 

I've tried for months to clarify the reason of such issue ...
My last working kernel was 5.7.6, and the issue appeared as soon as 5.8.0, I've done "diff" between both branches and I still didn't figured out the glitches ...

New version of Armbian 20210311.
Based on the main core 5.10.23.
Now anyone can build their own version of Armbian for Jetson Nano without an external PC, the entire process is completely performed on the Jetson Nano itself.

 

@Igor @Elclaudio
My C2 did already work/reboot with 
U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2
 
But today I compiled the new u-boot
U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2
which does also work/reboot fine on my C2
System diagnosis information has been uploaded to http://ix.io/2SaS
 
[EDIT]
does also work with newer dev-kernel
FROM Linux 5.10.19-meson64 TO Linux 5.11.4-meson64
System diagnosis information has been uploaded to http://ix.io/2SaU

 
 
# dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,0525366 s, 13,4 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2 # dpkg -i ./linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64.deb cd /usr/lib/linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64 dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=./u-boot.bin of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 [reboot] # dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,04659 s, 15,1 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2  
linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64.deb

@Elclaudio This could provide a fix. Change to nightly builds (armbian-config -> system -> nightly) and see if things are better. Patch is already in that code.

We have a commercial product running on Armbian based on the OPi Zero platform. We occasionally get reports from customers of intermittent connectivity, which (looking at the dmesg log on affected devices) manifests itself as something that looks very much like the up/down syndrome reported here. In this case we advise customers to purchase a cheap switch (e.g. https://www.amazon.com/NETGEAR-5-Port-Gigabit-Ethernet-Unmanaged/dp/B07S98YLHM/ref=sr_1_3?dchild=1&keywords=4+port+switch&qid=1614793487&sr=8-3) and put it between our product and their existing switch or router. We have found this always resolves the issue.
 
We still don't understand the cause, but at least we have a workaround (albeit not a perfect one).

Elclaudio, you're a legend.  Shoved ye olde uboot on and bam... eth0 is back.
 
Thank you!!
 
Not a fix, but it's enough of a workaround for my needs.

OK I FOUND THE CULPRIT ! the issue come from UBOOT like I imagined. After installing older uboot ETH0 worked straight away
Since I couldn't find the uboot .deb used in my old armbian 5.95 in https://imola.armbian.com/apt/pool/main/l/
I took the uboot files from my WORKING armbian version kernel 4.19.69 in /usr/lib/ linux-u-boot-next-odroidc2_5.95_arm64
there should be 2 files : bl1.bin.hardkernel  and u-boot.bin
copy them wherever you want on the latest armbian (currently in test : Armbian 21.02.2 Buster with Linux 5.10.16-meson64,) Linux odroidc2 5.10.16-meson64 #21.02.2 SMP PREEMPT Sun Feb 14 21:50:52 CET 2021 aarch64 GNU/Linux
I backed up the original files in the same directory with .ORI extension
Then I run the commands here
 
If you do it beware with dd it could crash your partition if missused, also adapt the paths and filename to your particular case.
 
#!/bin/bash # install older uboot from armbian kernel 4.19.69 dd if=/root/uboot/bl1.bin.hardkernel.OLD of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=/root/uboot/bl1.bin.hardkernel.OLD of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=/root/uboot/u-boot.bin.OLD of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 # restore original uboot #dd if=/root/uboot/bl1.bin.hardkernel.ORI of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; #dd if=/root/uboot/bl1.bin.hardkernel.ORI of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; #dd if=/root/uboot/u-boot.bin.ORI of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1  
It would be nice now to debug what's gone wrong with uboot code...

If you look at the resulting image, maybe the rtl8189fs.ko is still present and broken ...
 
Anyway, I've done builds+tests on all my OPi which using this rtl8189, and results are successful, I've done this commit :
https://github.com/armbian/build/commit/bba53d4644e83cd46b80820b5835ad7c2e7691e5

As a test I updated on a secondary Pihole-Server (buster on NanoPi K1 Plus) the kernel to 5.11.1-dev and at startup Pihole did seem to make some trouble
The server isnt getting to the login prompt and on the serial console the last info is "Starting kernel..."
 
I updated some of my SMB-Servers with kernel 5.11.1-deb without problems.
 
Will later try a new resinstall with buster and 5.11.1 and see if Pihole will run on a complete new installation.
 

Some additional information for the curious ... https://www.debian.org/ports/arm/
The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. The 64-bit ARM (arm64) port supports the latest 64-bit ARM-powered devices.

Moved to proper location.
armhf is 32bit
arm64 is 64bit.
 
There are a few other variants of arm in 32bit which you can lookup via Wikipedia for example

Did create a more compact version for me (and you?)
 
nano /etc/update-motd.d/10-armbian-header ARMBIAN_bsp=$(more /etc/armbian-release|grep VERSION|cut -f 2 -d '=') ARMBIAN_kernel=$(dpkg -s linux-image-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_uboot=$(dpkg -s linux-u-boot-$BOARD-$BRANCH|grep Version|cut -f 2 -d ' ') ARMBIAN_dtb=$(dpkg -s linux-dtb-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_firmware=$(dpkg -s armbian-firmware|grep Version|cut -f 2 -d ' ') ARMBIAN_config=$(dpkg -s armbian-config|grep Version|cut -f 2 -d ' ') printf '\n' printf 'pkg-version kernel[\e[0;91m%s\x1B[0m] u-boot[\e[0;91m%s\x1B[0m] dtb[\e[0;91m%s\x1B[0m] firmware[\e[0;91m%s\x1B[0m] config[\e[0;91m%s\x1B[0m]\n' "$ARMBIAN_kernel" "$ARMBIAN_uboot" "$ARMBIAN_dtb" "$ARMBIAN_firmware" "$ARMBIAN_config" printf '\n'  

Armbian have historically been much more geared towards "server/headless" usage, for many different reasons.  It has taken a much longer time not only for upstream development of underlying graphical libraries / drivers to mature, but also for us (the Armbian project itself) to come up with a sensible implementation that would fit nicely into our existing build framework.
 
However, this work has been going on in the background for quite some time already. 
 
Announcement
 
Finally, the time is right to announce we are publishing our initial implementation of these "desktop" features!
 
Warning!

We are only announcing this here on our own forums for the time being, as this is still early days.  In fact, at this point we are still mainly looking for testers. You should consider this an alpha quality release at this time!
 
What works so far?

Features we plan to develop works, we are already hunting bugs for months, but they are certainly still present. Remember, we are not looking for bugs that are tied to specific hardware feature, but bugs that are linked to the build process, userland and basic desktop functionality. 
 
Report bugs in Armbian build framework section: https://forum.armbian.com/forum/12-armbian-build-framework/
 
Currently, the following Desktop Environments (DEs) are considered to have early "support":
 

 

 
In addition, there are more DEs which should be considered very much WIP, in other words, not really fully working (yet), but we designed a system that can have unlimited variants.
 
Help Wanted!
 
These changes are wide ranging and touch many parts of the code.  Therefore even if you don't plan on using any "desktop" features, your testing can help to find bugs, even in "server" versions (as eventually this code will be merged with master in matter of weeks).
 
If you have been looking for some opportunity to help the project by getting involved a bit more, this could be your chance!

When you notice a problem make a pull request: https://github.com/armbian/build/pulls ( currently sits on a branch "desktop" )
 
Going forward we will be looking for additional desktop maintainers.  Currently the plan is for the Armbian core team to maintain the framework and perhaps settle on 2-3 DE options.  Any which are to be considered in addition to that, will need to come with some commitment to ongoing maintenance by whoever is interested in those additional desktops.
 
Join #armbian-devel IRC channel for development level chat and strengthen the desktop team. Welcome!
 
Getting Started
 
If this is your very first time using the build scripts, start with general instructions. If you are already familiar with the basics of building, some additional detailed instructions pertaining to desktop features can be found here.  You will also need to add:
 
./compile.sh LIB_TAG=desktop EXPERT=yes  
If you don't have option or desire to build from sources, you can also check if your board has nightly images - we are compiling them from this new development branch for a few weeks now - for the desktop you want to try / see:


 
Documentation
 
For end users, if you just want to build image interactively and by choosing supported OS variants, things hasn't changed much and should just work while advanced documentation has changed significantly. Its pretty much WIP and is scattered around in those files:
 
https://github.com/armbian/build/blob/desktop/config/desktop/README.md
https://github.com/armbian/documentation/pull/125
https://github.com/armbian/documentation/pull/98
 
Additional
 
During this change we also added most recent userland(s):
 

its working again with 5.10.10 (with my - at this time- local .dts/.dtb-change) 
 
_ _ ____ _ _ __ _ _ | \ | | _ \(_) / \ / /_ | || | | \| | |_) | | / _ \| '_ \| || |_ | |\ | __/| | / ___ \ (_) |__ _| |_| \_|_| |_| /_/ \_\___/ |_| Welcome to Armbian 21.02.0-trunk Buster with Linux 5.10.10-sunxi64 No end-user support: built from trunk package bsp-kernel[21.02.0-trunk] u-boot[21.02.0-trunk] dtb [21.02.0-trunk] firmware [21.02.0-trunk] config[21.02.0-trunk] branch[dev] System load: 4% Up time: 14:55 Memory usage: 10% of 985M IP: 192.168.6.116 CPU temp: 27°C Usage of /: 10% of 15G  
System diagnosis information has been uploaded to http://ix.io/2Npi
 

@Igor I created https://github.com/armbian/build/pull/2579
but please ignore the old part about the configuration.sh from 2019 - its only the 2021-part about the phy-mode patch

This is going to be fixed hopefully before next major release https://github.com/armbian/build/issues/2398
 

We have notice this problem but it seems to be related to some Debian library. There are so many problems and so little time ...

Yeah, that's it. IMO something is wrong with / around LCD driver. I suspect this - Pine only sells Pinephone, which is the very similar hw, just in different form factor and by upstreaming LCD on Pinephone they break support for Pinebook somehow ... Since we already lost several afternoons trying to fix this it is unlikely to repeat that anytime soon. Not possible  

@Igorstrange - got near the same problem this evening with a nanoPi K1 Plus
(after updating to pihole FTL 5.5.1 and reboot  = https://pi-hole.net/2021/01/19/pi-hole-ftl-v5-5-released-update-today#page-content )
The NPI K1 Plus is searching a shorter UUID than shown as blkid
 
The Boot-Error does show
boot-err    971c3757-23ee-42

 
 
So I did put the card of the NPI K1 Plus in my Neo2 (IP24) and monuted it on /mnt/sdb1
 
But with blkid and in /etc/fstab and /boot/armbianEnv.txt I ons could find the long UUID:
boot-err 971c3757-23ee-42 blkid 971c3757-23ee-4281-b0cb-989e7255e3d9 fstab 971c3757-23ee-4281-b0cb-989e7255e3d9 armbianEnv 971c3757-23ee-4281-b0cb-989e7255e3d9  
 
Everthing seems OK - so because the Neo2 had the problem in /etc/fstab I deleted (the correct one) and replaced it with (in my sight) the same text and did put back the card in the NPI K1 Plus and it worked again ?? just fine  Dont know what happend - while booting- the 4 times before I removed the card...

This is the second time this month with a different device...
 
System diagnosis information has been uploaded to http://ix.io/2MCd

Thank you - you save others  I didn't spot this problem ... fixed. I guess I'll need to expand my test rig with a few more boards.

https://github.com/armbian/build/commit/53bc9e481a6be1e76d13df1f3abca599dc305447

Thank you for providing these valuable infos.
I successfully installed picochess with the current Stockfish 12 engine and the 3-4-5-men syzygy endgame tables on a 64 GB eMMC chip with Ubuntu 20.04.
Now I can use my Odroid C2 with a DGT Smartboard in conjunction with a DGT 3000 chessclock.

@jeyjey For supported SBCs the easiest way to get minimal or server-only images of armbian is to setup a own armbian-buil-system
on a 64bit Ubuntu or a VM:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
with the armbian-build-system you will have a menu driven selection if you want to create a image for the type minimal, server or desktop
you can select between ubuntu and debian flavour of armbian and the version of ubuntu or debian...as long your SBC is supported by armbian.
 

Because mainline kernel is a RAW generic material which we use, make certain (actually quite a lot of - we deal with base development) changes, add certain boards to it and distribute. Integration and acceptance to mainline kernel takes a lot of time and many things are never accepted / integrated. While they can be a part of Armbian for weeks, months, years. It's our burden of maintaining and advantage at the same time. The same goes for u-boot.
 
All changes are public and you can study them in the following folders:
 
kernel
https://github.com/armbian/build/tree/master/patch/kernel
https://github.com/armbian/build/tree/master/patch/misc
https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh
https://github.com/armbian/build/tree/master/config/kernel
 
u-boot
https://github.com/armbian/build/tree/master/patch/u-boot

change of .dtb (activating 1c22000) & creating overlay (armbian-add-overlay ./sun8i-h3-I2S-out.dts) does also work on 
uname -a Linux npi-neo-25 5.10.0-sunxi #trunk SMP Wed Dec 16 17:45:03 +03 2020 armv7l GNU/Linux package bsp-kernel[21.02.0-trunk] u-boot[21.02.0-trunk] dtb [21.02.0-trunk] firmware [21.02.0-trunk] config[21.02.0-trunk] branch[dev] like before on kernel 5.9.0