Pinebook Pro support

[jcgruenhage]

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

• packaging
  • pinebookpro-kernel (New package: pinebookpro-kernel-5.5.0 void-packages#19293)
  • pinebookpro-uboot (New package: pinebookpro-uboot-20200212 void-packages#19196)
  • pinebookpro-base (New package: pinebookpro-base-0.1 void-packages#19216)
  • pinebookpro-firmware (New package: pinebookpro-firmware-20200215 void-packages#19197)
• add support to scripts in this repo (Add support for Pinebook Pro (pinebookpro) #109)
  • set_target_arch_from_platform in lib.sh.in
  • mkplatformfs
  • mkimage
• fix broken things in the scripts here
  • make sure /tmp is mounted correctly (lib: make sure /tmp is there and mount it #110)
  • fix post-install scripts on cross builds (Fix execution of 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.

[Vaelatern]

Can we try to use the generic uboot and kernel for this? I believe upstream uboot can run this machine

[jcgruenhage]

If that's possible, absolutely. The kernel still needs a few patches, but is very close to mainline

[Duncaen]

upstream uboot supporting the device does not allow to build a "generic" uboot.

[jcgruenhage]

@xtraeme I do have the hardware here and am willing to test stuff, but I have no experience packaging things like the linux kernel, so your help is appreciated!

A lot of the work done by the manjaro people can be used, like https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinebookpro/tree/master for example, so it's mostly a job of "translating" stuff from their PKGBUILDs to our templates

[houki0]

I've already been playing around with a simple rootfs install by replacing the root partition of the default debian image, so it's running their kernel and uboot right now. It booted just fine out of the box, but I did have to copy the wifi firmware to get wifi to work.

Maybe we could make a pbp-firmware package like the one for the rpi3?

That said, I should be able to test most things, but I'm not great at packaging, and stuff like configuring kernels and uboot is probably beyond me.

[ZachIndigo]

I don't have any packaging knowledge, but I have a pbp and would be willing to offer my services to get void running on it.

[jcgruenhage]

I think we don't lack testers, we mostly lack someone with packaging experience and time who is interested in working on this. I have a bit of experience and am certainly interested, but my schedule is pretty packed right now..

[renatoaguiar]

I can do the packaging. I'm also pretty busy right now, but I hope to find some time to work on that over the weekend.

[sunnaryt]

would really like to see this happen, i only have packaging experience with arch though. i have a lot of free time coming up, like 2 months free time for reasons and PBP is my favorite new toy, i will learn and help maintain if someone points me in the right direction.

[renatoaguiar]

I just pushed WIP to 'pbp' branch on my forks:

• https://github.com/renatoaguiar/void-packages/tree/pbp
  • pinebookpro-kernel (build works, boot not yet tested)
  • pinebookpro-base
• https://github.com/renatoaguiar/void-mklive/tree/pbp
  • add arch detection for pinebookpro
  • add pinebookpro to mkplatformfs

I'm now working on packaging pinebookpro-uboot.

[q66]

you know, there is already void-linux/void-packages#17672

[q66]

Also, we don't want a 4.4 kernel, it won't work with panfrost and the proprietary libmali which works with 4.4 doesn't work with modern userlands (and if you hack around it it still works poorly)

[renatoaguiar]

Also, we don't want a 4.4 kernel, it won't work with panfrost and the proprietary libmali which works with 4.4 doesn't work with modern userlands (and if you hack around it it still works poorly)

From what I read so far, mainline kernel still doesn't support some features, e.g. suspend/resume. My plan is to initially use same version as official (factory) build and upgrade to mainline kernel as soon as it becomes feature complete.

[q66]

Suspend/resume may not work, but accelerated graphics not working is worse.

You can use s2idle for suspend for now, which works.

[houki0]

Assuming the kernel @renatoaguiar packaged is the same one I copied from the default debian (I can confirm they are both version 4.4.202):

I am currently unable to launch any DE or WM both for wayland and x11 (I tested XFCE, KDE on both and Sway). I believe it is an issue with dbus because it seems NetworkManager doesn't work either (I normally use connman so I hadn't noticed before), but runit reports dbus as up, and I can't find any errors with socklog.

I haven't tried a 5.4 or 5.5rc kernel from Manjaro yet because I haven't got those to boot yet, and I don't have a working UART cable to see what's wrong.

In any case, it might be worth looking into.

[q66]

Wayland won't work on 4.4, except weston fbdev. Sway needs drm, and for that you need libmali (with weston you might be able to get away with pixman), and libmali does not expose enough of libgbm to have weston-drm/sway working. Out of curiosity, I set up proprietary libmali and went to make a preload library to stub out the missing libgbm calls, and got far enough to launch weston and sway with drm, but EGL still does not work. In X11, you will not get acceleration either, since GLAMOR requires EGL, which does not work. So yeah, unaccelerated fbdev or at most drm with llvmpipe is best you will get with the 4.4 kernel. Use 5.5-rc7 or 5.4 from the manjaro tree and panfrost if you want accel of any kind.

[houki0]

Ah, that probably explains why KDE was complaining about $DISPLAY not being set. I didn't know about fbdev. I'm learning new things by the minute.

In that case, I'll try to get a more recent kernel to run after I fix my UART cable.

[jcgruenhage]

I updated the top post with the WIP stuff that happened so far. I think going with a 4.4 kernel doesn't make sense, since mainline is so close to being feature complete. I'm using the manjaro build at the moment and it works definitely good enough for me.

[CameronNemo]

Firmware for the mainline kernel is here: https://gitlab.manjaro.org/tsys/pinebook-firmware/ .

I pushed 5.5 to the PR linked in the top comment, but have yet to test it.

[q66]

I'm using 5.5-rc7-panfrost-fixes branch and it works ok - I have not checked which branch your PR is based on now but you should use that one

Btw, I talked to the pine64 folks at fosdem yesterday and showed off mine with void on it a little, turns out at least with the 5.5 kernel we have the best battery life of all distros, nothing else comes close :P (i get 16+ hrs with low brightness and wifi and some slight usage like irc and so)

[renatoaguiar]

I was checking the latest news and It turns out @q66 was right from the beginning :)

Mainline kernel support is progressing faster than I initially thought, so I'll be focusing now on verifying the existing kernel package from @CameronNemo and packaging whatever is still missing.

[houki0]

I just finished compiling @CameronNemo 's kernel, and looking at the commit referenced in the template, it is the head of the v5.5 branch of manjaro's kernel.

That said, it boots just fine and sway seems to work, although scrolling in Wayland-native firefox is a bit laggy. Is there any way for Wayland to check if it's using software rendering? As far as I can tell glxinfo is only accurate for X11 and XWayland. XWayland firefox works just fine and mesa is installed.

I'll test some other DE's later this week.

[renatoaguiar]

I just added pinebookpro-uboot to https://github.com/renatoaguiar/void-packages/tree/pbp. It still needs some cleanup, but I was good enough to generate a bootable image from https://github.com/renatoaguiar/void-mklive/tree/pbp.

@CameronNemo could you rename your linux-pinebook-pro to pinebookpro-kernel, so it matches naming convention used on kernels for other platforms?

[renatoaguiar]

pinebookpro-uboot: void-linux/void-packages#19196
pinebookpro-firmware: void-linux/void-packages#19197

[anjandev]

I tried @renatoaguiar's build scripts. Just for anyone else that wants to try this:

clone https://github.com/renatoaguiar/void-packages and run git checkout pbp && ./xbps-src binary-bootstrap && ./xbps-src -a aarch64 pkg pinebookpro-base.

Run ./xbps-src -a aarch64 pkg wpa_supplicant cause the default rootfs doesnt come with a wireless...

Then, clone https://github.com/renatoaguiar/void-mklive and run git checkout pbp && make.
The rootfs off void's website has an outdated xbps that won't let us run mkplatform.sh. It's ok because we can generate one with ./mkrootfs.sh -o aarch64latest aarch64.

Next, we run sudo ./mkplatformfs.sh -r ../void-packages/host binpkgs/pbp/ -p 'pinebookpro-base wpa_supplicant' pinebookpro aarch64latest.

Finally, to generate the img, I ran: sudo ./mkimage.sh void-pinebookpro-PLATFORMFS-20200216.tar.xz

I burned it to my eemc and it works! It's 4 am and I have been up since 7am so I will do further testing in the morning. Thanks for your work. =)

If anyone wants me to test anything, please let me know.

[renatoaguiar]

I tried @renatoaguiar's build scripts. Just for anyone else that wants to try this:

Thanks for trying that out and posting instructions :)

Run ./xbps-src -a aarch64 pkg wpa_supplicant cause the default rootfs doesnt come with a wireless...

wpa_supplicant for aarch64 is available in official repos. You don't need to build it locally.

Next, we run sudo ./mkplatformfs.sh -r ../void-packages/host binpkgs/pbp/ -p 'pinebookpro-base wpa_supplicant' pinebookpro aarch64latest.

I didn't have to specify any extra packages in mkplatformfs. At least pinebookpro-base and wpa_supplicant are being installed automatically as part of pinebookpro platform, so you shouldn't need to list them in '-p'.

I burned it to my eemc and it works! It's 4 am and I have been up since 7am so I will do further testing in the morning. Thanks for your work. =)

I haven't tried booting from emmc yet. Good to know that it works too :)

[jcgruenhage]

So, to summarize: We have WIP stuff for everything now, we can use that to actually build images that work too, we just need to get the stuff merged now. Some thing have already gotten PRs, for the rest that still needs to be done. I updated the issue description, have I missed something there? Do we have something that's merged already?

[renatoaguiar]

void-mklive: #109

[renatoaguiar]

pinebookpro-base: void-linux/void-packages#19216

[anjandev]

@renatoaguiar So I installed void on the emmc but I changed my fstab in a way that it void failed to boot. Unfortunately, this failure to boot is not visible to the user. I looked to flash manjaro to an sd card and boot from it to fix the issue. However, the uboot on void doesnt prioritize booting from the sdcard before emmc like on most distros for pinebook pro.

This is an important bug that needs to be fixed before these pull requests can be merged.

I fixed my issue by following the advice here: https://forum.pine64.org/showthread.php?tid=8790

[CameronNemo]

For the rock64, I have heard that older u-boot cannot boot 5.8 kernels.

Not sure about the rk3399 boards, but it is something to watch out for.

Speaking of -- is the pinebookpro-uboot package going to track mainline u-boot in any expected timeframe?

[jcgruenhage]

The uboot package we have right now (https://github.com/void-linux/void-packages/blob/master/srcpkgs/pinebookpro-uboot/template) is based on a fork that's half a year old. I've looked at the manjaro PKGBUILD (https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-pinebookpro/-/blob/master/PKGBUILD), they're using an upstream release (1.5 months old) with a few patches and a firmware blob.

So, with these things in mind: It's definitely possible 5.8 works on manjaro but not on void because our uboot is older, and switching to upstream uboot should be fairly easy, someone just needs to do it. In case this is not done until October, I'll go clean up this stuff then (meaning switching to an upstream uboot and kernel). Two reasons for waiting for me: I have a big exam on 2020-09-29, so I'm pretty busy until October, and doing something meaningful as part of Hacktoberfest is also nice, instead of just getting the shirt/stickers for doing a few version bump PRs to void-packages.

[KeepBotting]

I'll help test, would like to switch my eMMC to Void with upstream kernel/u-boot :)

[jcgruenhage]

Thanks for the offer, but I'm not sure how much testing is actually needed/useful there. It either boots, or it doesn't, and for the "it doesn't boot" case there's not much one can do without the UART cable (which I have, so debugging won't be a problem). Still, once I have working builds, I'll publish them here.

[ghost]

Just got my PBP today. I tried running:

sudo ./mkrootfs.sh -o aarch64latest aarch64.
sudo ./mkplatformfs.sh pinebookpro aarch64latest
sudo ./mkimage.sh void-pinebookpro-PLATFORMFS-20200216.tar.xz

then unxz the resulting img.xz then dd'd to a microsd. When I insert the microsd and power on the power LED flashes between green and red. I did a sudo pacman -Syu in manjaro before trying as well as I read that some packages may need upgrading to boot off of the microsd.

Any ideas what I might be doing wrong?

[jcgruenhage]

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]

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]

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]

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]

Hi all, I have a PR to update to U-Boot to the 2020.10 release: void-linux/void-packages#21199

[Algorithmus]

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]

@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]

@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]

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

[jcgruenhage]

@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]

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]

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]

Are the final images going to be generated?

[Johnnynator]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[user18130814200115-2]

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