system-types/u-boot: Use GPT for partitions + add partitions #227
Conversation
samueldr
force-pushed
the
feature/u-boot/gpt
branch
from
a99bf4a
to
d1aa924
Compare
This allows us to make a hold in the header, while all other options apparently can't cope with that in scriptable and stable manner.
This is so stage-1 can end up using it as needed.
Ugh... The whole `''${devtype} ''${devnum}:''${bootpart}` thing was
cargo-culted from other u-boot scripts as "the way to go" to re-use the
information set by the generic distro boot...
EXCEPT that it doesn't work since 2018.
https://gitlab.denx.de/u-boot/u-boot/-/commit/13dd6665ed18f72380ca596931d609bc108d4b82
They are not environment variables since that change. So any of those
scripts end up working *by sheer luck* since it would end up booting
from the first device's first partition.
Ugh ugh ugh...
There is one **major** difference with the choice: We are now selecting
on a partition's label, rather than booting whatever is deemed bootable.
This assumes the upcoming change where we are using GPT rather than MBR.
But still, this is compatible with the default expectation from U-Boot
by falling back to the "bootable" attribute.
samueldr
force-pushed
the
feature/u-boot/gpt
branch
from
d1aa924
to
317bf72
Compare
|
How do users that already flashed an MBR-based Mobile NixOS setup update to this GPT-based setup? They re-install "from scratch". Though really they could realistically copy the content of their NIXOS_SYSTEM partition and plop it back in place too. Anyway, there is no SLA for now, and things are still highly in flux. |
|
It seems like it broke PinePhone Braveheart which does not boot with GPT-based SD cards |
|
There is no issue with the Braveheart. I have one. The platform firmware is absolutely unaware of, and does not care about the partitioning scheme used on the storage medium. It loads code at specific offset in the storage medium. Can you elaborate in a new issue about your observations that led to you identify this old PR merge as the source of a problem you are facing, and describe the problem you are facing too? |
|
Hm PostmarketOS image from 2022 works perfectly. Probably, I need to make an RS232-cable to see what is going on there. |
|
Using MBR-partitioned image from |
|
(Locked to prevent further off-topic discussions) You can continue on the issue I opened about your problem. Anyone else facing issues: please open a new issue. |
This is how it should have been done from the beginning.
What this gives us:
We don't really need more than 4 partitions. Though now we have the ability for it. We would need it if we were able to put the Allwinner bootloader at a location inside the usable space.
Though, shielding the bootloader from haphazard partitioning is nice.
Finally, partition labels are not strictly needed; we were doing just fine without. But this is more what I had in mind originally for a well-designed system.
Now, what's up with
miscandpersist??They're partitions that are going to be used basically like the Android-common ones.
The
miscpartition is a mebibyte of bytes that can be used for dialoguing from system to bootloader to system. This is how e.g. Android asks that a boot goes into recovery for flashing something or for erasing the system. The search term for it is BCB. Right now it's not in use. I don't know if it will be, but if it is going to be used by the stage-1 system at any point, we better prepare the systems.The
persistpartition is used by Android to... well... persist some informations outside of the userdata. Here it's not used for now, but there are plans to start using it.First, it would be nice if we had a compatible scheme with Android and Android-based recoveries for some things.
This would be helpful to setup the clock on Qualcomm-based hardware, see #127. If stage-1 knows about the scheme Android uses, we're going to be able to have proper [UTC] time at the first boot! Additionally, if stage-2 knows about it and on shut down syncs it, we have a full "hwclock-like" setup for that quirky platform.
Next, we can also use it for our own persistent data! Nothing has been sketched out publicly yet, but the thought is to fill in declara-statefully information from stage-2 into persist. The information would things like the keyboard map, and i18n options. I'm sure other useful things could be figured out. All in the goal to make the stage-1 image more generic, and configure it on-device rather than having to rebuild it.
Sure, right now it's 17MiB of "wasted" space for misc and persist, but I call it future-proofing.
More partitions on the horizon?
I'm not sure there is value in it, but rather than saving the boot information on the partition for both boot and recovery, we now have the leeway to make
boot_aandboot_band play with an A/B scheme for u-boot platforms.