Helios64 - Armbian 23.08 Bookworm issues (solved)

[ebin-dev]

A stable Armbian Bookworm configuration for your Helios64 is provided here (solved).

*************************************************************************

 

Recently a new Armbian 23.08.1 Bookworm image with linux-6.1.50 was made available for Helios64 on its download page (see here) - which is as such great 😀.

 

Everything  starts up nicely, but unlike the previous Bookworm 23.05 image, the current one has an issue with accessing USB devices. In the boot process the following error occurs: 

 

# cat /var/log/syslog | grep error
2023-09-07T12:31:05.671598+02:00 helios64 kernel: [    2.537009] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core
2023-09-07T12:31:05.671602+02:00 helios64 kernel: [    2.537107] dwc3: probe of fe900000.usb failed with error -110

 

No USB device could be accessed.

 

As this seems to be related to the realtek driver r8152, I compiled and installed the current version of that driver (see below) and after that the USB devices were accessible.

 

# compile and install the current realtek driver
git clone https://github.com/wget/realtek-r8152-linux.git
cd realtek-r8152-linux...
make 
sudo make install

Edited May 15 by ebin-dev

[ebin-dev]

For linux versions higher than 5.12, the Armbian build system does not replace the realtek driver r8152 but it uses an aged realtek driver from the linux source tree.

So if someone intends to build from sources at home, the realtek r8152 driver in the linux source tree must be replaced by a newer version, otherwise USB devices will not be accessible to helios64.

 

It follows that all fully automated builds with the current Armbian build system building linux kernel versions higher than 5.12 will not support USB devices on helios64 anymore (until that is fixed).

 

The good news is that there is an image available for download were the USB issue was fixed: Armbian_23.5.4_Helios64_bookworm_current_6.1.36.img (here)

Edited September 8, 2023 by ebin-dev

[mrjpaxton]

I don't know if 23.8 is the same as 23.08. This is where the numbering gets confusing, and I don't know why they did that...

 

If you mean "Colobus" which was released on Sep 1st, I'm not entirely on that version right now. I didn't "dist-upgrade" the rest of the 23.08 packages. I sort of am, but here's what I mean.

 

I have these packages held back:

armbian-bsp-cli-helios64-current
armbian-config
armbian-firmware
armbian-plymouth-theme
linux-dtb-current-rockchip64
linux-image-current-rockchip64
linux-u-boot-helios64-current

 

My version of these is apparently at "23.08.0-trunk". I can verify that my system is still working with USB and everything. Sorry to hear you're having this problem, but thanks for telling us, because I was also getting concerned if I should upgrade them or not, but I think I will hold off for a bit. The newest one available is actually 23.8.1. Have you tried that specific one, yet?

Edited September 9, 2023 by mrjpaxton

[ebin-dev]

It does not matter if you refer to the current Armbian version as 23.8 as indicated on the helios64 download page or to 23.08 as indicated on the welcome screen. And it does not matter if it is 23.8.1.

 

The important bit is that any current linux kernel or image (fully automatically) built by the Armbian build system does not provide any USB support for your Helios64 for linux kernel versions higher than 5.12. You could verify that yourself by upgrading your backup sd to the current kernel versions.

 

Unless you have access to the original linux kernel debs you would have to reinstall your system entirely from scratch.

 

You should therefore not upgrade your system to any current linux kernel produced by the Armbian build system until the linux rtl8152 driver is replaced for kernel versions higher than 5.12 (in this code). For the time being you could disable Armbian updates entirely (and still receive debian updates):

 

cat /etc/apt/sources.list.d/armbian.list 

# deb http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop

Edited September 9, 2023 by ebin-dev

[alchemist]

Hi, I also have dwc3 usb issues since kernel 6.4.12 (mainstream vanilla).

It seems there is a regression. a patch is recently in discussion: https://lore.kernel.org/lkml/ba6285cb-f9ff-8047-ad53-1f4534517b66@synopsys.com/T/
Kernel 6.5 doesnt boot, I will check if I enabled the PCI SATA bridge

 

So, try to keep kernel <= 6.4.11

Edited September 9, 2023 by alchemist

[ebin-dev]

@alchemist Thank you for the hint !

 

The dwc3 usb issue remains even if I compile a more recent realtek-r8152-linux driver into kernel 6.1.52. So the realtek driver does not seem to be the (only) reason for the issue.

 

While compiling the kernel I was informed by the build system that 74 patches need to be rebased and that the rk3399-enable-dwc3-xhci-usb-trb-quirk.patch could not be applied - something has changed. 

 

This is how a system looks like that was not maintained for years ...

 

P.S.: I will therefore currently not upgrade Helios64 (hosting all my data) to Armbian bookworm 23.05.4-6.1.36. It uses the linux-tree rtl8152 driver and needs proper testing first, in particular network performance (1Gbit/s and 2.5Gbit/s interfaces), reliability of accessing emmc and stability.

Edited September 10, 2023 by ebin-dev

[alchemist]

Hi!,

 

I tried kernel 6.5.2 vanilla

make oldconfig, + enable JMicron PATA driver

 

USB is working but I don't know if dwc3 is by chance reset or due to the fix...

EDIT: dwc3 reset still doesn't work, waiting for the fix

 

So yes, please freeze your kernels

Edited September 10, 2023 by alchemist

[mrjpaxton]

Ahh, okay. So it only has to do with the kernel and what version it is. Got it.

 

Well, I have an eMMC install, so I back up root FS and `/boot` on an SD card every month, or when making changes, since putting the backups on the NAS itself... won't work out very well unless it's also on the entire NAS backup disk I have, too.

 

But anyway, my kernel is "6.1.36-rockchip64", and just this week in early September I was able to do a full backup of my NAS array with Rsync on a USB 3 attached HDD just fine with zero problems on that kernel (I'm using the back USB ports, but that probably won't matter). Have you all also tested on both SD card and eMMC installs?

 

So wait, I'm guessing this "dwc3" driver thing has to do with some other problem besides specifically USB storage devices. Maybe there are some devices it will work with, and others that it wont?

Edited September 14, 2023 by mrjpaxton

[ebin-dev]

Linux 6.1.36 is not affected by the dwc3 usb issue. The braking changes made it into the kernel after that.

 

Thank you for confirming that you had no issues accessing emmc with that kernel - your system is even running from there.

 

Your linux kernel uses the linux-tree version of the realtek driver r8152. It is based on an old version of the manufacturer and we have to test if it is reliable when used to drive the 2.5G interface.

 

Once the dwc3 usb issue is resolved (upstream), I intend to build several versions of the linux kernel with different rtl8152 drivers so that performance and reliability can be compared.

Edited September 30, 2023 by ebin-dev

[amurchick]

Цитата

# cat /var/log/syslog | grep error 2023-09-07T12:31:05.671598+02:00 
[ 2.537009] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core
[ 2.537107] dwc3: probe of fe900000.usb failed with error -110

 

No USB device could be accessed.

@ebin-dev @alchemist
Current Armbian Build repo build images with kernel 6.5.4.
And kernel still have this issue (

[  +0.000000] Linux version 6.5.3-edge-rockchip64 (armbian@next) (aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #2 SMP PREEMPT Wed Sep 13 14:53:58 +07 2023
[  +0.013683] phy phy-ff800000.phy.8: phy poweron failed --> -110
[  +0.000616] dwc3 fe900000.usb: error -ETIMEDOUT: failed to initialize core
[  +0.000708] dwc3: probe of fe900000.usb failed with error -110

 

[ebin-dev]

On 9/7/2023 at 1:16 PM, ebin-dev said:

# compile and install the current realtek driver
git clone https://github.com/wget/realtek-r8152-linux.git
cd realtek-r8152-linux...
make 
sudo make install

 

You could try the above and let us know if it solves the issue (should work for linux up to 6.4.10+).

Edited October 2, 2023 by ebin-dev

[ebin-dev]

If you intend to switch to bookworm, the image Armbian_23.5.4_Helios64_bookworm_current_6.1.36.img is indeed a good starting point:

 

I have tested the 1G and 2.5G LAN interfaces and they perform well out of the box. On my Helios64, I could not obtain any stability issues with this system using kernel 6.1.36 (I have soldered the cable to the motherboard as suggested on the kobol.io website). 

 

As mentioned above, the dwc3 usb regression ist not jet present in that kernel. So I would advise to use that image if you intend to upgrade to bookworm.

 

However, I could not obtain any matching header files for that kernel version which are necessary if the dkms is needed (on my system by some home automation software).

 

Therefore, I had to compile the current linux kernel 6.1.58 (linux-image, linux-headers, linux-dtb) while applying a patch to solve the dwc3 usb issue (patch is discussed here). 

 

Welcome to Armbian 23.08.0-trunk Bookworm with Linux 6.1.58-current-rockchip64

No end-user support: community creations

System load:   2%           	Up time:       2:48	
Memory usage:  30% of 3.77G  	IP:	       xx.xx.xx.xx
CPU temp:      47°C           	Usage of /:    14% of 58G    	
storage/:      61% of 3.6T   	storage temp:  25°C   

 

All USB devices are working now - also with the current kernel (patched). The driver for the realtek 2.5G interface (mainline version v1.12.13 - 'modinfo r8152') performs well if all the following firmware files are present in /lib/firmware/rtl_nic/  (can be downloaded from here):

 

# ls -la /lib/firmware/rtl_nic/

drwxrwxr-x  2 root root  4096 Oct 18 16:56 .
drwxr-xr-x 27 root root 12288 Oct 16 15:46 ..
-rw-rw-r--  1 root root  3328 Oct 16 15:32 rtl8125b-2.fw
-rw-r--r--  1 root root  1768 Oct 16 15:32 rtl8153a-2.fw
-rw-r--r--  1 root root  1440 Oct 16 15:32 rtl8153a-3.fw
-rw-r--r--  1 root root   712 Oct 16 15:32 rtl8153a-4.fw
-rw-rw-r--  1 root root  1880 Oct 16 15:32 rtl8153b-2.fw
-rw-r--r--  1 root root   832 Oct 16 15:32 rtl8153c-1.fw
-rw-r--r--  1 root root  4024 Oct 16 15:32 rtl8156a-2.fw
-rw-r--r--  1 root root  7256 Oct 16 15:32 rtl8156b-2.fw
-rw-rw-r--  1 root root   976 Oct 16 15:32 rtl8168h-2.fw

# cat /var/log/syslog | grep r8152

2023-10-19T07:01:02.167978+02:00 helios64 kernel: [    6.672719] r8152 2-1.4:1.0: load rtl8156a-2 v2 04/27/23 successfully
2023-10-19T07:01:02.167981+02:00 helios64 kernel: [    6.715222] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add_weight() called with weight 256
2023-10-19T07:01:02.167984+02:00 helios64 kernel: [    6.730968] r8152 2-1.4:1.0 eth0: v1.12.13
2023-10-19T07:01:02.167986+02:00 helios64 kernel: [    6.731167] usbcore: registered new interface driver r8152

 

In order to avoid surprises I have disabled Armbian updates for the time being (debian updates still arrive):

 

cat /etc/apt/sources.list.d/armbian.list

# deb [signed-by=/usr/share/keyrings/armbian.gpg] http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop

 

After a few days of testing I am using this now 'in production' 🙂

 

Edited October 19, 2023 by ebin-dev

[ebin-dev]

dwc3 was patched In the current linux kernel 6.1.59 and the dwc3 error disappeared. All USB devices are accessible again.

 

Now a new Armbian build based on linux 6.1.59 should be pushed to the Helios64 download page.

[alchemist]

the fix is also present in 6.5.8 🙂

DWC3 USB ports are back !

[ebin-dev]

@alchemist USB ports are back - but the 2.5G interface is now unstable: transferring a 2GB file (Speed: 2500Mb/s) is interrupted (r8152 Tx timeout) and the interface is restarted by the watchdog process.

 

Could you test transferring large files through the 2.5G interface set to speed 2500Mb/s ?

 

I switched back to the previous kernel 6.1.58 (patched) - no TX timeouts ...

[alchemist]

I don't use the 2.5Gbps interface, since I have old 100/1000 switches...

[ebin-dev]

Bookworm (with linux 6.1.58 (patched) incl. header files) is now booting from emmc and it is indeed absolutely stable using the standard settings. 

 

To do that I just formatted the emmc partition and transferred the files from sd to emmc using a backup script.

 

/etc/fstab needs the correct UUID of the emmc (displayed by 'blkid') and some folders (i.e. cups, mysql, redis, nginx, ...) may have to be manually created in /var/log with proper access rights.

 

Make a copy of your sd card before, if you prefer armbian-config to do that (boot from emmc - system on emmc) as the bootloader on SD may be negatively affected after that.

 

Will now test different rtl8156 drivers and see if there is any effect on performance and stability of the 2.5G LAN interface for current kernels (>= 6.1.59).

Edited October 24, 2023 by ebin-dev

[alchemist]

Hi!,

 

I finally reverted to 6.1.* kernel series because I have NFS hanging with kernel 6.5.

This series is very stable.

[ebin-dev]

I am on linux kernel 6.1.60 now and both 1G and 2.5G LAN interfaces operate with the maximum expected throughput (about 300 MByte/s on the 2.5G interface) - without any further patches applied. 

 

If you like to test them, you can download the debs (kernel, header, dtb) from here ( install with 'dpkg -i linux*').

 

There is one little glitch: while the heartbeat LED starts to operate, the red LEDs on the front panel briefly light up (sata1 to sata5, bus rescan) and the fans spin up for a few seconds , then turn to normal operation.

 

P.S.: dmesg output attached, 2.5G interface used

The  usb 2-1.4 interface (Realtek USB 10/100/1G/2.5G LAN) is reset 2 times by the driver during boot and it works flawlessly after that. I consider this normal.

bus-scan-delay does not help to get rid of the bus rescan. I tried a delay of 2s:  [    2.832048] rockchip-pcie f8000000.pcie: wait 2000 ms (from device tree) before bus scan

 

dmesg.txt

Edited October 27, 2023 by ebin-dev

[ebin-dev]

There are other driver versions for the realtek r8152 driver. Just out of curiosity I tried version r8152-v2.16.3 and  r8152-v2.17.1. Both drivers crash immediately once a large data transfer is executed at least via the 2.5G interface (r8152 2-1.4:1.0 end1: Tx timeout;  xhci-hcd xhci-hcd.0.auto: bad transfer trb length 16741766 in event trb).

 

It would appear that those two driver versions do not patch the firmware during boot like the mainline driver (r8152 2-1.4:1.0: load rtl8156a-2 v2 04/27/23 successfully).

 

The bottom line is, that we have stable bullseye image with linux-6.1.36 (without header files) and a stable kernel 6.1.60 (with header files) both using the mainline r8152 driver (the required r8152 firmware files have to be in /lib/firmware/rtl_nic ; can be downloaded from here).

 

Linux 6.1.60 has a remaining glitch to be solved, since during boot there is an unnecessary rescan of the bus and the fans spin up for a second.

 

If anyone has a hint that helps to solve this, I would be grateful (dmesg output attached).

 

Cheers

 

P.S. The Armbian images on the Helios64 download page (version Aug. 31, 2023) are still broken, no usb support due to the dwc3 regression.

P.S.': iperf3 measurements between Helios64 (server) and a client through the 2.5G interface 😀:

 

./iperf3 -c 192.168.xx.xx -p 5201             
Connecting to host 192.168.xx.xx, port 5201
[  5] local 192.168.xx.xx port 57314 connected to 192.168.xx.xx port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   275 MBytes  2.31 Gbits/sec                  
[  5]   1.00-2.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   2.00-3.00   sec   281 MBytes  2.36 Gbits/sec                  
[  5]   3.00-4.00   sec   281 MBytes  2.36 Gbits/sec                  
[  5]   4.00-5.00   sec   281 MBytes  2.36 Gbits/sec                  
[  5]   5.00-6.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   6.00-7.00   sec   281 MBytes  2.36 Gbits/sec                  
[  5]   7.00-8.00   sec   278 MBytes  2.34 Gbits/sec                  
[  5]   8.00-9.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   9.00-10.00  sec   281 MBytes  2.36 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  2.73 GBytes  2.35 Gbits/sec                  sender
[  5]   0.00-10.00  sec  2.73 GBytes  2.35 Gbits/sec                  receiver

 

dmesg.txt

Edited October 27, 2023 by ebin-dev

[RlndVt]

FWIW, unknowingly of these issues, I've been updating my helios64 on armbian (23.8.1) peacefully in the background for the past month. I attempted viewing htop and was greeted with a kernel issue. Assuming it was related to the month uptime I went for a reboot.

 

Since then the system crashes (kernel panic) after the network service has started. It seems to be related to the r8152 driver. Is it useful if I post the kernel dump message? I've reverted to my older armbian sd-card. (22.02.1)

 

On 10/27/2023 at 12:35 PM, ebin-dev said:

(the required r8152 firmware files have to be in /lib/firmware/rtl_nic ; can be downloaded from here).

 

Do you mean that I have to manually 'install' the firmware files by copying them to that folder?

 

[ebin-dev]

2 hours ago, RlndVt said:

Do you mean that I have to manually 'install' the firmware files by copying them to that folder?

 

There are alternatives - you can install all the non-free firmware at once using apt.

But yes - you just need to copy the content of the rtl_nic folder downloaded from git.kernel.org to /lib/firmware/rtl_nic in your filesystem (at least the 9 firmware files indicated above).

Edited October 30, 2023 by ebin-dev

[0x349850341010010101010100]

Thank you for this thread and all the work you have been doing. 😍

I had moved house some months ago and for some reason in the new network my helios64 does not come up anymore.

I will use Armbian_23.5.4_Helios64_bookworm_current_6.1.36 for a fresh install as suggested.

[ebin-dev]

9 hours ago, RlndVt said:

Do you mean that I have to manually 'install' the firmware files by copying them to that folder?

 

There is an alternative way to install non-free firmware using apt. But yes - you can copy the content of the rtl_nic folder downloaded from git.kernel.org into /lib/firmware/rtl_nic/.

[ebin-dev]

Linux 6.6 was released yesterday and it is now another option: it boots just fine on Helios64 (also off emmc) and I am using it now instead of 6.1.60.

 

Edit: Download Link: Linux 6.6 debs

 

Edited November 1, 2023 by ebin-dev

[ebin-dev]

On 10/30/2023 at 4:12 PM, 0x349850341010010101010100 said:

I will use Armbian_23.5.4_Helios64_bookworm_current_6.1.36 for a fresh install as suggested.

 

Do not forget to disable the Armbian updates and to copy the firmware files to /lib/firmware/rtl_nic. And thank you too.

[ebin-dev]

On 10/25/2023 at 9:08 AM, alchemist said:

I finally reverted to 6.1.* kernel series because I have NFS hanging with kernel 6.5.

This series is very stable.

 

After two days of testing linux 6.6 seems almost perfect. However, on heavy network loads the 2.5G interface is not really stable yet and is reset several times during operation. It seems that cpu4 is overloaded by the transmission tasks and that those tasks need to be distributed differently between the cpu cores to avoid that.  

 

I switched back again to 6.1.60. 

 

 

[11806.608303] ------------[ cut here ]------------
[11806.608336] NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8180 ms
[11806.608512] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x298/0x2a0
[11806.608566] Modules linked in: xt_comment xt_tcpudp nft_compat nf_tables nfnetlink eq3_char_loop(O) rpi_rf_mod_led(O) dummy_rx8130(O) hb_rf_eth(O) generic_raw_uart(O) sunrpc lz4hc lz4 zram binfmt_misc cp210x usbserial hantro_vpu rockchip_vdec(C) rockchip_rga snd_soc_hdmi_codec snd_soc_rockchip_i2s v4l2_vp9 leds_pwm panfrost v4l2_h264 snd_soc_core videobuf2_dma_contig gpio_charger pwm_fan videobuf2_dma_sg v4l2_mem2mem snd_compress gpu_sched videobuf2_memops snd_pcm_dmaengine drm_shmem_helper rk_crypto snd_pcm videobuf2_v4l2 snd_timer videodev snd videobuf2_common mc soundcore cpufreq_dt gpio_beeper sg cfg80211 rfkill ledtrig_netdev lm75 dm_mod ip_tables x_tables autofs4 efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod cdc_ncm cdc_ether usbnet realtek r8152 dwmac_rk fusb302 tcpm stmmac_platform stmmac typec pcs_xpcs adc_keys
[11806.609441] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C O       6.6.0-edge-rockchip64 #1
[11806.609468] Hardware name: Helios64 (DT)
[11806.609483] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[11806.609511] pc : dev_watchdog+0x298/0x2a0
[11806.609543] lr : dev_watchdog+0x298/0x2a0
[11806.609573] sp : ffff800080003dc0
[11806.609586] x29: ffff800080003dc0 x28: ffff800080ea70d4 x27: ffff800080003ec0
[11806.609634] x26: ffff800081818008 x25: 0000000000001ff4 x24: ffff800081b67000
[11806.609680] x23: 0000000000000000 x22: ffff0000075f341c x21: ffff0000075f3000
[11806.609725] x20: ffff000007680c00 x19: ffff0000075f34c8 x18: ffffffffffffffff
[11806.609771] x17: 6d20303831382074 x16: 756f2064656d6974 x15: 2030206575657571
[11806.609816] x14: 2074696d736e6172 x13: 0000000000000304 x12: 00000000ffffffea
[11806.609862] x11: 00000000ffffefff x10: ffff800081be5f08 x9 : ffff800081b8deb0
[11806.609907] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8
[11806.609951] x5 : 0000000000000fff x4 : 0000000000000000 x3 : 0000000000000027
[11806.609994] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800081b74680
[11806.610038] Call trace:
[11806.610052]  dev_watchdog+0x298/0x2a0
[11806.610083]  call_timer_fn+0x34/0x1bc
[11806.610113]  __run_timers.part.0+0x228/0x2ec
[11806.610141]  run_timer_softirq+0x48/0x84
[11806.610167]  __do_softirq+0x150/0x3e4
[11806.610191]  ____do_softirq+0x10/0x1c
[11806.610217]  call_on_irq_stack+0x24/0x4c
[11806.610242]  do_softirq_own_stack+0x1c/0x28
[11806.610268]  irq_exit_rcu+0xb4/0xe4
[11806.610298]  el1_interrupt+0x38/0x68
[11806.610326]  el1h_64_irq_handler+0x18/0x24
[11806.610354]  el1h_64_irq+0x64/0x68
[11806.610375]  default_idle_call+0x38/0x16c
[11806.610407]  do_idle+0x20c/0x264
[11806.610435]  cpu_startup_entry+0x34/0x3c
[11806.610461]  kernel_init+0x0/0x1e0
[11806.610491]  arch_post_acpi_subsys_init+0x0/0x8
[11806.610524]  start_kernel+0x734/0x950
[11806.610554]  __primary_switched+0xb4/0xbc
[11806.610582] ---[ end trace 0000000000000000 ]---
[11806.610611] r8152 2-1.4:1.0 end1: Tx timeout
[11806.612779] r8152 2-1.4:1.0 end1: Tx status -2
[11806.612997] r8152 2-1.4:1.0 end1: Tx status -2
[11806.613129] r8152 2-1.4:1.0 end1: Tx status -2
[11806.613246] r8152 2-1.4:1.0 end1: Tx status -2

 

[ebin-dev]

This is an issue that started with Armbian bookworm (not present in bullseye):

 

Updating the bootloader on emmc and sd with the current (mainlined) bootloader provided by Armbian is easily done using armbian-config (or armbian-install).

However, as discussed by @prahal and @blmhemu, that bootloader causes trouble (free() invalid pointer issue). You can easily test if you are affected by running the following python loop:

 

for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done

 

If you get the 'free() invalid pointer; aborted' message, you should replace the bootloader by either linux-u-boot-edge-helios64_22.02.1_arm64 or by linux-u-boot-current-helios64_21.08.9_arm64. You can do that using armbian-install as shown here - you need to modify /usr/lib/u-boot/platform_install.sh before. armbian-install always changes the bootloader on the medium that was used to boot the last time and the bootloader on the target medium if you transfer a system with it.

 

P.S.: On my system the bootloader also caused some other trouble: the sata bus was not detected reliably during boot, and sometimes accessed only with very low speeds causing boot delays of 5-10 seconds.

 

P.S.': If you prefer to manually update the bootloader on emmc (/dev/mmcblk1), just do the following:

 

# cd /tmp
# wget --content-disposition https://imola.armbian.com/apt/pool/main/l/linux-u-boot-helios64-current/linux-u-boot-current-helios64_21.08.9_arm64.deb
# dpkg -x linux-u-boot-current-helios64_21.08.9_arm64.deb linux-u-boot-current-helios64_21.08.9_arm64/
# cd linux-u-boot-current-helios64_21.08.9_arm64/usr/lib/linux-u-boot-current-helios64_21.08.9_arm64/
# ls -la
# dd if=idbloader.bin of=/dev/mmcblk1 seek=64 conv=notrunc
# dd if=uboot.img of=/dev/mmcblk1 seek=16384 conv=notrunc
# dd if=trust.bin of=/dev/mmcblk1 seek=24576 conv=notrunc
# reboot now

 

Edited November 3, 2023 by ebin-dev

[RlndVt]

On 10/30/2023 at 12:48 PM, ebin-dev said:

There are alternatives - you can install all the non-free firmware at once using apt.

Adding non-free-firmware to apt-sources?

 

On 10/30/2023 at 8:14 PM, ebin-dev said:

But yes - you can copy the content of the rtl_nic folder downloaded from git.kernel.org into /lib/firmware/rtl_nic/.

Do you mean from here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rtl_nic ?

 

I don't see any mention of `8152` in the list.

[ebin-dev]

56 minutes ago, RlndVt said:

Adding non-free-firmware to apt-sources?

 

Yes

 

56 minutes ago, RlndVt said:

Do you mean from here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rtl_nic ?

 

Exactly. Your friend is rtl8156a-2.fw. It it is the firmware patch for your 2.5G interface. The driver r8152 also takes care of it (load rtl8156a-2 v2 04/27/23 successfully)

 

(Once the firmware files are transferred, update uInitrd: 'sudo update-initramfs -u' and reboot):

# sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.60-current-rockchip64
update-initramfs: Armbian: Converting to u-boot format: /boot/uInitrd-6.1.60-current-rockchip64
Image Name:   uInitrd
Created:      Sat Nov  4 20:21:18 2023
Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
Data Size:    15769458 Bytes = 15399.86 KiB = 15.04 MiB
Load Address: 00000000
Entry Point:  00000000
update-initramfs: Armbian: Symlinking /boot/uInitrd-6.1.60-current-rockchip64 to /boot/uInitrd
'/boot/uInitrd' -> 'uInitrd-6.1.60-current-rockchip64'
update-initramfs: Armbian: done.

#reboot now

 

# dmesg | grep 2-1.4
[    4.799058] usb 2-1.4: new SuperSpeed USB device number 3 using xhci-hcd
[    4.820177] usb 2-1.4: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=30.00
[    4.820199] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[    4.820215] usb 2-1.4: Product: USB 10/100/1G/2.5G LAN
[    4.820229] usb 2-1.4: Manufacturer: Realtek
[    4.820242] usb 2-1.4: SerialNumber: 000000001
[    6.774096] usb 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd
[    6.874385] r8152 2-1.4:1.0: load rtl8156a-2 v2 04/27/23 successfully
[    6.915329] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add_weight() called with weight 256
[    6.931069] r8152 2-1.4:1.0 eth0: v1.12.13
[    6.952950] r8152 2-1.4:1.0 end1: renamed from eth0
[   10.353834] r8152 2-1.4:1.0 end1: Stop submitting intr, status -108
[   10.998114] usb 2-1.4: reset SuperSpeed USB device number 3 using xhci-hcd
[   11.058100] r8152 2-1.4:1.0: load rtl8156a-2 v2 04/27/23 successfully
[   11.305382] r8152 2-1.4:1.0 eth0: v1.12.13
[   11.513913] r8152 2-1.4:1.0 end1: renamed from eth0
[   14.940343] r8152 2-1.4:1.0 end1: carrier on

 

Edited November 4, 2023 by ebin-dev