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

[Brad Kemp]

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 at cc.gatech.edu] 
> Sent: Monday, February 23, 2004 3:29 PM
> To: Brad Kemp
> Cc: u-boot-users at 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.)
> 
>