[Arm-netbook] identification EEPROM: writable or not?

[Aaron J. Seigo]

hi..

the LAST thread in the saga! perhaps not as fun to read as your average Terry 
Pratchett novel, but hopefully as or more useful ;)

ok, so this thread is about the decision of whether to permit within the 
EOMA68 spec for the identification EEPROM to be writable.

there are three options:

a) the ID EEPROM must be writable
b) the ID EEPROM must not be writable
c) the ID EEPROM may be writable, but this should not be relied on by any 
software

let’s consider each in turn:

a) must be writable

this option raises quality issues for consumer devices where easy access to 
the EEPROM may be implicated in a variety of device damaging events. from 
virus propagation to accidental destruction of the device tree due to user-
initiated EEPROM write ... this just isn’t a great option for many mass-market 
devices.

ergo, (a) is not an option.


b) must not be writable

for generic chassis (including, but not limited to, engineering boards) being 
able to write to the EEPROM is a requirement. so if the EOMA68 standard says 
that the EEPROM “must not be writable” then none of those boards can ever be 
certified as EOMA68 compliant. 

this will result in specification defying chassis that work with EOMA68 CPU 
cards, but which aren’t themselves EOMA68 chassis. encouraging such defiance of 
the standard simply to fulfill completely valid use cases is a great way to 
lower the value of the standard"

"sure, there’s a standard *wink* *wink* but we all know that not all devices 
*really* follow it."

that is a horrible precedence to set in the very first revision of the spec.


c) may be writable, but portable software may not rely on this

this is a middle ground which allows devices which would be in violation of 
the standard in the (b) case to remain compliant, while allowing devices which 
really are best served by (a) to not only be compliant but also avoid having 
theoretically portable software not performing correctly on them.

basically, (c) implies that the EEPROM must be treated as not-writable in the 
general case. any user actions or software that attemps to write to the EEPROM
is classified as non-portable and device-specific, and the EOMA68 would provide 
zero guarantees as to the expected behaviour in such cases.

as this allows for compliant generic chassis *and* mass-market consumer 
devices, i highly recommend (c)

-- 
Aaron J. Seigo