There is a thread for official Debian support, but it's not PBP-specific, so I thought it would be appropriate to create one here.
Since linux-image-5.10.0-7-arm64, the linux-image-arm64 meta-package in Debian Sid/Unstable now supports PBP. That corresponds to the kernel version 5.10.38. Latest version is actually 5.10.40. By now linux-image-5.10.0-7-arm64 should've made its way into Debian Bullseye/Testing, which should become the next stable some time this year. I've been running it for the past almost two weeks, and below are my findings so far, primarily compared to the 5.8.5 kernel build using xmixahx's pbp-tools. Since U-boot have an effect on some of the functionality, full disclosure - I'm using BSP u-boot release 2.0 by mrfixit ( https://github.com/mrfixit2001/updates_r...filesystem). I have not yet tried other versions of u-boot, neither any of the custom builds nor u-boot-rockchip package from Debian repos that since some time ago claims to support PBP.
Did not test:
* Bluetooth
What works:
* WiFi
* Built-in display at native resolution
* 3D acceleration
* Webcam
* Built-in microphone
* Sound (built-in speakers and headphones, I'm still using custom acpid event to switch output)
What doesn't work:
* Deep sleep (regression compared to xmixahx's 5.8.5)
What works differently:
* Debian's kernel defaults to schedutil scaling governor.
* big cores are now limited to 1.8GHz instead of 2.0GHz, little cores still run at up to 1.416GHz. This could potentially explain why with Debian kernel I have not yet been running into any freezes outside of my attempts at deep sleep, unlike with xmixahx's 5.8.5 kernel.
This message was created with 100% recycled electrons
(06-05-2021, 01:45 PM)moonwalkers Wrote: There is a thread for official Debian support, but it's not PBP-specific, so I thought it would be appropriate to create one here.
Since linux-image-5.10.0-7-arm64, the linux-image-arm64 meta-package in Debian Sid/Unstable now supports PBP. That corresponds to the kernel version 5.10.38. Latest version is actually 5.10.40. By now linux-image-5.10.0-7-arm64 should've made its way into Debian Bullseye/Testing, which should become the next stable some time this year. I've been running it for the past almost two weeks, and below are my findings so far, primarily compared to the 5.8.5 kernel build using xmixahx's pbp-tools. Since U-boot have an effect on some of the functionality, full disclosure - I'm using BSP u-boot release 2.0 by mrfixit (https://github.com/mrfixit2001/updates_r...filesystem). I have not yet tried other versions of u-boot, neither any of the custom builds nor u-boot-rockchip package from Debian repos that since some time ago claims to support PBP.
Did not test:
* Bluetooth
What works:
* WiFi
* Built-in display at native resolution
* 3D acceleration
* Webcam
* Built-in microphone
* Sound (built-in speakers and headphones, I'm still using custom acpid event to switch output)
What doesn't work:
* Deep sleep (regression compared to xmixahx's 5.8.5)
What works differently:
* Debian's kernel defaults to schedutil scaling governor.
* big cores are now limited to 1.8GHz instead of 2.0GHz, little cores still run at up to 1.416GHz. This could potentially explain why with Debian kernel I have not yet been running into any freezes outside of my attempts at deep sleep, unlike with xmixahx's 5.8.5 kernel.
Hello, I've been struggling to get Debian testing or unstable displaying something on the screen with a custom install. Everything boots OK, but X won't start or any display manager (GDM etc). I'm booting with u-boot+uefi though, maybe that's the issue? I don't know how to do a custom /boot for non-UEFI though (I think there's a config.txt file I need? grub?). UEFI was easier to get going with. Any chance you could send me the contents of your /boot directory or instructions on how you populated it? maybe a fdisk dump too?
(06-06-2021, 12:27 PM)thequailman Wrote: Hello, I've been struggling to get Debian testing or unstable displaying something on the screen with a custom install. Everything boots OK, but X won't start or any display manager (GDM etc). I'm booting with u-boot+uefi though, maybe that's the issue? I don't know how to do a custom /boot for non-UEFI though (I think there's a config.txt file I need? grub?). UEFI was easier to get going with. Any chance you could send me the contents of your /boot directory or instructions on how you populated it? maybe a fdisk dump too? I do not use UEFI, opting for booting directly from u-boot instead. Here is my disk layout:
Code: $ sudo fdisk -l
Disk /dev/mmcblk2: 58.24 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: <derp>
Device Start End Sectors Size Type
/dev/mmcblk2p1 64 32767 32704 16M Linux reserved
/dev/mmcblk2p2 32768 122140671 122107904 58.2G Linux filesystem
There the first partition is just to protect the area on eMMC used by u-boot, the second partition is where I actually have the system installed. I installed already referenced above BSP u-boot manually, using good ol' `dd`. I also have `u-boot-menu` package installed, that automatically generates extlinux-style boot menu for u-boot. In my /boot I have just the vmlinuz images, kernel build config files, initramfs images, system map, and `extlinux` folder that has single automatically generated by u-boot-menu `extlinux.conf` file.
When you say "everything boots OK", does that mean you get your usual basic VT1 through VT6 where you can enter your username and password in text mode and get to your basic shell of choice (bash, zsh, fish, whatever)? If yes, then I'd start troubleshooting by trying `startx` command, which should be a part of `xinit` package.
This message was created with 100% recycled electrons
How did you enable the 3D acceleration? I tried this a couple of days ago and the X server was very much not accelerated.
(06-06-2021, 07:00 PM)moonwalkers Wrote: When you say "everything boots OK", does that mean you get your usual basic VT1 through VT6 where you can enter your username and password in text mode and get to your basic shell of choice (bash, zsh, fish, whatever)? If yes, then I'd start troubleshooting by trying `startx` command, which should be a part of `xinit` package.
Thank you for the info! I can only get serial console access, I don't get any output to the laptop screen. I see the GPU is recognized (mali driver etc) and I have a /dev/dri/card0 endpoint, but startx complains no screens can be found (same with GDM and friends). Specifically it says /dev/fb0 does not exist, but I can't confirm or deny that is something important (may not be needed in newer versions).
Did you have to change any X settings? Can you paste your boot cmdline (append line in extlinux)?
(06-07-2021, 06:32 AM)thequailman Wrote: Thank you for the info! I can only get serial console access, I don't get any output to the laptop screen. I see the GPU is recognized (mali driver etc) and I have a /dev/dri/card0 endpoint, but startx complains no screens can be found (same with GDM and friends). Specifically it says /dev/fb0 does not exist, but I can't confirm or deny that is something important (may not be needed in newer versions).
Did you have to change any X settings? Can you paste your boot cmdline (append line in extlinux)?
Black screen is typical on PBP until Debian kernel 5.10.38 or later. Which kernel version are you running?
This message was created with 100% recycled electrons
(06-07-2021, 08:16 AM)moonwalkers Wrote: (06-07-2021, 06:32 AM)thequailman Wrote: Thank you for the info! I can only get serial console access, I don't get any output to the laptop screen. I see the GPU is recognized (mali driver etc) and I have a /dev/dri/card0 endpoint, but startx complains no screens can be found (same with GDM and friends). Specifically it says /dev/fb0 does not exist, but I can't confirm or deny that is something important (may not be needed in newer versions).
Did you have to change any X settings? Can you paste your boot cmdline (append line in extlinux)?
Black screen is typical on PBP until Debian kernel 5.10.38 or later. Which kernel version are you running?
Latest from testing/sid, 5.10.40
06-07-2021, 09:13 AM
(This post was last modified: 06-07-2021, 09:21 AM by moonwalkers.)
(06-07-2021, 03:15 AM)hjalfi Wrote: How did you enable the 3D acceleration? I tried this a couple of days ago and the X server was very much not accelerated.
I didn't have to do anything special, not on Debian Sid/Unstable. Debian Testing by now should also work fine. So long as you have recent enough Mesa and kernel you should have OpenGL acceleration.
(06-07-2021, 08:29 AM)thequailman Wrote: Latest from testing/sid, 5.10.40
Is that output of `uname -a` when you're connected to serial console? What's the content of your /proc/cmdline? What's the u-boot version you're using? How exactly do you have your UEFI set up, how do you tell your kernel where to find the device tree blobs? Like I already said, I boot directly from u-boot, without any extra UEFI layers, so that's entirely possible that is the crucial difference between our setups.
This message was created with 100% recycled electrons
(06-07-2021, 09:13 AM)moonwalkers Wrote: Is that output of `uname -a` when you're connected to serial console? What's the content of your /proc/cmdline? What's the u-boot version you're using? How exactly do you have your UEFI set up, how do you tell your kernel where to find the device tree blobs? Like I already said, I boot directly from u-boot, without any extra UEFI layers, so that's entirely possible that is the crucial difference between our setups.
No, it's not the exact output but it is that kernel version. I have an EFI partition using systemd-bootd, which loads a loader config that has the /proc/cmdline--nothing fancy, initrd, ftd which points to the dtb on the efi partition, root, and rw mostly. Can you share yours? I see some examples (and the default Manjaro) shows a few video= arguments.
Do you have a /dev/fb0? I saw a kernel regression that this doesn't get setup when using EFI. I'm also assuming you're doing extlinux boot? You have a /extlinux directory on your boot volume? Can you paste the output of it?
(06-07-2021, 11:16 AM)thequailman Wrote: No, it's not the exact output but it is that kernel version. I have an EFI partition using systemd-bootd, which loads a loader config that has the /proc/cmdline--nothing fancy, initrd, ftd which points to the dtb on the efi partition, root, and rw mostly. Can you share yours? I see some examples (and the default Manjaro) shows a few video= arguments.
Do you have a /dev/fb0? I saw a kernel regression that this doesn't get setup when using EFI. I'm also assuming you're doing extlinux boot? You have a /extlinux directory on your boot volume? Can you paste the output of it? Well, your setup is definitely much more fancy than mine. Mine is as simple as a nail - u-boot, extlinux.conf in /boot/extlinux/ generated automatically by u-boot-menu package, and that's about it. My kernel command line is no different from an x86 system - no custom video modes, nothing about console or coherent_pool, just "root=..." and "ro quiet splash". My only customizations to /etc/default/u-boot is reducing timeout from 50 to 10, adding "splash" to parameters, and removing "recovery" from alternatives. I don't have a separate copy of .dtb file in /boot, there is only fdtdir entry in extlinux.conf that's auto-generated by u-boot-menu and points to /usr/lib/linux-image-<whatever>/
I do have /dev/fd0. I didn't bother with EFI because right now the only tangible benefit I see is Secure Boot, but until I start leaving my PBP unattended none of the attack vectors that Secure Boot would mitigate are anywhere near my threat model, so I just don't see the point of all that extra complexity UEFI brings and thus prefer to keep it simple and stupid.
This message was created with 100% recycled electrons
|
