@GrahamcOfBorg eval

Hi @artemist 👋

Thanks for the contribution!

I was shying away at enabling the defconfig build personally since to my eyes it's "not ready" for use at large, but at the same time, upstream U-Boot does have that defconfig. So it's fine to have this as part of Nixpkgs.

I figure you already know of my overlay + configuration repo, but just in case:

• https://github.com/samueldr/wip-pinebook-pro

If you're interested in a more opinionated take for better UX with U-Boot on the PBP. I'll add notes as to what it adds.

At some point all patches will be in mainline U-Boot, except for my opinionated boot menu things which are not mainline material. In fact most of the patches are not of my doing, but patches that are already in the hands of maintainers or the mailing lists at U-Boot.

Additional notes

(for other new Pinebook Pro users seeing this thread)

The NixOS on ARM section of the wiki, and the additional WIP repositories

• https://nixos.wiki/wiki/NixOS_on_ARM/PINE64_Pinebook_Pro
• https://github.com/Thra11/nixpkgs-overlays-rk3399
• https://github.com/samueldr/wip-pinebook-pro

The latter (my) overlay has a PR with the WIP upcoming patches for display init.

Ergonomics

The defconfig for U-Boot is something I would personally not recommend for daily use. The main reason in my opinion is the lack of information for the end-user when booting as it won't light-up any LED. This leads to hard-to-debug boot problems due to the lack of transparency, especially when the user doesn't have serial access.

• https://github.com/samueldr/wip-pinebook-pro/blob/master/u-boot/0001-rk3399-light-pinebook-power-and-standby-leds-during-.patch

With that patch the LEDs light up ASAP to let the user know something is executing, so the powered state of the laptop is more easily known.

Boot order

I'll also note that the defconfig configuration also works differently than most of the community-provided U-Boot builds for the Pinebook Pro (but it's not really an issue, more of a word of advice). The default boot order for RK3399 platforms in U-Boot is to try to boot from eMMC, then try SD. Most community builds do it the other way around to allow booting an SD card even though you have a system installed to the eMMC. My overlay provides both options as different builds.

Thanks! That's a lot of stuff I hadn't realized about u-boot. I hadn't looked too much at your overlay as one of the overlays I saw looked unmaintained and I prefer to stay on a mainline kernel (Not that it's going great for me, I'm currently having problems with not getting DRM devices for eDP-1 and HDMI-A-1). I'm still expecting to use this uboot though.
It makes me thing some of the patches should be upstream, though I don't know how obnoxious contributing to uboot is.

Most patches are already being upstreamed, really the bunch that isn't is the bunch that configures the custom boot menu :).

I'm not sure about the LED patch, but IIRC in its current state it can't be. Though I think, or maybe I imagined, that there is work for "default triggers" with LEDs, just like the kernel supports, which would be the actual mechanism used by U-Boot to configure the LED.

As for the kernel, try 5.9-rc*, it should have better support for the basics (still haven't got around to testing it). Though HDMI output IIRC still requires patches to work.

I haven't flashed it into SPI but I have had success booting NixOS with the secondary parts on the microSD card. I don't fully understand how uboot works on this device though so I mayb e misunderstanding what that actually does.

and thanks for the suggestions! I'll definitely try that and post my discoveries

There are two boot orders. The SoC boot order, and U-Boot's boot order.

On RK3399 hardware, the SoC will look for a bootable program (more often than not U-Boot) via a magic signature found, in order, either on (1) the SPI Flash, (2) the eMMC, (3) the SD card.

That means that if you have a U-Boot A installed on the eMMC, and insert an sd card with a U-Boot B on an SD card, it will boot the eMMC U-Boot A always.

U-Boot will, by default, use the generic distro boot mechanism to boot. It has different semantics on different platforms. On RK3399 it mirrors the same order as the SoC would. U-Boot will look for different kind of bootable systems. The order is (from memory) (1) eMMC, (2) SD and (3) USB... I don't remember where NVMe falls in there. I'm not even sure about USB's place :).

What this means is that you have a matrix of possibilities if you have a valid system on both the eMMC and SD card.

• A. SoC boots U-Boot from eMMC; U-Boot boots system from eMMC
• B. SoC boots U-Boot from eMMC; U-Boot boots system from SD
• C. SoC boots U-Boot from SD; U-Boot boots system from eMMC
• D. SoC boots U-Boot from SD; U-Boot boots system from SD

Depending on whether there is a valid U-Boot on the eMMC:

• With most community U-Boot (AFAIK), you would get B. and D. scenarios.
• With the defconfig you would have A. and C. scenarios.

You can extrapolate for SPI flash, and USB, hopefully. The main thing to remember is that both boot orders are totally independent, and one is in hardware on the boot ROM.

(Sorry if it sounds patronizing in the explanation, I didn't know what you knew already about the boot process.)

That was quite useful. I'm mainly used to using u-boot on devices with only one eMMC or SD device. Thanks!