[U-Boot-Users] patch for CFI flash driver

[Josh Fryman]

attached is a full patch for the CFI flash driver.  it tries to correct
a problem i spent a lot of time examining.  i've sent the patch to brad
(the maintainer) as well, but wanted to post it here for others to give
feedback on as well.

if anyone has a better solution, other ideas, etc, i'd appreciate hearing
them.

in short, in "write_buff(...)", the platform i'm using needs to be able to
pass in any mixture of alignments and lengths.  ie, the target flash addr
may not be aligned on a nice boundary, and the memory-to-write-from may
not be either.

there was a very rudimentary "check" in the prior version that would try
to do something for misaligned boundaries, but it just didn't work.  it
wound up writing padding to the beginning or end of the flash, which would
make things fail (ie, CRC) all over the place.  it also wound up dropping 
(!!) bytes under certain conditions, never writing them at all.

below is my "fix".  again, i think this is a hack, albeit a robust one at
the moment.  i think there's a better way to do this, or at least a 
cleaner way, but i wanted to get your feedback on it.  i'm not sure what
the "better way" is.

the first function, flash_write_aligned, is _always_ handed a nicely 
aligned block of data to write.  the "data" pointer and the "addr" flash
target location are always on a boundary which is a multiple of the width.
(ie, 8, 16, 32, or 64-bits.)  count is the number of bytes, but it's also
promised to be an integer multiple of the width.

the revised version of "write_buff()" uses the "READ_CURR" macro in two
places... but otherwise is fairly commented by itself.  it does essentially
a pre-alignment set of operations, then does a block-write via the first
function "write_aligned", and then does any necessary tail corrections.

any thoughts?

-josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.B
Type: application/octet-stream
Size: 11468 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040221/8a254bd3/attachment.obj