Comment 1 for bug 609700

Proposed change:
=== modified file 'tools/boot/maverick/post-boot-armel+omap'
--- tools/boot/maverick/post-boot-armel+omap 2010-07-06 08:27:47 +0000
+++ tools/boot/maverick/post-boot-armel+omap 2010-07-25 09:57:08 +0000
@@ -195,7 +195,7 @@
 VATSTART=$(parted $IMAGE unit B print|grep "^ 1"|awk '{print $2}')
 VATSIZE=$(LANG=C fdisk -l ${IMAGE} 2>/dev/null|grep W95 |awk '{print $5}')

-mkdosfs -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
+mkdosfs -C -F 32 $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
 mcopy -i $IMAGE.vfat MLO ::MLO
 mcopy -i $IMAGE.vfat u-boot.bin ::u-boot.bin
 mcopy -i $IMAGE.vfat $uboot_kernel ::uImage

Important notes:
* this will also affect OMAP4 (the OMAP4 script is a symlink to the OMAP one)
* this might not fix QEMU entirely, since the behavior of mkdosfs on files might differ from its behavior on devices

When I did this locally I saw:
sudo file -s /dev/mapper/loop1p1
/dev/mapper/loop1p1: x86 boot sector, mkdosfs boot message display, code offset 0x3c, OEM-ID " mkdosfs", sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 141, heads 64, sectors 144522 (volumes > 32 MB) , serial number 0x4c4563c7, label: " ", FAT (16 bit)

sudo mkfs.msdos -F 32 /dev/mapper/loop1p1
mkfs.msdos 3.0.9 (31 Jan 2010)
unable to get drive geometry, using default 255/63

sudo file -s /dev/mapper/loop1p1
/dev/mapper/loop1p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 255, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0x295c1311, label: " "

the drive geometry message might or might not be identical on files and devices (I was using a devmapper device, created by kpartx)