From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vagrant Cascadian Subject: Re: Use genimage for disk-image creation. Date: Sun, 29 Mar 2020 12:06:19 -0700 Message-ID: <87k133vv4k.fsf@ponder> References: <87eetgo9o6.fsf@gmail.com> <20200327002438.527eb1d0@scratchpost.org> <871rpb1aqw.fsf@gnu.org> <20200329170714.1bf26eb3@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33508) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdGp-0007PD-05 for guix-devel@gnu.org; Sun, 29 Mar 2020 15:06:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIdGn-0002yP-Dp for guix-devel@gnu.org; Sun, 29 Mar 2020 15:06:54 -0400 In-Reply-To: <20200329170714.1bf26eb3@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic , Ludovic =?utf-8?Q?Court?= =?utf-8?Q?=C3=A8s?= Cc: guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-03-29, Danny Milosavljevic wrote: > Hi Ludo, > > On Sun, 29 Mar 2020 16:44:39 +0200 > Ludovic Court=C3=A8s wrote: > >> Oh, really? I=E2=80=99m surprised partitioning causes problems (though = I=E2=80=99m >> 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 somew= here > 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 redu= ce > 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCXoDxrQAKCRDcUY/If5cW qm8YAP9vN1qKVdPG9S7vbw98V64Yc8kx9yla1BuYvpuhFxmaKgEAtyaIiRnzt9UP 1TjkEezUVqeQcEqK6RNxA4tCe6iskgg= =rcLY -----END PGP SIGNATURE----- --=-=-=--