Possible bug in libchip/i2c/spi-sd-card.c (my MMC/SD problem)

[Gene Smith]

I don't have a way to check or verify this right now but I may see the 
reason for the problem I am having doing shell copies on my MMC cards.

In my previous email 
http://www.rtems.com/ml/rtems-users/2009/january/msg00078.html
I mentioned that 4 sectors (flash blocks) were written sequentially that 
should have been scattered about in flash. Only the first one was at the 
right place (the first FAT entry).

Also in this email, before I had a clue as to what I was seeing, I 
reported 4 multiple blocks being written on file copy and the last 
contained the copied file data: 
data:http://www.rtems.com/ml/rtems-users/2009/january/msg00040.html

In both cases I think I am seeing the same thing.

The multiple block write occurs in spi-sd-card.c in function 
sd_card_disk_block_write(..., r) where prm r is a struct/array of 
scattered buffers (each at a random address). There are 4 block to be 
written at address 0x200 (main FAT), 0x1ec0 (redundant FAT), 0x3d600 
(root dir entry) and 0x41600 (cluster 2 with file data). Since there are 
4 buffers (r->bufnum > 1) in the scatter array, a multiple block write 
to MMC/SD is selected. The multiple write sets the starting address to 
the first block (0x200) and writes all 4 blocks back to back beginning 
at that address, which is wrong in this case. That's why my blocks end 
up in the FAT area instead of at the right place.

So, unless the blocks are known to be truly sequential and not scattered 
or random, only then should the multiple blocks method be used. I don't 
know if there is a way to know without parsing the scatter array each 
time. So it might be better (but slower) to always just use single block 
write method multiple times if bufnum > 1.

Again, this is a theory that has yet to be verified.

-gene