Another DOS Format issue with MMC/SD [Fixed]

[Joel Sherrill]

Since you have filed PRs for both of these.  If you
will attach diffs to both of them, I will commit to
both 4.9 and the head as appropriate.

Thanks.

--joel

Gene Smith wrote:
> 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
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985