[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.

jg@xxxxxxx.com said:
> Chip not ready for buffer write. Xstatus = 300028, status = b000a8  
	
	Xstatus	Status
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...

Chip1: SR.7+SR.5+SR.4
Chip2: SR.7+SR.5+SR.3

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...

--- drivers/mtd/chips/cfi_cmdset_0001.c
+++ drivers/mtd/chips/cfi_cmdset_0001.c
@@ -755,4 +755,5 @@
 
         ENABLE_VPP(map);
+        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.

--
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com