guidol

why didnt you use the install instructions from the github page?
or do use a newer kernel?
for which board you will use the driver?
whats the model name of you usb device?

Wherever you are around the world I wish you all a happy new year!
May 2020 bring all the best for you, your family and your friends. Don't party too hard

I spent some time investigating this, I think it is a hardware/production issue. There is a calibration value in the eFuse, set during chip production. That value is currently not used in mainline, but in the affected hardware, it does not correct the offset anyway. In my good boards, it only caused a small change that looks reasonable. But the problematic boards are off by 20-30 degrees.
I wrote a small python3 script to access the hardware directly, it will print a dump of the THS registers, interpret the raw value into a temperature with all the formulas that were published one time or another, and apply the eFuse factory-calibration value. To see the effect, wait a few seconds and run again.
import time import os import mmap from sys import exit dev_mem_rw = os.open("/dev/mem", os.O_RDWR | os.O_SYNC) #send reset pulse to the THS subsystem if False: ccu_base = 0x01C20000 mmap_base = int(ccu_base/mmap.PAGESIZE)*mmap.PAGESIZE ccu_registers = mmap.mmap(dev_mem_rw, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE, offset=mmap_base) ccu_offset = ccu_base - mmap_base rst_reg3 = ccu_offset + 0x2D0 # bus soft rst reg3 current_state = ccu_registers[rst_reg3+1] ccu_registers[rst_reg3+1] = current_state & 0xFE ccu_registers[rst_reg3+1] = current_state print("Reset THS peripheral") ths_base = 0x01C25000 mmap_base = int(ths_base/mmap.PAGESIZE)*mmap.PAGESIZE ths_offset = ths_base - mmap_base ths_ctrl_reg0 = ths_offset + 0x00 # ctrl reg0 ths_ctrl_reg1 = ths_offset + 0x04 # ctrl reg1 ths_cdat_reg = ths_offset + 0x14 # ADC cal data ths_ctrl_reg2 = ths_offset + 0x40 # ctrl reg2 ths_int_ctrl = ths_offset + 0x44 # interrupt ctrl ths_stat_reg = ths_offset + 0x48 # status reg ths_alarm_ctrl = ths_offset + 0x50 # alarm ctrl ths_shdn_ctrl = ths_offset + 0x60 # shutdown ctrl ths_filter_ctrl = ths_offset + 0x70 # filter reg ths_cdata_reg = ths_offset + 0x74 # calibration data register ths_data_reg = ths_offset + 0x80 # thermal sensor data register ths_registers = mmap.mmap(dev_mem_rw, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE, offset=mmap_base) regs = { "ctrl0": ths_ctrl_reg0, "ctrl1": ths_ctrl_reg1, "cdat": ths_cdat_reg, "ctrl2": ths_ctrl_reg2, "int_ctrl": ths_int_ctrl, "stat": ths_stat_reg, "alarm": ths_alarm_ctrl, "shdn": ths_shdn_ctrl, "filter": ths_filter_ctrl, "cdata": ths_cdata_reg, "data": ths_data_reg } def dmp(): for name, r in regs.items(): b = ths_registers[r:r+4] x = int.from_bytes(b, byteorder='little') print(f"{name:10}{b[3]:02X} {b[2]:02X} {b[1]:02X} {b[0]:02X}\t{x}") adc_data = ths_registers[ths_data_reg:ths_data_reg+2] adc_value = int.from_bytes(adc_data, byteorder='little') print(f"ADC value: {adc_value}") t_ds = (adc_value-2794)/(-14.882) print(f"H2/H3 datasheet formula: {t_ds:.1f}C") t_h5 = -0.1191 * adc_value + 223 print(f"H5 datasheet formula: {t_h5:.1f}C") t_bsp1 = -0.1180 * adc_value + 256 print(f"BSP v4.9 formula: {t_bsp1:.1f}C") t_bsp2 = -0.1211 * adc_value + 217 print(f"mainline & xunlong kernel: {t_bsp2:.1f}C") with open("/sys/devices/virtual/thermal/thermal_zone0/temp", "r") as f: t_kernel = int(f.read()) / 1000.0 print(f"Running Kernel: {t_kernel:.1f}C") print("\nTHS Registers:") dmp() cal_value = int.from_bytes(ths_registers[ths_cdata_reg:ths_cdata_reg+4], "little") print(f"\nCurrent THS calibration value: 0x{cal_value:3x}") with open("/sys/bus/nvmem/devices/sunxi-sid0/nvmem", "rb") as f: f.seek(0x34) fuse_cal_value = int.from_bytes(f.read(4), "little") print(f"EFuse THS calibration value: 0x{fuse_cal_value:3x}") if cal_value != fuse_cal_value: ths_registers[ths_cdata_reg:ths_cdata_reg+4] = fuse_cal_value.to_bytes(4, "little") delta = (fuse_cal_value-cal_value)*0.1211 print(f"Applied calibration value from EFuse, this causes a change of {delta:.1f} deg C") #ths_registers[ths_ctrl_reg0:ths_ctrl_reg0+4] = (0xFF).to_bytes(4, "little") # 16x averaging #ths_registers[ths_filter_ctrl:ths_filter_ctrl+4] = (0x07).to_bytes(4, "little") # ADC calibration, seems to do nothing? #ths_registers[ths_ctrl_reg1:ths_ctrl_reg1+4] = ((1 << 17) | (0 << 20)| (0 << 21)).to_bytes(4, "little") # stop #ths_registers[ths_ctrl_reg2:ths_ctrl_reg2+4] = (4128769-1).to_bytes(4, "little") # start #ths_registers[ths_ctrl_reg2:ths_ctrl_reg2+4] = (4128769).to_bytes(4, "little") You'll have to run it as root because it accesses the memory directly.
H2+ datasheet: http://wiki.friendlyarm.com/wiki/images/0/08/Allwinner_H2%2B_Datasheet_V1.2.pdf (THS is on page 255)
I left in some stuff in the script to control the hardware, if anyone wants to play with it without messing with the kernel

Good board, SoC temperature measured with thermocouple at 46°C: 
ADC value: 1414 H2/H3 datasheet formula: 92.7C H5 datasheet formula: 54.6C BSP v4.9 formula: 89.1C mainline & xunlong kernel: 45.8C Running Kernel: 45.6C THS Registers: ctrl0 00 00 00 FF 255 ctrl1 00 00 00 00 0 cdat 00 00 00 00 0 ctrl2 00 3F 00 01 4128769 int_ctrl 00 00 71 00 28928 stat 00 00 00 00 0 alarm 05 A0 06 84 94373508 shdn 04 E9 00 00 82378752 filter 00 00 00 06 6 cdata 00 00 08 00 2048 data 00 00 05 86 1414 Current THS calibration value: 0x800 EFuse THS calibration value: 0x817 Applied calibration value from EFuse, this causes a change of 2.8 deg C Affected LTS board, SoC temperature on top: 47°C:
ADC value: 1626 H2/H3 datasheet formula: 78.5C H5 datasheet formula: 29.3C BSP v4.9 formula: 64.1C mainline & xunlong kernel: 20.1C Running Kernel: 20.0C THS Registers: ctrl0 00 00 00 FF 255 ctrl1 00 00 00 00 0 cdat 00 00 00 00 0 ctrl2 00 3F 00 01 4128769 int_ctrl 00 00 71 00 28928 stat 00 00 00 00 0 alarm 05 A0 06 84 94373508 shdn 04 E9 00 00 82378752 filter 00 00 00 06 6 cdata 00 00 08 00 2048 data 00 00 06 5A 1626 Current THS calibration value: 0x800 EFuse THS calibration value: 0x7fb Applied calibration value from EFuse, this causes a change of -0.6 deg C  

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