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

[Derek]

Aaron J. Seigo <aseigo <at> kde.org> writes:

> 
> On Tuesday, November 5, 2013 15:53:00 Derek wrote:
> > 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 look back at option A: Must be writable.  Your opposition is that an
end-user or malware may damage the necessary data in the EOMA68 data area. 
Thus, there are times when the data must be write-protected.

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

And I come to the conclusion that products should thus be open to being
engineering kits, such as having an extensible EOMA68 data area.  If a Maker
were to extend the GPIOs, they would have need to flash new information into
the EEPROM to be able to sell it as an end-user device, yet still pass on
the ability to build upon their work.

Thus, there are times when the data must be read-write.

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

Yes.  It would mean the buyer does not own their device.

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

I would characterize C as "I can't decide between a or b, thus I abdicate
and make it an option.  Luke is fond of saying "No options in the spec," for
good reason.  Tough cookies, let's put this brick on the wall!

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

There appear to my eye a number of similarities between your proposed data
structures and that of UEFI.  On an x86 machine, the spec requires the
vendor to make the firmware read-write under certain conditions.  While this
may be an attempt to avoid Antitrust litigation, it was not so onerous a
requirement for vendors.

If I may stand on the shoulders of giants, the GPL allows you to use and
modify code, and makes you grant the same right to the next person.  Open
hardware such as EOMA68 should likewise grant the right of defining the
device to the next owner.  Not that it need be permanently read-write, but
that it must be available and suitably easy.