[Arm-netbook] defining the eoma68 eeprom usage

[Aaron J. Seigo]

On Monday, November 4, 2013 10:56:20 luke.leighton wrote:
> > this will depend on the device. for an engineering board, you almost
> > certainly want this ability.
> 
>  yes.  engineering boards would not be classed as "mass-volume
> end-user" boards. 

raspberry pi has sold 1.75+ million units so far. people are putting them into 
products like POS terminals (saw a crowd funding campaign for such a thing the 
other week).

for the maker community, this concept of “mass volume end-user board” is 
simply out of touch with reality.

> the requirements are very different.  EOMA68 is
> designed as a mass-volume standard.

so then:

* engineering kits that use EOMA68 cards should be assumed to be an invalid 
method for designing devices that are EOMA68 compliant since they will not 
adhere to the same standard. any device made with an engineering kit will not 
be able to pass (future) EOMA68 specification tests and so should not be 
considered a way to fully prototype an EOMA68 based product.

* EOMA68 is uninterested in powering devices for which there may be only 1000, 
100 or even just 10 of them made.

i’d like to know now before i invest more time in this.

> > for a security device, you probably don’t.
> 
>  a security device would be an end-user board.
> 
> > 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.
>  my feeling is that it has to be stronger than that.  the risks of
> mass-returns in the context of mass-volume distribution are too great.

this is not your risk. i don’t understand why you feel you need to save others 
from themselves. it is not your responsibility to do so.

>  what i think i will do is put in the spec that end-user applications
> (including the linux kernel and boot software) should assume that the
> EEPROM has been made write-only, and that methods for updating it for
> firmware-update should be taken into consideration during the hardware
> design phase.

i agree that it is sane for portable applications to assume that the EEPROM is 
not writable and that the EOMA68 spec should not require that the EEPROM is 
writable.

> >>  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.
>  yes.  not a problem.

great. so tell me how they do that without a writable eeprom? or is your 
answer to them “yes, you don’t get to adhere to the EOMA68 standard for your 
point of sale device because you only made a few hundred of them and you used 
some off-the-shelf engineering kit to do so”?

> > encryption keys in hardware.
> 
>  then a crypto chip should be used, or a SoC which has TPM, or has a
> bootloader area or on-board secure PROM - *anything* but an open
> readable EEPROM.

i’m really not looking for advice from you on how to do this, and you’re 
missing the point:

what to put on the EEPROM is something we need to know for the upcoming MEB. 
i’d  *like* that layout to be compatible with whatever might follow.

so let’s pretend instead of a crypto cert, i want to store a bitmap of a 
penguin on the eeprom. why? it doesn’t matter. i just do.

so let's define an EEPROM data layout so we can both get back to useful things.

>  in the case of the flying squirrel,

it has nothing to do with ‘flying squirrel’.

please, say on topic.

-- 
Aaron J. Seigo