Hi Ludo,

On Sun, 29 Mar 2020 16:44:39 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Oh, really?  I’m surprised partitioning causes problems (though I’m
> not familiar with embedded dev!).

Well, maybe not that bad, but it's pretty bad.

It's because the boot sector for ARM, for some unfathomable reason, is not
the first sector but has basically a vendor-dependent sector number somewhere
in the middle of the disk :P

(with the "boot sector" I mean the sector(s) where usually u-boot resides)

So there are all kinds of stupid problems like sometimes you have to reduce
the size of the GPT partition table (TABLE!) because it would write right over
the actual boot sector of the platform otherwise.  For that vendor.  Other
vendors do other silly things.

Parted doesn't really have support for that stuff either, and I while I
brought it up with them[1], I can't think of a practical way to fix it
(i.e. automatically keep clear of all possible boot ranges of all ARM
vendors) or to even find the extent of the problem.  I think it should be
the vendors' responsibility to standardize on one way to boot that doesn't
suck :P

It turns partitioning basically from straightforward allocation inside
one block into allocation with strange hidden mines to avoid.

Embedded usually ignores the problem, finds a partitioning that works
(with dummy spacer partition if you are lucky--otherwise just random
gap) and everyone just uses that one.  Sigh...

(x86 kinda has standardized a gap at the beginning of the disk until the
second head (seems to be 2048 sectors with 512 Byte/sector nowadays
since the drive doesn't expose valid CHS information anymore), and put
the bootloader there--so that's a 1 MiB gap at the beginning of the
disk)

[1] https://alioth-lists.debian.net/pipermail/parted-devel/2017-December/005152.html