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

[luke.leighton]

On Tue, Nov 5, 2013 at 3:53 PM, Derek <dlahouss at mtu.edu> 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?

 agreeing with aaron (read in advance) - "must" is too strong for the
standard.  it's enough that end-user applications (including linux
kernel) have to treat the EEPROM as read-only but that factories and
"upgrade" programs have their own vendor-specific EEPROM-upgrading
procedures...   .... where "engineering boards" *happen* to fall into
that same EEPROM-is-writeable category

> Are there any examples of software that store values in EEPROM?

 it's usually in the ARM/embedded world.

 MAC IDs for ethernet.

l.