Am 23.07.2012 15:34 schrieb Stefan Tauner:
blacklisting and ignorelisting opcodes is just not enough. this patch does not introduce the most outstand failure injection ever, but it certainly helped me testing the other patch. maybe we want to make similar failures user configurable?
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
I really like simulating chip failure. What about doing this with a programmer parameter, maybe erasestuckbyte=val@addr+count:val@addr+count etc. (essentially an AND mask for the desired erase result) writestuckbyte=val@addr+count:val@addr+count etc. (essentially an OR mask for the desired write result)
val would be the hex representation of a single byte, addr would be the in-chip address where the stuck byte is placed, and count would be how often you have to write/erase to get the right value (with 0 as special count meaning the byte is stuck forever). For erasestuckbyte=0xfe@0xbabe+2 we'd get the following result: 1. Address 0xbabe has value 0xfe&oldval_at_0xbabe 2. Run erase 3. Address 0xbabe has value 0xfe 4. Run erase again (same or different block size) 5. Address 0xbabe has value 0xff 6. Write anything to address 0xbabe 7. Address 0xbabe has desired value 8. If you erase again, address 0xbabe has value 0xfe
Write resets the counter for erasestuckbyte.
For writstuckbyte=0x01@0xbabe+2 we'd get the following result: 1. Address 0xbabe has value 0x01|oldval_at_0xbabe 2. Run erase 3. Address 0xbabe has value 0xff 4. Write newval to address 0xbabe 5. Address 0xbabe has value 0x01|newval_at_0xbabe 6. Write newval to address 0xbabe 7. Address 0xbabe has desired value
Erase resets the counter for writestuckbyte
What do you think? Is this completely overdesigning a solution, or is it a useful unit test?
Regards, Carl-Daniel