Pinebook Pro support about void-mklive HOT 175 OPEN

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

from void-mklive.

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.

from void-mklive.

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 ###```

from void-mklive.

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

from void-mklive.

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

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

from void-mklive.

I've built an image yesterday and I can't get it to boot from eMMC or from the sdcard.. I'll delete everything, rebase stuff on master and will try again. Maybe I missed something.

from void-mklive.

panfrost is rather unstable still and has issues with GLAMOR, you should run mesa from git for best experience

from void-mklive.

I pushed another PR #111 to void-mklive fixing the execution of post install scripts on cross builds. That is also required to successfully create an image from #109.

I cleaned https://github.com/renatoaguiar/void-mklive/tree/pbp-local up by keeping only changes from opened PRs, so people should still be able to build images from it.

from void-mklive.

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

• I can actually see part of the kernel log on the screen.
• When it boots, it first displays a red power light, which then turns green after a few seconds.

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?

from void-mklive.

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!)

from void-mklive.

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.

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

from void-mklive.

@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

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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..

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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

from void-mklive.

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 void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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)

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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?

from void-mklive.

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

from void-mklive.

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.

from void-mklive.

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 :)

from void-mklive.

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?

from void-mklive.

void-mklive: #109

from void-mklive.

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

from void-mklive.

@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

from void-mklive.

After further testing, it seems that the emmc does prioritize the sdcard if the system is in a working condition. However, if the pbp is not able to boot from the emmc, it does not even boot the sd card. Im not modifying /boot so I am confused as to what this could be.

I guess if the bug is not reproducible, ignore my original post.

from void-mklive.

I have attempted to create some bootable media for Void on the Pinebook Pro using the packages and instructions present in this issue.
Near as I can tell, the image was created properly, but I have been unable to boot from SD card.

Here are my steps. I ran these commands on a 64-bit x86 server running Void glibc.

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

The build for pinebookpro-base (which includes the kernel) is using eight makejobs (-j8), so scale this according to your hardware.

cd ../
git clone https://github.com/renatoaguiar/void-mklive mklive-pbp && cd mklive-pbp
git checkout pbp && make
sudo ./mkrootfs.sh -o aarch64latest aarch64

This last command errored with FATAL: qemu-aarch64-static binary is missing in your system, exiting.

So I installed qemu-user-static and then attempted rebuilding the rootfs again. This time it was successful.

Continuing, the only extra package I can see myself wanting straight away is wifish as this is my preferred way to manage wireless network associations from the command-line.

sudo ./mkplatformfs.sh -r ../void-packages-pbp/hostdir/binpkgs/pbp/ -p 'wifish' pinebookpro aarch64latest
sudo ./mkimage.sh void-pinebookpro-PLATFORMFS-*.tar.xz

Finally, I decompressed the image and flashed it to a SD card.

unxz void-pinebookpro-*.img.xz
# be careful with dd, as always
sudo dd status=progress if=void-pinebookpro-*.img of=/dev/sdX

After flashing, I inserted the SD card into my Pinebook Pro, but it failed to boot. Instead, the default Debian (on eMMC) booted.
I added the boot flag to the Void partition on the SD card and tried again, but this did not have any effect.

My Pinebook Pro still has the default Debian image present on eMMC, so the bootloader is (presumably?) untouched.
I have not tried writing the Void image to eMMC just yet. I am not quite comfortable with u-boot (I have only used GRUB and rEFInd), and am hesitant to wipe out the eMMC, since that is where u-boot lives. I would rather not have to open the laptop to recover.

What should I do differently?

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

from void-mklive.

I just rebuilt it and it still doesn't work. OOI, can we gather info on who here 1) had success and 2) what revision they have? Maybe all the people who had success have devices from the same batch and there's some weirdness going on with newer/older revisions. I had no success, from both eMMC and sdcard, on a device from the first ANSI batch

from void-mklive.

@jcgruenhage @KeepBotting could you try again using https://github.com/renatoaguiar/void-mklive/tree/pbp-local?

It reintroduces some local changes I had in pbp branch before opening the PR.

from void-mklive.

I am using an ANSI model. I am unsure how to tell which batch it is from. It was ordered on 27th December and arrived on 20th January 2020.

No success booting from SD. I tried another SD card but no joy.

I notice there is no boot.txt/boot.scr present on the Void image, while Manjaro has some extra files like this. I do not fully understand how to operate u-boot but maybe that's all that is missing.

Edit: @renatoaguiar trying that now!

from void-mklive.

Odd, using pbp-local branch fails with an error on this command: sudo ./mkrootfs.sh -o aarch64latest aarch64

Reconfiguring packages for aarch64 ...
Running xbps-reconfigure --rootdir /tmp/tmp.J90tU0vw5u base-files
base-files: configuring ...
ERROR: base-files: [configure] INSTALL script failed to execute the post ACTION: No such file or directory
Failed to reconfigure `base-files': No such file or directory
chroot: failed to run command ‘sh’: No such file or directory
chroot: failed to run command ‘sh’: No such file or directory
Setting the default root password ('voidlinux')
chroot: failed to run command ‘sh’: No such file or directory
chroot: failed to run command ‘sh’: No such file or directory
FATAL: Could not set default credentials

I do not understand why this could be, because sh is unpacked and installed prior to this reconfiguration:

dash-0.5.10.2_2: unpacking ...
dash-0.5.10.2_2: registered 'sh' alternatives group
Creating 'sh' alternatives group symlink: sh -> /usr/bin/dash
Creating 'sh' alternatives group symlink: sh.1 -> /usr/share/man/man1/dash.1
bash-5.0.016_1: unpacking ...
bash-5.0.016_1: registered 'sh' alternatives group

from void-mklive.

@KeepBotting you probably have stale entries on your binfmt.

Try running $ echo -1 | sudo tee /proc/sys/fs/binfmt_misc/status before the build to remove all entries.

from void-mklive.

Try with this patch https://patch-diff.githubusercontent.com/raw/void-linux/void-mklive/pull/110.patch

from void-mklive.

@renatoaguiar Interesting, that did indeed solve the error. I have never interacted with binfmt_misc before, but I gather it's used because I am cross-compiling for aarch64 on an x86 host. The patch provided by @Duncaen should fix the configure scripts so manual intervention is not required.

I'm happy to say I was able to successfully boot from the Void SD card after flashing this new image. The process used was identical to my original comment above, with the exception of using pbp-local branch of void-mklive.

Wi-Fi works properly of course, and I was able to install X11 and Mesa to achieve hardware acceleration with the Panfrost driver.

Opening Firefox's filechooser dialog causes X to segfault and crash, however. Not sure what that's about.

Edit: Oh, and thanks to everyone who's contributed!

from void-mklive.

It may be worthwhile to start documenting the pinebook pro. I ran into keyboard mapping issues on my iso keyboard and documented it here: https://wiki.voidlinux.org/Pinebook_Pro. Please let me know if you would like me to add anything else to the wiki.

I am running the image from the original pull request without any issues for the last 24 hours. It's been great!

from void-mklive.

I've built an image using the pbp-local branch rebased on upstream master, this image boots (from eMMC), but once I install a bit of stuff and resize the partition, it doesn't boot anymore. I'll investigate a bit more what exactly causes it to not boot anymore, but without an external eMMC flasher and a uart adapter, this is a bit hard.

from void-mklive.

I have booted it once since I installed it, so far everything appears to be working perfectly on my pbp. Fwiw, I got the batch that shipped January 2020, which I believe is the second batch, and I flashed to SD, not to emmc. I installed Xorg and the MATE desktop. First thing I notice is that every time I start X, the mouse is jittery for a few seconds, then moves normally. Also, what method would we use to upgrade the pbp base image (I.e. kernel and uboot) from the installed computer? Do we clone https://github.com/renatoaguiar/void-packages and use that particular xbps source?
I used the pbp-local branch as well for my build.

from void-mklive.

@BenEvolent333 since you already have it working, I'd just wait until packages are available in the official mirrors. pinebookpro-uboot and pinebookpro-firmware are already merged, others are coming soon.

from void-mklive.

pinebookpro-kernel: void-linux/void-packages#19293

I also fixed musl builds, so now it is also possible to make images for pinebookpro-musl.

from void-mklive.

I ran into a problem with Xorg, after I installed panfrost and then logged out of mate (using lightdm), where xorg no longer loads properly. I uninstalled panfrost, but the issue persisted. I attempted to load mate, lightdm, KDE plasma, abiword, and MATE terminal using xinit, of which only mate-terminal loads successfully. Somehow I also deleted the services directory, so I have to re-flash the image anyways, but I will update if I can pinpoint a cause.

from void-mklive.

Now #112 is also needed because older versions of some packages are already available in official repos. I updated the pbp-local branch with that PR.

from void-mklive.

can you confirm a void image for pinebookpro works now?

@xtraeme you mean when building from the master branch of void-mklive, without building any packages from source, right?

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

from void-mklive.

I did pull right before building

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

Can someone try booting from emmc?

from void-mklive.

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

from void-mklive.

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.

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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?

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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.

from void-mklive.

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

from void-mklive.

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

from void-mklive.

I opened a clean, fresh PR. Want to keep the old branch handy in case anyone wants the old packages. void-linux/void-packages#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.

from void-mklive.

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

from void-mklive.

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

from void-mklive.

Mine continues to wok after resizing the partition, hmm

from void-mklive.

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

from void-mklive.

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

• /var/lib/alsa/asound.state – ALSA mixer configuration
• /etc/udev/hwdb.d/10-usb-kbd.hwdb – mappings for sleep and brightness keys

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.

from void-mklive.

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

from void-mklive.

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.

from void-mklive.

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

from void-mklive.

@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: #115

from void-mklive.

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

from void-mklive.

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.

from void-mklive.

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.)

from void-mklive.

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.

from void-mklive.

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.

from void-mklive.

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

void-linux/void-packages#19380

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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

from void-mklive.

Why would I need that? Trying now..

from void-mklive.

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

from void-mklive.

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

from void-mklive.

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):

• base-system
• base-voidstrap
• elogind
• mesa
• mesa-dri
• pinebookpro-base
• polkit
• sway
• xdg-user-dirs
• xdg-utils
• and some stuff for testing a xfce/i3 setup.

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.

from void-mklive.