guidol

@guidol @raschid what an amazing job! i hope some day we will have mainline kernel and armbian on our device! keep it up!

Yes - I did give it a try - but first a little helpful reminder
You can ZIP the .img from 923MB to 282MB - so its faster for you to upload and faster to us to download
 
932 MB (977.272.832 Bytes) Armbian_19.11.3_Sunvell-r69_bionic_dev_5.4.0-rc8.img
282 MB (296.077.974 Bytes) Armbian_19.11.3_Sunvell-r69_bionic_dev_5.4.0-rc8.img.zip
 
I did boot the image with serial-TTL attached and the image also didnt load the overlays for analog-audio and cir:
 
Found mainline kernel configuration 29532 bytes read in 8 ms (3.5 MiB/s) 382 bytes read in 8 ms (45.9 KiB/s) Applying kernel provided DT overlay sun8i-h3-cir.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 339 bytes read in 9 ms (36.1 KiB/s) Applying kernel provided DT overlay sun8i-h3-analog-codec.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ Error applying DT overlays, restoring original DT 29532 bytes read in 8 ms (3.5 MiB/s) BUT the blue led keeps blinking and the kernel DOENST die
 
Uncompressing Linux... done, booting the kernel. Armbian 19.11.3 Bionic ttyS0 sunvell login: root Password: Last login: Wed Nov 27 17:19:58 UTC 2019 on ttyS0 ____ _ _ ____ __ ___ / ___| _ _ _ ____ _____| | | | _ \ / /_ / _ \ \___ \| | | | '_ \ \ / / _ \ | | | |_) | '_ \ (_) | ___) | |_| | | | \ V / __/ | | | _ <| (_) \__, | |____/ \__,_|_| |_|\_/ \___|_|_| |_| \_\\___/ /_/ Welcome to Armbian Bionic with Linux 5.4.0-rc8-sunxi System load: 1.08 0.26 0.08 Up time: 0 min Memory usage: 7 % of 998MB IP: 192.168.6.151 CPU temp: 41°C Usage of /: 6% of 15G  
How did you did that (what did you changed before or while the compile process)?
And do you got a image with working analog-audio and cir (OK, analog-audio would be enough for me  )
 
Thanks in advance

Due to this bug https://github.com/armbian/build/issues/1604 I just found the root of the problem. Fix will follow once during a day, tomorrow build should be fine.

Enabled kernel 5.4.y / on:
 
- sunxi/sunxi64 dev (+ u-boot 2019.10)
- imx6 current
- mvebu64 dev
- meson64 dev
 
Will also available in 6 - 8h in beta repository if building on all targets succeeds. 

Only for experimenting - no end user support.

Not to soon, I need some rest ...

Mine (red PCB, v1.2) is running 5.3 - but with a modified device tree if I remember correctly. I'll check ..

Ok ! I will try to push it by the end-of-the-day, in mean time, I will test some more boards, even if random MAC is an issue, it is not a show stopper.
 

Add this
extraargs=net.ifnames=0 to /boot/armbianEnv.txt

Right ! Due to change of structures in configs and branches, I've to redo testing again before doing my commits. Maybe by the end-of-weekend ...

Release details

https://docs.armbian.com/Release_Changelog/
 
Upgrading your Armbian to v19.11.y
 
This upgrade is changing kernel branch names and first upgrade is not done via regular apt-upgrade process, but you have to login as root or get super user privileges with sudo su. Than do the following:
apt update apt upgrade armbian-config -> system -> Other -> select either legacy or current with v19.11.3
 
 
Choose latest version of 19.11.x and select upgrade according to this scheme:
Odroid XU4 default, next or dev -> legacy (stock 4.14.y) Allwinner default, next, dev -> legacy (4.19.y), current (5.3.y) Odroid C2 and other meson64 boards -> current (5.3.y) Odroid N2 -> legacy (4.4.y), current (5.3.y) Tinkerboard and other rockchip boards -> legacy (4.4.y), current (5.3.y) Cubox and Udoo -> imx6 current (5.3.y) Helios 4 and Clearfog -> mvebu legacy (4.14.y), current (4.19.y) Espressobin -> mvebu64 legacy (4.14.y), current (4.19.y) Those upgrades were tested manually:
 

Note: upgrade will replace your boot script. In case you made changes, you can find a backup in /usr/share/armbian
Main build system changes
Due to changes in branch names and removal of all legacy kernels < 4 your predefined automatic scripts might need updating. Temporally quick fix is to add
LIB_TAG="v19.08" to your build config file which by default is:
userpatches/config-default.conf Then run your script as you did before.
 
Thanks to all who are contributing their time to Armbian in various forms and especially developers who contributed to this release. Also thanks to the greater kernel developers community which are playing great role in this.

In case you want to participate, you are more then welcome. Step up and start making changes! In case you run into the troubles or find a bug, forum is the place for talking about while fixes you are welcome to prepare and send here.

Note: some images will be missing today and tomorrow from the download section. Missing one are being created and uploaded but this takes time ... Most of the images were manually tested for booting, upgrades as stated above, but we can't afford to make stability, functional or just boot auto tests on industrial scale. Not with our ultra tiny resources. Perhaps in the future if "you" will support that.
 
Enjoy! 

Well - the LEDs are not statically defined, because you can define their usage by yourself - and the OS can have another default funtion like on a other OS (Orange Pi original Linux <--> armbian)
 
Your could find the available LEDs here:
root@pihole:~# ls -l /sys/class/leds
total 0
lrwxrwxrwx 1 root root 0 Jan  1  1970 green_led -> ../../devices/platform/leds-gpio/leds/green_led
lrwxrwxrwx 1 root root 0 Jan  1  1970 red_led -> ../../devices/platform/leds-gpio/leds/red_led
 
and which function is assigned to the LED you could find out while do a "more" an their trigger-file:
root@pihole:~# more /sys/class/leds/red_led/trigger
none mmc0 mmc1 timer [heartbeat] backlight default-on
 
here you could see I assigned the funtion [heartbeat] to the red LED
 
I did this in the /etc/rc.local with the following command (before the line with "exit 0") :
echo "heartbeat" > /sys/class/leds/red_led/trigger
 
heartbeat is this flashing LED - showing the system is running
 
mmc0 will be like a HDD-LED for your uSD-Card:
echo "mmc0" > /sys/class/leds/green_led/trigger
 
The names of your LEDs may varies.
 

Well - the LEDs are not statically defined, because you can define their usage by yourself - and the OS can have another default funtion like on a other OS (Orange Pi original Linux <--> armbian)
 
Your could find the available LEDs here:
root@pihole:~# ls -l /sys/class/leds
total 0
lrwxrwxrwx 1 root root 0 Jan  1  1970 green_led -> ../../devices/platform/leds-gpio/leds/green_led
lrwxrwxrwx 1 root root 0 Jan  1  1970 red_led -> ../../devices/platform/leds-gpio/leds/red_led
 
and which function is assigned to the LED you could find out while do a "more" an their trigger-file:
root@pihole:~# more /sys/class/leds/red_led/trigger
none mmc0 mmc1 timer [heartbeat] backlight default-on
 
here you could see I assigned the funtion [heartbeat] to the red LED
 
I did this in the /etc/rc.local with the following command (before the line with "exit 0") :
echo "heartbeat" > /sys/class/leds/red_led/trigger
 
heartbeat is this flashing LED - showing the system is running
 
mmc0 will be like a HDD-LED for your uSD-Card:
echo "mmc0" > /sys/class/leds/green_led/trigger
 
The names of your LEDs may varies.
 

In the past I did hope that the "minimal-image" would save memory, but I looks to me to have only less included packages.
The "minimal-image" do use also around 60-90MB after bootup, but I dont know if I do need every loaded package.
 
I did wonder about the 60-90MB from armbian when I did see a x86 PC after debian netinstall OR my old trusty Marvell Kirkwood devices
Linux excito-b3 4.19.59-1 #1 Wed Jul 17 14:58:51 EDT 2019 armv5tel GNU/Linux
which do start up with 25-35MB of Memory-usage.

So I did also having a strip-down-script, but I dont know which packages do eat up the additional Ram, because the Excito-B3-image also do use already systemd.
 
With a footprint of 25-35MB even a 256MB device like the OPi R1 is very useable
 

another picture from the Wiki page http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M1_Plus
and the pdf: http://wiki.friendlyarm.com/wiki/images/5/57/AP6212_V1.1_09022014.pdf

I use the USB-A to Barrel cable for my OPi's - maybe it was a connector problem?

Well - the LEDs are not statically defined, because you can define their usage by yourself - and the OS can have another default funtion like on a other OS (Orange Pi original Linux <--> armbian)
 
Your could find the available LEDs here:
root@pihole:~# ls -l /sys/class/leds
total 0
lrwxrwxrwx 1 root root 0 Jan  1  1970 green_led -> ../../devices/platform/leds-gpio/leds/green_led
lrwxrwxrwx 1 root root 0 Jan  1  1970 red_led -> ../../devices/platform/leds-gpio/leds/red_led
 
and which function is assigned to the LED you could find out while do a "more" an their trigger-file:
root@pihole:~# more /sys/class/leds/red_led/trigger
none mmc0 mmc1 timer [heartbeat] backlight default-on
 
here you could see I assigned the funtion [heartbeat] to the red LED
 
I did this in the /etc/rc.local with the following command (before the line with "exit 0") :
echo "heartbeat" > /sys/class/leds/red_led/trigger
 
heartbeat is this flashing LED - showing the system is running
 
mmc0 will be like a HDD-LED for your uSD-Card:
echo "mmc0" > /sys/class/leds/green_led/trigger
 
The names of your LEDs may varies.
 

And for those who live on the command line - byobu is like screen and tmux on steroids - and it's in the ubuntu repos...
 
 
If one wants to have a fun demo...
 
 
byobu rocks...

@John Outrider Gault before this is useable give the command:
apt install p7zip-full

Hi Guido,
 
Thank you. As you mentioned several components I wasn't sure what is really needed and to install was a bit overkill, at first sight.
I could have gone ahead with try and error, but as you already have the knowledge, I thought it was better to ask.
 
Apart from that, others can now also easily benefit from your lesson 😊
 
Cheers,
Tido

which of the 2 configs you want to rebuild?
for the non-chromebox (colored on black) prompt line there is already everything you need to put on the end of your ~/.bashrc in the first source-part box above.
 
for the chromebox prompt you need to install the 2 packages fonts-powerline &  powerline via
apt install fonts-powerline powerline
copy powerline.sh to your home-directory:
cp ./powerline.sh ~/
and append at the end of your ~/.bashrc the line:
source ~/powerline.sh
and change pUTTY to UTF8-translation:
Change Setting => Window => Translation => Remote character set => UTF-8 => Apply
or save it directly to your pUTTY session
 
then activate the new ~./bashrc while starting a new bash with
bash
or reboot
 
BTW: you have to change the ~/.bashrc for every user where you want to use it - for me these files are
/home/root/.bashrc    and
/home/guido/.bashrc
 
Do you got any other questions?
 
powerline.sh

Over a year (or two?) I used a PS1-line in my ~/-bashrc with many cryptic ANSI-Escape-codes which were hard to read and edit
 
export PS1='\[\033[1;36m\]\u\[\033[1;37m\]@\[\033[1;33m\]\h\[\033[1;37m\](\[\033[1;32m\]$THEIP\[\033[1;37m\])\[\033[1;31m\]:\[\033[1;36m\]\w\[\033[1;31m\]\$\[\033[0m\] ' Today I did installed Linux Lite 4.6 on a PC (a former Chromebox) and did see the nice Powerline prompt and did try to use that on a nanoPi Neo2.
I installed the packages fonts-powerline &  powerline and copied the powerline-script /usr/share/powerline/bindings/bash/powerline.sh
from the pc to the NanoPi Neo2.
It did work after I used UTF8 translation in pUTTY, but it wasnt very perfomant
 
So I decided to cleanup my PS1 line for better reading,
 
I had to define some variables and then I did put these in my PS1 export line in ~/.bashrc:
 
export THEIP="$(/sbin/ifconfig | grep "inet " | grep -v 127.0.0. | awk '{print $2}')" BRed='\[\033[31;1m\]' BGreen='\[\033[32;1m\]' BYellow='\[\033[33;1m\]' BCyan='\[\033[36;1m\]' BWhite='\[\033[37;1m\]' Reset='\[\033[0m\]' UserPromptPS1='\$' export PS1="${BCyan}\u${BWhite}@${BYellow}\h${BWhite}(${BGreen}${THEIP}${BWhite})${BRed}:${BCyan}\w${BRed}${UserPromptPS1}${Reset} " # \u = User # @ = @ # \h = Host # \w = working directory # \$ = # for root (uid=0) or $ for user That worked well and did give me the same result as my old but bad readable PS1-line
Now its - for me - much more easy to edit
 
As Information some more useable color-definition (B before the color is for Bright and colors starting with On are for the Background):
Black='\[\033[30m\]' Red='\[\033[31m\]' Green='\[\033[32m\]' Yellow='\[\033[33m\]' Blue='\[\033[34m\]' Magenta='\[\033[35m\]' Cyan='\[\033[36m\]' White='\[\033[37m\]' BBlack='\[\033[30;1m\]' BRed='\[\033[31;1m\]' BGreen='\[\033[32;1m\]' BYellow='\[\033[33;1m\]' BBlue='\[\033[34;1m\]' BMagenta='\[\033[35;1m\]' BCyan='\[\033[36;1m\]' BWhite='\[\033[37;1m\]' OnBlack='\[\033[40m\]' OnRed='\[\033[41m\]' OnGreen='\[\033[42m\]' OnYellow='\[\033[43m\]' OnBlue='\[\033[44m\]' OnMagenta='\[\033[45m\]' OnCyan='\[\033[46m\]' OnWhite='\[\033[47m\]' OnBBlack='\[\033[40;1m\]' OnBRed='\[\033[41;1m\]' OnBGreen='\[\033[42;1m\]' OnBYellow='\[\033[43;1m\]' OnBBlue='\[\033[44;1m\]' OnBMagenta='\[\033[45;1m\]' OnBCyan='\[\033[46;1m\]' OnBWhite='\[\033[47;1m\]' Reset='\[\033[0m\]'  

I finally managed to get the official buster desktop image for the nanopi-m4 fully working on the version 2 of this board too.
 
Basically, I extracted the working bootloader from the Armbian_5.99.191102_Rockpi-4b_Debian_buster_dev_5.3.0 image (which boots, but doesn't works well on the nanopi-m4 v2) and I burnt it to the https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z image.
 
This morning I did some initial tests and it seems that everything is working well.
 
I have prepared a patched image you can try. At the moment, I've tested it only with an SD card, but I guess It'll work on the emmc too.
Download it from https://drive.google.com/open?id=1LaJIywiZnZUkLDZ9HkWrRtc0PyfiYGOL
 
You can also apply the patch by yourself:
 
1) download buster desktop image for nanoPi M4 (version 1) from Armbian's web site https://dl.armbian.com/nanopim4/Debian_buster_default_desktop.7z
2) extract and burn it to an SD card
3) apply the patch I have shared at the link above using the following command, changing sdX with the correct device:
sudo dd if=8M_after64ibs_uboot_working_rockpi4image_on_nanopim4v2.dd of=/dev/sdX seek=64  
Let me know if it works for you too.
 

take a look at
https://www.cnx-software.com/wp-content/uploads/2019/09/NanoPi-M4V2-Large.jpg
from
https://www.cnx-software.com/2019/09/30/nanopi-m4v2-metal-case-kit-review-unboxing-assembly/
 
 

also do 
cp /lib/firmware/brcm/brcmfmac4356-sdio.txt /lib/firmware/brcm/ brcmfmac4356-sdio.friendlyarm,nanopi-m4.txt
then check if  /lib/firmware/brcm/brcmfmac4356-sdio.bin would be loaded?

You may want to consider buying an OrangePi One. The 512MB configuration is even a tiny bit cheaper than the 512MB OPi Zero, no (useless anyways) wireless onboard, offering HDMI and H3 instead of balls-cut-off-H2+ SoC. It cannot be powered from microUSB though. Barrel plug has to be used.