hi..
the LAST thread in the saga! perhaps not as fun to read as your average Terry Pratchett novel, but hopefully as or more useful ;)
ok, so this thread is about the decision of whether to permit within the EOMA68 spec for the identification EEPROM to be writable.
there are three options:
a) the ID EEPROM must be writable b) the ID EEPROM must not be writable c) the ID EEPROM may be writable, but this should not be relied on by any software
let’s consider each in turn:
a) must be writable
this option raises quality issues for consumer devices where easy access to the EEPROM may be implicated in a variety of device damaging events. from virus propagation to accidental destruction of the device tree due to user- initiated EEPROM write ... this just isn’t a great option for many mass-market devices.
ergo, (a) is not an option.
b) must not be writable
for generic chassis (including, but not limited to, engineering boards) being able to write to the EEPROM is a requirement. so if the EOMA68 standard says that the EEPROM “must not be writable” then none of those boards can ever be certified as EOMA68 compliant.
this will result in specification defying chassis that work with EOMA68 CPU cards, but which aren’t themselves EOMA68 chassis. encouraging such defiance of the standard simply to fulfill completely valid use cases is a great way to lower the value of the standard"
"sure, there’s a standard *wink* *wink* but we all know that not all devices *really* follow it."
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
this is a middle ground which allows devices which would be in violation of the standard in the (b) case to remain compliant, while allowing devices which really are best served by (a) to not only be compliant but also avoid having theoretically portable software not performing correctly on them.
basically, (c) implies that the EEPROM must be treated as not-writable in the general case. any user actions or software that attemps to write to the EEPROM is classified as non-portable and device-specific, and the EOMA68 would provide zero guarantees as to the expected behaviour in such cases.
as this allows for compliant generic chassis *and* mass-market consumer devices, i highly recommend (c)
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?
I also don't understand why you couldn't just have "end-user" class devices (option B) and "engineering" class devices (option A). All that is necessary to convert from Eng class would be to write-protect the EEPROM.
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.
On Tuesday, November 5, 2013 15:53:00 Derek 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?
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 also don't understand why you couldn't just have "end-user" class devices (option B) and "engineering" class devices (option A). All that is necessary to convert from Eng class would be to write-protect the EEPROM.
yes, there could be two classes of devices. it makes the standard more complicated, of course, and one would need to find a suitably concrete division line. as i noted in an earlier email there are point of sale (POS) systems with raspberry pi’s in them. ignore whether that’s a brilliant idea or not for a moment, and consider whether that makes the r-pi an engineering (or, well, learning) type device or an ‘end-user’ device.
the maker community and easy access to awesome hardware is destroying the lines between “product” and “engineering kit”.
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?
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)
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.
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.
On Tuesday, November 5, 2013 16:25:01 Derek wrote:
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!
sort of; (c) proposes that portable software must treat the EEPROM as non- writable (so that’s a decision, albeit one that affects software) but otherwise leaves it *unspecified*. unspecified is not the same as an option.
that said, there are already lots of options in the OEMA68 spec (e.g. which USB versions, which ethernet speeds) and there are unspecified items such as covering multiple displays.
imho a standard of this sort contain the minimal set of rules to be useful, as that keeps both development and certification simpler, which in turns makes adoption and successful interoperability more likely.
so the question perhaps is: how important is it for the EEPROM writability to be specified?
if it is not important for interoperability or otherwise useful standards conformance, i would label it as “unnecessarily complex” and leave it unspecified.
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.
if a goal of the EOMA68 is to force open hardware, then i agree.
if that is not a goal, i would give the decision to the vendor. they are best positioned to know what will serve their audience best.
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.
IIUC this EEPROM only holds data which the kernel can elect to use, but which it can also just ignore (and use some other data from a µSD card instead). So making it unwritable doesn't mean the owner is screwed.
Stefan
On 11/05/2013 03:43 PM, Stefan Monnier wrote:
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.
IIUC this EEPROM only holds data which the kernel can elect to use, but which it can also just ignore (and use some other data from a µSD card instead). So making it unwritable doesn't mean the owner is screwed.
Stefan
I do not feel it is fair to exclude proprietary vendors from a open standard by insisting their hardware be open. That will cripple adoption in this current OEM climate and severely reduce the chances of making the desired change in the market.
What we can do is encourage participants to be open and endorse products that adopt open hardware philosophies. We need real life examples to compel people to switch. Once the EMOA-68 standard is adopted by both proprietary and open hardware vendors, being fully open and 'respects your freedom' becomes a selling point in an apples to apples comparison. We can not get folks to understand 'not owning your' device until there is such a direct comparison. We need to bring these vendors on to even ground with us.
Options 'C' is the best course forward for a healthy ecosystem with competition. Do not artificially restrict the participants be insisting on a philosophy, that defeats the point of an 'open' standard.
I do not feel it is fair to exclude proprietary vendors from a open standard by insisting their hardware be open. That will cripple adoption in this current OEM climate and severely reduce the chances of making the desired change in the market.
I don't think either of A, B, or C requires the hardware to be open, so this seems orthogonal to the discussion at hand.
Stefan
On 11/06/2013 04:14 PM, Stefan Monnier wrote:
I do not feel it is fair to exclude proprietary vendors from a open standard by insisting their hardware be open. That will cripple adoption in this current OEM climate and severely reduce the chances of making the desired change in the market.
I don't think either of A, B, or C requires the hardware to be open, so this seems orthogonal to the discussion at hand.
Agreed, and i made a poor effort towards the point I was trying to make. I let myself be side tracked by some of Derek's statements about open hardware.
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.
On Wednesday, November 6, 2013 22:15:42 luke.leighton wrote:
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.
sounds spot on; your mention of the X25 spec is a good lesson to follow, indeed.
On Thu, Nov 7, 2013 at 8:54 AM, Aaron J. Seigo aseigo@kde.org wrote:
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.
sounds spot on; your mention of the X25 spec is a good lesson to follow, indeed.
the truth tables you used also helped me to clarify this, as it reminded me of venn diagrams. the rules by which i derive the EOMA standards is not so much "there are no options" as it is "every option must be a superset of the other options in the same category". so supporting USB1 is ok, supporting USB1 & 2 is ok, supporting *only* USB2 is *not* ok, neither for CPU Card nor I/O board. the EEPROM is similar logic.
l.
luke.leighton <luke.leighton <at> gmail.com> writes [stuff about superset options]
Thanks for explaining all this.
On Tue, Nov 5, 2013 at 4:06 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Tuesday, November 5, 2013 15:53:00 Derek wrote:
the maker community and easy access to awesome hardware is destroying the lines between “product” and “engineering kit”.
destroy too strong. blurring maybe :) if a merged-product-engineering-kit that's EOMA68 compliant ends up being sold in 50million+ units i think.. i think... a) i will fall off my chair backwards b) the goals of EOMA68 could be said to have been well and truly met.
bottom line please remember the EOMA68 standard is designed for absolutely ginormous volumes, for some very specific reasons which i won't go in to (as they're future-speculative), but if you work out how many 5mm x 85mm x 54mm cards can fit into a 50ft sea-going shipping container it gives some perspective.
l.
On Tue, Nov 5, 2013 at 3:53 PM, Derek dlahouss@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.
On Tue, Nov 5, 2013 at 10:25 AM, Aaron J. Seigo aseigo@kde.org wrote:
hi..
the LAST thread in the saga! perhaps not as fun to read as your average Terry Pratchett novel, but hopefully as or more useful ;)
:)
c) may be writable, but portable software may not rely on this
yep.
as this allows for compliant generic chassis *and* mass-market consumer devices, i highly recommend (c)
agreed.
recorded here
http://elinux.org/Talk:Embedded_Open_Modular_Architecture/EOMA-68
On Tue, Nov 5, 2013 at 10:25 AM, Aaron J. Seigo aseigo@kde.org wrote:
hi..
the LAST thread in the saga! perhaps not as fun to read as your average Terry Pratchett novel, but hopefully as or more useful ;)
ok, so this thread is about the decision of whether to permit within the EOMA68 spec for the identification EEPROM to be writable.
there are three options:
arm-netbook@lists.phcomp.co.uk
-
Aaron J. Seigo -
Derek -
joem -
luke.leighton -
Scott Sullivan -
Stefan Monnier