Josh, I think the solution to the 8 bit x8/x16 problem is to separate the query command matching from the commands that are written to the flash. Not having an 8bit x8/x16 implementation has made it hard for me to work this out.
As for your patch. While it does let me copy odd amounts of data at unaligned boundaries (something the driver did not previosly do). The results I get are not correct. Below I have filled memory with 010203040506... And copied part of it to a previously erase sector in flash.
=> nm 0x140000 00140000: ffffffff ? 01020304 00140000: 01020304 ? 05060708 00140000: 05060708 ? 090a0b0c 00140000: 090a0b0c ? 0d0e0f10 00140000: 0d0e0f10 ? 11121314 00140000: 11121314 ? 15161718 00140000: 15161718 ? 191a1b1c 00140000: 191a1b1c ? 1d1e1f20 00140000: 1d1e1f20 ? 21222324 00140000: 21222324 ? 25262728 00140000: 25262728 ? 292a2b2c 00140000: 292a2b2c ? 2d2e2f30 00140000: 2d2e2f30 ? .
=> cp.b 0x140005 0xe8180003 0x15 Copy to Flash... done => md 0xe8180000 e8180000: ffffffff 0ffe99cc ffffffff ffffffff ................ e8180010: ffffffff ffffffff 0000ffff 0ffe99cc ................ e8180020: ffffffff ffffffff ffffffff ffffffff ................ e8180030: ffffffff ffffffff ffffffff ffffffff ................ e8180040: ffffffff ffffffff ffffffff ffffffff ................
-----Original Message----- From: Josh Fryman [mailto:fryman@cc.gatech.edu] Sent: Monday, February 23, 2004 3:29 PM To: Brad Kemp Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] patch for CFI flash driver
hi brad,
I think this patch will break 8bit x8/x16 implementions.
not surprising :) i was worried i was breaking things when i did that solution, but wasn't sure how it would break.
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.
i'm almost certain of it. i don't design well after a long day of debugging problems.
do you have a nice solution to the problem? or do you just have the same "there has to be a better way" feeling about it that i do? i can go back and try to actually design a proper solution, but i was hoping the "fix" would give you the insight needed that you'd have an elegant solution...
cheers,
-josh
(another idea was to malloc a sufficiently large buffer, read in current flash contents, do the update to memory, then call the existing -unhacked- routines to write back to flash on nice boundaries to kill padding problems and alignment issues... but this seemed like an even worse approach.)