A true mainline Linux Kernel for the Pinebook Pro

[danielt]

This looks really promising! Thanks for the effort. LUKS encryption would be a beautiful addition, but I have retrofitted this on to other Debian-derived distros, post-install. In this case, it looks like a job for which the USB eMMC adaptor would be very useful!

Nice of you to say so but this thread is about the mainline kernel... and I certainly didn't intend to derail it. Let's discuss it on the thread for installer.

[Der Geist der Maschine]

In these days, I'm running Manjaro off a slow micro SD card ... and all my problems are gone. I have an uptime of 7 days and counting. I would prefer Debian running on a 5.4 kernel, though.

Now that I have a debug cable, I can confirm that the default Debian+MATE distro does boot with pinebook_pro_defconfig plus CONFIG_COMPAT, just (as sort of expected) without functioning video. Next stop: debootstrap!

When I read here about CONFIG_COMPAT a few days ago, I booted a 5.4 kernel with that option as well. As you observed, the screen remained black. I could not ping the Pinebook Pro. Even if video is not set up, the laptp should be pingable and ssh-able, shouldn't it? Did you try that?


What will you do with debootstrap? Can't you ssh into your Pinebook Pro and load various video drivers (and eventually load one in /etc/modprobe of whatever it's called)?

[Solra Bizna]

When I read here about CONFIG_COMPAT a few days ago, I booted a 5.4 kernel with that option as well. As you observed, the screen remained black. I could not ping the Pinebook Pro. Even if video is not set up, the laptp should be pingable and ssh-able, shouldn't it? Did you try that?


What will you do with debootstrap? Can't you ssh into your Pinebook Pro and load various video drivers (and eventually load one in /etc/modprobe of whatever it's called)?

Fiddling around with the serial console, I wasn't able to get the network up. Which it turns out is because the cable was outputting 5V instead of 3.3V and breaking all sorts of things, including WiFi.

I have to use Debian because of ... reasons. I'm debootstrapping up a particular LUKS setup, and since it's Bullseye I get both Panfrost and the GNOME desktop in the deal. danielt's installer installs this kernel and everything else you'd expect on a standard Debian Bullseye system. I didn't upgrade mrfixit's build in place because I don't want to run into problems coexisting with the setup that he already did; instead I'm keeping that build around, intact, as a "rescue OS", for when (when) I screw something up on my "main OS".

[tsys]

Hey all,

took me some time but I finally got around to enable CONFIG_COMPAT in the defconfig. I've enabled CONFIG_KEXEC_FILE, too just in case someone wants to toy around with that.

[DrYak]

I tested today with all three of my USB-C to HDMI adapters... all can put up a display (and are reversible).

Thanks for testing! Kind of expected my cable to be at fault here.

Did also some tests with the standard-issue LMP mini-dock at my work place.
(I've put all the details in the USB-C docks thread in the Hardware subforum)

Long story short:

• In my case, too. It only works in one orientation and never in the other (except USB-PD).
  
• It's one of these which is supposed to be able to both USB-3 and HDMI 4k @60Hz (so able to dynamically assign high-speed lanes to either USB-3 or DisplayPort depending on needs).
  
• It cycles weirdly
  
• But if setup on a 2-lanes only mode (e.g.: 1920x1080 @24fps) everything works perfectly.
  

This strongly makes me think of some race condition happening between the OS trying to enumerate everything available (USB-PD, everything on USB-3, all the display modes on DP) and the drivers assigning high-speed lanes to either USB-3 or HDMI.

In one orientation: probing 4K @60Hz requires 4 DisplayPort lanes, which would yank out the two USB3 lanes, which would trigger a rescan of the USB-3, which in turn yaks out two out of the four DisplayPort lanes, etc. thus the on/off cycles.

In the other orientation: the probing reaches a dead end on the USB-3 lanes where nothing gets detected (random imaginary speculative example: the laptop looks for two USB-3 lanes on the high-speed lanes where the mini-dock gives Display lanes and vice versa). Only USB-PD works because it uses completely different lanes (the charging lanes and the detection lanes).

I might be completely wrong and it might be that the detection of alt-mode is just b0rked on that mini-dock. (the mini-dock just outputs wrong values on the auto-detect lanes, à la Raspberry Pi 4 pretending to be an unpowered audio-jack adapter due to wrong resistors pattern). But I thought it's worth sharing.

---

took me some time but I finally got around to enable CONFIG_COMPAT in the defconfig.

Cool, this will enable me to get Netflix running (requires Widevine on a 32-bits Google Chrome/Chromium), e.g.: in a 32bits chroot.

I've enabled CONFIG_KEXEC_FILE, too just in case someone wants to toy around with that.

...faster reboots into newer kernels?~ :-D

[DrYak]

I've spent some time investigating the failing to load time from RTC at boot. (Some people are circumventing it by fumbling around with NTP daemons).

Looking at the logs:

Code:

$ journalctl --boot | grep -P 'rtc0|timesyncd'|head -n 3
Dec 17 13:44:08 nereid kernel: hctosys: unable to open rtc device (rtc0)
Dec 17 13:44:13 nereid kernel: rk808-rtc rk808-rtc: registered as rtc0
Dec 17 13:44:17 nereid systemd-timesyncd[791]: System clock time unset or jumped backwards, restoring from recorded timestamp: Tue 2019-12-17 23:29:02 CET

Seems that there's a race condition: kernel's `hctosys` tries to fetch time before the RTC driver has actually registered a device to fetch from, and thus when timesyncd starts the clock is still wrong and gets restored from last shutdown timestamp.

It looks like a time race that looks exactly like this bug report.

In pinebook pro's situation:

Code:

$ zgrep -P 'RTC_(HCTOSYS|SYSTOHC|DRV_RK808)' /proc/config.gz
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_DRV_RK808=m

it seems that we hit the same situation:
- hctosys is a built-in kernel function and is ran immediately during kernel start-up, at which time there is no RTC available yet.
- rk808 is a module and is loaded much later (5 sec later), by which time it's too late.

Compare with a PC Workstation:

Code:

> zgrep -E 'RTC_(HCTOSYS|SYSTOHC|DRV_CMOS)' /proc/config.gz
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
CONFIG_RTC_DRV_CMOS=y

and thus

Code:

> sudo dmesg | grep rtc0
[    1.384356] rtc_cmos 00:04: registered as rtc0

RTC is loaded almost immediately and there are no error from hctosys.

Would it be possible to:
- either compile the RK808 driver as builtin? (CONFIG_RTC_DRV_RK808=y like the bug report mentionned above)
- or add a udev rule to `hwclock --hctosys` as soon as rtc0 is registered ?

[tsys]

I've spent some time investigating the failing to load time from RTC at boot. (Some people are circumventing it by fumbling around with NTP daemons).

I saw someone mention that problem on the Dicord the other day.
I've just looked at it. First and foremost the IRQ GPIO of the pmic is just wrong which will prevent pretty much all read operations on the RTC from succeeding. I've fixed that.

Looking at the logs:

Code:

$ journalctl --boot | grep -P 'rtc0|timesyncd'|head -n 3
Dec 17 13:44:08 nereid kernel: hctosys: unable to open rtc device (rtc0)
Dec 17 13:44:13 nereid kernel: rk808-rtc rk808-rtc: registered as rtc0
Dec 17 13:44:17 nereid systemd-timesyncd[791]: System clock time unset or jumped backwards, restoring from recorded timestamp: Tue 2019-12-17 23:29:02 CET

Seems that there's a race condition: kernel's `hctosys` tries to fetch time before the RTC driver has actually registered a device to fetch from, and thus when timesyncd starts the clock is still wrong and gets restored from last shutdown timestamp.

It looks like a time race that looks exactly like this bug report.

In pinebook pro's situation:

Code:

$ zgrep -P 'RTC_(HCTOSYS|SYSTOHC|DRV_RK808)' /proc/config.gz
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
CONFIG_RTC_DRV_RK808=m

it seems that we hit the same situation:
- hctosys is a built-in kernel function and is ran immediately during kernel start-up, at which time there is no RTC available yet.
- rk808 is a module and is loaded much later (5 sec later), by which time it's too late.

Compare with a PC Workstation:

Code:

> zgrep -E 'RTC_(HCTOSYS|SYSTOHC|DRV_CMOS)' /proc/config.gz
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
CONFIG_RTC_DRV_CMOS=y

and thus

Code:

> sudo dmesg | grep rtc0
[    1.384356] rtc_cmos 00:04: registered as rtc0

RTC is loaded almost immediately and there are no error from hctosys.

Would it be possible to:
- either compile the RK808 driver as builtin? (CONFIG_RTC_DRV_RK808=y like the bug report mentionned above)
- or add a udev rule to `hwclock --hctosys` as soon as rtc0 is registered ?

The broken load order of the rtc subsystem is probably an issue, too though. Imho hctosys is missing a mechanism to defer loading unti the rtc dev appears. Adding the RTC module as a builtin does result in the correct load order since it uses a late initcall. I'm not sure I like that solution though.

[DrYak]

I saw someone mention that problem on the Dicord the other day.
I've just looked at it. First and foremost the IRQ GPIO of the pmic is just wrong which will prevent pretty much all read operations on the RTC from succeeding. I've fixed that.

Thank you for fixing it!

The broken load order of the rtc subsystem is probably an issue, too though. Imho hctosys is missing a mechanism to defer loading unti the rtc dev appears. Adding the RTC module as a builtin does result in the correct load order since it uses a late initcall. I'm not sure I like that solution though.

I was suggesting the builtin route, because it follows the same solution path that CMOS RTC is doing on PC-compatible class hardware.

But if you prefer not to do it, then the best strategy would be to use UDEV rules to manually call the hctosys, or compile *that* one as module (is it possible) and load the module right after /dev/rtc0 shows up (again, courtesy of some udev rule).
It's basically way to force the *deferring until rtc dev appears* part.

[tsys]

The broken load order of the rtc subsystem is probably an issue, too though. Imho hctosys is missing a mechanism to defer loading unti the rtc dev appears. Adding the RTC module as a builtin does result in the correct load order since it uses a late initcall. I'm not sure I like that solution though.

I was suggesting the builtin route, because it follows the same solution path that CMOS RTC is doing on PC-compatible class hardware.

But if you prefer not to do it, then the best strategy would be to use UDEV rules to manually call the hctosys, or compile *that* one as module (is it possible) and load the module right after /dev/rtc0 shows up (again, courtesy of some udev rule).
It's basically way to force the *deferring until rtc dev appears* part.

I have now made the rk808 rtc module a builtin. However I do still think the hctosys code just is not particularly good. Using a udev rule has some drawbacks like not updating the system clock on resume from suspend and that kind of stuff. Thus it would then need some systemd integration, too. I just don't think that is worth the hassle.

[ElektromAn]

I think you should set rtc-rk808.c as builtin module.

static int __init rtc_hctosys(void)
will go away (freed) after init phase of the kernel