Re: cfi_cmdset_0001 unaligned write problems.

[David Woodhouse <dwmw2@infradead.org>]

Quick response :)

nico@cam.org said:
>  Yeah...  I just fixed that one...  Wonder why it worked for me till
> now...

If you're testing with JFFS you won't have exercised that code. 

> However I suspect that there might be an issue with __u16 promoted to
> __u32 then back to __u16 on big endian CPUs.  What is the expected
> behavior?

> On LE, 0x1234 becomes 0x00001234 the back to 0x1234 which is fine... 

On BE, I think it'll match the comments I put in.
 (writing 0x5a to an odd address)
tmp_buf holds {0xff, 0x5a, xx, yy}
*(__u16)tmp_buf is 0xff5a
datum is 0x0000ff5a, which is stored as 0x00,0x00,0xff,0x5a
do_write_oneword uses the two bytes at &datum, which are 0x00 and 0x00.

I have no BE machine to test on ATM, though.

I was also seeing problems with JFFS - whatever I was writing to the flash 
wasn't 'taking'. Immediately reading files back would give corrupted data, 
and the filesystem was entirely untouched on rebooting - it didn't even 
complain of invalid nodes.

I very much doubt that was the same problem - I'm running on SH3 where the
unaligned trap would kill it first time. The unaligned problems showed up
when I was using 'cat' to write to the flash, to check it was working.

I've reverted to v1.25 for now. 


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org