libblock and FAT

[ruizx]

On Monday, August 26, 2013 7:43 AM Claus, Ric wrote:

 
> 1) The ZYNQ's SD/SDIO host controller takes order 650 uS to respond with DATA_AVAILABLE after being sent a read command.  The
> cause of this may, of course, be the SD card and not the host controller.  However, the same card can be read and written by a
> Mac much quicker than I can achieve with the ZYNQ and RTEMS. 

My SD card is SanDisk Class 4, 4GB capability.
I measured the delay between single or multi block command send to the data available is about 265us,
so I think 650us is too long, you can change another SD card for test.

>2) I gather that the block size given to rtems_disk_create_phys()
> should be 512, which is the same as that of the card.  This appears to cause all read and write ioctl sg requests to have a
> length of 512, thus preventing a device driver from being able to take advantage of a device's ability to handle larger amounts
> of contiguous data in one go.  In the SD card's case, I'm referring to the read- and write- multiple block command. 

My problem is my SDHC controller do not support DMA block tranfer interrupt, the DMA interrupt only occured when the total 
number of blocks transferd finished. 
In this case, the buffer passed to DMA controller must contiguous.
Linux can use dma_map_sg to mao scatter discrete memory to a contiguous buffer address.
RTEMS s/g buffer mechanism can not provide such buffer.

I'v used an alternative but not good method to solve this problem.

I allocate a large size buffer which provided a contiguous DMA memory address.

When read access, SDHC controller fills the buffer first, then use memcpy  to move data from the buffer to s/g buffers.

The write access is the same.

The performance is not very good, the Class 4 grade SD card speed is about Read:4MB/s, Write:2MB/s, only half of Linux.


> 3) A read request generated with the shell command 'cp /mnt/sd/<file> ./t.tmp', with <file> being less than 512 bytes long, generates at
> least 3 reads of the FAT block and the directory (64 blocks in my case).  I have seen the number of these reads as high as 7, but
> generally it seems to be 3 or 4.      
> 
> Since I haven't found much documentation describing how libblock and libfs should be used, I've been using nvdisk and others in
> the libblock directory as examples, along with libchip/i2c/spi-sd-card.c.  If I've missed some reading material, could someone
> please point it out?  
> 
> It looks to me to be a difficult job to figure out how libblock and libfs/FAT work.  Could someone please give me some guidance
> on how to approach this? 
> 
> I would like to understand why the FAT and directory need to be read multiple times, and why, if it does, the buffering feature
> of libblock doesn't seem to be taken advantage of.  Is there perhaps a cache buffer size that's not configured properly
> somewhere?  
> 
> Since the directory is made up of 64 contiguous blocks, it would be more efficient to read it with one read command.  What can be
> done to get that to happen? 
> 
> A number of block device drivers divide the device's block size into the sg length (as length / blocksize rather than (length +
> blocksize - 1) / blocksize, surprisingly), suggesting that the result could be larger than one.  Why perform this calculation if
> that's never the case?  
> 
>  Thanks,
>             Ric
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
> .