Pinebook Pro support - Githubissues

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

[x] packaging
- [x] pinebookpro-kernel (https://github.com/void-linux/void-packages/pull/19293)
- [x] pinebookpro-uboot (https://github.com/void-linux/void-packages/pull/19196)
- [x] pinebookpro-base (https://github.com/void-linux/void-packages/pull/19216)
- [x] pinebookpro-firmware (https://github.com/void-linux/void-packages/pull/19197)
[x] add support to scripts in this repo (#109)
- [x] set_target_arch_from_platform in lib.sh.in
- [x] mkplatformfs
- [x] mkimage
[x] fix broken things in the scripts here
- [x] make sure /tmp is mounted correctly (#110)
- [x] fix post-install scripts on cross builds (#111)
[ ] Images available on https://alpha.de.repo.voidlinux.org/live/

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.

jcgruenhage commented 4 years ago

You might need to manually flash the new uboot after updating the uboot package. https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-pinebookpro/-/raw/master/uboot-pinebookpro.install has the instructions for that

CameronNemo commented 4 years ago

Manjaro switched from a custom kernel to the upstream kernel, so we shouldn't need a pinebook pro specific kernel anymore.

Their "upstream kernel" has tons of patches... many of them PBP related. https://gitlab.manjaro.org/manjaro-arm/packages/core/linux

jcgruenhage commented 4 years ago

Ah right, didn't see that. 19 patches in total is indeed quite a lot. So that means we'll stay on a custom kernel package on the pinebook pro for now. I hope that the people who wrote those patches are contributing them upstream..

CameronNemo commented 4 years ago

It seems like they are decidedly not. I took a look at some of the larger sets and they all have "do not mainline" and "hack" stated in them. One of the patches had a call to usleep_range in it haha. They mainly accomplish:

deep suspend (states it is a hack, not for mainline, and is also reportedly not quite functional with the newer blob-free u-boot) edit: I am also noticing an issue where if the audio device is in use when the board is put to sleep, audio becomes unusable until after reboot.
USB type-c altmode (uses extcon to accomplish this, a pattern which the rockchip subsystem maintainer said yesterday is a hack that should not be extended) edit: manjaro dev also commented that rebasing this batch onto 5.8 was not successful.
A set of patches to power cycle the bluetooth and WiFi chips on reboots to ensure that the firmware does not act up. might be upstream-able, but it is a longshot. This is the patchset that contains the sleep, and it also seems not at all specific to the BT/WiFi chipsets in use on the PBP. Maybe we can find a way to manually power cycle the devices from userspace during boot?
some ALSA/sound fixes, these may be upstream-able. I would give it about a 50/50 chance.
some small DTS tweaks for the USB type-c port role and enabling earlycon. Not sure why the latter is useful, but they both seem entirely reasonable to upstream.

Overall, if we are fine sacrificing deep suspend and USB-C altmode until someone finds solutions for both using the right methods (ATF's PSCI interface and the "battle plan" in Heiko's mail linked above, respectively), then I would say we have a highly maintainable kernel. BT/WiFI stability is non-negotiable for me, but that patchset is the smallest of the first three large ones.

CameronNemo commented 4 years ago

Hi all, I have a PR to update to U-Boot to the 2020.10 release: https://github.com/void-linux/void-packages/pull/21199

Algorithmus commented 3 years ago

I had an issue with some firmware blobs missing, so the wifi didn't work correctly when I ran the voidlinux image on my pinebook pro. The firmware came from here: https://gitlab.manjaro.org/manjaro-arm/packages/community/ap6256-firmware

nore4 commented 3 years ago

@jcgruenhage I used void-mklive unchanged to build the image. Did an lvm on luks installation with boot unencrypted on a seperate partition.

In /boot/boot.txt you need to add/update some bootargs:
* `root=/dev/void/root` (void is the name of my lvm volume group and root is the name of the volume)

* `rd.auto=1` (to enable auto assembly of luks/lvm, without that it wont ask for a password and won't boot)

* `cryptdevice=/dev/mmcblk2p2:lvm` (you can use persistent block naming too here, should be the better choice)
Update /boot/boot.scr: mkimage -A arm -O linux -T script -C none -n "boot script" -d /boot/boot.txt /boot/boot.scr

Build initramfs (dracut should pick up on the needed modules automatically): dracut

Convert the initramfs to a the u-boot format:
* `mkimage -A arm64 -O linux -T ramdisk -C none -d /boot/initRamfs-5.6.0_1.img initRamfs-5.6.0_1.img`
  -`mv initRamfs-5.6.0_1.img /boot/initRamfs-5.6.0_1.img`
The boot.txt provided by pinebookpro-uboot picks that up automatically.

Add the cryptdevice to /etc/crypttab: crypt /dev/mmcblk2p2 none luks (again, uuid should work too).

That's what I did, hope it helps. I am also not sure if I can leave parts of that out, still trying stuff and I am very new to the arm world :)

EDIT: so, the dracut part was only necessary because it failed during the initial installation (don't know why), after running xbps-reconfigure -f pinebookpro-kernel it generated the initramfs correctly.

And the crypttab part is not necessary either, only makes you input the password twice.

Awesome work! Thanks to everyone involved in this project. I really enjoy the Pinebook Pro and Void Linux is one of my favorite distros! I have a question regarding fde. I know how to install Void on x86 with lvm/fde but I just can't get it to work on the Pinebook Pro. I've tried moving files from the image after setting up lvm with unencrypted boot following the steps mentioned. I've tried so many combinations and I'm lost. I feel like I'm missing something important in this little "guide". Would you or someone else mind explaining this a little more in depth? Like a small howto would be very appreciated. Sorry if I'm missing something obvious here but I think this is also a great way to learn. Thnx and take care all!

thallian commented 3 years ago

@snufkin99 You can take a look at how I am doing it when installing: https://code.vanwa.ch/sebastian/void-linux-pbp-installer

The relevant parts for fde are in the luks, fstab and boot_scr functions (just look for these words, the function names are not exactly that). Also ensure to have the packages dracut, lvm2 (if using lvm) and cryptsetup installed.

My email is on the website that is linked on my gitlab profile, that might be a better way to figure out communications without spamming the issue here : )

the-maldridge commented 3 years ago

@jcgruenhage 12/12 are done on this ticket, are there remaining work items you'd like it kept open for?

jcgruenhage commented 3 years ago

@the-maldridge yeah, sorry, haven't updated this ticket in a while. Ideally I'd like to see images on the download site, added that to the list. Does that sound okay to you, or would you prefer having the issue closed as it is right now?

via commented 3 years ago

I'm experiencing kernel oops's in the pinebookpro-kernel 5.10.35 that prevent void from being usable. They usually trigger when the cpu/disk is under load, and I've reproduced this on both a usb root device as well as the emmc. Has anyone else seen this?

[  601.089721] Unable to handle kernel paging request at virtual address ffff00003d530000
[  601.090420] Mem abort info:
[  601.090667]   ESR = 0x96000047
[  601.090937]   EC = 0x25: DABT (current EL), IL = 32 bits
[  601.091401]   SET = 0, FnV = 0
[  601.091670]   EA = 0, S1PTW = 0
[  601.091947] Data abort info:
[  601.092200]   ISV = 0, ISS = 0x00000047
[  601.092537]   CM = 0, WnR = 1
[  601.092799] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000001815000
[  601.093382] [ffff00003d530000] pgd=00000000f3ff9003, p4d=00000000f3ff9003, pud=00000000f3ff8003, pmd=00000000f3e18003, pte=006800000000446e
[  601.094479] Internal error: Oops: 96000047 [#1] SMP
[  601.094906] Modules linked in: clk_rk808 rk808_regulator rtc_rk808 rk808 cw2015_battery fan53555 regmap_i2c gpio_keys hid_multitouch panfrost gpu_sched rockchipdrm dw_mipi_dsi dw_hdmi analogix_dp cec drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_rk3x panel_simple drm drm_panel_orientation_quirks i2c_core pwm_bl btrfs blake2b_generic xor xor_neon zstd_compress raid6_pq
[  601.097925] CPU: 4 PID: 5259 Comm: gzip Not tainted 5.10.35_1 #1
[  601.098448] Hardware name: Pine64 Pinebook Pro (DT)
[  601.098876] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
[  601.099405] pc : clear_page+0x14/0x28
[  601.099731] lr : kernel_init_free_pages+0x68/0xa0
[  601.100141] sp : ffff800018c839e0
[  601.100432] x29: ffff800018c839e0 x28: ffff8000133fb6c0 
[  601.100898] x27: ffff800018c83b10 x26: 0000000000000000 
[  601.101364] x25: 0000000000000000 x24: ffff8000133fcfc0 
[  601.101829] x23: 0000000000000001 x22: ffff000000000000 
[  601.102294] x21: 0000000000f54c40 x20: ffff00002ae08e80 
[  601.102759] x19: 0000000000f54c00 x18: 0000000000000000 
[  601.103224] x17: 0000000000000000 x16: 0000000000000000 
[  601.103689] x15: 0000000000000000 x14: 0000000000000003 
[  601.104154] x13: 00000000000b67d4 x12: 0000000000000040 
[  601.104619] x11: ffff00000f2e8248 x10: ffff800018c83d50 
[  601.105084] x9 : 0000000000001000 x8 : 00000000f7e00000 
[  601.105549] x7 : 0000000000000018 x6 : ffff800013c71870 
[  601.106014] x5 : ffff800013c71870 x4 : 0000000000000001 
[  601.106479] x3 : 0000000000000881 x2 : 0000000000000004 
[  601.106944] x1 : 0000000000000040 x0 : ffff00003d530000 
[  601.107410] Call trace:
[  601.107627]  clear_page+0x14/0x28
[  601.107919]  prep_new_page+0xa8/0xd4
[  601.108234]  get_page_from_freelist+0x1e0/0x280
[  601.108630]  __alloc_pages_nodemask+0x138/0x2c0
[  601.109028]  pagecache_get_page+0x1dc/0x3ec
[  601.109394]  grab_cache_page_write_begin+0x28/0x4c
[  601.109815]  ext4_da_write_begin+0xb4/0x3d0
[  601.110183]  generic_perform_write+0xa8/0x1d0
[  601.110564]  ext4_buffered_write_iter+0x9c/0x180
[  601.110968]  ext4_file_write_iter+0x34/0x60
[  601.111335]  new_sync_write+0xe8/0x184
[  601.111662]  vfs_write+0x220/0x2b4
[  601.111961]  ksys_write+0x68/0xf4
[  601.112252]  __arm64_sys_write+0x20/0x2c
[  601.112602]  el0_svc_common.constprop.0+0x78/0x1a0
[  601.113021]  do_el0_svc+0x24/0x90
[  601.113314]  el0_svc+0x14/0x20
[  601.113584]  el0_sync_handler+0x1a4/0x1b0
[  601.113935]  el0_sync+0x178/0x180
[  601.114229] Code: d53b00e1 12000c21 d2800082 9ac12041 (d50b7420) 
[  601.114762] ---[ end trace 3ed49acd6eab72af ]---
[  601.286828] Unable to handle kernel paging request at virtual address ffff00003d5b0000
[  601.287680] Mem abort info:
[  601.287944]   ESR = 0x96000047
[  601.288219]   EC = 0x25: DABT (current EL), IL = 32 bits
[  601.288687]   SET = 0, FnV = 0
[  601.288960]   EA = 0, S1PTW = 0
[  601.289237] Data abort info:
[  601.289494]   ISV = 0, ISS = 0x00000047
[  601.289834]   CM = 0, WnR = 1
[  601.290102] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000001815000
[  601.290690] [ffff00003d5b0000] pgd=00000000f3ff9003, p4d=00000000f3ff9003, pud=00000000f3ff8003, pmd=00000000f3e18003, pte=00680000000044ae
[  601.291804] Internal error: Oops: 96000047 [#2] SMP
[  601.292236] Modules linked in: clk_rk808 rk808_regulator rtc_rk808 rk808 cw2015_battery fan53555 regmap_i2c gpio_keys hid_multitouch panfrost gpu_sched rockchipdrm dw_mipi_dsi dw_hdmi analogix_dp cec drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_rk3x panel_simple drm drm_panel_orientation_quirks i2c_core pwm_bl btrfs blake2b_generic xor xor_neon zstd_compress raid6_pq
[  601.295320] CPU: 0 PID: 5279 Comm: htop Tainted: G      D           5.10.35_1 #1
[  601.295967] Hardware name: Pine64 Pinebook Pro (DT)
[  601.296400] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
[  601.296938] pc : clear_page+0x14/0x28
[  601.297270] lr : kernel_init_free_pages+0x68/0xa0
[  601.297684] sp : ffff800018d43b30
[  601.297979] x29: ffff800018d43b30 x28: ffff8000133fb6c0 
[  601.298453] x27: ffff800018d43c60 x26: 0000000000000000 
[  601.298927] x25: 0000000000000000 x24: ffff8000133fcfc0 
[  601.299400] x23: 0000000000000001 x22: ffff000000000000 
[  601.299873] x21: 0000000000f56c40 x20: ffff0000f2ef6580 
[  601.300346] x19: 0000000000f56c00 x18: 0000000000000000 
[  601.300818] x17: 0000000000000000 x16: 0000000000000000 
[  601.301291] x15: 0000000000000000 x14: 0000000000000003 
[  601.301764] x13: 00000000000b66d8 x12: 0000000000000000 
[  601.302237] x11: 0000000000000000 x10: ffff00002dcc1000 
[  601.302710] x9 : 0000000000000001 x8 : 00000000f7e00000 
[  601.303183] x7 : 0000000000000018 x6 : ffff800013c71870 
[  601.303656] x5 : ffff800013c71870 x4 : 0000000000000001 
[  601.304128] x3 : 0000000000000881 x2 : 0000000000000004 
[  601.304601] x1 : 0000000000000040 x0 : ffff00003d5b0000 
[  601.305074] Call trace:
[  601.305297]  clear_page+0x14/0x28
[  601.305596]  prep_new_page+0xa8/0xd4
[  601.305918]  get_page_from_freelist+0x1e0/0x280
[  601.306322]  __alloc_pages_nodemask+0x138/0x2c0
[  601.306725]  do_cow_fault+0x3c/0x220
[  601.307043]  do_fault+0x3c/0x250
[  601.307333]  handle_pte_fault+0x74/0x1a0
[  601.307684]  __handle_mm_fault+0x10c/0x190
[  601.308049]  handle_mm_fault+0x9c/0x200
[  601.308395]  do_page_fault+0x168/0x3e4
[  601.308732]  do_translation_fault+0xb0/0xdc
[  601.309106]  do_mem_abort+0x44/0xa4
[  601.309418]  el0_da+0x28/0x34
[  601.309686]  el0_sync_handler+0x168/0x1b0
[  601.310043]  el0_sync+0x178/0x180
[  601.310347] Code: d53b00e1 12000c21 d2800082 9ac12041 (d50b7420) 
[  601.310886] ---[ end trace 3ed49acd6eab72b0 ]---

via commented 3 years ago

I still was using u-boot from my previous debian installation. Using the void package's u-boot on my emmc seems to have resolved this.

vdo commented 3 years ago

Are the final images going to be generated?

Johnnynator commented 3 years ago

Are the final images going to be generated?

I wanted to wait until uboot has a version released that supports initialising the display panel and allow for some crude boot menu. Afaik 2021.07 should support that. (And maybe also fixup or default non pinebook pro kernel config to work fine on a pbp).

So maybe August, maybe a bit later.

CameronNemo commented 3 years ago

@Johnnynator have you by chance tried a U-Boot with ATF with the suspend patch? (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9616) I have been meaning to give it a spin, but have not had much time.

jcgruenhage commented 3 years ago

Re uboot: we should pribably fix that it breaks customized uboot stuff on each update: my luks encrypted pbp refuses to boot because I forgot to fix that after an upgrade. Easy-ish to fix, but I'll have to whip out a live system for that again

Johnnynator commented 3 years ago

Yeah, hardcoding the bootargs in the uboot kernel hook is bad. I currently use u-boot-menu, which just reuses the bootargs if the booted system. Should probably also just noticed, why do we even hardcode the Mac address in the uboot image

CameronNemo commented 3 years ago

I would be glad to see void just ship u-boot-menu by default for the PBP. Much cleaner, easier to understand and customize.

Skirmisher commented 3 years ago

If the latest u-boot has display support, then using u-boot-menu is probably the best thing to do. I do remember an oddity with u-boot's extlinux.conf parsing where the timeout value is evaluated as tenths of a second for some reason, and if the value was less than 10 then it was interpreted as "no timeout", meaning your computer was effectively hung if you had no display or serial console to proceed with.

Also, last I checked, the install.d script in the u-boot-menu package uses some broken logic for figuring out the boot and root filesystems, and uses PARTUUID instead of UUID on the kernel cmdline, which is dubious. I have a fixed version of the script, but I haven't used the PBP in a long time so I haven't updated the package.

Johnnynator commented 3 years ago

Yeah, the u-boot-menu script would need some more work. (I only ever fixed it to not break on dash as sh).

As alternative using grub or refind might even give a more user friendly (and familiar) interface, and are more tested than half broken extlinux generators named u-boot-menu :). But my last attempt with getting an image with refind resulted in it not finding any systems, and a ton of errors spammed in u-boot (too fast to read, need to check it over serial).

And yes 2021.07 has working display support, but I need to investigate where my builds (also with 2021.04) fail to boot our kernels,

CameronNemo commented 3 years ago

Also, last I checked, the install.d script in the u-boot-menu package uses some broken logic for figuring out the boot and root filesystems, and uses PARTUUID instead of UUID on the kernel cmdline, which is dubious.

➜ rg PARTUUID srcpkgs/u-boot-menu/
➜ rg UUID srcpkgs/u-boot-menu/
➜ rg root srcpkgs/u-boot-menu/

Not seeing any handling for root at all. Looks like you inherited it from the PBP specific kernel script:

➜ rg PARTUUID srcpkgs/pinebookpro-uboot/
srcpkgs/pinebookpro-uboot/files/kernel.d/uboot
6:partuuid=$(blkid -o value -s PARTUUID "${dev}")
17:setenv bootargs console=ttyS2,1500000 console=tty1 root=PARTUUID=${partuuid} rootwait video=eDP-1:1920x1080@60 loglevel=4

u-boot-menu does have some weird logic for /boot, but the logic seems to work. I guess it could be simplified a bit (e.g. just check if mountpoint -q /boot and prefix the paths with /boot otherwise).

I have a fixed version of the script, but I haven't used the PBP in a long time so I haven't updated the package.

Well feel free to shoot your changes over. I would be curious about what is broken. I don't doubt that there are edge cases not covered, but for the images created by void-mklive it seems to do alright.

Skirmisher commented 3 years ago

Not seeing any handling for root at all. Looks like you inherited it from the PBP specific kernel script

Ah you're right, I got that mixed up sometime in the last while. I'll take a look at all the scripts again when I pull out my PBP again.

user18130814200115-2 commented 3 years ago

As for the uboot supporting visual boot and suspend to ram, you might consider using tow boot.

I have been using this fork on my pinebookPro for a while and it works well. It is also the uboot used for the unofficial archlinuxARM repo

CameronNemo commented 3 years ago

@user18130814200115-2 have you confirmed that it works with suspend to RAM? I have tried to get s2ram working and failed.

user18130814200115-2 commented 3 years ago

I managed to get s2r working a while back on ArchlinuxARM with manjaro 5.13.? kernel. I stopped using it though because it does not work with NVME (towboot generally does though).

The visual boot works great though, it displays useful information and has a bootmenu which can also boot from usb. Generally an improvement on das uboot IMO

edit: clairty

void-linux / void-mklive

Pinebook Pro support #105