search

void-linux / void-mklive

The Void Linux live image maker
https://voidlinux.org
Other
332 stars 194 forks source link

Pinebook Pro support #105

Open jcgruenhage opened 4 years ago

jcgruenhage commented 4 years ago

This issue tracks progress towards a usable voidlinux image for the Pinebook Pro. Currently, we can already build a working image

How to read the list: A checked box means that the work is done and merged, an unchecked box with a PR linked means that this is basically done, but not merged yet.

KeepBotting commented 4 years ago

Nice to hear about musl images! Going to try that out ASAP.

News post sounds like a great idea. Once support is finalized we will need to add an entry to the Pinebook Pro wiki page here: https://wiki.pine64.org/index.php/Pinebook_Pro_Software_Release

jcgruenhage commented 4 years ago

sudo ./mkplatformfs.sh pinebookpro <aarch64 rootfs> should work, right? This currently gives me FATAL: mkplatformfs.sh: invalid platform!

jcgruenhage commented 4 years ago

sudo ./mkrootfs.sh -o aarch64latest aarch64 is what I used to generate the rootfs

jcgruenhage commented 4 years ago

I did pull right before building

renatoaguiar commented 4 years ago

@renatoaguiar can you confirm a void image for pinebookpro works now?

It worked fine, but I had to build pinebookpro-base from void-packages (master) because it is not yet available in mirrors. I'm trying musl build now.

jcgruenhage commented 4 years ago

Don't mind my previous report, I pulled master from @renatoaguiar's fork... Trying again now with the upstream master branch.

renatoaguiar commented 4 years ago

I tried glibc and musl images from sdcard and they both worked :)

Can someone try booting from emmc?

jcgruenhage commented 4 years ago

building the image right now, will try eMMC boot after that

jcgruenhage commented 4 years ago

Random thought: We should make the uboot prefer the sdcard over the eMMC before publishing this as done to the community, as booting from the sdcard after flashing this image currently requires toggling the eMMC off using a hardware switch inside the chassis of the PBP.

jcgruenhage commented 4 years ago

The image I built does not boot from eMMC it seems.

jcgruenhage commented 4 years ago

I mean it doesn't boot at all, not that it prefers the sdcard

renatoaguiar commented 4 years ago

I've never tried, but @anjandev tried before and it worked at some point.

jcgruenhage commented 4 years ago

I also had eMMC boot work at some point.. https://cloudflare-ipfs.com/ipfs/QmRCcbSic46xgtYLZEj2SFe97HMYF88CKWKj3MNDpCN721 is the image I built, can someone test that on an sdcard to see whether it's generally broken?

jcgruenhage commented 4 years ago

@renatoaguiar could you upload your known-to-work images so that I can try those on my PBP?

jcgruenhage commented 4 years ago

If you send me download links, I will try them from eMMC

renatoaguiar commented 4 years ago

The ones I tested earlier with sdcard are available at https://volans.renatoaguiar.net/pub/

jcgruenhage commented 4 years ago

seems these neither boot from sd nor emmc for me..

jcgruenhage commented 4 years ago

My guess is that they do some booting, but the display just doesn't work for some reason. Debugging that isn't really possible without their 4 pin aux to usb uart thingy.

renatoaguiar commented 4 years ago

It looks like my emmc reader and console cable are coming tomorrow, so I can try and debug booting from emmc.

CameronNemo commented 4 years ago

@renatoaguiar I have updated my pinebookpro-kernel PR, and I tested the firmware package.

CameronNemo commented 4 years ago

I opened a clean, fresh PR. Want to keep the old branch handy in case anyone wants the old packages. https://github.com/void-linux/void-packages/pull/19336 Just realized y'all merged the kernel already haha. I had it built a couple days ago but lacked much time to test during the work week.

sunnaryt commented 4 years ago

that image works for me, until i resize it. i believe it might be an issue with the way uboot on pbp detects a bootable device, but i'm just speculating. i don't have a console cable either

renatoaguiar commented 4 years ago

@sunnaryt boot partition is separate, so I guess it is booting fine. Maybe the root= argument passed to the kernel is wrong after resizing. How are you resizing the partition? Any chances the PARTUUID is changing? Did you change anything in /etc/fstab?

ZachIndigo commented 4 years ago

Mine continues to wok after resizing the partition, hmm

sunnaryt commented 4 years ago

fresh copy: -boots first time -boots 2nd time (to make sure something isn't changing just by booting it) -did nothing else -record uuid -resize via gnome-disks from other linux install (boot untouched) -uuids are the same -boot fails -uuids are still the same

i did nothing besides resize....hmmmm

maybe a different resize method? what do you use @BenEvolent333

update: tried again with gparted resize, no luck

Skirmisher commented 4 years ago

Manjaro includes a pinebookpro-post-install package that adds a couple supplementary files that could be included in pinebookpro-base:

They also edit the logind config to force s2idle, but that can also be forced with a mem_sleep_default=s2idle on the kernel command line. As an aside, the Manjaro kernel supports suspend-to-RAM correctly, the issue lies with the ATF (ARM trust firmware) in mainline U-boot (it works with Rockchip's fork). (Also, the kernel is not truly 5.5.0, but rebased on master shortly after 5.5.0's release for some reason...)

Additionally, the RockPro64 is essentially a subset of the PBP hardware—same SoC and a number of similar peripherals. I've booted an unmodified PBP kernel on the RP64 before, so I could see a rockpro64-kernel vpkg of some sort existing, or maybe the main package being named rk3399-kernel, specifying PBP and RP64 in the description. Will need testing, of course, and something to determine which device tree to point the bootloader at.

Speaking of kernel packaging, from past experience I'm a little annoyed with how the device-specific kernel packages function. There's no old kernel retention/vkpurge support even though it seems quite possible, and it's ugly when packages (e.g. dkms modules) pull in the mainline kernel headers when the system doesn't need them (and then dkms wastes time trying to build for the mainline kver). ignorepkg lets you work around the latter, but it isn't a real solution. I would like to try to improve this and other issues (e.g. naming consistency) in the future to streamline the experience of using Void on ARM devices.

renatoaguiar commented 4 years ago

Manjaro includes a pinebookpro-post-install package that adds a couple supplementary files that could be included in pinebookpro-base

@Skirmisher thanks for pointing that out. I'll take a look and update pinebookpro-base as needed.

ZachIndigo commented 4 years ago

@sunnaryt I used cfdisk, and then resize2fs, from my main laptop before booting from the SD. I also used resize2fs from the pbp while it was running before I had to reinstall because of xorg, and it rebooted just fine.

ZachIndigo commented 4 years ago

I just updated my void install, and installed plasma, and it would seem that no audio devices or Bluetooth adapters were found. I installed pulseaudio, which I thought was already installed, and the device appeared, but still no audio is played.

ZachIndigo commented 4 years ago

@Skirmisher are you saying the issue with suspend-to-RAM could be fixed with using rockchip's fork of uboot?

houki0 commented 4 years ago

I don't think mkimage.sh includes a uboot in the image.

cfdisk doesn't report ~64mb of empty space preceding any partitions, the same as in @KeepBotting 's post:

Here is the partition layout for my Manjaro ARM SD card (which boots properly): https://branon.me/files/NjVkM2E.png And here is Void's SD card: https://branon.me/files/NGJkNWR.png

I think that's why it doesn't boot from eMMC yet.

Here's the output my UART gives me if I flash the image to eMMC:


Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2020.01-2-g365495a329 (Feb 20 2020 - 04:17:35 +0000)
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###```
renatoaguiar commented 4 years ago

@houki0 that's a very good catch. uboot is actually being installed, but the '/boot' partition is overlapping with it. This should cause it to be randomly overwritten at runtime while operating on '/boot' filesystem.

I pushed a fix for that to pbp-local branch of my void-mklive fork (https://github.com/renatoaguiar/void-mklive/tree/pbp-local). @jcgruenhage @sunnaryt, could you guys try it out and check if that fixes your boot/resize problems?

I also pushed new images with that fix to https://volans.renatoaguiar.net/pub/

PR: https://github.com/void-linux/void-mklive/pull/115

Skirmisher commented 4 years ago

@Skirmisher are you saying the issue with suspend-to-RAM could be fixed with using rockchip's fork of uboot?

That's correct; the Manjaro kernel developer was using that when patching suspend into the kernel, not realizing that it didn't work on upstream. (Manjaro was previously using Rockchip's fork of 2017.09, from this tree. The PKGBUILD for that can be found here.)

I don't know how long it'll take for the ATF to get fixed, but so far Manjaro hasn't reverted to the Rockchip version. But they require users to install it manually, so many people are still using the original one anyway.

houki0 commented 4 years ago

@renatoaguiar Your new image boots perfectly and lightning fast! There's a couple weird/useful things with it though:

Here's the boot log from the UART:

Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2020.01-2-g365495a329 (Feb 20 2020 - 04:17:35 +0000)
Trying to boot from MMC2

U-Boot 2020.01-2-g365495a329 (Feb 20 2020 - 04:17:35 +0000) Voidlinux

Model: Pine64 Pinebook Pro
DRAM:  3.9 GiB
PMIC:  RK808 
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Model: Pine64 Pinebook Pro
## Error: Can't overwrite "serial#"
## Error inserting "serial#" variable, errno=1
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3c0000: USB EHCI 1.00
Bus dwc3: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus dwc3: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 3 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
865 bytes read in 13 ms (64.5 KiB/s)
## Executing script at 00500000
22583808 bytes read in 1005 ms (21.4 MiB/s)
63060 bytes read in 33 ms (1.8 MiB/s)
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
Host not halted after 16000 microseconds.
ERROR: reserving fdt memory region failed (addr=0 size=0)
   Loading Device Tree to 00000000f5f0a000, end 00000000f5f1cfff ... OK

Starting kernel ...

The led turns green when it starts the kernel, and that's also where it starts displaying the rest of the log on the screen. I guess the kernel messages get relayed to serial on the other distro's?

Now, the kernel messages aren't necessarily a problem, but the last few unfortunately interfere with the login prompt.

One last thing of note: the messages on the screen don't always start appearing at the exact same time. Usually at around 1.7 seconds out of 3.9 in my case.

I wonder if this is the kernel or uboot doing this?

houki0 commented 4 years ago

Also, login is a bit wonky. (Try pressing arrow keys.) And the kernel messages can randomly interfere with the shell when you're in any tty.

Skirmisher commented 4 years ago

When it boots, it first displays a red power light, which then turns green after a few seconds.

This is a feature of uboot—it's helpful for diagnosing boot issues, since the light turns green only after uboot passes control to the kernel. (If the kernel panics, it flashes red!)

houki0 commented 4 years ago

It doesn't do that with the other distro's though, so I thought I'd report it. Seems pretty useful.

But I tried resizing the root partition a bit, but it doesn't boot anymore now. Uboot seems to work fine though. The light's green and the UART log is the exact same as ever.

Unfortunately, the kernel doesn't output to the UART, so I can't provide any logs this time, but it seems runit hasn't started yet. (acpid doesn't respond to short-pressing the power button.)

Skirmisher commented 4 years ago

It doesn't do that with the other distro's though, so I thought I'd report it. Seems pretty useful

Right, I should have specified—this feature is in mainline uboot only. The 2017.09 Rockchip fork doesn't, and it's what many distros are using.

houki0 commented 4 years ago

Apparently PARTUUID changes when resizing the partition. After editing boot.scr through boot.txt with the new PARTUUID from blkid and compiling it with sudo mkimage -A arm -O linux -T script -C none -n "U-Boot boot script" -d boot.txt boot.scr it works again.

renatoaguiar commented 4 years ago

Apparently PARTUUID changes when resizing the partition. After editing boot.scr through boot.txt with the new PARTUUID from blkid and compiling it with sudo mkimage -A arm -O linux -T script -C none -n "U-Boot boot script" -d boot.txt boot.scr it works again.

It didn't change when I tried. I think it depends on how you do it or what tool you use. In any case it is always good to run xbps-reconfigure -f pinebookpro-kernel after changing things that could affect booting and that also runs mkimage, so you don't need to call it manually.

renatoaguiar commented 4 years ago

The kernel cmdline should have loglevel=4 like we do with GRUB.

https://github.com/void-linux/void-packages/pull/19380

jcgruenhage commented 4 years ago

@renatoaguiar I flashed the musl image to my eMMC, works nicely. Bonus: It seems to prefer the sdcard over the eMMC when booting! Did you change something there or were my previous attempts just failing because the boot itself failed somehow?

renatoaguiar commented 4 years ago

@renatoaguiar I flashed the musl image to my eMMC, works nicely. Bonus: It seems to prefer the sdcard over the eMMC when booting! Did you change something there or were my previous attempts just failing because the boot itself failed somehow?

There is no other changes, so I guess boot itself was failing from eMMC.

jcgruenhage commented 4 years ago

Neither lightdm, nor gdm nor sway work on the latest image you posted, @renatoaguiar. I tried gdm in both xorg and wayland modes, lightdm with the gtk3 greeter with xorg and sway. For gdm, I couldn't find any error in the logs (just some warnings about systemd not being present), same with lightdm. sway complains about being unable to open a wayland socket (https://github.com/swaywm/sway/blob/master/sway/server.c#L142). i3 works, which confuses me a bit. Did anything else change in the latest build? ftr, these are the packages I have installed, they should contain everything needed for this to work:

base-system-0.113_2
base-voidstrap-0.10_1
gnome-3.32.0_2
i3-4.18_1
lightdm-1.30.0_2
lightdm-gtk3-greeter-2.0.7_1
mesa-panfrost-dri-19.3.4_1
pinebookpro-base-0.1_1
sway-1.4_1
xorg-fonts-7.6_5
xorg-input-drivers-7.6_4
xorg-minimal-1.2_2
xtools-0.57_1
jcgruenhage commented 4 years ago

Thanks everyone for the work on this, btw. It's getting quite close now, you've been doing an awesome job!

CameronNemo commented 4 years ago

I think you should have mesa-kmsro-dri installed too, no?

jcgruenhage commented 4 years ago

Why would I need that? Trying now..

CameronNemo commented 4 years ago

just going based off https://panfrost.freedesktop.org/building-panfrost-mesa.html

jcgruenhage commented 4 years ago

So, installed that, sway still can't open a wayland socket and gdm still displays it "oh no, something went wrong" screen

houki0 commented 4 years ago

That's weird. I did get sway to work on that image. Everything wayland-native is a bit laggy though. XWayland actually performs better.

Slightly overkill list of relevant explicitly installed packages (basically all of them except user programs):

About that i3 setup. Hovering over any xfce button, be it a launcher button or a application menu, results in a segfault. And xinit i3 won't start without xterm, and it opens xterm as a i3 window that logs i3 itself, shutting down i3 when closed. With default settings. I've never really messed around with xorg settings.

Most other DE's I tested end up crashing one way or another before showing anything usable. (KDE and MATE.)

It also seems mesa-kmsro-dri, like many other mesa packages, is a dummy package linking to either mesa or mesa-dri.

I'll try to find some meaningful logs later.

EDIT: This is the February 21 glibc image from @renatoaguiar.