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@cc.gatech.edu] Sent: Saturday, February 21, 2004 12:30 AM To: u-boot-users@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