Re-partitioning; Adding swap partition; Using GPT partitions

[Arwen]

...
and yes, about a proper installation, i wrote that too a couple of weeks ago, maybe someone noticed. i am not a linux guy, so I can't try myself in it. but that thing would be very good to have. i don't agree, that it's arm difference though. nothing special, x86 starts its execution at the predefined address aw well, that platform just managed to agree on always having flash chip from which bios runs, starting it all. this mess with uboot pieces being hardcoded at places in the user areas of not so "firmware" storages is mostly due to overlooking on the OS side, linux, in this case  lack of development force, other reasons. should it get enough attention, the only normal place for these pieces are either (in)famous SPI NOR chip, pretty fatty on pine products or, shoul rockchip be not this lazy, the boot areas of eMMC, specifically made for this purpose, leaving all the collisions with user data. then creating a modern GPT laid out disk on user disks would be free of this clumsy stuff.

Ah, you make a good point about the x86/x64 system's BIOS, (or EFI, etc...). They handle all the nitty gritty. So your point about ARM being special is only because in some cases, like our Pinebook Pros, have not, (yet?), implemented BIOS like firmware.

I don't know if the 16MB SPI is large enough for a decent BIOS like interface. We would likely want this;

 - Built in keyboard support
 - USB keyboard support
 - Built in display support, (which might automatically include USB C alternate mode DisplayPort)
 - NVMe boot
 - USB boot
 - And the classics, eMMC & SD boot
 - Plus, parameters to specify boot order or disable bootable USB

Of course, if we truly have a need, we can have a slim BIOS that fits into the SPI. And a larger one that uses SPI and the eMMC boot areas.

[danielt]

A normal GPT with the recommended partition array (plus the protective MBR) runs from LBA0 through to LBA 33 (and is repeated at the end of the disk). It is not a problem to have the first partition at LBA 64.

it's a bare minimum - 1 block goes to the Protective MBR (LBA 0), 1block for the GPT Header (LBA 1) and in case of 512 byte blocks - 32 blocks go for the Partition Array. normally, utilities initializing GPT disks allocate larger space for avoiding "no entries for number of partitions you wanted" situations.
the alignment recommendation (it's 1 MB, not 2, I was wrong) is for efficiency purposes, again "only" a recommendation, but every normal utility respects it. it's both relared to RAID and flash based storages efficient operations.

It is the minimum required by the standard but it is not a bare minimum. A 32 block partition array is sufficient for 128 partitions and there are few practical use cases (especially on small laptop with 128GB storage) that will require this many partitions.
To be honest even if you actually do believe that 128 partitions is a bare minimum it is *still* far better to have a protective partition starting at block 64 that tells the partitioner it is not safe to have more than 248 partitions and this will avoid you corrupting the firmware.
As I said before creating a protective partition at block 64 does not stop the GPT being fully standards compliant and it is safer than the alternative (although as Arwen mentioned if you continue to run the stock Debian Stretch image then it would be wise to review the updater scripts before running them since it often makes assumptions that the partitioning has not been changed).

---

Ah, you make a good point about the x86/x64 system's BIOS, (or EFI, etc...). They handle all the nitty gritty. So your point about ARM being special is only because in some cases, like our Pinebook Pros, have not, (yet?), implemented BIOS like firmware.

Nice to have something we all agree on!

That some Arm systems that cannot boot off-the-shelf distro installers is ultimately caused by missing features in the firmware for that specific system rather than being caused by the Arm architecture. I have a blog post about running an off-the-shelf Debian installer on qemu-system-aarch64: http://www.redfelineninja.org.uk/daniel/...u-and-kvm/ . Rather pleasingly these instructions worked for me without any change on a Pinebook Pro runnning Debian Bullseye.

With regard to the gaps in the current PBP firmware I think only a few, relatively small, changes to u-boot are needed to make it useable. UEFI support should just be a matter of running it on in u-boot. It will be made a little more difficult because I suspect the vendor kernels use non standard devicetree bindings but there are techniques to work around that (admitedly not nice ones and not ones that u-boot upstream is likely to take). Note I said "relatively small" rather than "easy". I think the most difficult missing piece in u-boot is adding code to enable GFX on the display panel.

Note that it will definitely be better to move the firmware to SPI (and is one of the next things I will be trying) but it is not required to be UEFI compliant, provided there are protectice partitions with the RequiredPartition flag set.

[z4v4l]

2 arwen, I think 16 MB of the NOR chip is a huge amount for the FW. not that I'm too aware of it, but I'd say most PCs have much smaller ones for BIOS/UEFI. somehow, I remember my 2007 PC has 2x 2MB. so, yes, 16 MB should be enough for even a firmware with a cute GUI.
2 danielt, uboot UEFI so far is sucky according to people trying it. but definitely is incomplete and incompliant.

the interesting question is if Rockchip's ROM code tries eMMC boot areas before trying the GP area. that would be fantastic, because this scenario is brickless - eMMC is removable on most of Pine products and also the boot areas come in double - for strengthening against wrong updates. Rockchip manuals are scarce on this info, they just say - it checks eMMC, but what does it check, remains unclear.

[Arwen]

@z4v4l, In regards to size of the SPI compared to PCs. I think you are right. I vaguely remember some PCs having 4MByte, BIOS memory.

The issue I see is that we have 2 x 4MByte binary blobs. I don't really know their names and functions, but one is some trusted firmware Rockchip supplies. That eats up half the SPI storage. We can't even use the eMMC boot partitions for these, as we would still need room for the U-Boot code. (Unless we use both SPI & eMMC.) But, perhaps we can look at the eMMC standard secure data partition, which may be 16MB, for those 2 x 4MByte binary blobs.


As for Rockchip's ROM code on the RK3399, I'd sign and honor a NDA, (Non-Disclosure Agreement), if they gave me access to the source code. Plus, I have enough embedded software development experience to give them feed back on silly mistakes and or outright bugs. (Then keep it confidential... per NDA.) That way, they can fix the ROM in later generations, without worrying about prior generations being less than ideal, shall we say.

[Der Geist der Maschine]

The issue I see is that we have 2 x 4MByte binary blobs. I don't really know their names and functions, but one is some trusted firmware Rockchip supplies. That eats up half the SPI storage. We can't even use the eMMC boot partitions for these, as we would still need room for the U-Boot code

I did not read the whole thread, but where do we have 2x4MB binary blobs? This is from my notes (for a very high level overview, see my website link)

Code:

Master Boot Record  offset      0kb   size   0.5kb
[Unused?]           offset    0.5kb   size  31.5kb
IDBLoader           offset     32kb   size   160kb
[Unused?]           offset    192kb   size  8000kb
U-boot              offset   8192kb   size  4096kb
Trusted Firmware    offset  12288kb   size  4096kb

[Der Geist der Maschine]

I've just seen the link you posted in https://forum.pine64.org/showthread.php?...3#pid54523

The table there is more precise. What I claim to be unused is partially used for "data". By the way, our loader1 does not make use of its 2.5 MB partition - its just 160kb small.

[danielt]

2 danielt, uboot UEFI so far is sucky according to people trying it. but definitely is incomplete and incompliant.

I don't think there is anything missing from u-boot that is necessary to boot a generic distro image (such as the Debian netinst ISO for arm64). My own experience is that the upstream u-boot UEFI for pine a64 has been complete enough to boot from SD card, display the grub menu via HDMI and boot the kernel for over a year.

[z4v4l]

completeness and compliance is defined not by the ability to boot some linux distribution, but what percentage of functionality defined in the specification as the requirement is implemented and how properly it is implemented. uboot doesn't even have UEFI Boot Manager*, I don't know does it understand UEFI environment variables, device paths? without this, installation of a UEFI aware OS is impossible. linux is a bad example here, honestly, it doesn't have a normal UEFI OS loader, and I suspect, - barely uses UEFI at all, that so called "efi stub" just calls ExitBootServices() as soon as possible and that is all - with this it's hard to get how UEFI implementation is full in uboot.

* - the fact, you can feed it with BOOTAA64.EFI on a removable medium and it will run it, is way not enough to call it UEFI. it should support the whole Boot Manager environment, with its look and feel mostly left for the implementer fantasy or its lack, but with the support of "boot options" and the specified mechanisms and all the variables needed for this. when a UEFI application, the OS installer, asks to create such a boot option and the Boot Manager makes it, and that option contains a "device path" - a chain of device protocol instances, assigning the hardware path for the firmware to find the boot device in question up to the file system and file. does uboot implement all that? does it provide all the Boot Services? Runtime Services? these are just a core of the requirements, they are much broader, there is a lot of protocols needed to be supported as well.

---

@Arwen, the trusted firmware part may be open source, it's that ATF stuff from ARM. as of NDA for ROM code, I don't know, but you can contact them, there is a person at rockchip, responsible for opensource, he responds to emails (the email, posted somewhere at opensource.rock-chips.com).

[danielt]

Hi @z4v4l, for UEFI I think completeness is best defined by the ability to accomplish useful tasks, such as booting an installer from SD card and installing a (working  ) OS to eMMC. Ultimately the minimum feature set needed to be UEFI complaint is surprisingly small (and, with the latest spec update, includes the option to return EFI_UNSUPPORTED for all runtime services) and I think it is better to measure "completeness" in what percentage of *use-cases* work rather than what percentage of *features* are implemented.

As a concrete example personally I would prioritize support for the eDP panel over support for setting non-volatile variables (neither of which is required to be compliant). This is because multiple Linux installers can install a bootable OS on UEFI systems where EFI_RUNTIME_SERVICES.SetVariable() is not implemented but interacting with grub via the serial port is a lousy user experience. To be clear SetVariable() is a good thing to implement but for my own hacking it is not on the radar yet.

Bringing this back to @Arwen's topic, which perhaps we have been derailing a bit, adopting GPT with protective partitions is a great step towards running a real installer (although I guess moving the bootloaders to SPI is better still). After that I think the least work to unlock installer use cases is u-boot driver enablement, and authoring an installer ISO with a PBP kernel support included.

Maybe we will reach a point where improving the completeness of the generic u-boot UEFI support is a road block that must be overcome to unlock another use-case. However that, IMHO would be a success, not a failure, since it would be an indicator of how far the PBP has come!

[Arwen]

I'll skip the U-Boot, Grub and UEFI discussions for the moment. I just don't know enough about them, (on ARM), to make useful comments. Other than to echo @danielt desire for eDP panel & keyboard support for interactive booting would be quite useful. Even if it was a 2 stage process, U-Boot loaded as it is now, but launching Grub or UEFI for the next stage.

Looking at the default debian update script, I figured out why my kernel was not updating. Turns out the script uses a FS label of BOOT to file "/boot". Since I did not know this, and used "sd_boot" for the SD card and "emmc_boot" for the eMMC, the script failed to update boot. I'll redo the original post after I have some time to think about the details, and verify that prevented kernel updates.