Re: Use genimage for disk-image creation.

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3485 bytes --]

On 2020-03-29, Danny Milosavljevic wrote:
> 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...

Someday... but not today. :/

The biggest offset I'm aware of is rockchip platforms, at what I think
is ~16MB:

  http://opensource.rock-chips.com/wiki_Partitions

sunxi/allwinner 64-bit platforms have offsets that conflict with a
standard GPT partition table, though there are rumours of it working
fine as long as you keep the number of partitions below four:

  https://bugs.debian.org/928643

32-bit sunxi/allwinner platforms are generally pretty reasonable, but I
don't recall the issues off the top of my head.

ti/omap/etc platforms tend to fit under 4MB.


I haven't really looked at buildroot at all... but I suspect buildroot
is just a collection of all these criteria applied on a board-by-board
basis, but most of these boards don't actually require specific
partition layout, per se, it's just nice to not clobber the raw offsets
of various parts of the boot process... but creating partitions for each
of those can make installation less error-prone in some cases.

I think the default for most partitioning tools these days is to create
the first partition starting at 2MB, but If the guix partition started
at 16MB and you limited partitions to under four partitions, that should
work for all the platforms I'm aware off of the top of my head... at
least for now...

I seem to also recall an that some disk media (emmc, microSD, maybe some
SSDs) have an erase block granularity of 4MB, and so it'd be ideal if
the first partition started at a multiple of 4MB:

$ lsblk -D

NAME                DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
mmcblk0                    0        4M     3.5G         0

Or alternately, detecting this size and making sure the first partition
starts as a multiple of this value.

I really need to sort some of these issues out in Debian as well, so
happy to carry on the conversation!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]