Aaron J. Seigo <aseigo <at> kde.org> writes:
a) must be writable [reasons] ergo, (a) is not an option.
b) must not be writable 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 [reasons] I highly recommend (c)
Would it be so horrible to say something like "must provide physical pads to be shorted or a switch" (or some suitable technical term) to allow the end-user to remove the "write-protect" status of the EEPROM?
I also don't understand why you couldn't just have "end-user" class devices (option B) and "engineering" class devices (option A). All that is necessary to convert from Eng class would be to write-protect the EEPROM.
Are there any examples of software that store values in EEPROM? My experience is limited to x86 laptops, desktops, and servers, which I believe allow the bios to be flashed (thus option A), but assume a bad flash will brick devices. It's not an end-user storage area.