Official Debian support

[thequailman]

u-boot 2021.07.rc4 was recently added to experimental. Using this with a bullseye debootstrap, I get a graphical boot (including the u-boot bits) up to the EFI screen and then nothing after the system starts initing.

[moonwalkers]

u-boot 2021.07.rc4 was recently added to experimental.  Using this with a bullseye debootstrap, I get a graphical boot  (including the u-boot bits) up to the EFI screen and then nothing after the system starts initing.

I remember during the early days of UEFI support in Debian (IIRC circa 2012 and right around kernel transitioning from 2.6.x to 3.x) there was a bug with, I think, proper support for either UGA or GOP, I don't remember. Probably GOP. It resulted in no output whatsoever until X11 kicked in. Eventually it got fixed though. Now since you're using UEFI, and AFAIK u-boot's UEFI implementation is not complete (see https://u-boot.readthedocs.io/en/v2021.0...ent-target), I wonder if you're hitting some kind of incomplete implementation of GOP or something else in u-boot?

That said, I should probably give u-boot 2021.07.rc4 a shot myself - I've been reluctant to switch to it from BSP u-boot and get an un-bootable system that I'd need to open up to un-brick, since I find that opening up PBP is always somewhat of a pain in the ass, even compared to the more recent ThinkPads.

[sepp]

!!!! Do not install to eMMc it will brick it and afterwards does not boot at all (firmware.pinebook-pro-rk3399.img.gz 2021-06-26 02:07 + partition.img.gz 2021-06-26 02:07)
To recover
(!!!!!!! read ths before https://wiki.pine64.org/index.php/Pinebo...Reassembly and take extra care !!!!!)
switch off eMMc
boot from SD interrupt u-boot
switch on eMMc
on the u-boot prompt enter "=> mmc erase 0 1000" follwed by boot

[moonwalkers]

!!!! Do not install to eMMc it will brick it and afterwards does not boot at all (firmware.pinebook-pro-rk3399.img.gz 2021-06-26 02:07 + partition.img.gz 2021-06-26 02:07)
To recover
(!!!!!!! read ths before https://wiki.pine64.org/index.php/Pinebo...Reassembly and take extra care !!!!!)
switch off eMMc
boot from SD interrupt u-boot
switch on eMMc
on the u-boot prompt enter "=> mmc erase 0 1000" follwed by boot

Actually, I still haven't had much success booting the official installer media. Not with working built-in display anyway. Which is one of the reasons I'm reluctant to risk trying u-boot-rockchip. My system right now uses everything stock Debian except u-boot and couple WiFi firmware blobs, but it was originally installed using (a manual equivalent of) debootstrap rather than proper Debian installer.

[thequailman]

Ok I'm getting closer. I think the problem is with the linux kernel, specifically the option CONFIG_ROCKCHIP_CDN_DP=y is set on the Debian 5.10.40 kernel. This may cause issues, as I have found a couple of references (https://www.kulesz.me/post/150_devuan_pinebookpro/) to recompiling a kernel without this option and it fixes the display. Curiously, the working Manjaro image runs 5.12 with this option set to yes, so I'm wondering if it's fixed in the latest stable kernel.

I'm going to try recompiling 5.10.40 with that option unset and see if it fixes it, and then I'll try building the latest 5.12 with that option set to yes/defaulted. With this done, all that's left is to get the wifi firmware included into somehow (linux-firmware-nonfree?). You'll need to use u-boot in experimental or grab the itb/u-boot.img/dtbs from the Manjaro image.

[alpopa]

I wander if passing some parameters to kernel does the trick rather than recompilation of it.

Also, I am under impression that for WiFi firmware the best place is linux-firmware-misc package.

[thequailman]

Here are the results:

5.10.40 with CONFIG_ROCKCHIP_CDN_DP unset = display works
5.12.13 with Debian default kernel config = display does not work

So, do I submit a bug report to the Debian kernel team and ask for the config to be unset?

Also, the u-boot in experimental doesn't work, I had to use the one from Manjaro.

[moonwalkers]

I wander if passing some parameters to kernel does the trick rather than recompilation of it.

Also, I am under impression that for WiFi firmware the best place is linux-firmware-misc package.

I doubt it. My kernel command line besides the usual `root=<device> ro quiet splash` contains only `plymouth.ignore-serial-consoles`. But it also works fine without `plymouth.ignore-serial-consoles`, it's just that I get a wall of text instead of graphical splash in that case.

And for firmware I think more appropriate would be the current firmware-brcm80211 package instead of the no longer existent in Debian linux-firmware-misc package.

---

Here are the results:

5.10.40 with CONFIG_ROCKCHIP_CDN_DP unset = display works
5.12.13 with Debian default kernel config = display does not work

So, do I submit a bug report to the Debian kernel team and ask for the config to be unset?

Also, the u-boot in experimental doesn't work, I had to use the one from Manjaro.

I did not recompile 5.10.38, it had CONFIG_ROCKCHIP_CDN_DP=y, yet it worked fine on my machine. I do suspect that it has to do with the version of u-boot, interaction between the firmware and the kernel. BTW, I'm running 5.10.46 right now, Debian's linux-image-5.10.0-8-arm64 from Unstable. Still CONFIG_ROCKCHIP_CDN_DP=y, still works fine with mrfixit's release v2.0 BSP u-boot.

[sepp]

Finally I figured it out: Debian bullseye stock on nvme:

Here is what I did:

Prerequisite: bulleye sd card created with https://d-i.debian.org/daily-images/arm6...rd-images/

Installed this u-boot to emmc: the modified u-boot images provided by forum user pcm720
be sure to have not boot partition on emmc

create an ext4 and a swap partition on nvme0n1
ext4 nvme0n1p1
swap nvme0n1p2

debootstrap into nvme0n1p1 following this https://gist.github.com/varqox/42e213b6b2dde2b636ef
(instead of debootstrap the Debian install can also be use but then a serial interface is needed - for debootstrap any Distro booted from SD card works)

create symlinks for vmlinuz-5.10.0-7-arm64 (vmlinuz) and initrd.img-5.10.0-7-arm64 (initrd.img)
cp dtb, dtb-5.10.0-7-arm64 and dtbs folders recursive from boot on debian sd card

to have the following boot folder on nvme0n1p1
root@Pine64:/# ls -ltra boot
total 53548
-rw-r--r--  1 root root 27400064 May 28 10:31 vmlinuz-5.10.0-7-arm64
-rw-r--r--  1 root root  254127 May 28 10:31 config-5.10.0-7-arm64
-rw-r--r--  1 root root      83 May 28 10:31 System.map-5.10.0-7-arm64
drwxr-xr-x 18 root root    4096 Jun 29 07:13 ..
-rw-r--r--  1 root root 27147997 Jun 29 07:14 initrd.img-5.10.0-7-arm64
lrwxrwxrwx  1 root root      52 Jun 29 07:22 dtb -> dtbs/5.10.0-7-arm64/rockchip/rk3399-pinebook-pro.dtb
lrwxrwxrwx  1 root root      52 Jun 29 07:22 dtb-5.10.0-7-arm64 -> dtbs/5.10.0-7-arm64/rockchip/rk3399-pinebook-pro.dtb
drwxr-xr-x  3 root root    4096 Jun 29 07:22 dtbs
lrwxrwxrwx  1 root root      22 Jun 29 07:23 vmlinuz -> vmlinuz-5.10.0-7-arm64
lrwxrwxrwx  1 root root      25 Jun 29 07:23 initrd.img -> initrd.img-5.10.0-7-arm64
-rw-r--r--  1 root root    2210 Jun 29 08:47 boot.cmd
drwxr-xr-x  3 root root    4096 Jun 29 08:47 .
-rw-r--r--  1 root root    2282 Jun 29 08:47 boot.scr


you cannot just copy the boot.scr from debian. you have to strip the 72 long u-boot header like so https://wiki.ubuntu.com/ARM/EditBootscr to get a boot.cmd

insert a line into boot.cmd (the one I use is attached)

setenv bootargs  ${bootargs} quiet
(this one) setenv bootargs root=/dev/nvme0n1p1 rootwait ${bootargs}

if test -z "${fk_kvers}"; then

and
mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

issues remaining:
nvme not detected sporadically though rootwait
wakening from suspend
sound: es8316.c in linux-source is outdated. Upstream contains the necessary patch by Tobias Schramm. so this will come (and I want to stick to stock as this is "Official Debian support")

[sepp]

I wander if passing some parameters to kernel does the trick rather than recompilation of it.

Also, I am under impression that for WiFi firmware the best place is linux-firmware-misc package.

I doubt it. My kernel command line besides the usual `root=<device> ro quiet splash` contains only `plymouth.ignore-serial-consoles`. But it also works fine without `plymouth.ignore-serial-consoles`, it's just that I get a wall of text instead of graphical splash in that case.

And for firmware I think more appropriate would be the current firmware-brcm80211 package instead of the no longer existent in Debian linux-firmware-misc package.

---

Here are the results:

5.10.40 with CONFIG_ROCKCHIP_CDN_DP unset = display works
5.12.13 with Debian default kernel config = display does not work

So, do I submit a bug report to the Debian kernel team and ask for the config to be unset?

Also, the u-boot in experimental doesn't work, I had to use the one from Manjaro.

I did not recompile 5.10.38, it had CONFIG_ROCKCHIP_CDN_DP=y, yet it worked fine on my machine. I do suspect that it has to do with the version of u-boot, interaction between the firmware and the kernel. BTW, I'm running 5.10.46 right now, Debian's linux-image-5.10.0-8-arm64 from Unstable. Still CONFIG_ROCKCHIP_CDN_DP=y, still works fine with mrfixit's release v2.0 BSP u-boot.

CONFIG_ROCKCHIP_CDN_DP=y in 5.10.0-7-arm64 stock with u-boot by  pcm720 also fine