11-05-2019, 01:07 PM
(This post was last modified: 04-29-2020, 01:14 PM by tsys.)
Hi all,
I've built a true mainline Linux Kernel for the Pinebook Pro. It does only have a minimal amount of patches required to support - the eDP panel Mainlined
- the battery fuel gauge (Mainlining in progress)
- the Pinebook Pro devicetree (Mainline starting 5.7) Mainlined in 5.7
- USB-C DP altmode
- Rockchip SIP driver
- Ultra low power sleep
I do plan on mainlining those patches ASAP.
Display and graphics work using panfrost (xf86-video-fbturbo is not required if your mesa build is recent and has panfrost support). The whole device does pretty much just work as you would expect it to do.
At the moment there are a few caveats: - WiFi seems to be unstable, possibly due to issues with the Broadcom firmware and power management Fixed
- Bluetooth is untested Works through hciattach, actual native support through hci_uart would be great though Migrated to hci_uart and stable
- PCIe is untested PCIe works just fine
- Sound does not work (wip) Fixed though pinctrl
- Bootup takes a long time (~ 3 minutes) since the kernel hangs twice for quite some time during boot Workaround through new defconfig
- Charging via USB-C does not work Fixed though some devicetree adjustments
- Device does not power down fully Workaround in the rk808 driver, proper support in the ATF would be nice
- USB-C DP altmode does not work Fixed, with USB 3.1 gen 2 support
- Suspend to RAM is not working Fixed through forward port of SIP driver. Works only with BSP U-Boot, gives > 200 h standby
Development is taking place in the Manjaro gitlab: https://gitlab.manjaro.org/tsys/linux-pinebook-pro
Have a nice day,
Tobias
Thanks, looking forward to see this upstream 
Quote:I do plan on mainlining those patches ASAP.
Awesome, thanks. Do you have any idea of how well Linux-libre would work? I understand WiFi/Bluetooth won't function - that's fine; are there any other problems?
(11-06-2019, 12:46 AM)aleksei Wrote: Quote:Do you have any idea of how well Linux-libre would work? I understand WiFi/Bluetooth won't function - that's fine; are there any other problems?
Hard to tell. I think there is some binary firmware involved in the display port interface, too. Thus running without any firmware blobs at all might stop the display from working.
(11-06-2019, 11:42 AM)tsys Wrote: (11-06-2019, 12:46 AM)aleksei Wrote: Quote:Do you have any idea of how well Linux-libre would work? I understand WiFi/Bluetooth won't function - that's fine; are there any other problems?
Hard to tell. I think there is some binary firmware involved in the display port interface, too. Thus running without any firmware blobs at all might stop the display from working.
Could you be bothered to test it? It's a "to buy or not to buy" factor for me.
(11-06-2019, 11:16 PM)aleksei Wrote: Could you be bothered to test it? It's a "to buy or not to buy" factor for me.
I've just taken a look at the displayport source for the analogix dp transmitter and it does indeed require firmware. Conceptually that's not really a problem though. The firmware runs on a separate processor inside the display port transceiver to offload timing-critical tasks (of which DP has a lot).
Having to load this blob externally just means that there is no non-volatile memory inside the component itself to store a copy of the firmware permanently. There is probably embedded firmware in quite a few components of the device. Just think about devices like the camera, the rk3399 SoC or the rk808 power management IC. They do most certainly all have non-free firmware inside. The only difference there is that you don't see it.
If you want a real, GNU+free modern device currently no commercially available one is for you. The Pinebook Pro is pretty much as blob-free as it gets. In the distant future there might be RISC-V devices that are truly blob-free. But at the moment there are hardly better choices
(11-07-2019, 02:34 AM)tsys Wrote: The Pinebook Pro is pretty much as blob-free as it gets. But at the moment there are hardly better choices No it's not, and yes there are. Not sure if it would be appropriate to give a shout out to them here (pine64-specific forum), so I better not.
(11-07-2019, 02:34 AM)tsys Wrote: I've just taken a look at the displayport source for the analogix dp transmitter and it does indeed require firmware. Where does this blob come from, can you share a link to it? Interested in the license.
(11-07-2019, 12:07 PM)aleksei Wrote: (11-07-2019, 02:34 AM)tsys Wrote: The Pinebook Pro is pretty much as blob-free as it gets. But at the moment there are hardly better choices No it's not, and yes there are. Not sure if it would be appropriate to give a shout out to them here (pine64-specific forum), so I better not.
There are? All I know of do contain firmware in some chips. You just can't /do not need to upload it into the chip yourself. While this might solve some licensing issues it does not do anything regarding truly free devices.
Quote:aleksei
Quote:tsys
I've just taken a look at the displayport source for the analogix dp transmitter and it does indeed require firmware.
Where does this blob come from, can you share a link to it? Interested in the license.
License seems to be this one https://git.kernel.org/pub/scm/linux/ker...E.rockchip
Blob is this one https://git.kernel.org/pub/scm/linux/ker...p/dptx.bin
11-07-2019, 09:29 PM
This is great, thanks @ tsys !
Hi Tobias
I've been kicking the tyres a bit here. Overall its looking good but I am finding that the display is a bit hit and miss starting up (it worked for about four/five reboots yesterday but today I haven't had a successful boot yet).
Thankfully I grabbed the dmesg for the good boots so I've been able to diff the logs and, other than USB interleaving differently, the only new messages on a "bad" boot are edp timeouts/failures which makes sense given the problem ;-) (full log is here if you want to see it... but nicely tucked out of the way if you don't: https://gist.github.com/daniel-thompson/...ccf59796dd ):
Code: [ 228.390347] [drm:analogix_dp_bridge_atomic_enable [analogix_dp]] *ERROR* failed to get hpd single ret = -110
[ 228.390412] rockchip-dp ff970000.edp: failed to set bridge, retry: 0
[ 228.539603] [drm:analogix_dp_bridge_atomic_enable [analogix_dp]] *ERROR* failed to get hpd single ret = -110
[ 228.539772] rockchip-dp ff970000.edp: failed to set bridge, retry: 1
[ 228.653224] [drm:analogix_dp_bridge_atomic_enable [analogix_dp]] *ERROR* failed to get hpd single ret = -110
[ 228.653356] rockchip-dp ff970000.edp: failed to set bridge, retry: 2
[ 228.766128] [drm:analogix_dp_bridge_atomic_enable [analogix_dp]] *ERROR* failed to get hpd single ret = -110
[ 228.766200] rockchip-dp ff970000.edp: failed to set bridge, retry: 3
[ 228.881911] [drm:analogix_dp_bridge_atomic_enable [analogix_dp]] *ERROR* failed to get hpd single ret = -110
[ 228.882057] rockchip-dp ff970000.edp: failed to set bridge, retry: 4
[ 228.882101] rockchip-dp ff970000.edp: too many times retry set bridge, give it up
I'll go looking for more clues later today but I just wondered if you have seen anything like this yourself as you've been working.
|
