Official Debian support

[moonwalkers]

Yes, it's hand rolled but it works fine.  The files are there and it boots, verified using UART.

It's up to you how you want to do it, if you want to manage it manually - by all means do so. But in my experience unless you have good reasons to do it manually (which in my book usually means "automation does the wrong thing or incapable of supporting my use case") you'll save yourself a ton of money on headache medicine if you just let the automation take care of things. In case of /boot/extlinux/extlinux.conf that means installing `u-boot-menu` and let it take care of generating the config for you after you adjust the parameters under /etc/default/u-boot.

I'll update the timeout.  The dtb part is what may be the problem--u-boot has a dtb file under /usr/lib/u-boot/pinebook-pro-rk3399/rk3399-pinebook-pro.dtb that I've been using.  This is probably my issue, I assumed since it shipped with one that I need to use it.  I don't do much with ARM but I hand roll all my other Debian setups.

If it boots with your current timeout - don't worry about adjusting it, not unless you actually want more than 0.5s to select which kernel to boot. I tried sub-1s timeout with BSP u-boot, never tried it with Manjaro or stock Debian u-boot, but if I can keep it below 1s I would just to speed up the boot. That said, before the menu delay there is 3s delay while u-boot detects boot devices, reducing that would save me much more on boot time if I knew how to. However, 4s is a joke compared to overall time it takes to boot the OS and start the KDE Plasma session, so the motivation is low.

As to device tree part - see what I wrote above about `u-boot-menu` package.

I kinda skipped the whole Raspberry Pi bandwagon and the original 14" PB I bought in 2017 had a hardware fault so it wasn't until I got my PBP in January 2020 that I was able to get any substantial Linux on ARM experience. Following the "start with basics" rule helped me not to get bogged down and burn out before I got any usable results.

Everything boots OK (verified using UART/SSH to the machine), just the LCD doesn't show anything.

If your LCD doesn't show anything until Linux is loaded then you're not booting using the u-boot from Debian Experimental. You probably installed the package `u-boot-rockchip`, but never ran `sudo u-boot-install rockchip ...` command.

I'm trying to integrate all of this into my existing amd64 debian flashing setup so I don't have to document the steps I did to get this working, I just kick off the script I have.  To that end, yes I am customizing this stuff.  The problem with leaving the defaults in place is, there aren't any, unless you're using an image.  I'm trying to piece together documentation that is scattered in this forum, in the upstream u-boot, kernel changelogs, and manjaro.  It's quite frankly a mess, especially coming from the buttery smooth amd64 boot process.

By defaults I mean "simplest thing that works", which is exactly what Debian installer does if you leave all the default options. With actual ARM installer the only problem is that Debian installer doesn't leave any space for u-boot during partitioning and doesn't actually install u-boot, so those have to be done manually. Last time I checked Debian defaults to ext4, not btrfs. No LUKS, no LVM (a shame, really), just two partitions using MBR - one for all files and one for swap (though I do recommend skipping swap partition/file and go straight for swap on zram. Just don't use zram-tools package, it's atrocious). From the viewpoint of actually running the system you can mostly ignore the ISA differences, the biggest difference between AMD64 and ARM64 is in how to boot the system, and the simplest thing there is u-boot loading kernel directly using extlinux.conf or bootscript. Once you have that down fully functional you can then play around with UEFI/GRUB/what have you.

And yes, ARM is undeniably still a hot mess, and probably will remain so for a very long time. The reason for your "buttery smooth" amd64 experience is that it got de-facto standardized when IBM published it's BIOS code back in 1981, so when everybody and their uncle started building PC clones some half a decade later everyone was also re-creating the same exact boot process. AMD64 is not just a CPU ISA, it's an evolution of the same old IBM PC from 1981 - a computer that from the start was intended to be capable of running more than one OS. In comparison, ARM is just a CPU ISA licensed for everyone to do their own (primarily embedded) thing with it. It started in 1985, but there was never any kind of standardized firmware/bootloader for it until recently, and even the de-facto standard u-boot is a separate project that started in 1999 for PowerPC rather than ARM.

EDIT: Yes, the dtb from the /usr/lib kernel directory fixed it.  I seem to get white lines down the screen instead of console/gdm after reboot occasionally though, anyone else experiencing this?

Nope, no white lines. Only some framebuffer junk when Linux takes over the screen after u-boot, but those get cleared up as soon as Linux finishes the device setup.