Re: [flashrom] [PATCH 3/3] Not for merge: make the dummy programmer FAIL

[Carl-Daniel Hailfinger]

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

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

[PATCH 3/3] Not for merge: make the dummy programmer FAIL

[Stefan Tauner]

On Tue, 24 Jul 2012 00:59:16 +0200
Carl-Daniel Hailfinger  wrote:
> What do you think? Is this completely overdesigning a solution, or is it
> a useful unit test?

imho there are more pressing problems (that patch pile has quite some
mass for example ;)
and even if someone implements the described behavior... it wont be
trivial code hence it wont get reviewed soon just adding more pain - it
is also of no use to users.

but in general i think it would be nice to have... later (together with
a real unit test framework)... much later. but i'll put it on my todo
list because we both like it and that's what i wanted to find out with
this patch. :)