Mainline Debian Buster on RockPro64 ?

[kuleszdl]

Just a short update after upgrading to mainline kernel 5.10.4 in Debian unstable and U-Boot 2020.10. My boot now hangs after the dtbs have been detected (tried booting from sdcard):

Code:

U-Boot 2020.10 (Jan 03 2021 - 03:00:07 +0000)

SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM:  3.9 GiB
PMIC:  RK808
MMC:   mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Pine64 RockPro64 v2.1
Net:   eth0: ethernet@fe300000
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:2...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
210 bytes read in 4 ms (50.8 KiB/s)
1:      Linux devuan
Retrieving file: /initrd.img
28216151 bytes read in 1274 ms (21.1 MiB/s)
Retrieving file: /vmlinuz
23842672 bytes read in 1077 ms (21.1 MiB/s)
append: root=LABEL=root cryptopts=source=LABEL=rootencrypted,target=root_crypt,luks
Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb
56849 bytes read in 10 ms (5.4 MiB/s)
Moving Image from 0x2080000 to 0x2200000, end=3960000
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000

The same issue is present with the pinebookpro, so I assume the 5.10 kernel in Debian has some issue here.

Edit: Issue seems to be specific for the rk3399 as the smaller rock64 boots fine with the same kernel.

Update: For the current kernel to work you have to compile u-boot with "PREBOOT=y" disabled as mentioned by toons. Then it will probably boot - at least the pinebook pro does. See here for details:

https://forum.pine64.org/showthread.php?...5#pid86475

Update 2: Confirmed. The rockpro64 boots up fine with the change in u-boot and is usable. I tried only booting from eMMC as I keep having issues with the sdcard in the official Debian kernels.

[kuleszdl]

@n4tter4ngell Thank you for your contribution regarding the dropbear issue - I experienced the same now on my rockpro64 and your workaround worked fine. However, I had another issue with network being broken in the regular OS although it worked in dropbear. It shows these errors in the kernel log:

Code:

[   35.456271] rk_gmac-dwmac fe300000.ethernet: Failed to reset the dma
[   35.456281] rk_gmac-dwmac fe300000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed                                                                                  
[   35.456287] rk_gmac-dwmac fe300000.ethernet eth0: stmmac_open: Hw setup failed

This can be solved by unloading and loading the dwmac_rk kernel module.

I added these bits to the article now.

[n4tter4ngell]

Thanks for the updates, @kuleszdl !

I haven't done any changes to my system since I got it up and running, it's been so stable and functions just fine as a multipurpose server

I did not have any issues with the network after booting, it's been rock solid for me.

I see now that before I figured out I needed to add that sleep parameter, I preloaded some of the network modules in /etc/initramfs-tools/conf.d/modules
dwmac_rk
rk_gmac-dwmac
stmmac_platform
stmmac


I don't know if that made any difference as to why it worked out of the box for me. Maybe this saves you from unloading/reloading after boot?

Anyways, good to know there is now a predictable way to get the board running with Debian!

[kuleszdl]

@n4tter4ngell Okay, that's really interesting. I will try to change the order of loading the modules as suggested and see if this renders my "flub" reload-script obsolete.

[foresto]

Code:

rk_gmac-dwmac fe300000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed

I've been using the debian unstable 5.10 kernel for months without this problem, but it finally appeared today. I'm currently using linux-image-arm64/unstable 5.10.12-1 . Except for small handful of applications, the system is otherwise running debian buster.

It's curious that dropbear-initramfs configures eth0 just fine (with my workaround for 968519 in place), allowing me to ssh in and unlock the luks volume, but the error then shows up later in the boot process, preventing the OS from bringing up eth0 for regular use.

Logging in on the serial console and removing/reloading the dwmac_rk kernel module does get eth0 working, but that's obviously not a practical fix.

Based on a few test boots, it looks like the bug vanishes is less frequent when a scheduled fsck delays the boot process. Maybe there's a race condition in play? Maybe it's related to the issue underlying  968519 ?

[kuleszdl]

Well, that's hard to tell. I am sticking now with the workaround which works reliable and sufficiently for my setup. Yet, many thanks for communicating this upstream @foresto to get this fixed properly in the long term (it always sucks when such things don't work ootb)!

[foresto]

@kuleszdl To be clear, the report I submitted months ago was not necessarily the same bug that we're discussing here. I only mentioned it in case it turns out to be related.

Since you have tested with a workaround that seems consistent, I encourage you to submit a report upstream about *this* bug. Debian in soft freeze for the upcoming Bullseye release, so getting this fixed now would be helpful.