guidol Posted August 16, 2019 Posted August 16, 2019 2 hours ago, martinayotte said: @guidol here is the new commit for 8189es : https://github.com/armbian/build/commit/7ab8d6288d55f634bafda5de5beb105f61d4163d I will compile new image on my side as soon as current 5.2.y image is completed (I don't want to abort it)... Great Job @martinayotte ! I did a new compile with 5.3 - and no exception anymore AND restart does work (also while using the NAS-Hat for the OPi Zero on the OPi R1 ) login as: root root@192.168.6.101's password: ___ ____ _ ____ _ / _ \| _ \(_) | _ \/ | | | | | |_) | | | |_) | | | |_| | __/| | | _ <| | \___/|_| |_| |_| \_\_| Welcome to Debian Buster with Armbian Linux 5.3.0-rc3-sunxi package bsp-kernel[5.94] u-boot[5.94] dtb[5.94] firmware[5.94] config[5.94] System load: 0.72 0.26 0.09 Up time: 1 min Memory usage: 32 % of 238MB IP: 192.168.6.101 CPU temp: 46°C Usage of /: 7% of 15G Last login: Fri Aug 16 23:42:39 2019 from 192.168.6.17 root@opi-r1(192.168.6.101):~# 2
martinayotte Posted August 16, 2019 Author Posted August 16, 2019 1 minute ago, guidol said: Great Job @martinayotte ! Thanks ! ... And the WiFi 8189es is now working ... 1
guidol Posted August 17, 2019 Posted August 17, 2019 Does work fine on NanoPi Neo Core2 System diagnosis information will now be uploaded to http://ix.io/1S0E login as: root root@192.168.6.21's password: _ _ ____ _ _ _ ____ ____ | \ | | _ \(_) | \ | | ___ ___ / ___|___ _ __ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ | | / _ \| '__/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | | |__| (_) | | | __/ / __/ |_| \_|_| |_| |_| \_|\___|\___/ \____\___/|_| \___| |_____| Welcome to Debian Buster with Armbian Linux 5.3.0-rc3-sunxi64 package bsp-kernel[5.94] u-boot[5.94] dtb[5.94] firmware[5.94] config[5.94] System load: 0.05 0.12 0.16 Up time: 15 min Local users: 2 Memory usage: 10 % of 989MB IP: 192.168.6.21 CPU temp: 35°C Usage of /: 19% of 7.1G Last login: Sat Aug 17 16:18:07 2019 from 192.168.6.17 root@npi-neo-core2(192.168.6.21):~#
martinayotte Posted August 17, 2019 Author Posted August 17, 2019 Tested on forgotten boards in first AllWinner's garden Tour : nanopiduo2, nanopineo2, nanopim1plus2 and bananapim2plus ... 3
5kft Posted August 18, 2019 Posted August 18, 2019 For the sake of completeness - I've been running 5.3.0-rc3 on one of my nanopineoplus2s for a few days now and it has been working great! Nice work!!
Werner Posted September 2, 2019 Posted September 2, 2019 Megous 5.3 branch has been pushed from rc3 to rc6 and it seems like we have a regression somewhere. Did not have a chance to look further yet. == kernel == arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address f ormat error, expected "0" arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address f ormat error, expected "0" arch/arm64/boot/dts/allwinner/overlay/sun50i-h5-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address fo rmat error, expected "0" arch/arm64/boot/dts/allwinner/overlay/sun50i-h5-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address fo rmat error, expected "0" arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi:200.20-210.5: ERROR (duplicate_label): /soc/ths@1c25000: Duplicate label 'ths' on /soc/ths@1c25000 and /soc/ thermal-sensor@1c25000 ERROR: Input tree has errors, aborting (use -f to force output) make[2]: *** [arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus.dtb] Error 2 make[2]: *** Waiting for unfinished jobs.... arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi:200.20-210.5: ERROR (duplicate_label): /soc/ths@1c25000: Duplicate label 'ths' on /soc/ths@1c25000 and /soc/ thermal-sensor@1c25000 ERROR: Input tree has errors, aborting (use -f to force output) make[2]: *** [arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus-v1.2.dtb] Error 2 arch/arm64/boot/dts/allwinner/overlay/sun50i-h6-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address fo rmat error, expected "0" arch/arm64/boot/dts/allwinner/overlay/sun50i-h6-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address fo rmat error, expected "0" make[1]: *** [arch/arm64/boot/dts/allwinner] Error 2 make: *** [dtbs] Error 2 make: *** Waiting for unfinished jobs....
martinayotte Posted September 2, 2019 Author Posted September 2, 2019 2 hours ago, Werner said: Duplicate label 'ths' That should be pretty easy to fix by commenting or erasing the duplicate in our patch. I will look at it ... EDIT: removal of guilty patches is now done ! https://github.com/armbian/build/commit/b53556a5f1ada29169d08b6a106a01f87d763774 2
Werner Posted September 3, 2019 Posted September 3, 2019 Awesome. Starting a new build round right now
guidol Posted September 3, 2019 Posted September 3, 2019 Compiled fresh version with rc6 for a OPi PC2 - but why happend the following while apt upgrade? Starting apt-get upgrade ================================================================================================ Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done update-initramfs: Deleting /boot/initrd.img-5.3.0-rc6-sunxi64 Removing obsolete file uInitrd-5.3.0-rc6-sunxi64 Unpacking linux-image-dev-sunxi64 (5.95) over (5.95) ... Setting up linux-dtb-dev-sunxi64 (5.95) ... Setting up linux-image-dev-sunxi64 (5.95) ... update-initramfs: Generating /boot/initrd.img-5.3.0-rc3-sunxi64 root@opi-pc2(192.168.6.95):~# uname -a Linux opi-pc2 5.3.0-rc3-sunxi64 #5.95 SMP Sun Sep 1 00:42:13 CEST 2019 aarch64 GNU/Linux package bsp-kernel[5.95] u-boot[5.95] dtb[5.95] firmware[5.95] config[5.95]
guidol Posted September 6, 2019 Posted September 6, 2019 On 9/3/2019 at 11:16 PM, guidol said: update-initramfs: Deleting /boot/initrd.img-5.3.0-rc6-sunxi64 update-initramfs: Generating /boot/initrd.img-5.3.0-rc3-sunxi64 Linux opi-pc2 5.3.0-rc3-sunxi64 #5.95 SMP Sun Sep 1 00:42:13 CEST 2019 aarch64 GNU/Linux Linux 5.3.0-rc6-sunxi has now arrived via apt upgrade after rc6 was before deleted and replaced with rc3
Werner Posted September 6, 2019 Posted September 6, 2019 I always freeze firmware updates when using custom build kernel images on my boards to avoid issues like this. 1
guidol Posted September 8, 2019 Posted September 8, 2019 On 9/6/2019 at 2:57 PM, Werner said: I always freeze firmware updates 5.3 does "freeze" my Orange Pi One Debian Buster with Armbian Linux 5.3.0-rc6-sunxi package bsp-kernel[5.96] u-boot[5.95] dtb[5.96] firmware[5.95] config[5.95] root@opi-one(192.168.6.114):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:13:20: 1008MHz 0.00 2% 0% 1% 0% 0% 0% -209935°C 0/4 16:13:25: 480MHz 0.00 0% 0% 0% 0% 0% 0% -210177°C 0/4 16:13:30: 480MHz 0.07 0% 0% 0% 0% 0% 0% -208967°C 0/4 16:13:35: 480MHz 0.07 0% 0% 0% 0% 0% 0% -210540°C 0/4
Werner Posted September 8, 2019 Posted September 8, 2019 28 minutes ago, guidol said: 5.3 does "freeze" my Orange Pi One Debian Buster with Armbian Linux 5.3.0-rc6-sunxi package bsp-kernel[5.96] u-boot[5.95] dtb[5.96] firmware[5.95] config[5.95] root@opi-one(192.168.6.114):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:13:20: 1008MHz 0.00 2% 0% 1% 0% 0% 0% -209935°C 0/4 16:13:25: 480MHz 0.00 0% 0% 0% 0% 0% 0% -210177°C 0/4 16:13:30: 480MHz 0.07 0% 0% 0% 0% 0% 0% -208967°C 0/4 16:13:35: 480MHz 0.07 0% 0% 0% 0% 0% 0% -210540°C 0/4 Yeah....kind of root@honeypot:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 13:47:48: 1008MHz 0.21 3% 0% 3% 0% 0% 0% 33.5°C 0/6^C root@honeypot:~# uname -a Linux honeypot 5.3.0-rc3-sunxi #5.94 SMP Sat Aug 17 13:17:44 UTC 2019 armv7l GNU/Linux Interesting. RC3 seems to be okay
guidol Posted September 8, 2019 Posted September 8, 2019 34 minutes ago, Werner said: Yeah....kind of Interesting. RC3 seems to be okay RC7 with full armbian 5.96 .debs also has these freezing temperatures on the OPi One: Debian Buster with Armbian Linux 5.3.0-rc7-sunxi package bsp-kernel[5.96] u-boot[5.96] dtb[5.96] firmware[5.96] config[5.96] root@opi-one(192.168.6.114):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 17:21:49: 1008MHz 0.63 19% 10% 8% 0% 0% 0% -208241°C 0/4 17:21:54: 480MHz 0.58 0% 0% 0% 0% 0% 0% -209451°C 0/4 17:21:59: 480MHz 0.53 0% 0% 0% 0% 0% 0% -208846°C 0/4 17:22:04: 480MHz 0.49 0% 0% 0% 0% 0% 0% -207394°C 0/4
guidol Posted September 13, 2019 Posted September 13, 2019 Its the first time that I did see a date after the package version for armbian-packages after a apt upgrade Welcome to Debian Buster with Armbian Linux 5.3.0-rc8-sunxi package bsp-kernel[5.96.190913] u-boot[5.91] dtb[5.96.190913] firmware[5.95] config[5.95] Temperature looks "OK" for a OPi Zero with 72 degree... With that kernel and DTB the temperature is working, but this OPi Zero has been updated since serveral armbian-versions. The problem with these "freeze"-temperatures I did see mainly on new installed H3/H5 devices where a freshly compiled image has been installed... [EDIT] these .190913 packages seem to fix the "freeze"-temperatures After the OPi Zero I did update my OPi One and now I got real temperatures again Welcome to Debian Buster with Armbian Linux 5.3.0-rc8-sunxi package bsp-kernel[5.96.190913] u-boot[5.96] dtb[5.96.190913] firmware[5.96] config[5.96] root@opi-one(192.168.6.114):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 21:04:26: 1008MHz 0.24 16% 8% 6% 0% 0% 0% 54.1°C 0/4 21:04:32: 480MHz 0.22 0% 0% 0% 0% 0% 0% 53.9°C 0/4 21:04:37: 480MHz 0.20 1% 0% 0% 0% 0% 0% 52.7°C 0/4
vlad59 Posted September 16, 2019 Posted September 16, 2019 Hi, I just updated my pine64 1Gb today (so 190916), it restarted perfectly with 5.3.0 kernel but I lost eth0 with `no phy at addr -1` in dmesg (wlan0 still works fine). Anybody can confirm ? I remember reading about this on irc about 5.3 and pine64 some weeks ago , I'll try to find it again.
vlad59 Posted September 17, 2019 Posted September 17, 2019 I rebuilt a full image this morning and I still have no wired network. I went back to kernel 4.19.X. I'll spend some time tonight to compare the device trees between 5.2 and 5.3. 1
Igor Posted September 17, 2019 Posted September 17, 2019 4 hours ago, vlad59 said: I rebuilt a full image this morning and I still have no wired network. I went back to kernel 4.19.X. I'll spend some time tonight to compare the device trees between 5.2 and 5.3. Don't have Pine64 but Bananapi M64 works well http://ix.io/1VAi
martinayotte Posted September 17, 2019 Author Posted September 17, 2019 My Pine A64-DB-2G-Rev B is currently running 5.3.0-rc3 and eth0 is working fine. (I don't see any "no phy at addr -1" error in "dmesg")
vlad59 Posted September 18, 2019 Posted September 18, 2019 That's strange indeed, I'll try a new build in a few days (it's currently building and uploading new arm64 docker images 24/7) It was perfectly working with a dev build between the end of july and the beginning of august. I had many problem with date jump in 2114 so I tried updating yesterday (apt-get update && upgrade) and had the problem with eth0. I then tried a full install and I had the same problem. As I said I still have a few days of work for the pine64 and I'll retry a new build
jock Posted September 19, 2019 Posted September 19, 2019 Hello, I managed to bump the rockchip-dev kernel to 5.3.y on my fork. After removing a couple of redundant patches and updating two or three of them I'm able to compile with no problems. The new kernel also boots fine on my rk3288. Don't know if anyone is already working on this (maybe @Igor or @TonyMac32), if my work can ease someone's else fatigue I can make a merge request from my repo to main armbian repo for code review (the single commit is here) documenting the steps I did. 1
guidol Posted September 20, 2019 Posted September 20, 2019 I got dev Debian Buster with Armbian Linux 5.3.0-sunxi64 package bsp-kernel[5.97.190919] u-boot[5.97] dtb[5.97.190919] firmware[5.97] config[5.97] on my OrangePi Zero Plus2 H5, but got only (via cpufreq-info) hardware limits: 480 MHz - 816 MHzavailable frequency steps: 480 MHz, 648 MHz, 816 MHz the .dtb/.dts also include 960, 1008, 1104, 1200, 196 and 1368 Mhz entrys for all CPUs / opp_table0 / operating-points-v2 : Spoiler opp-960000000 { opp-hz = < 0x00 0x39387000 >; opp-microvolt = < 0x124f80 0x124f80 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1008000000 { opp-hz = < 0x00 0x3c14dc00 >; opp-microvolt = < 0x124f80 0x124f80 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1104000000 { opp-hz = < 0x00 0x41cdb400 >; opp-microvolt = < 0x142440 0x142440 0x142440 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1200000000 { opp-hz = < 0x00 0x47868c00 >; opp-microvolt = < 0x142440 0x142440 0x142440 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1296000000 { opp-hz = < 0x00 0x4d3f6400 >; opp-microvolt = < 0x147260 0x147260 0x147260 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1368000000 { opp-hz = < 0x00 0x518a0600 >; opp-microvolt = < 0x155cc0 0x155cc0 0x155cc0 >; clock-latency-ns = < 0x3b9b0 >; }; They doesnt seem to be deactivated- so does anyone got a clue why they arent available? [EDIT] activating cpu-clock-1.3GHz-1.3v and gpio-regulator-1.3v didnt help, because then my OPi Zero Plus H5 doenst boot anymore. Had to restore the eMMC from a bootable/configured SDCard. On other Orange Pi SBCs we could use also 960 and 1008 Mhz without a switch to other voltages with additional regulators. Isnt this SBC build good as other OPi SBCs? 480 - 648 MHz : opp-microvolt = < 0xfde80 0xfde80 0x13d620 >; 816 MHz : opp-microvolt = < 0x10c8e0 0x10c8e0 0x13d620 >; 960 - 1008 MHz : opp-microvolt = < 0x124f80 0x124f80 0x13d620 >; 1104 - 1200 Mhz : opp-microvolt = < 0x142440 0x142440 0x142440 >; 1296 Mhz : opp-microvolt = < 0x147260 0x147260 0x147260 >; 1368 MHz : opp-microvolt = < 0x155cc0 0x155cc0 0x155cc0 >; armbianmonitor -uSystem diagnosis information will now be uploaded to http://ix.io/1VYD
5kft Posted September 20, 2019 Posted September 20, 2019 Hi @guidol, my guess is that you are seeing the crash at boot on your board because of the default hardware limitation in the Plus2. Using the default opp table you can run an Plus2 at higher clock rates than 816MHz only if you've added the missing MOSFET part (see thread at https://forum.armbian.com/topic/6866-orange-pi-zero-plus2-h5-hardware-oddity-in-vdd_cpux-power-circuit/). The default opp table is requiring 1.2v for operation at 960MHz+, and the regulator output for an unmodified OPi Plus2 is 1.1v. It might be possible to reliably push the H5 to 1008MHz at 1.1v, but the default table is more conservative (not sure why). FWIW I run all my boards at higher speeds, (including my NEO Core2s at 1.4GHz - see https://github.com/5kft/nanopi-misc/blob/master/nanopi-neo-core2-1.4GHz/nanopi-neo-core2-1.4GHz.dts). 1
guidol Posted September 20, 2019 Posted September 20, 2019 1 hour ago, 5kft said: It might be possible to reliably push the H5 to 1008MHz at 1.1v, but the default table is more conservative (not sure why). @5kft I edited my table a bit less conservative - setting also 960 and 1008Mhz to 1.1V. Spoiler opp-816000000 { opp-hz = < 0x00 0x30a32c00 >; opp-microvolt = < 0x10c8e0 0x10c8e0 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-960000000 { opp-hz = < 0x00 0x39387000 >; opp-microvolt = < 0x10c8e0 0x10c8e0 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; opp-1008000000 { opp-hz = < 0x00 0x3c14dc00 >; opp-microvolt = < 0x10c8e0 0x10c8e0 0x13d620 >; clock-latency-ns = < 0x3b9b0 >; }; and the OPi Zero Plus2 H5 "does work" - i dont know how good, but for testing reasons it seems to be OK for me hardware limits: 480 MHz - 1.01 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHzidle: cpufreq stats: 480 MHz:95.51%, 648 MHz:0.15%, 816 MHz:0.70%, 960 MHz:0.01%, 1.01 GHz:3.63% (142) 1
5kft Posted September 20, 2019 Posted September 20, 2019 32 minutes ago, guidol said: @5kft I edited my table a bit less conservative - setting also 960 and 1008Mhz to 1.1V. Nice!!
vlad59 Posted September 22, 2019 Posted September 22, 2019 @martinayotte@Igor I finally found where I read about problem on some pine64+ for ethernet, it was in Librelec forums and Jernej added a patch fixing that a few weeks ago : https://github.com/LibreELEC/LibreELEC.tv/blob/9d68e4ba191d7b0bd319e1e254610917e69526e0/projects/Allwinner/devices/A64/patches/linux/03_pine64_plus_ethernet_fixes.patch The last part of the patch is interesting (= could fix my problem) and was queued for kernel 5.4 : https://lkml.org/lkml/2019/9/18/714 Grepping for `config-magic-for-pine64` or `regulator-enable-ramp-delay = <100000>` inside armbian build source return nothing so I guess that can be it. I'll try a dev build with this patch tomorrow and report here either way. 2
vlad59 Posted September 24, 2019 Posted September 24, 2019 A little late but it's working fine : root@pine64:~# uname -a Linux pine64 5.3.1-sunxi64 #5.97 SMP Mon Sep 23 18:28:48 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux root@pine64:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes root@pine64:~# for now my patch is in `userpatches/kernel/sunxi-dev/`. If I understand correctly I just have to move the patch to `patch/kernel/sunxi-dev/` and make a PR, right ?
Igor Posted September 24, 2019 Posted September 24, 2019 1 hour ago, vlad59 said: for now my patch is in `userpatches/kernel/sunxi-dev/`. If I understand correctly I just have to move the patch to `patch/kernel/sunxi-dev/` and make a PR, right ? Yes.
Recommended Posts