Mainline Debian Buster on RockPro64 ?
#31
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.
  Reply
#32
@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.
  Reply
#33
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 Smile

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!
  Reply
#34
@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.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  New OS for RockPro64 is here, TwisterOS Armbian jtremblant 39 3,642 3 hours ago
Last Post: jtremblant
  OpenSuse for ROCKPro64: testimage hemertje 0 67 01-18-2021, 01:35 PM
Last Post: hemertje
  Chromium OS for the RockPro64 is now available! Luke 9 4,066 01-09-2021, 12:13 PM
Last Post: Ruben
  slarm64 (unofficial slackware) ROCKPro64 RK3399 (aarch64) mara 39 16,024 01-08-2021, 01:45 PM
Last Post: mara
  slave mode on Rockpro64 Radhika.gabani 0 215 01-07-2021, 03:31 AM
Last Post: Radhika.gabani
  DietPi OS for ROCKPro64 MichaIng 6 605 12-25-2020, 03:24 PM
Last Post: MichaIng
  How To Lay Hands on a True 64-bit Debian Install? vandys 4 498 12-01-2020, 06:12 AM
Last Post: as365n4
Question Help getting a GPU running on my RockPro64 Ceazer 0 289 11-23-2020, 04:05 PM
Last Post: Ceazer
  RockPro64 eMMC mrfixit to 5.9 rthorntn 1 515 10-27-2020, 07:09 PM
Last Post: rthorntn
Question Ayufan RockPro64 updates? hemertje 3 991 10-22-2020, 01:16 PM
Last Post: dukla2000

Forum Jump:


Users browsing this thread: 1 Guest(s)