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.