Mainline Debian Buster on RockPro64 ?

[n4tter4ngell]

"n4tter4ngell" - I updated my post and included a video with the detailed steps for partitioning.

Please don't be confused how the installer names the crypto device (sda3_crypt or vda3_crypt). That's just the name of the device, not the name of the partition label. Maybe this is what actually might have confused you? I added a hint, pointing this out more clearly (hopefully).

Once again, thank you for your feedback!

@kuleszdl , thank you so much! I appreciate your help! I've finished the SD card now, hopefully my RockPro64 arrives tomorrow so I can test it

[kuleszdl]

Great! Just remember that you can use the image to install the OS on most other "unofficially supported" SbCs as well if you use a different uboot. So if you have something to play already, I recommend starting with a familiar SbC first. Getting used to a new device can be challenging - e.g. the rockpro64 has this nasty issue of not booting with the TX serial pin attached and also has issues with sdcards, usb3 and some other stuff (at least on older kernels like the 5.6 series - I hope this got fixed in the newer ones).

If you encounter any strange behavior on the rockpro64 I suggest booting it from eMMC (if you bought the module) instead of the microSD card.

[n4tter4ngell]

Thanks!

I intend to use this board as a headless server, so I will hopefully be good once it is up and running.

My plan is to install u-boot on the spi and boot from a USB 3.0 SSD disk once I have confirmed it's working. Got an spi image based on the "mainline uboot thread" on this forum with apparently working USB boot ready to test. I think the controller in my orico case should be friendly and uasp compatible, but I won't know until I've had time to test it.

[kuleszdl]

I was also planning to put uboot in the SPI, however, I was unable to get my self-compiled version working in there - at least on the smaller rock64 board.

[n4tter4ngell]

@kuleszdl

Just an update, now that I got to test this. Sorry for the late reply, for some reason I can't post the links I'd like.

Unfortunately, the SD-card i prepared with your instructions on your blog post didn't work, although not because of anything wrong in your post. U-boot worked as expected, but the kernel didn't boot. There's already a Debian bug post on this. Apparently setting FAT as the working environment for u-boot works, but I didn't try that.

I ended up following the approach outlined by @foresto  in his post recently. I chose to put /boot as the 2nd partiton on the SD-card prepared using the debian unstable installer image. Like foresto, I defined preseed to debian stable and then installed the unstable kernel through chroot before completing the installer. I got around the potential pitfalls with the installer by zcat'ing the last working firmware.rockpro64-rk3399.img.gz from "20201006" and partition.img.gz from "daily", as mentioned by @MSteam did in foresto's post.

I set up encrypted root on a USB 3.0 SSD while installing. Because quite a few people seem to have issues with booting MMC-modules, and SD-card having limited performance, this seemed like a good compromise without requiring the PCIe-SATA adapter and a large NAS-case to house it. I'm merely using the aluminium case for the RockPro64. Using the SD card for u-boot and the /boot partition gives me the flexibility to experiment with future u-boot versions etc without using the serial adapter and messing around with the SPI all the time. Like a lot of others, I couldn't get u-boot on SPI to detect my disk when connected to the USB 3.0 port. So this is a decent workaround for the problems @idontgetit experienced recently. I'm sure USB 3.0 support in u-boot will mature eventually.

Also, as I wanted to use dropbear-initramfs to unlock the encrypted root through SSD as outlined in the blog post, I had to make a small adjustment to @kuleszdl instructions. I ran into a race condition where eth0 wasn't ready before reaching the luks unlock-prompt. There's a Debian bug report for this too. The workaround for me was to add "sleep 10" before "configure_networking ()" is called in "/usr/share/initramfs-tools/scripts/init-premount/dropbear".

So now I have Debian stable with the unstable kernel, and my USB 3.0 SSD works great! After flashing stock JMS578 firmware from here to my $8 Orico enclosure and adding udev-rule for it, I have working UASP with TRIM-support too!

Best of all, "reboot" from commandline works without issue.

Performance seems to be really great! The disk is snappy, and I can easily saturate my 500/500 fiber connection. No issues or any other problems so far. Nice to finally run a fully open source system without binary blobs.

I'm hoping support will be more end-user friendly by the time Debian 11 is released

[kuleszdl]

@n4tter4ngell Thank you for this update! Sounds quite interesting, but I would be interested in why the kernel did not boot for you using my approach. Is this a bug in the newer unstable kernels? And could you describe the error message, please?

Imho, uboot should not have issues with FAT vs. ext4? And did you install directly to SSD or did you use only the microSD card like I did?

[n4tter4ngell]

@n4tter4ngell Thank you for this update! Sounds quite interesting, but I would be interested in why the kernel did not boot for you using my approach. Is this a bug in the newer unstable kernels? And could you describe the error message, please?

Imho, uboot should not have issues with FAT vs. ext4? And did you install directly to SSD or did you use only the microSD card like I did?

 This is the problem I experienced (someone else reported it): https://bugs.debian.org/cgi-bin/bugrepor...bug=973323

Well, technically I can't be sure the problem is really due to u-boot. U-boot starts as expected from the SD-card, but the kernel doesn't boot, it hangs at "Booting using the fdt blob at 0x01f00000". The FAT environment referenced as I understand it is it set in rockpro64-rk3399_defconfig, it doesn't seem to refer to the file system on the SD-card.

When you wrote your guide, what kernel version was the Debian unstable using at the time? Mine was at 5.9.0-1. It occurred to me I could have tried the kernel in buster-backports, but I haven't done that yet. I believe it's still at 5.8.10-1.

I installed root directly on the SSD. The debian-unstable installer image creates a FAT-partition for the installer on the SD-card, after leaving space for u-boot with the correct offset. I simply created /boot as the second partiton on the same SD-card.

---

And this is the bug report for dropbear-initramfs as mentioned, with a workaround: https://bugs.debian.org/cgi-bin/bugrepor...bug=968519

[kuleszdl]

This rather looks like an issue with the DTB file to me since that's what the "loading fdt" is about. Did you try to replace the dtb file with a version from an earlier kernel? Since there are two rockpro64 dtbs that are linked - did you make sure you have both in your dtb directory?

Afair, I used kernel 5.6 and later 5.7 when writing my guide but I didn't use or upgrade my rockpro64 since then (I use the installation on other boards as I find the rockpro64 too power-hungry).

Edit: Double-checked - I can confirm the current kernel in Debian/Devuan unstable is 5.9 now, I will try to see how it works for me.
Edit 2: Kernel 5.9 boots fine (on the pinebook pro), however I have issues with the sdcard. Not sure whether this might be a hardware issue though.

[n4tter4ngell]

This rather looks like an issue with the DTB file to me since that's what the "loading fdt" is about. Did you try to replace the dtb file with a version from an earlier kernel? Since there are two rockpro64 dtbs that are linked - did you make sure you have both in your dtb directory?

Afair, I used kernel 5.6 and later 5.7 when writing my guide but I didn't use or upgrade my rockpro64 since then (I use the installation on other boards as I find the rockpro64 too power-hungry).

Edit: Double-checked - I can confirm the current kernel in Debian/Devuan unstable is 5.9 now, I will try to see how it works for me.
Edit 2: Kernel 5.9 boots fine (on the pinebook pro), however I have issues with the sdcard. Not sure whether this might be a hardware issue though.

Ah! No, I didn't try that. Come to think of it, I only put one of them in the dtb directory. In that case, I guess your image works fine. I still have it on my other computer, I'll try to check with a different SD-card when I have time.

What issues do you have with the SD-card?

The board works fine for me right now, it powers a small webserver with a couple of other services. I'm actually very impressed with it as compared to the RPi's I've toyed with before.

[kuleszdl]

Well, the SD card is highly unreliable and even fails to boot. This does not happen when using the eMMC module. When using Armbian (at least on the Pinebook Pro) this issue does not occur either. Therefore, I assume that the current combination of mainline kernel (5.9) and uboot is not yet production-ready when running from sd-card.