Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

system-types/u-boot: Use GPT for partitions + add partitions #227

merged 7 commits into from Oct 18, 2020


Copy link

@samueldr samueldr commented Oct 15, 2020

This is how it should have been done from the beginning.

What this gives us:

  • Ability to make more than 4 partitions.
  • Somewhat shield the Allwinner bootloader
  • Partition labels

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 misc and persist??

They're partitions that are going to be used basically like the Android-common ones.

The misc partition 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 persist partition 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_a and boot_b and play with an A/B scheme for u-boot platforms.

@samueldr samueldr force-pushed the feature/u-boot/gpt branch from a99bf4a to d1aa924 Oct 15, 2020
samueldr added 7 commits Oct 15, 2020
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.

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.
Copy link
Member Author

@samueldr samueldr commented Oct 18, 2020

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.

@samueldr samueldr merged commit c7b196c into NixOS:master Oct 18, 2020
3 checks passed
@samueldr samueldr deleted the feature/u-boot/gpt branch Oct 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

1 participant