Official Debian support

[sepp]

I wouldn't say that. E.g. the kernels on my x86 work laptop that is a-OK with compressed ones are all less than 10MiB, but the kernels on my PBP are all over 25MiB+. What's the size of your kernels, the problematic one included?

-rw-r--r-- 1 root root 25M Aug 27  2020 /boot/vmlinuz-5.8.5-0.40-1-pinebookpro-hwaccel @xmixahlx 
-rw-r--r-- 1 root root 27M May 28 10:31 /boot/vmlinuz-5.10.0-7-arm64                               stock debian
-rw-r--r-- 1 root root 11M Jul  8 14:07 /boot/vmlinuz-5.10.48-0.40-1-pinebookpro-hwaccel my

to compare my uncompressed image
-rw-r--r-- 1 sepp sepp 54M Jul  8 14:47 dev/kernel/linux-5.10.48/arch/arm64/boot/Image
mkimage -l dev/kernel/linux-5.10.48/arch/arm64/boot/Image
GP Header: Size 4d5a0091 LoadAddr ffbf5314

Manjaro stock boots Image
-rw-r--r-- 1 sepp sepp 30M Jun 16 12:41 /media/sepp/BOOT_MNJRO/Image
mkimage -l /media/sepp/BOOT_MNJRO/Image
GP Header: Size 4d5a40fa LoadAddr ffbf5c14

I will try my Image later today and report back

[sepp]

That was the issue
thank you @moonwalkers

[moonwalkers]

That was the issue
thank you @moonwalkers

Just a lucky guess on my part. Glad it works now. 54M seems pretty large though, you might be building-in a bunch of modules that are either completely unnecessary or can be made loadable.

[sepp]

Debian has a new stock image 5.10.0.8:

Tested it shortly - still not there

GPU issues - slow not usable for Video Playback
no USB-C DP alt mode

Continue to use the stock kernel 5.9.10 with all the patches from @tsys provided by @xyzzy here https://github.com/xyzzy42/linux/tree/pbp/arch/arm64 together with his minimal configuration (@moonwalkers Image size 20M).
Everything works good though wakeup from sleep sometims fails.

[moonwalkers]

Any change you could send me a dpkg -l output some time along with your extlinux.conf?  I have the u-boot from experimental, dtb from experimental, kernel from bullseye (same version as sid), and i'm using this extlinux config:

TIMEOUT 5
DEFAULT debian
LABEL debian
  MENU LABEL Debian bullseye
  LINUX /vmlinuz
  INITRD /initrd.img
  FDT /pinebookpro.dtb
  APPEND root=LABEL=btrfs rootflags=compress=zstd:3,subvol=debian-bullseye rw


Still no output to the screen after boot.

I do not like answering these types of questions in private - other people don't get to benefit.

Your extlinux.conf appears to be hand-rolled rather than generated by (already mentioned by me) u-boot-menu, and it points to /pinebookpro.dtb for the device tree. Unless you did something special to have that file created, your config likely points to a non-existent device tree and very well could result in unbootable system.


Your TIMEOUT is set to 0.5s, in my experience anything less than 1s doesn't boot right for some reason (quirk of u-boot, perhaps?)

You mentioned you have dtb from experimental, but kernel from bullseye/sid? Not sure what exactly do you mean. Device trees are packaged together with the kernel in Debian, so if you install, e.g., linux-image-5.10.0-8-arm64, among other files it will create directory tree /usr/lib/linux-image-5.10.0-8-arm64/ where you will have, among others, folder rockchip, in which you will have rk3399-pinebook-pro.dtb device tree binary. Now unless you have a separate /boot, you generally don't need to do anything with that file - no copying or symlinks necessary, so long as your /boot/extlinux/extlinux.conf has the line "fdtdir /usr/lib/linux-image-5.10.0-8-arm64/". If you do have separate /boot, installing flash-kernel package should automate copying the appropriate device tree binary to your /boot.

When you said "I have the u-boot from experimental", do you get early u-boot messages on the screen, before it actually boots the kernel? If you don't, you likely don't have u-boot actually installed - it's a separate step from "apt install", you need to run `sudo u-boot-install-rockchip <eMMC device>` first before your machine will actually use it.

Finally, as a general comment - always start from the most basic, simplest setup, even when you think you know exactly what you're doing, and leave the defaults in place until you got the most basic default setup working well. While probably not the case here, I can give you plenty examples from my own experience when something as simple as adding an explicitly configured compression method broke things. So don't hand-roll anything until you either fully understand the implications of every parameter, or you got your basic defaults working and you're starting to experiment. And when you do, don't change more than one thing at a time.

[thequailman]

Your extlinux.conf appears to be hand-rolled rather than generated by (already mentioned by me) u-boot-menu, and it points to /pinebookpro.dtb for the device tree. Unless you did something special to have that file created, your config likely points to a non-existent device tree and very well could result in unbootable system.

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

Your TIMEOUT is set to 0.5s, in my experience anything less than 1s doesn't boot right for some reason (quirk of u-boot, perhaps?)

You mentioned you have dtb from experimental, but kernel from bullseye/sid? Not sure what exactly do you mean. Device trees are packaged together with the kernel in Debian, so if you install, e.g., linux-image-5.10.0-8-arm64, among other files it will create directory tree /usr/lib/linux-image-5.10.0-8-arm64/ where you will have, among others, folder rockchip, in which you will have rk3399-pinebook-pro.dtb device tree binary. Now unless you have a separate /boot, you generally don't need to do anything with that file - no copying or symlinks necessary, so long as your /boot/extlinux/extlinux.conf has the line "fdtdir /usr/lib/linux-image-5.10.0-8-arm64/". If you do have separate /boot, installing flash-kernel package should automate copying the appropriate device tree binary to your /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.

When you said "I have the u-boot from experimental", do you get early u-boot messages on the screen, before it actually boots the kernel? If you don't, you likely don't have u-boot actually installed - it's a separate step from "apt install", you need to run `sudo u-boot-install-rockchip <eMMC device>` first before your machine will actually use it.

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

Finally, as a general comment - always start from the most basic, simplest setup, even when you think you know exactly what you're doing, and leave the defaults in place until you got the most basic default setup working well. While probably not the case here, I can give you plenty examples from my own experience when something as simple as adding an explicitly configured compression method broke things. So don't hand-roll anything until you either fully understand the implications of every parameter, or you got your basic defaults working and you're starting to experiment. And when you do, don't change more than one thing at a time.

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.  I appreciate your patience here as I try to understand the whys and the hows instead of curl | bash my way through this.

---

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?

[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.

[bcnaz]

IF I understand correctly, the upcoming Debian Bullseye ARM release August 15th 2021, should 'just work out of the box'... ?

I am still running "mrfixit's" Debian on both my ISO and ANSI Pinebook Pro's.

Last year sometime I did try a copy of the Debian ARM on an sd card and the system ran ok, had working wifi....
I did not test it extensively, I was just curious, but I have not followed up since.

This 'May be' my next OS on my Pinebook Pro's

[moonwalkers]

IF  I understand correctly,  the upcoming Debian Bullseye ARM release August 15th 2021,  should 'just work out of the box'... ?

Would be pretty awesome. That said, the installer SD card didn't result in usable screen when I tried couple weeks ago. Considering (at least in theory) the only difference between it and my system should be in u-boot and currently Bullseye still has the same version it did when I tried SD card - I guess we'll see what happens when it is officially released. When I tried the SD card installer on my original PB it worked fine, but lacked firmware (WiFi and BT) in the installer image and when left to its own devices did nothing to install u-boot onto eMMC or even partition correctly to leave space for u-boot on eMMC. Which is where comes my advice to keep an eye on partitioning and making sure u-boot is installed properly.

[bcnaz]

I only ran my PBP from the sd card, I didn't try installing it,  I was just  messin around.