On 2024-05-11, Richard Sent wrote: > I'm a bit confused as to how a system image is generated when certain > bootloader types are used. For example, rockpro64-rk3399-u-boot. ... > From what I can tell this is a 4 step process. > > 1. Generate a genimage.cfg file via image->genimage-cfg. This does not > appear to take the bootloader into account. > > 2. Call genimage in (gnu build image) to create the image defined in the > genimage.cfg file. > > 3. use bootloader-installer to write directly into the image file that > was just created. In this case we write two files at specific offsets. > > 4. Convert the raw disk image into the desired output format. > > How do we avoid "screwing up" the image by writing directly to the > image? What stops genimage from putting important data there that gets > overwritten in step 3? Is it just coincidence? A convention in the image > file to leave a large amount of space at the beginning? Some other > factor? What if another embedded board uses a different offset that > genimage does happen to use?
I'd hope guix is at least using "A convention in the image file to leave a large amount of space at the beginning" if it is not doing anything fancy. Leaving the first 16MB of the partition table empty, or partitioning it with dedicated partitions at appropriate offsets, or with one big blank partition ... was at least the approach I used when manually installing. 16MB covers most rockchip based systems, and all others systems I am aware of tend to be much smaller than that, thankfully, and... dare I tempt fate, hopefully stays that way. I was too involved in the image generation switch to genimage much, so cannot answer your question of what the code is actually is doing. > I'm *guessing* that the answer lies in the image type and > raw-with-offset-disk-image function, but I'd appreciate any > clarification on this! I see that pinebook-pro-image-type, which also > uses Pine64's rk3399 SoC has an offset of 2^20, or 1,048,576. However > > 1) There isn't a rockpro64-image-type, only a pinebook-pro-image-type. > Why only have one image type but two bootloaders? > > 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... live well, vagrant
signature.asc
Description: PGP signature
