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.