[flashrom] [PATCH] Warn of one-time programmable (OTP) memory

[Carl-Daniel Hailfinger]

Am 15.02.2012 14:11 schrieb Stefan Tauner:
> On Wed, 15 Feb 2012 02:55:38 +0100
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> Now if something is outside the scope of
>> flashrom, should flashrom care at all?
> depends... i dont think of "the scope" as a clearly bounded area.
> everything related to flash chips is somewhat in its scope (else we
> would not talk about this), heck we even discussed EEPROM handling
> multiple times... we dont need to support any and all feature found in
> any flash chip out there, but we should integrate knowledge and code
> for the more common ones that might be useful, if there is someone
> willing to provide them (and maintain them if necessary).

If we target non-flash EEPROMs, we might as well support OTP. I'd say
such support is post-1.0 material, though (and no, I don't plan to delay
flashrom 1.0 like Wine 1.0 was delayed).


>> And then you have the problem that multiple chip generations often
>> share the same device ID, so probing can't differentiate between a
>> chip with OTP and one without unless you're extremely lucky. Do we
>> want FEATURE_OTP and FEATURE_MAYBE_OTP? 
> FEATURE_MAYBE_NOT_CLONEABLE
> half serious... at least this is the semantics i would like to tag
> and convey to the user for now.

Heh. I think FEATURE_OTP is OK for now, and postpone a split between
_OTP and _MAYBE_OTP.


>> Do we warn if a chip has a readonly serial number? That means the chip
>> can't be cloned. People who care about OTP for clonability reasons
>> probably care about other readonly contents as well. OTOH, other people
>> who don't use the OTP at all (for them, OTP is just an accidental
>> feature of a cheap flash chip) don't want to be bothered by yet another
>> line of output from flashrom which has no relevancy for them.
> do you agree to lowering the verbosity of the whole message to dbg
> level?

Yes.


>> Removing the trac reference and adding the IRC reference should be a
>> separate patch, though, which is
>> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> ok, this will go into the recently posted manpage improvement patch
> (planned to do that anyway because i did not think that you would look
> at this one now :)

Thanks!


>> do you know any good reference about man page formatting? I had trouble
>> finding out what .RE and .RS do.
> i have to look that stuff up every time myself, sorry.
> yesterday i have used http://gnustep.made-it.com/man-groff.html but
> it looks like that would not answer your question...

Thanks, it's a good start anyway.


>>> the other more theoretical argument i have is: OTP memory is just some
>>> memory in the flash chip. it may need other access patterns, but it is not much
>>> different from other write protected memories apart from that.
>>> some chips implement it in a way that it is even possible to erase the OTP
>>> regions. those regions are just normal flash and are made unwriteable by fuses
>>> in a register or another addressable byte.
>>>
>>> Signed-off-by: Daniel Lenski <dlenski at gmail.com>
>>> Signed-off-by: Stefan Tauner <stefan.tauner at student.tuwien.ac.at>
>> Stefan: I don't want to veto this patch, and although I think that OTP
>> handling is not really a flashrom feature, I think that this
>> implementation satisfies the quality criteria for merging, so the patch is
>> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> thanks! ill wait for your response regarding message verbosity while
> merging the (independent) manpage change into my other patch.

Go ahead.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/