It is partly academic, but as I indicated earlier, I want to keep all contents on 1 known-to-be-good SD-card as is, a 32GB or 64GB one, except the first 32k sectors. Although bootcode.bin is on SD-card, only the ROM reads it, the kernel does not need to use anything from /dev/mmcblk0, so once the Pi is available via ssh, SD-card can be swapped for example. But more relevant, I can restore the first 32k sectors from the saved file again and then it is just the original GPT based SD-card again with various partitions (not only 0x8300 for Linux) that took a lot of time to create but also takes time to re-write again. Think of Debian Testing rootfs that I run on different SoCs to compare things in custom kernels etc. Or VM images inside a GPT partition. It just makes a testing/debugging workflow more convenient as you don't need to wait for multi-GigaBytes re-writes. I also use Btrfs rootfs, you can set default subvolume which makes it very fast to switch complete OS test branches. But bootloader stuff is proprietary and tricky as it could 'brick' devices, so you want to keep 'bytes written' as small as possible. If you have worked with bootloaders on non-removable storage you know what I mean (smartphones, router, etc).Now, of course, the real question here is: What is the overall goal? Why do you care about making it as small as possible? Is there a practical end goal or is it just an academic exercise (not that there is anything wrong with that) ?
Now while thinking, I might just create a greater gap for my SD/SSD/EMMC/NVME at the beginning, so not like from sector 34-2047 or 34-32k, but just 34-1024M, so keep the first roughly 512M 'free', but this also requires transforming standard downloadable images first before writing. Then that is is not standard anymore. I know 1 distro has the sequence MBR/GPT/fw-blob, ESP, swap, rootfs. Makes sense, except that swap is then fixed, so on an SBC or VM with more RAM, hibernate isn't an option.
Indeed what tool is used matters. Recently it was discovered that Windows10 pokes in the first 2048 sector area which made certain HA images unbootable (was Pi5 AFAIR, or all SBC's). People who wrote the HA image via Linux had no issue. I don't know exact details, but one can set a 'first usable sector' AFAIK. I also noted that for some fdisk/distro, a complaint is displayed that there is unused space from sector 34-2047. Might have to do with default alignment.IIUC, one of the issues is that the format programs don't make the partition "bittedness" as you'd like it, if the partition you are formatting is "too small". I'm pretty sure that if you use the right formatting program and the right options, you can force it to do the right thing. I'm not up-to-date on which formatting program(s) that would be, nor what options need to be used.
In the past I once had an issue that only FAT16 worked (older U-Boot AFAIR), not FAT32, should be fixed I guess.
Statistics: Posted by redvli — Mon Sep 16, 2024 8:00 am