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

[Brad Kemp]

Josh,
I think this patch will break 8bit x8/x16 implementions. 
The reports I got back from the field indicated that the port width had
to be 
halved to get flash writes to work sucessfully on 8bit  x8/x16
implementations.
I think there is a better solution to the problem than the one that was
originally implemented.
Brad

> -----Original Message-----
> From: Josh Fryman [mailto:fryman at cc.gatech.edu] 
> Sent: Saturday, February 21, 2004 12:30 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] patch for CFI flash driver
> 
> 
> 
> 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
>