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

[luke.leighton]

On Tue, Nov 5, 2013 at 4:25 PM, Derek <dlahouss at 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.