[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Jffs2 lossage after reboot
I'm a little confused by this. It's not JFFS2 but the flash chips and/or
drivers which are at fault here.
> Chip not ready for buffer write. Xstatus = 300028, status = b000a8
Chip1 03 b0
Chip2 28 a8
Only the top bit of Xstatus is meaningful, and it's clear on both chips,
which means 'Write buffer not available'.
Looking at the normal status bits...
SR.7 being set means 'Write State Machine Ready'.
SR.5 being set means 'Error in Block Erasure of Clear Lock-Bits'
SR.4 being set means 'Error in Setting Lock-Bit'
SR.3 being set means 'Low Programming Voltage Detected, Operation Aborted'
The datasheet also says that SR.5 and SR.4 _both_ being set after a block
erase or lock-bit configuration attempt indicates an improper command
sequence was entered.
So... one chip is just playing silly buggers and the other may possibly be
complaining of a low voltage?
Is this repeatable? Were the errors you quoted the first errors it
reported? Had you been talking to the flash with the bootldr before booting
Linux? What was Linux doing before the reboot?
We should probably be resetting the error bits in the status register more
frequently than we do. Can you try something along the lines of...
@@ -755,4 +755,5 @@
+ cfi_write(map, CMD(0x50), cmd_adr);
cfi_write(map, CMD(0xe8), cmd_adr);
chip->state = FL_WRITING_TO_BUFFER;
I don't see how that would make it _work_, but it should at least clear up
the status bits so it's more obvious _why_ it fails.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org