guidol

Looking decent.
___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ | | | | |_) | | | | | | '_ \ / _ \ | |_| | __/| | | |_| | | | | __/ \___/|_| |_| \___/|_| |_|\___| Welcome to Armbian Buster with Linux 5.5.0-rc2-sunxi [...] root@honeypot:~# lsmod Module Size Used by wireguard 57344 0  
 
Edit: OPi0+ looking good too.
___ ____ _ _____ ____ _ / _ \| _ \(_) |__ /___ _ __ ___ | _ \| |_ _ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_) | | | | / __| | |_| | __/| | / /| __/ | | (_) | | __/| | |_| \__ \ \___/|_| |_| /____\___|_| \___/ |_| |_|\__,_|___/ Welcome to Armbian buster with Linux 5.5.0-rc2-sunxi64 Though CPU is capped to 1.01GHz while the H5 should work at 1.2GHz.
Found this:
[ 6.037059] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 6.037083] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 6.037167] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 6.037174] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 6.037301] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 6.037309] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 6.037392] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 6.037400] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) Maybe something missing in the dts?

I did compile with 
./compile.sh EXPERT=yes WIREGUARD=no AUFS=no BUILD_KSRC=no and it did also work for for my non-64Bit-sunxi SBCs OPi Zero, OPi One and my BPi M2 Berry

At this time I have no need for WireGuard.

happy happy, joy joy, kernel compilation and upgrade to buster (jessie to stretch to buster) without any error.
For compilation of the kernel i followed the instructions at https://licheepizero.us/build-kernel-for-licheepi-zero
I just changed to kernel 5.2 instead default branch 4.10.y, also i used the latest gcc-linaro instead the one mentioned in the instructions.
Next thing to do:   make X running :-)

@raschid that ONLY  the same dtb-problem as in 5.4
I copied my changed sun8i-h2-plus-sunvell-r69_guido.dts from the 5.4 kernel to the 5.3 buster installation via ftp 
 
then compiled it with kernel 5.3 as .dtb
dtc -I dts -O dtb /home/guido/r69_dts_dtb/sun8i-h2-plus-sunvell-r69_guido.dts -o /home/guido/r69_dts_dtb/sun8i-h2-plus-sunvell-r69_guido.dtb backuped the 5.3 original .dtb
cp /boot/dtb/sun8i-h2-plus-sunvell-r69.dtb ./sun8i-h2-plus-sunvell-r69.dtb_org_53 and inserted the new compiled .dtb into /boot/dtb
cp sun8i-h2-plus-sunvell-r69_guido.dtb /boot/dtb/sun8i-h2-plus-sunvell-r69.dtb after that I deleted the follwoing lines from /boot/armbianEnv.txt (because the overlays are included in the dtb)
overlay_prefix=sun8i-h3 overlays=cir analog-codec now reboot and you will have analog audio (and cir) also in kernel 5.3 (Ok I got debian buster and not ubuntu bionic):
Welcome to Armbian Buster with Linux 5.3.13-sunxi package bsp-kernel[19.11.3] u-boot[19.11.3] dtb[19.11.3] firmware[19.11.3] config[19.11.3] branch[current] root@sunvell:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: allwinnerhdmi [allwinner-hdmi], device 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 [1c22800.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 I will attach the compiled 5.3 version which you could copy to /boot/dtb  and reboot - I think the "debian" version 5.3 should work with ubuntu 5.3
(and dont forget to kill the 2 lines in /boot/armbianEnv.txt)
sun8i-h2-plus-sunvell-r69.dtb

Both !
I still have to test some boards but 75% of my garden is now on 5.5.0-rc2 ...

I've made a breakout board. The small white IC, is an optocoupler and the non connected cables are for a midi in (but not yet finished) interface.
From this breakout board, I will also connect the RCA cinch out.  
Final goal is to run a zynthian synth on armbian (see https://zynthian.org/)

As I said in this other thread :
 

So, I just got mine a few days ago. It's the OPi Zero LTS 512mb version. The board states it's v1.5.
 
I have it running Pi Hole with around 2 million blocked hosts and it's around 20C. Before installing anything (PiHole), even with passive heating it was well below 10C (Only had Armbian). I'd say it's pretty good. Max I have seen it hit under some load is 33C.
 
Edit 1: I just installed a heat sink and can already see the temperatures are lower than before.  With heatsinks I'm now at around 13C and don't go over 26C when it's under load. Pi Hole isn't super intensive on the CPU anyway but still. 
 
Edit 2: I think it's also worth mentioning I have mine in a case. 

Wait, after all the checks I will update git.

That is because /boot is on FAT32 filesystem but update wants to make hardlinks and FAT32 does not support it.
For it to work /boot needs to be on ext filesystem but uBoot needs FAT32. So you can not covert it to ext.
 
Other than that it is just as every other Debian/Ubuntu and updating is the same.
 
How I did get around it?
* Make alternate boot directory somewhere else
* copy/rsync contents of /boot into that directory
* umount /boot
* bind mount new directory to /boot
* update kernel
* umount /boot
* mount normal /boot again
* copy/rsync contents of alternate boot to /boot
 
In the end you have updated kernel...
If you read my posts above, you see that I had some problems and I think that something went wrong when I updated kernel last time.
So there is some risk involved.
 
I am not sure if there is any way to make it possible to update kernel without any such workarounds.

Thanks actually I am not trying the get sound to work right now - I would like to understand why I does not function as it is supposed to, though ...

and dont forget to raise the volume with
alsamixer

 
and save the setting with
alsactl store

"current" on an OPi zero also seems to be missing analog audio at this time - so this is not specific to this board.
 

Hmmm. I dont use sshfs - but samba/cifs and I copied
-rwxrwxrwx 1 root root 1031158598 Nov 12  2015  Starfighter.mp4
from my video-share
[ 6151.533916] CIFS: Attempting to mount //192.168.6.xxx/video
without any errors to the local sdcard.
 
I did compile today the following current version:
Armbian Buster with Linux 5.3.13-meson64 package bsp-kernel[19.11.3] u-boot[19.11.3] dtb[19.11.3] firmware[19.11.3] config[19.11.3] branch[current]  

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