Embedded Open Modular Architecture/EOMA68
NOTE TO WIKIPEDIA EDITORS AND WIKIPEDIA READERS REGARDING FALSE AND MISLEADING INFORMATION ON WIKIPEDIA
A Wikipedia page covering the EOMA68 Standard was created recently and is being edited by people who have clearly not read the standard nor are familiar with the standard's background. In a little under two weeks at the time of writing there have been no less than SIX separate individuals providing false and misleading statements. The page on the site known as "Wikipedia" is NOT AUTHORITATIVE: considerable effort is being expended to ensure that factually inaccurate statements are not made, however at any one time there may be another editor who has, once again, not read the standard, edited the page without thinking of the consequences, and thus brought both EOMA68 and Wikipedia into disrepute as a direct result. If you intend to edit the page on Wikipedia and are unsure of any facts CONSULT THE AUTHOR OF THIS STANDARD. Update 26sep2016: the false and misleading page has been moved to a user page and is currently being developed in a safe environment that clearly carries no implicit "authority" - not that the Wikipedia page will ever be granted "authority"
Table of contents
- 1 NOTE TO WIKIPEDIA EDITORS AND WIKIPEDIA READERS REGARDING FALSE AND MISLEADING INFORMATION ON WIKIPEDIA
- 2 Table of contents
- 3 Glossary of Terms
- 4 EOMA68 Introduction
- 5 Specialist Tools, Equipment and Software
- 6 DRM and Tivoisation
- 7 External Considerations
- 8 EOMA68 Hardware-related Specification
- 9 EOMA68 Software / OS Requirements
- 10 Example Housings
- 11 Contact and Discussion
- 12 Slides
- 13 FAQ
Glossary of Terms
- EOMA68: name of the standard (not EOMA-68). stands for "an Embedded Open Modular Architecture Standard (68 pin connector variant)".
- EOMA68-<designation>: recommended unique naming convention for Cards that implement the EOMA68 standard. Examples: EOMA68-A20 (contains an Allwinner A20 SoC). EOMA68-jz4775 (contains an Ingenic jz4775).
- Housings: a "base board" into which (one or more) EOMA68 Cards can be plugged. similar to a "motherboard" but "motherboard" is subtly misleading (motherboards typically allow CPU and RAM to be replaced: EOMA68 Cards are where the entire computer is typically housed). previous names used during the development of EOMA68 include "Dock" and "Chassis" - both now deprecated.
- Card: short-hand for "EOMA68 Card". It slots into "Housings". may contain a fully-functioning computer (Single-Board Computer), but legitimate implementations of the EOMA68 Standard include FPGA Cards and something known as a "Pass-through" Card.
- MIC: stands for "Manufacturer Identification Code", similar to USB and PCI Manufacturer Identification codes. Currently defined as 4 bytes in length, and present in the EOMA68 I2C EEPROM.
The primary purpose of the EOMA68 specification is to bring end-users the right to upgrade their own mass-produced Computing Appliances. To make end-users lives easier, purchasing decision-making should be made not on technical interface capabilities, neither should they be expected to have significant technological expertise. This is the primary reason why EOMA specifications have no optional interfaces of any kind. The tag-line is "Just Plug It In: It Will Work". To achieve this level of simplicity for the lifetime of the specification (anticipated to be at least a decade) all Cards compliant with the EOMA68 specification have to be compatible with all compliant "Housings".
The trade-off between choosing a single-board design or even another modular form-factor is as follows:
- EOMA68 products will not use all of the integrated functions of single-board designs, automatically resulting in minor cost increases for products, however this cost is negligeable compared to the long-term end-user cost savings.
- EOMA68 products are user-upgradeable. The Housings can be kept out of landfill - kept in useful service - for the lifetime of its components. Only the Cards need be upgraded at a much lower cost than a single-board design in order to continuously give the product a new lease of life.
- EOMA68 Cards can be shared by the same end-user across multiple products, automatically resulting in a cost saving that far outweighs the minor overhead of a single EOMA68 system when compared to a single hermetically-sealed throw-away product.
- However, single-board designs are typically throw-away products where the lifetime of the product is critically dependent on an extremely fast-changing market.
- Single-board designs are typically throw-away hermetically-sealed products with neither user-serviceable nor user-replaceable parts.
- Old Housings and Cards can be re-purposed instead of discarded as e-waste.
- Q-Seven and other similar standards are not realistically user-upgradeable (not for the average person) because products require tools, technical knowledge in the selection of technically-compatible replacement parts, and expert knowledge in the handling of electronics for ESD-precautions before even opening the case.
- EOMA68 products are upgraded by pushing a button and popping out the module: it literally takes seconds to install a new Card.
So the benefits for end-users are very clear: EOMA68 is easily understandable as a long-term investment for its end-users with significant long-term cost savings and reductions in e-waste. The benefits for factories are very clear: Cards aggregated across multiple products means much better bulk purchasing power, and Housings can also continue to be produced without requiring redesigns pretty much until the components go end-of-life.
No other modular computing standard available today has been designed with these aims in mind. An analysis of the standard is covered in-depth in a whitepaper on Ecocomputing at http://rhombus-tech.net/whitepapers/ecocomputing_07sep2015/
Specialist Tools, Equipment and Software
From the example and lesson of the Vehicle Industry and the "On-board Diagnostics" equipment fiasco which has been ongoing for decades, specialist tools, equipment and software for the purposes of installing firmware, or managing Cards, or operating the device, or components utilised anywhere in Cards or Housings, or even just for opening up casework, is simply not permitted, including after the Cards or Housings are distributed.
The lesson of the OBD scenario is particularly relevant from several perspectives:
- Firstly, the hardware protocol had to be reverse-engineered in order for people to interoperate with it
- Secondly, once hardware-level interoperability had been achieved, it was discovered that the data format is not self-describing and there is no provision for ascertaining the available features (unlike COM, which has "Interface self-describing Capabilities" as a fundamental and integral part of its design). So although there was a core format that appeared to be common across a wide range of manufactured vehicles, various manufacturers had added proprietary "extensions" without declaring or publishing the same, on a per-vehicle and even "per-vehicle-firmware-upgrade" basis.
- Thirdly, the connectors utilised varied drastically from vehicle to vehicle. The author of this standard was shocked to have been shown (over 15 years ago), by one small independent garage, an ENTIRE SUITCASE stuffed with adapter cables. Early efforts to standardise the connectors actually resulted in the complete opposite, as Manufacturers resorted to DELIBERATELY putting custom connectors (in violation of common sense) as a desperate last-ditch effort to use the well-known utterly flawed practice of "security by obscurity".
- Fourthly, the proprietary software available which vaguely keeps up-to-date with the thousands of vehicles ever manufactured (and their associated firmware updates) was ultra-expensive, ran on the oldest most out-of-date computing equipment known to man, and was itself DRM-locked such that the only way for a garage to utilise it without paying the exorbitant ongoing license fees just to use it for older vehicles was to remove the legacy PC's BIOS backup battery, so as to reset the clock back to a date preceding the "expiration" date associated with the proprietary software's badly-designed DRM.
- Fifthly, several court cases against reverse-engineers have been initiated over the years. There are also several efforts by groups such as the EFF and others to pursue changes to the law in various countries, all with a view to ensuring that drivers and garages have a "Right to Repair" their own legitimately and wholly-owned vehicles without fear of retribution or harm or damage to their vehicle. The primary (but no sole) purpose of these court proceedings is to compel Vehicle Manufacturers to provide full and complete documentation of the custom data formats and custom communications protocols, removing their designation as "proprietary" and "trade secret".
- Sixthly, despite numerous "attempts" by various Vehicle Manufacturers to "fix" problems, vehicles to this day remain vulnerable to hacking attempts via their OBD Interface (including some that could cause death or injury, such as engaging a single brake disk on only one wheel when a vehicle is travelling at over 70mph).
- Sevently, rather than acknowledge these problems and deal with them, some of the manufacturers incredibly seek to SUE the Security Researchers who act in a responsible and ethical manner after bringing the vulnerabilities to the attention of the manufacturer!
This unbelievably ridiculous situation is one which simply may not be tolerated in regard to EOMA68, because all of the above interferes with the tagline "Just Plug It In: It Will Work" as well as simply flat-out scaring people silly, such that they would want absolutely nothing to do with EOMA68 if it suffered from any of the above insane problems!
There is a simple way to ensure that this practice does not affect EOMA68 compliant hardware: not only will Certification not be granted if specialist tools, software or equipment are required to use, diagnose, repair, operate or initialise EOMA68 compliant hardware, but if party endeavours to "change the rules of the game" after first distribution, Certification will be automatically revoked for all and any hardware that critically relies on or depends on the same. This is regardless of whether it is a third party that endeavours to seek patent royalties, forces NDAs, claim or seek copyright, trademark infringment, enables or activates DRM, or deactivates services (online or otherwise) on which DRM measures critically rely (please note that this includes 3G / 4G / LTE or other wireless services, particularly those that are "locked" to a particular vendor).
Thus it becomes in the best interests of Manufacturers to put pressure on such third parties (should the situation arise) to very quickly resolve the situation (or to ensure that the situation never arises by not making a design be critically dependent on one exclusive technology). Note that "paying up" does NOT constitute "resolution". Certification is still guaranteed to be revoked under these circumstances, as the threat is still present. An example of "Resolving the situation" would be "buying up the third party's patent, Trademark or Copyright claim" followed by "issuing a clear and royalty-free license". Also, challenging the patent or requesting a review would also constitute "Resolving the situation" (as long as there does not also exist the possibility (or an actual) Court Order requiring that products be impounded, held or otherwise prevented and prohibited from distribution, sale or use).
About the only possible exception here is for FPGA-based EOMA68 Cards (or Cards or Housings whihch require or utilise FPGAs). Given that FPGAs typically require proprietary software, it is a reasonable expectation that they continue to be programmable for the duration of their operational lifespan. However, even here: if the proprietary software suddenly becomes unavailable (or stops working due to OS incompatibility, or due to bugs), Certification of any product utilising FPGAs that are critically dependent on that software will be revoked, even if the product is otherwise still functional and operational. The reason for this is because any third party may, at any time, wish to re-program the on-board FPGA, and would, at that time, discover that this is simply no longer possible. It really is therefore in the best interests of anyone considering utilising FPGAs to ensure that the tools and toolchain required to program them are entirely "Libre".
DRM and Tivoisation
For purely practical reasons related to the anticipated lifespan of EOMA68, neither DRM nor Tivoisation is permitted in either EOMA68 Housings or Cards. The reason for this is very straightforward: the tagline over the anticipated decade lifespan of the standard is "Just plug it in: it will work". So there is anticipated to be a huge range of decade-old all the way up to modern Housings that are expected to interoperate without hassle with a decade-old all the way up to modern EOMA68 Cards.
Any application of DRM in the Housings automatically interferes with that tagline, and would thus bring the EOMA68 Standard into disrepute. To avoid this occurrence, DRM is simply not permitted. Or... it is permitted... but only if (just as in the GPLv3) the DRM key is published (under an in-perpetuity, irrevocable and royalty-free unencumbered license). Imagine if there is a DRM-locked peripheral in a Housing that only worked with a certain third party Manufacturer's Computer Card. How on earth would the tagline "Just plug in it: It Will Work" be a guaranteed promise when another manufacturer's EOMA68 Card does not work with that DRM-locked Housing?
Tivoisation (the practice of DRM-locking the software including but not limited to the bootloader so that it can never be replaced or upgraded) is also not permitted. End-users will also have certain expectations that older Cards will continue to function in newer Housings well beyond the manufacturer's anticipated lifespan (of their own company, even, let alone of the Card). So as to ensure that the projected eco-conscious benefits of EOMA68 actually materialise, end-users must be able to upgrade and replace the bootloader and the full OS on their own legitimately-purchased hardware (at their own expense). A third party manufacturer cannot be expected to assist end-users with the process of ensuring that their legitimately-purchased Card continues to function in another third party's (more modern) Housings, but neither should they be permitted to prevent end-users from ensuring that their Card continues to function.
Given that some Cards may be FPGA Cards, and given that some may be "Pass-through" Cards, it is simply too complex and too costly to implement DRM or Tivoisation. Passthrough Cards would require arbitrary OSes to have drivers written, because Pass-through Cards (which would typically have a USB port and/or HDMI or other video output) may be plugged into tablets (with any OS), smartphones (with any OS), laptops (with any OS), desktops (with any OS) - any device with a USB port or an HDMI port with such a massive list of OSes that it becomes utterly impractical to consider writing DRM-locked proprietary drivers to support such an overwhelming array of devices and OSes. Therefore, for purely logical and practical reasons, DRM and Tivoisation are simply prohibited.
Exception to DRM and Tivoisation
There is one and only one exception, under very specific circumstances: Virtualisation. If there is a CPU in the Card, and the CPU is capable of "Hardware Virtualisation" - the capability to run one or more OSes as "guests" under a "Host" OS - those "Guest" OSes are permitted to run DRM and Tivoisation, as long as it is entirely software-isolated within the "Virtualised Container" that in absolutely no way affects the end-user's ability to replace the "Host" OS at their own discretion, and does not affect the end-user's ability to use any of the hardware features of Cards or Housings.
A good test of compliance with this Exception would be: if the "Virtualised OS" is not running (or the Host OS entirely replaced), do all of the features of the Card still function (with the exception of those provided exclusively by the "Virtualised OS") and does it still function in all available EOMA68 Housings? If the answer is "no" to this question, the Card is not compliant with the EOMA68 Specification.
An example therefore of a non-compliant Card would be that the Virtualised OS sends proprietary (DRM-related) messages to a peripheral (a screen or storage device) that is an integral part of a Housing which, without those messages, the screen or storage device is either inoperable or operates with reduced capability (this practice is well-known to be implemented in portable USB-based DVD-RW drives). Thus in this example, if the operation of the Housing's built-in peripheral requires the Virtualised OS to be running, that is non-compliance with the EOMA68 specification.
It's worth noting that through Virtualisation, entire proprietary OSes may best be deployed. Given that proprietary OSes are extremely unlikely to be able to keep drivers up-to-date over decades-long periods with the huge projected range of future Housings, Virtualisation is about their only sensible deployment option. The "Host" OS (most likely GNU/Linux-based) would be responsible for helping normalise the interaction with the outside world to a limited subset of "abstracted hardware drivers" (for Networking, screen, keyboard etc) providing soft-emulation that maps down to real-world hardware. QEMU, VMWare, L4KA and XEN all have this well-known capability: some even provide optimised hardware-acceleration as well, making the "Virtualisation" route less burdensome for the proprietary OS vendor.
External Factors and Considerations is now on its own page.
Hardware-related Requirements is now on its own page.
EOMA68 Software / OS Requirements
Software / OS Requirements is now on its own page.
Here is a list of example designs which conform to the EOMA68 Standard:
- Mini Engineering Board - suitable for Free Software Developers, ODM Development, SoC "Board Support Packages", Experimentation, Prototyping, Electrical Engineers, Training and R&D purposes.
- Monster Engineering Board - suitable for ODM Development "Demonstration" Purposes: designed to be "cut down to size", requiring the minimum amount of CAD/CAM Development effort and maximising return on investment.
- The Obligatory Tablet - a simple tablet motherboard which could potentially be developed as a very low cost single-sided 2-layer PCB. Components are chosen to reduce development cost and risk, as well as reduce manufacturing cost.
- Laptop - a laptop motherboard which could potentially be developed as a very low cost single-sided 2-layer PCB, through the use of modular and optional components for WIFI and 3G.
- LCD (TV) - an LCD Monitor (or Picture Frame) which can be upgraded into a TV or an All-in-One Computer or an Internet TV or Personal Video Recorder or Media Centre. very versatile yet simple to do.
- Passthrough or "Blank" Card - a special type of card which simply passes through the connectors, with little or no signal conversion.
Contact and Discussion
For questions, comments and general discussion, please use arm-netbook mailing list
The FAQ is now on its own page.