Re-partitioning; Adding swap partition; Using GPT partitions

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