Re: How does system-disk-image work with embedded-style boot loaders?

[Richard Sent <richard@freakingpenguin.com>]

>> 2) install-rockpro64-rk3399-u-boot writes u-boot.itb at (* 16384 512),
>> or 8,388,608, past the 2^20 offset in the image type. (Likely not
>> coincidentally 8,388,608 / 8 = 1,048,576. I don't know what to make of this
>> because it feels weird that bytes are used in one situation while
>> another uses bits.)
>
> Hopefully this is just a bit of confusion, or some of the images are
> broken and nobody noticed!
>
> I would suggest to inspect the partition table of a generated image to
> confirm if there is an empty space or blank/reserved partition(s)
> falling in that range...

Hi Vagrant!

Thanks for the response! I looked at the code again and I did realize I
missed one thing regarding point 2. pinebook-pro-image-type isn't using
a 1,048,576 offset, but a 9,437,184 offset. There's a *9 I missed,
oopsie.

Alas, there's still some confusion. We place the u-boot.itb image at an
offset of 16384*512, or 8,388,608. When building the u-boot image—part
of the output from the u-boot-pinebook-pro-rk3399-2024.01 derivation
built as part of $ guix system image gnu/system/images/pinebook-pro.scm
--system=aarch64-linux—the u-boot.itb file is 1,089,024 bytes long. Our
raw image offset is system offset is 9 * 2^20, or 9,437,184 (AKA 9 MiB).

So that means writing a 1,089,024 byte image to 8,388,608 spills over to
9,477,632. This is beyond the 9 MiB offset, so our u-boot image should
be overwriting the root FS.

Running fdisk on the image produces (emulated build due to
cross-compilation failures):

--8<---------------cut here---------------start------------->8---
gibraltar :( guix$ fdisk -l $(guix system image gnu/system/images/pinebook-pro.scm --system=aarch64-linux)
Disk /gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image: 1.62 GiB, 1741840384 bytes, 3402032 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device                                                                        Boot Start     End Sectors  Size Id Type
/gnu/store/832w3d7dh2vdfdm2qdv5025w8sfm8zrl-pinebook-pro-barebones-raw-image1 *    18432 3402031 3383600  1.6G 83 Linux
--8<---------------cut here---------------end--------------->8---

I can't figure out where that 18432 offset is coming from. Also, based
on the genimage configuration used to create this image, I'd expect at
least two partitions:

--8<---------------cut here---------------start------------->8---
;; /gnu/store/2ah9p62crpar2iq2jcni85i4fz4yx9x4-genimage.cfg
image image {
	hdimage {
		partition-table-type = "mbr"
	}
	partition GNU-ESP {
  		partition-type = 0xEF
  		image = "/gnu/store/d8irqwcay0w1wm54l1ydrs3kp6vcdd1a-partition.img"
  		offset = "1048576"
  		bootable = "false"
  	}
	partition Guix_image {
  		partition-type = 0x83
  		image = "/gnu/store/823mxbjirpcqgjkybkq60vc34p6nc218-partition.img"
  		offset = "0"
  		bootable = "true"
  	}
}
--8<---------------cut here---------------end--------------->8---

I do find it surprisingly we split "generate base image with genimage"
and "copy bootloader into base image" into different steps. From what I
see at https://github.com/pengutronix/genimage genimage is entirely
capable of placing the bootloader itself. Perhaps there is some value in
reworking the direct bootloader installers (mostly u-boot I think?) to
use genimage.

--8<---------------cut here---------------start------------->8---
;; example from README
partition bootloader {
    in-partition-table = false
    offset = 0
    image = "/path/to/bootloader.img"
}
--8<---------------cut here---------------end--------------->8---

If we are indeed deleting part of our Linux partition due to an overly
large u-boot image (perhaps the image grew over time?), having genimage
be in charge of copying both the partition images AND the bootloader
file would presumably catch that error. At least, I assume genimage
performs those kinds of sanity checks.

I may very well be missing something here, particularly with
interpreting the fdisk output. Sorry if I didn't make sense. This stuff
is hard! :)

I haven't even started looking into what, if any, logic is done on the
Guix side for u-boot to find the Linux kernel. Spooky. 👻

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.