Jump to content

Start looking at 5.3.y


Recommended Posts

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):~#

 

OPi_R1_NAS_Hat.jpg

Link to comment
Share on other sites

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):~#

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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]

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 :lol:

 

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

Link to comment
Share on other sites

34 minutes ago, Werner said:

Yeah....kind of :lol:

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 MHz
available 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 -u
System diagnosis information will now be uploaded to http://ix.io/1VYD

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 GHz
idle:

  cpufreq stats: 480 MHz:95.51%, 648 MHz:0.15%, 816 MHz:0.70%, 960 MHz:0.01%, 1.01 GHz:3.63%  (142)
 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines