Another DOS Format issue with MMC/SD [Fixed]

[Gene Smith]

Gene Smith wrote:
> In cpukit/libfs/src/dosfs/msdos_format.c function dos_format() I added 
> dd->start to every place the sector number is used and it seemed to fix 
> the problem. The sector numbers in dos_format() were all zero based so 
> all writes started at the 0th sector, overwriting the MBR.

When I back port the HEAD version of spi-sd-card.c to 4.9.1 discussed in
http://www.rtems.org/bugzilla/show_bug.cgi?id=1356
I don't need to change msdos_format.c. That is because the new HEAD 
version sets up all writes to SD/MMC card to go through the cache/block 
layer which adds in dd->start automatically. Writes to absolute sectors 
are not done.

> 
> But when I look at the formatted card on linux, df says it is 1% used 
> but gparted says it it 42% used with one small file on it. Blocks look 
> reasonable with dd. Sectors per cluster was originally 4 (OEM 
> formatting) now it is 2. Total number of sector in f/s is 65,537. With 
> 512 bytes per sector that is only 33M while the device with OEM 
> formatting showed about 60M I think.  ??? :(
> 
> When reformatted in linux df shows 56068 1K blocks. gparted show 
> slightly more probably includes boot rec, fats and root.
> 
> dd shows 4 sectors per cluster (same as OEM format),
> dd shows 112,392 sectors in the fs, same as gparted starting a sector 63 
> (start of boot rec).
> 
> Print to rtems syslog of card's CSD data at startup shows
> Block size [B] 512
> Block number 127232     <--- Linux only uses 112392 of these! ??
> Capacity [B] 65142784
> 
> So something is still not quite right in rtems dos_format() or somewhere 
> else in the way it is setting the boot record.
> 

This problem still exists in 4.9.1 even with the new HEAD version of 
spi-sd-card.c. But I found the reason and fix described here:
http://www.rtems.org/bugzilla/show_bug.cgi?id=1363