A Wandboard (and other iMX platforms) is one of those where the
first stage bootloader is loaded from a hard-coded offset of 1K,
i.e. immediately after the GPT header. So the partition table itself
needs to be moved.
I wanted to get rid of updating the bootloader involving writing to
the raw disk rather than some well-defined partition. Both to reduce
risk of stray writes, and to be able to just use
/dev/disk/by-partlabel/SPL rather than some error-prone "dd
seek=...". Defining a partition at 1K with the GPT moved far out of
the way to 1M actually worked (at least produced an image file that
the linux kernel would happily mount via losetup).
But then I stumbled on the text that says that partitions in the table
must start after the partition table. It wasn't immediately clear if
this was a (historical, as evidently it worked now) limitation of the
genimage implementation or actually mandated. So I looked it up, and
unfortunately, it's the latter:
The GPT Header defines the range of LBAs that are usable by GPT
Partition Entries. This range is defined to be inclusive of First
Usable LBA through Last Usable LBA on the logical device. All data
stored on the volume must be stored between the First Usable LBA
through Last Usable LBA, [...]
The primary GPT Partition Entry Array must be located after the
primary GPT Header and end before the First Usable LBA.
So update the README to state where that requirement comes from, and
enforce it in the implementation. Since it does seem to work on linux,
we might later add an I-know-what-I'm-doing option to allow such a use
case, but the default should be to generate images according to the spec.
michaelolbrich
commented
3 years ago
A Wandboard (and other iMX platforms) is one of those where the first stage bootloader is loaded from a hard-coded offset of 1K, i.e. immediately after the GPT header. So the partition table itself needs to be moved.
I wanted to get rid of updating the bootloader involving writing to the raw disk rather than some well-defined partition. Both to reduce risk of stray writes, and to be able to just use /dev/disk/by-partlabel/SPL rather than some error-prone "dd seek=...". Defining a partition at 1K with the GPT moved far out of the way to 1M actually worked (at least produced an image file that the linux kernel would happily mount via losetup).
But then I stumbled on the text that says that partitions in the table must start after the partition table. It wasn't immediately clear if this was a (historical, as evidently it worked now) limitation of the genimage implementation or actually mandated. So I looked it up, and unfortunately, it's the latter:
The GPT Header defines the range of LBAs that are usable by GPT Partition Entries. This range is defined to be inclusive of First Usable LBA through Last Usable LBA on the logical device. All data stored on the volume must be stored between the First Usable LBA through Last Usable LBA, [...]
The primary GPT Partition Entry Array must be located after the primary GPT Header and end before the First Usable LBA.
So update the README to state where that requirement comes from, and enforce it in the implementation. Since it does seem to work on linux, we might later add an I-know-what-I'm-doing option to allow such a use case, but the default should be to generate images according to the spec.
Signed-off-by: Rasmus Villemoes rasmus.villemoes@prevas.dk