[Arm-netbook] defining the eoma68 eeprom usage

[Aaron J. Seigo]

On Sunday, November 3, 2013 11:03:15 luke.leighton wrote:
> hi aaron, thanks for joining in here.  most welcome.

:)

> On Sun, Nov 3, 2013 at 9:34 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > "The EEPROM MUST NOT be used for the storage of user data: it is reserved
> > exclusively for EOMA-68."
> 
>  yes.  my concerns here are that the EEPROM would be overwritten by
> user applications otherwise, potentially destroying the ability of CPU
> Cards to identify the device.

this will depend on the device. for an engineering board, you almost certainly 
want this ability. for a security device, you probably don’t.

since being able to write to the eeprom once it leaves the factory is a 
decision made in the choice of eeprom and the PCB writing, i’d suggest leaving 
this up to the device and simply note in the spec the pros/cons of each.

>  the hardware's not going to change, so why would the data
> representing it change?

the device id could be changed. consider people creating custom solutions 
using a generic engineering kit as an example. not only can they wire things 
to the 44 pin DIL, but they may wish to give their project a custom ID.

> > My understanding from past threads on the matter is that currently the
> > only
> > specified usage for this by EOMA-68 is a product ID string + device node
> > tree.
>  there was some debate about whether device node trees *plural* would
> be more appropriate - one per "thing".  e.g. "GPIO pin 5" would have

yes, this is an entirely other discussion, namely: “What should the device 
node page(s) format be?"

> > as well as vendor specific additions would be golden.
> 
>  ah.  right.  knowing partly the answer already [and thank you for
> agreeing to join the list to discuss this!], i have to ask, for the
> benefit of the list: what _kind_ of vendor-specific additions?
> specific examples, general examples, doesn't matter.

encryption keys in hardware.

>  bear in mind that the EEPROM is only 32k in size, it's a $0.10 part,
> and its main purpose is to store this critical missing identification
> data that all the other EOMA68 buses don't need because they're
> self-describing.

it is just far more elegant a solution imho to have one “this is the device 
information” EEPROM than have multiple ones that are all underutilized. yes, 
it’s a 0.10 part but i don’t see the point of using more materials, require 
more space on the PCB, etc.

> > A simple page based system would suffice afaics. Sth like:
> > 
> > Address         Size                    Value
> > ======  ===             ====
> > 0x00            2                       Page identifier (defined by EOMA68
> > spec) 0x02            2                       Size of page data
> > 0x06            val 0x02        Page data
> > 
> > Page data would (obviously) be limited to a maximum 64k in size, but that
> > really should not be an issue given the application (and given how much
> > data you can read at a time via i2c_smbus calls). A checksum could be
> > added to the page header if desired to verify the data read in, but that
> > could also be left to the page specific data. I don’t think a checksum is
> > needed for the device ID page, for instance.
> 
>   i recommend having at least one byte saying "capabilities", as the
> first byte.  then you can read that first byte and go "oh.  bit {say}
> 5 is set!  that means we use the new-spangly-expanded-data-format"
> which happens to be that you use 32-bit addressing not 16-bit for
> example.  8th bit you set to be "escape sequence".

good point; so we’ll put another 4 byte header at the front of the whole 
thing. i had such a thing in my first draft, but dropped it as unnecessary 
overhead .. but a version byte makes lots of sense.

4 bytes for the data header so we can fetch it all with a single 
i2c_smbus_read_word_data and have a checksum, etc. so:

Address         Size                Value
======  	===             	====
0x00		2		     	Capabilities byte
0x02		1			Checksum byte
0x03		1			Reserved

We would leave the capabilities bytes as 0x00 for now, and mark all bits 
reserved. This would give us 16 ‘capabilities’ to twiddle with in future. We 
have another reserved byte in their for future use and a checksum byte.

I briefly considered using that reserved byte for a page count, but it only 
saves 2 bytes in total, didn’t seem worth it, especially since that would not 
give us a “total amount of data to read from the eeprom”.

If we really wanted to get fancypants, we could add another 4 byte word that 
is the total size of the EOMA68 paged data block and then read the whole thing 
in one go from the EEPROM. I’m not sure there is really any benefit to this, 
however.

We can play with this an other options when we try it on actual hardware, of 
course.

>  then, yes!  you can set one of the bits as "there is a checksum".
> another way to do this is to have a checksum "page".  hmm, so many
> possibilities...
> 
> > Page identifiers would be things like: "0x01 Device ID".
> 
>  originally i was going to follow the principle of USB class : vendor.
>  but now that i think about it this is best reserved for an actual
> in-page piece of information.  so there would be "0x01 Device ID Page
> Info" then a page with that type would have... oh you describe it
> below already :)

even the USB standard mandates having all the data described below on the 
device. only the USB standard is really poorly done: 16 bits for all the USB 
manufacturers in the world? 16 bits for all the devices any one manufacturer 
will ever make? meh.

> > A simple, sequential page ordering would to make it easy to use a function
> > lookup table to parse the data. Page 0x00 would be a special “there are no
> > more pages” id.
> 
>  ... giving a simple linked list in effect.  yes.  like it.

exactly ...

> > this would have the nice
> > characteristic of any page id with the high bit set to 1 would be a vendor
> > page.
> 
>  ... but, again, before getting to that, i'd like to determine what
> those vendor-specific applications are, and to discuss whether it's
> appropriate to even have them.  given the potential risks of having
> the hardware destroyed by user applications getting it wrong i'm
> inclined very much towards the "absolutely not" end of the spectrum.

whether or not user applications *write* to the EEPROM is an entirely other 
matter.

the point is to be able to put device/vendor specific data on the EEPROM that 
can be read out at runtime. again, use case: encryption keys stored in 
hardware.

they can then be read at any time during the boot process to do things like 
create an encrypted tunnel on the network.

by having them in the EEPROM we would:

* avoid another component on the PCB (cost, complexity and ecological benefits)
* have this data somewhere we could make non-writable

this NOT, however, about saving random application data generated at runtime.

we have NAND and network for that.

>  i owned a Motorola A1200.  actually i owned two.  one of them was
> already a brick (ebay purchase... *sigh*...)  in the end i worked out
> what happened, after i had the phone switched off over a timezone
> change.  basically when i powered the phone up after a prolonged
> period of disuse, it tried to overwrite its own firmware, got it
> wrong, and destroyed itself.  that was _two_ $300 costly bricks i
> owned.  both of them out of warranty.

a) i hope we never store *firmware* on the EEPROM
b) one hopes we’d provide a way to write to the EEPROM even if the data on it 
gets messed up. with all the tinkering with uboot we’ve done in the past over 
the OTG port, i can’t imagine this is out of the realm of reason.

>  so for safety, even _allowing_ vendors to write to the EEPROM is
> something that i would like to see *actively* prevented.

writing is a secondary concern and imho is a decision that must be made on 
device-by-device basis. or would you like mebv2 to not be able to certify as 
EOMA68 compatible?

>  if vendors *really* want some non-volatile space, there's a couple of
> options.  1) some NAND/NOR 2) a second EEPROM [with a different
> address] 3) other [e.g. a proper crypto-chip].

honestly, requiring more hardware on PCB is ludicrous. let’s assume the vendor 
is completely incompetent and hoses their data on a theoretical second EEPROM. 
how good is the device now? you can’t save people from themselves. you can, 
however, make the specification less attractive and more expensive to use.

>  these I2C EEPROMs are only $0.10 to $0.15 so it's not a huge deal to
> put a 2nd one down on any board.

a 64k chip is 2.5-3x the price, it means another address on the i2c bus and 
more routing on the PCB.

> > The device ID page data definition might look sth like:
> > 
> > Size in Byte(s)         Value
> > ==========              ======================
> > 2                                       Device type (assigned centrally)
> > 2                                       Device revision
> > 4                                       Vendor ID (assigned centrally)
> > 4                                       Product ID (vendor generated,
> > registered centrally) N                                      
> > Manufacturer cstring
> > N                                       Product cstring
> > N                                       Serial number cstring
> 
>  can i think of anything else here.... no i think you have it covered.
>  the guiding principle here is the USB spec / consortium.  and the
> linux kernel MACHINE_TYPE registry.

yep.

-- 
Aaron J. Seigo