NAND OTP operations (preliminary patch)

Hi Harald,

my first version of the NAND OTP code is in SVN:
trunk/src/target/u-boot/patches/nand-otp.patch

It allows arbitrary reads within any OTP page, and writes of
entire
pages (enforced by nand_write_ecc), with "nand
read.otp" and
"nand write.otp". 

Addresses are "linearized", so OTP is in the area
0-0xBFF.

By the way, the OTP can be updated incrementally, so it's
not strictly
"one time". If we want to put data there that
really ought to be hard
to change, e.g., a serial number, we could protect it with
an MD5 hash
or similar.

We could store data in the form of strings
"foo=bar", followed by a
checksum/CRC/hash. u-boot could then scan some or all of the
OTP pages
for such strings, and load them into its environment.

A byte with value 0 at the place of the first character of a
string
would be skipped, so entries could be "erased" by
overwriting them
with zeroes. A 0xff byte would indicate the end of the
strings in the
current page.

Ideally, I'd supporting writing only from under Linux, to
keep that
somewhat complex code out of u-boot. (Writing should also
allow the
page to be selected, in case we have a pattern we know to
cause
fragmentation.)

- Werner

-- 
 
____________________________________________________________
_____________
 / Werner Almesberger, Buenos Aires, Argentina    
werneralmesberger.net /
/_http://www.almesberger.net/_____________
_______________________________/

On Wed, Apr 18, 2007 at 01:30:31AM -0300, Werner Almesberger
wrote:
> Hi Harald,
> 
> my first version of the NAND OTP code is in SVN:
> trunk/src/target/u-boot/patches/nand-otp.patch

cool, thanks.

> It allows arbitrary reads within any OTP page, and
writes of entire
> pages (enforced by nand_write_ecc), with "nand
read.otp" and
> "nand write.otp". 

good.

> Addresses are "linearized", so OTP is in the
area 0-0xBFF.

nice.

> By the way, the OTP can be updated incrementally, so
it's not strictly
> "one time". If we want to put data there that
really ought to be hard
> to change, e.g., a serial number, we could protect it
with an MD5 hash
> or similar.

mh.  The 'usual' method I have seen is to store the whole
content twice:
non-inverted and inverted.

Even with a MD5 sum there is the slight non-zero probability
that the
checksum might be updated incrementally ;)   So maybe at
least storing
that checksum non-inverted and inverted should give us the
absolute
guarantee that nothing has changed.

> We could store data in the form of strings
"foo=bar", followed by a
> checksum/CRC/hash. u-boot could then scan some or all
of the OTP pages
> for such strings, and load them into its environment.

have you seen my proposal at
https://wiki.internal.openmoko.org/wiki/OpenMo
ko_OTP_Specification ?

> A byte with value 0 at the place of the first character
of a string
> would be skipped, so entries could be
"erased" by overwriting them
> with zeroes. A 0xff byte would indicate the end of the
strings in the
> current page.

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

> Ideally, I'd supporting writing only from under Linux,
to keep that
> somewhat complex code out of u-boot. (Writing should
also allow the
> page to be selected, in case we have a pattern we know
to cause
> fragmentation.)

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.

-- 
- Harald Welte <laforgeopenmoko.org>          	
       http://openmoko.org/
============================================================
================
Software for the world's first truly open Free Software
mobile phone

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/OpenMo
ko_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    
werneralmesberger.net /
/_http://www.almesberger.net/_____________
_______________________________/