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

[Aaron J. Seigo]

On Tuesday, November 5, 2013 15:53:00 Derek wrote:
> 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?

this could be a recommendation in the spec; my concern for making it a 
requirement is that it would make the specification less desirable to vendors. 
every requirement extra is one more brick in the wall one must clear.

> 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.

yes, there could be two classes of devices. it makes the standard more 
complicated, of course, and one would need to find a suitably concrete division 
line. as i noted in an earlier email there are point of sale (POS) systems 
with raspberry pi’s in them. ignore whether that’s a brilliant idea or not for 
a moment, and consider whether that makes the r-pi an engineering (or, well, 
learning) type device or an ‘end-user’ device.

the maker community and easy access to awesome hardware is destroying the 
lines between “product” and “engineering kit”.

there is also the question of read-only eeproms. these exist and may be used 
for various reasons in both end-user- and engineering-type boards. would 
having a read-only eeprom make an otherwise engineering board an end-user 
product?

having  only (c) resolves possible ambiguities by not allowing for them.

what do you see as the benefits of specifying both option (a) and option (b) 
instead of option (c)? 

(keep in mind that (c) is really just a+b)

> 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.

yes, there is malware that infects the BIOS on our beloved x86 machines, and a 
writable eeprom would offer similar opportunities for mischief.

-- 
Aaron J. Seigo