rpi-make-boot-image: Fix FAT12 image generation

[pseregiet]

    rpi-make-boot-image: Fix FAT12 image generation

    mkfs.vfat -F option was not specified which caused mkfs to deduce the FAT type
    on it's own. For a small enough image FAT12 would be selected.

    805a4fda37cf580d4d9734a9ab6ddbf1d1b18ea9 introduced cluster calculation
    function that ends up only using FAT32 or FAT16. Creating a small image
    would fail with message : mkfs.fat: Not enough or too many clusters
    for filesystem - try less or more sectors per cluster

[timg236]

@roliver-rpi I think we've decided to drop FAT12 from the script.

[pseregiet]

@roliver-rpi I think we've decided to drop FAT12 from the script.

Even if, then the script has to be changed to automatically increase the number of clusters/sectors to make the image generation not fail. FAT12 works on the pi so why not keep using it ?

[pelwell]

Even if, then the script has to be changed to automatically increase the number of clusters/sectors to make the image generation not fail. FAT12 works on the pi so why not keep using it ?

The comment was not for you - wait for a considered answer.

[roliver-rpi]

Yes, we'd decided to drop FAT12 support.

This script is designed to produce FAT ramdisks; there's a documented constraint that these should be exceed 96MiB in total size. As such, it makes sense to use 512-byte sectors and 1 sector-per-cluster to reduce unused/wasted space in clusters (common due to numerous small overlay files).

Given that we select FAT16 at 4086 clusters, an end-user would have to be attempting to produce a ramdisk smaller than ~2MiB in total size to require the use of FAT12. Seeing as start.elf is ~3MiB and kernel8.img is ~9MiB this does not seem likely to occur.

[pseregiet]

Yes, we'd decided to drop FAT12 support.

This script is designed to produce FAT ramdisks; there's a documented constraint that these should be exceed 96MiB in total size. As such, it makes sense to use 512-byte sectors and 1 sector-per-cluster to reduce unused/wasted space in clusters (common due to numerous small overlay files).

Given that we select FAT16 at 4086 clusters, an end-user would have to be attempting to produce a ramdisk smaller than ~2MiB in total size to require the use of FAT12. Seeing as start.elf is ~3MiB and kernel8.img is ~9MiB this does not seem likely to occur.

It happened to me, I'm running U-Boot which is ~500kb. My long running setup broke after update to usbboot since this script (intentionally or not) stopped generating valid FAT12 images. I can stuff my boot.img with dummy data just to blow it to the minimum required size for FAT16 or keep my own fork, but that would be silly.

[timg236]

This script should be viewed as an internal part of pi-gen-micro rather than a general purpose tool so features such as FAT12 or overrides to sector sizes are not supported or tested, so regressions are possible.

However, since the change looks small, I'm happy for it to be merged if you fixup the extra spacing in the formatting.

[pseregiet]

However, since the change looks small, I'm happy for it to be merged if you fixup the extra spacing in the formatting.

Done

This script should be viewed as an internal part of pi-gen-micro rather than a general purpose tool so features such as FAT12 or overrides to sector sizes are not supported or tested, so regressions are possible.

Fair enough but this script is referenced in the secure boot readme so I imagine there are other people too that use this script to generate their boot.img. And U-Boot usage might also be somewhat popular because it is used by Mender to implement A/B boot. In hindsight I would just use a kernel image directly and use the autoboot.txt tryboot_a_b option, unfortunately somehow I've missed that option when I did my initial research into the rpi5.