Another DOS Format issue with MMC/SD

[Gene Smith]

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.

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.

-gene

Gene Smith wrote:
> Thomas,
> It just occurred to me too that that might be my user error. But I tried 
> formatting /dev/sd-card-a1 on rtems and it seems to get the same result. 
> I only see /dev/sd-card-a and can only mount it, not sd-card-a1. I will 
> look on linux with dd to see if the result is the same.
> 
> Thanks,
> -gene
> 
> Thomas Doerfler wrote:
>> Gene,
>>
>> it makes a big difference whether you format /dev/sd-card-a or
>> /dev/sd-card-a1.
>>
>> The former will format the whole disk as a MSDOS filesystem (sometimes
>> called a "superfloppy"), this means, that the partition table residing
>> in the first sectors is overwritten with msdos information.
>>
>> The later will format partition 1 of the sdcard, still leaving the
>> partition table intact.
>>
>> Possibly you might do the same thing with linux....
>>
>> wkr,
>> Thomas.
>>
>>
>>
>> Gene Smith wrote:
>>> After getting the format command to actually write to my MMC card I 
>>> noticed another problem. I am not sure that it might not be a user error 
>>> of some sort.
>>>
>>> When I format with shell cmd
>>> msdosfmt -t 16 /dev/sd-card-a
>>> if I mount the card (or if it remained mounted during fmt), the files 
>>> and data are still there but I think just in cache. So it appears the 
>>> cache is not invalidated by fmt code.
>>>
>>> If I restart RTEMS and mount, I can no longer mount /dev/sd-card-a1 but 
>>> have to mount /dev/sd-card-a . Also, the sd-card-a1 partition no longer 
>>> appears when I "ls /dev/", just sd-card-a.
>>>
>>> When I put the card on linux, it automounts as device sdc and not sdc1 
>>> as it would before. If I try to format it with gparted, it claims there 
>>> are problems.
>>>
>>> When I look at the device with dd in=dev/sdc out=t.txt I see that 
>>> previous OEM formatting of the MBR (1st sector) and the FAT boot record 
>>> (many sectors down) are gone. Instead the first block is not the MBR but 
>>> the FAT boot record followed by the FAT tables and after that OK I 
>>> think. So the disk looks like a "partition" (called sdc) w/o a MBR. I 
>>> can mount it and copy files to it OK in linux.
>>>
>>> When I put the card back on RTEMS I can see files and copy them OK but 
>>> still can only mount /dev/sd-card-a.
>>>
>>> Then back on linux with gparted, if I re-partition and then format I get 
>>> a MBR back and can see and mount partition sdc1 and on RTEMS sd-card-a1 
>>> again.
>>>
>>> Looking at the RTEMS dos fmt code, it appears that it does not read in 
>>> the current MBR and FAT boot record before reformatting but tries to 
>>> determine the parameters based on other information it has. Also, it 
>>> writes the FAT boot record in the first sector (in the code it calls it 
>>> "MBR") which wipes out the valid MBR in the first sector.
>>>
>>> I have noticed that other fmt tools (gparted, xp format) seem to keep 
>>> the original MBR and FAT boot record (if valid) and only reinitializes 
>>> the fat table and root dir area. They don't delete or change the 
>>> MBR/partition table or move or change the FAT boot record, I think.
>>>
>>> -gene