[Arm-netbook] identification EEPROM: writable or not?
Aaron J. Seigo
aseigo at kde.org
Tue Nov 5 10:25:06 GMT 2013
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
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
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
More information about the arm-netbook