A true mainline Linux Kernel for the Pinebook Pro

[tsys]

@tsys : One more question regarding the upstream kernel - do you currently enable 32bit userland ?

Sorry. This has not really been my main focus. My defconfig does not enable a 32 bit userland. However you can easily do so by setting CONFIG_COMPAT to y.

How is WiFi testing going? Did you experience any crashes since switching to the other firmware?

@tsys & @DrYak, I too would like both 32 and 64 bit userland.

Most everything can stay at 32 bit. But, somethings may work better at one or the other.

Sure. Enabling it in the kernel is easy. However, ARMv8 code will have significantly better performance. Thus only applications that do absolutly need to be run as 32 bit binaries like widevine should be run in compat mode.

Trying to boot this kernel with the stock Debian image that comes pre-installed. I built the defconfig, copied the Image and DTB onto /boot, modules into /lib/modules. It starts to boot, and then I see serial output, but suddenly after the following, it becomes garbage:

[   12.051588] OF: graph: no port node found in /i2c@ff3d0000/fusb30x@22
[   12.065983] OF: graph: no port node found in /i2c@ff3d0000/fusb30x@22/connector
[   12.068329] OF: graph: no port node found in /i2c@ff3d0000/fusb30x@22/connector

Has anyone else seen this? I'm using the 1500000 baud rate, and that works fine for u-boot output and early kernel output until this point. I've tried a few other common baud rates at this point, but nothing shows reasonable output.

Yes, I've seen that before. There is probably no connection between the messages and the weird baudrate though. I've had my pinebook use weird baudrates before. Due to differences in libkmod the debian userland might be unable to load modules compiled from my kernel tree. That might be why your system is not working as expected. I'd suggest installing Manjaro to a Micro SD Card or even the eMMC flash. There the kernel will work properly.

[Solra Bizna]

@tsys : One more question regarding the upstream kernel - do you currently enable 32bit userland ?

Sorry. This has not really been my main focus. My defconfig does not enable a 32 bit userland. However you can easily do so by setting CONFIG_COMPAT to y.

Well, that would explain why my attempts to boot Debian armhf have failed... but now that I know which option to set, let's see if setting it fixes that.

EDIT: still black screen, still gotta wait for that serial cable to get here
EDIT 2: at which point I half expect the serial output to show that it boots successfully but that I just don't have a proper video driver installed...

[danielt]

Well, that would explain why my attempts to boot Debian armhf have failed... but now that I know which option to set, let's see if setting it fixes that.

EDIT: still black screen, still gotta wait for that serial cable to get here
EDIT 2: at which point I half expect the serial output to show that it boots successfully but that I just don't have a proper video driver installed...

I've knocked together a dirt simple userspace Debian installer based on debootstrap (the idea is either to run it from the factory image to provision an SD card or run it from an SD card distro to provision the eMMC).

Until I read this I've only been testing it for arm64 but since it was only a two line change to the installer and I already had CONFIG_COMPAT=y in my kernel config... end result is I can confirm that Debian/armhf using the tsys kernel works fine. I've only done a simple smoke test but WiFi and gnome-shell are both working fine (which in particular means panfrost has come up OK).

If you are interested I'm happy to push it to a git server this evening. As I said it is dirt simple and there's several bits that are currently an exercise for the reader but I'm happy with release-early-release-often so I don't feel I need to finish it before I share it ;-) .

[Hexxeh]

Well, that would explain why my attempts to boot Debian armhf have failed... but now that I know which option to set, let's see if setting it fixes that.

EDIT: still black screen, still gotta wait for that serial cable to get here
EDIT 2: at which point I half expect the serial output to show that it boots successfully but that I just don't have a proper video driver installed...

I've knocked together a dirt simple userspace Debian installer based on debootstrap (the idea is either to run it from the factory image to provision an SD card or run it from an SD card distro to provision the eMMC).

Until I read this I've only been testing it for arm64 but since it was only a two line change to the installer and I already had CONFIG_COMPAT=y in my kernel config... end result is I can confirm that Debian/armhf using the tsys kernel works fine. I've only done a simple smoke test but WiFi and gnome-shell are both working fine (which in particular means panfrost has come up OK).

If you are interested I'm happy to push it to a git server this evening. As I said it is dirt simple and there's several bits that are currently an exercise for the reader but I'm happy with release-early-release-often so I don't feel I need to finish it before I share it ;-) .

I came to the same conclusions last night.

Enabling CONFIG_COMPAT and dropping the baud rate on the cmdline to 115200 means I can now boot the default Debian rootFS. I have to switch baud rates during boot through as it transitions from 1500000 to 115200 when u-boot hands off, so I'll have to rebuild a new u-boot with the lower rate.

It seems that the issue is that not all agetty versions will accept the higher baud rate. This happens on the Manjaro image too, so it isn't a Debian thing.

[Arwen]

...

@tsys & @DrYak, I too would like both 32 and 64 bit userland.

Most everything can stay at 32 bit. But, somethings may work better at one or the other.

Sure. Enabling it in the kernel is easy. However, ARMv8 code will have significantly better performance. Thus only applications that do absolutly need to be run as 32 bit binaries like widevine should be run in compat mode.
...

Thank you for the explanation that ARMv8 code will have significantly better performance. I was not aware of that, and assumed we used ARMhf because 32 bit was faster for most things.

My preference is 64 bit anyway, and WideVine does not mean much to me. (When traveling, I can use a 10" tablet to watch Netflix.)

[manawyrm]

I used debootstrap to extract a Debian sid arm64 userland and recompiled the tsys kernel with the following flags:

Code:

CONFIG_MODULE_SIG_FORMAT=y
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_ASM_MODVERSIONS=y
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_SHA256=y
CONFIG_MODULE_SIG_HASH="sha256"
CONFIG_MODULES_TREE_LOOKUP=y

Then the debian userland tools (modprobe, etc.) were able to load the kernel modules.

1 big ext4 partition on a SD card, copied u-boot to the 32768 byte offset, installed kernel, modules, headers and (important!) the device tree from tsys/linux-pinebookpro.

Graphics also work, but I wasn't able to get xf86-video-fbturbo-git working.

[tsys]

Hey everyone,

more good news: DP altmode on the USB-C port is now working!

Support is not perfect and pretty hacky but it should still work just fine. It does only work in one USB-C plug orientation for me though. Since it does only work in one orientation on the stock debian image, too I'm currently suspecting my USB-C -> HDMI cable. Unfortunately I do not have any other device that can do USB-C DP altmode thus I can't really test that hypothesis.

[Arwen]

@tsys, Do you happen to know if the DP Alt-mode over USB-C is using 2 or 4 lanes?

If I understand DP Alt-mode correctly, (and it's possible I don't :-), if we use 2 lanes for DP, we can use the other 2 lanes for USB 3. This would allow some of the USB-C docks to have both video from the Pinebook Pro, (not USB device video), And USB 3 peripherals like Gigabit Ethernet and more USB 3 ports via a hub.

A drawback to using DP Alt-mode over 2 lanes is that it would limit the resolution or refresh rate. So it's a choice the user would have to make. Use a simple 4 lane DP Alt-mode to video adapter, (I have one that works), and use Pinebook Pro's other USB 3 port for any higher speed peripherals.

[tsys]

@tsys, Do you happen to know if the DP Alt-mode over USB-C is using 2 or 4 lanes?

If I understand DP Alt-mode correctly, (and it's possible I don't :-), if we use 2 lanes for DP, we can use the other 2 lanes for USB 3. This would allow some of the USB-C docks to have both video from the Pinebook Pro, (not USB device video), And USB 3 peripherals like Gigabit Ethernet and more USB 3 ports via a hub.

A drawback to using DP Alt-mode over 2 lanes is that it would limit the resolution or refresh rate. So it's a choice the user would have to make. Use a simple 4 lane DP Alt-mode to video adapter, (I have one that works), and use Pinebook Pro's other USB 3 port for any higher speed peripherals.

I think the Pinebook Pro hardware should support Pin assignments C, D and E. Of those only mode D supports DP + USB. Since the rk3399 supports 4k@60HZ with DP 1.2 it must be using 4 lanes in mode C and/or E. I've added software support for all of the modes but sadly I'm missing a dock to test the USB mode. I've just ordered a cheap dock with DP altmode and one superspeed USB port so I can do some testing. Will get that in a few days.

[DrYak]

How is WiFi testing going? Did you experience any crashes since switching to the other firmware?

I had a couple of occasions to test it and haven't seen any crash.
I noticed today a 2019-11 firmware popping up in the Manjaro repository, I'll see how that one handles.

Sorry. This has not really been my main focus. My defconfig does not enable a 32 bit userland. However you can easily do so by setting CONFIG_COMPAT to y.

Any chance of enabling it by default in the kernel ? Useful for people who might be thinking about playing around with 32bit userland / in chroots / in containers.
(hacking stuff for Raspberry Pi, getting the "Digital Restriction Management" to work, etc.)

Thank you for the explanation that ARMv8 code will have significantly better performance. I was not aware of that, and assumed we used ARMhf because 32 bit was faster for most things.

There was that urban legend that 64bit is slower because pointers are now 2x) wider and thus take more RAM, and somehow that would (magically ?) amount to more bloat... (Hence also all the time some have lost around setting up the "ia32x" userland).
Not true in practice (unless you can come with some weird example where most of used datatype is nearly exclusively pointer).

In practice in most of the 64bit variant of architecture introduce more register (AMD64 vs IA32 is the most widely known example (they doubled all the registers everywhere, including SIMD registers). From my limited knowledge of the platform Aarch64 has also a few more registers available), introduced new more efficient instructions, and also can do 64bit chunks of processing at a time which is useful when tackling very large bit structures (think cryptography and their 512 to 4096 bits keys).
All these strongly help making 64 bit code faster.

The reason 32bits userland stuck for so long is: *LEGACY*.
By the time AMD64 arrived, there were tons of legacy blob for IA32 on Windows on which people where highly dependent (even trivial stuff like Flash plugin in browser).
By the time Aarch64 arrived, huge swathes of the Android ecosystem were Arm7 only.
So each time it's easier for companies like Microsoft and Google to keep large chunk of 32bits userland than try track every single one maker of critical blobs and force them to recompile the blob 64bits (and debug).
So Windows 10 is mixed bi-arch, and Android is hybrid 64bit Linux kernel with 32bit Google (bionic/etc.) userland.

On GNU/Linux we don't have this problem at all:
- opensource mean source is available and so re-compiling isn't that hard, one some automatic build systems, that's even as simple as "just" enabling an extra arch.
- linux has been ported under nearly every architecture under the sun (the mythical toaster running linux) so by the time AMD64 poped-up into existence, there was already lots of code battle tested on other different 64bit arch. (I personnally remember SuSE making a special AMD64 edition in the months following the release of the first Athlon64, and it more or less worked - I had maybe to recompile a newer patched Pidgin and that's about it).
Only the closed source parts are troublesome:
- blob drivers (was a porblem back in AMD64 era, not that much anymore)
- flash player used to be a thing back then (32-to-64bits wrapper emerged, a few attempts at opensource re-implementation such as Gnash, and eventually HTML5/CSS/Javascript killed it definitely).

I think the Pinebook Pro hardware should support Pin assignments C, D and E. Of those only mode D supports DP + USB. Since the rk3399 supports 4k@60HZ with DP 1.2 it must be using 4 lanes in mode C and/or E. I've added software support for all of the modes but sadly I'm missing a dock to test the USB mode. I've just ordered a cheap dock with DP altmode and one superspeed USB port so I can do some testing. Will get that in a few days.

Oh joy! (Which model did you pick up, by the way ?)
Looking forward to this.
Having the display out work on projector will about to feature-complete my uses cases of the laptop (I want to use it for presentations too).

Is the C/D/E mode auto detected, or is it something that needs to be set by the user depending on the plugged in hub ?
(I'm a total USB-C noob).

It does only work in one USB-C plug orientation for me though. Since it does only work in one orientation on the stock debian image, too I'm currently suspecting my USB-C -> HDMI cable.

Hmmm... didn't think about testing orientations last time I played with stock Debian.

Graphics also work, but I wasn't able to get xf86-video-fbturbo-git working.

Keep in mind that panfrost and xf86-video-fbturbo-git aren't compatible with each other.
(~turbo currently works only with the official proprietary blob).