On Tue, Nov 5, 2013 at 4:25 PM, Derek dlahouss@mtu.edu wrote:
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.
correct. hence the recommendation that under normal operation the EEPROM should be read-only (and user-applications *including* the bootloader *and* operating system should consider it normal that the EEPROM is read-only) **** BUT ***** that it is an OEM's decision to decide when the EEPROM is readable or writeable, and there will be a RECOMMENDATION that a factory-jumper or other mechanism entirely of the OEM's choosing to permit OS upgrades, developer modes and so on.
an "engineering board" would probably ship by default in "developer mode" i.e. read-write EEPROM. or just not have a read-only mode at all. that is the *OEM*'s choice.
I would characterize C as "I can't decide between a or b, thus I abdicate and make it an option.
that's not entirely correct in this case. the lesson is from the X25 specification. the choices they gave were a set of 2 options. option A was "use software to indicate control characters with an escape sequence". option B was "use a hardware line to indicate control characters".
option A obviously was available "all the time".
option B obviously could be available *sometimes*.
the problem with that is that you never knew whether option B would be available.... and therefore you could not *ever* count on it being available.... so it was completely and utterly useless. the irony is that (as i've mentioned before), if that redundant hardware line had been used instead as a TX clock line, X25 would have been a fantastic low-cost replacement for RS232 (to connect two X25 systems back-to-back you had to have a separate powered clock-generator box!).
in this case, what we're saying is "the software (OS, apps) in normal day-to-day mode MUST consider the EEPROM to be read-only". that is *not* optional. it doesn't matter how many CPU Cards there are, nor I/O boards: day-to-day operation WILL be read-ony.
then there is the practical decision for implementors to do firmware-upgrades. many systems simply won't upgrade. ever. a media centre. a fridge. a car stereo. if it breaks, you return it or you buy another one. in such systems, an e-fuse makes sense, or a factory-only jumper setting.
then there is engineering boards. these would ship factory-default probably with the EEPROM permanently read-writeable. that's entirely their decision.
what is *NOT* affected by any of these OEM decisions is that the day-to-day operation, software would be forced (For All X |= Y) to consider the EEPROM to be read-only.
l.