NAND OTP operations (preliminary patch)

[Werner Almesberger]

Harald Welte wrote:
> Even with a MD5 sum there is the slight non-zero probability that the
> checksum might be updated incrementally ;)

Yep, if someone really wants to make that effort :-)

> So maybe at least storing
> that checksum non-inverted and inverted should give us the absolute
> guarantee that nothing has changed.

That sounds nice. Someone who can find exploitable hash collisions
could still get away, but the air would get pretty thin for that.
Besides, about the only information we want to be tamper-proof
would probably be the serial number. For anything else, the
determined hacker could just interfere outside the OTP.

> have you seen my proposal at
> https://wiki.internal.openmoko.org/wiki/OpenMoko_OTP_Specification ?

Ah, now I did. Hmm, I don't really like all that binary stuff.
Putting the initial BBT there looks nice, though.

For the BBT, we could get away with a simple text representation:
BBT=d(1),d(2),d(3),...
where block b(0) = 0 (unused), and b(N) = B(N-1)+D(N). This should
typically take only around 200-300 bytes even for the maximum number
of blocks allowed to be bad.

> I really don't like having more strings.  just too difficult to parse.

But very flexible and human-friendly :-) Most of this information
should be for the kernel anyway, and there, we may very well have
a string-based interface, e.g., module parameters.

About the only thing I could imagine u-boot to use at the moment
would be hw_revision, for a multi-platform u-boot binary. That
would certainly be very nice to have. (You know that I like to
keep those things simple for the user ;-)

Also, making OTP just an extension of the environment would allow
functionality to be added easily, without requiring code changes
or even revisions of that big binary structure.

> No, I also don't think that's an option.  If we want to store BT MAC
> address here, during production we don't have a Linux kernel but rather
> only u-boot / devirginator running.

Yeah, I wonder what exactly they'll have at that moment. They do have
a Linux kernel at some point in time, so if it's done then, we don't
need u-boot to get involved. Well, with a string approach, we would
at least only one access function for everything, so that wouldn't
be too onerous.

Hey, we could even have DFU read/write access :-)

Cheers, Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/