shell cmd msdosfmt a NOOP (in 4.9.1) for SD/MMC

[Joel Sherrill]

Gene Smith wrote:
> Chris Johns wrote, On 01/23/2009 07:01 PM:
>   
>> Gene Smith wrote:
>>     
>>> I tried the shell command msdosfmt again on my MMC and still nothing 
>>> happens. I thought I had all my drivers working OK. It gets to the point 
>>> in the format code where it wants to write a block to flash but the 
>>> "write_entry" for the driver is NULL so nothing happens. However, no 
>>> error is flagged so the shell still prints "formatting successful."
>>>
>>> The write_entry is the NULL entry for sd_card_disk_ops in spi-sd-card.c. 
>>> When I change it from NULL and set it to sd_card_driver_write (a 
>>> function in the same file that I had never seen called) msdosfmt 
>>> attempts to do the write of the block with this function.
>>>
>>> However, it still fails inside sd_card_driver_write(). I think because 
>>> the driver table "e" that it gets with the call to 
>>> sd_card_driver_get_entry() is bad since the "major number" is 8 (a 2nd 
>>> instance) instead of "major number" 9 (the first instance with the flash 
>>> info set correctly). This kludge fixes it inside 4.9.1's 
>>> sd_card_driver_write():
>>>
>>> 	/* Get driver entry */
>>> #if 0
>>> 	rv = sd_card_driver_get_entry(minor, &e);
>>> 	CHECK_RVSC( rv, "Get driver entry");
>>> #else
>>> 	e = &sd_card_driver_table[0];
>>> #endif
>>>
>>> 	/* Start */
>>> 	sc = sd_card_start(e);   <---this failed with #if 0 code!
>>>
>>> I made the same change in sd_card_driver_read(), not sure if it is called.
>>>
>>> Looking at the HEAD version of spi-sd-card.c, I see it has been changed 
>>> so that there would only be a single "major" instance generated per bus 
>>> device (in my case one SPI device).  Also functions 
>>> sd_card_driver_write/read() are removed from HEAD. However, the 
>>> "write_entry" function is now rtems_blkdev_generic_write (not defined in 
>>> 4.9.1). Hopefully the correct function will be called when msdosfmt code 
>>> calls rtems_blkdev_generic_write().
>>>
>>>       
>
> I am wrong. The "generic" blk read/write *are* in 4.9.x.
>
>   
>> Maybe these threads will help explain what has changed:
>>
>>   http://www.rtems.com/ml/rtems-users/2008/october/msg00120.html
>>   http://www.rtems.com/ml/rtems-users/2008/november/msg00050.html
>>     
>
> Yes, I remember seeing this now and being totally snowed.
>
>   
>> Given what you say I suspect the CVS version will format the card.
>>
>>
>> Regards
>> Chris
>>     
>
> Yes, I think Robert S. Grimes was seeing his write to "absolute" sector 
> not work for the same reason. So if these "generic" functions are used 
> they are buffered by the cache during format, I think. Is that OK? Seems 
> like fmt should be done on an unmounted device and do immediate sector 
> writes? But if it's OK, can the fixes to spi-sd-card.c from 1.7 to 1.8 
> be merged in to 1.6.2.1? Lots of changes in the diff. Otherwise, 
> msdosfmt of SD/MMC is broken on the 4.9 branch. Or my kluge is the fix?
>   

Whatever has to be backported to the spi-sd-card.c is OK.  If I am
right, you should be able to take the new version and just use it
in 4.9.  I am not sure though.

Whatever the technical solution, just associate it with a PR so
we can track it on the branch.
> -gene
>
> _______________________________________________
> 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