A true mainline Linux Kernel for the Pinebook Pro

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