Embedded Open Modular Architecture/EOMA68
- 1 NOTE TO WIKIPEDIA EDITORS AND WIKIPEDIA READERS REGARDING FALSE AND MISLEADING INFORMATION ON WIKIPEDIA
- 2 Glossary of Terms
- 3 EOMA68 Introduction
- 4 Specialist Tools and Equipment
- 5 DRM and Tivoisation
- 6 EOMA68 Hardware-related Specification
- 6.1 Interface Summary
- 6.2 Background to Interface Selection
- 6.3 Pinouts (version 1.0)
- 6.4 Table of EOMA68 pinouts
- 6.5 Start-up procedure
- 6.6 Future Versions
- 6.7 Deliberate Mechanical Non-interoperability
- 6.8 Physical Dimensions
- 6.9 Thermal Considerations
- 6.10 Header Connectors
- 7 EOMA68 Software / OS Requirements
- 8 Example Housings
- 9 Contact and Discussion
- 10 Slides
- 11 FAQ
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
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 and Equipment
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 components utilised anywhere in Cards or Housings, or even simply for opening up casework, is simply not permitted, including after the Cards or Housings are first distributed.
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 are equipment are required, but any 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.
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. 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".
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.
This section summarises the specification of EOMA68's physical interfaces. EOMA68 is an "aggregation" of a set of other pre-existing hardware interface standards. The number of pins on the interface is 68; the physical form-factor is the legacy PCMCIA.
Re-purposing of the PCMCIA interface and form-factor has been chosen to create portable mass-volume (100 million units and above) Embedded Computing Modules (Computer on Module) and other modules. Mass-volume "Lowest Common Denominator" interfaces have been chosen, all of which have existed for over a decade, are all low-power, DRM-free, royalty-free, fully-documented, supported across the entire industry and are well understood.
The interfaces are:
- 18-pin RGB/TTL (for LCD Panels and DVI/VGA/HDMI or other display conversion ICs)
- I2C (freely available for use except for one address: 0x51 which is reserved)
- 1st USB port (Low Speed, Full Speed, optionally Hi Speed/480 Mbit/s and optionally USB3.0 or USB3.1)
- 2nd USB port (Low Speed, Full Speed, optionally Hi Speed/480 Mbit/s)
- SD/MMC 4-bit wide with multiplexing to SD/MMC and SPI on 6 pins
- 4 pins "External Interrupt" capable GPIO that are guaranteed to generate a fast hardware interrupt to the SoC
- 1 pin "PWM" which is also multiplexed to GPIO
- SD/MMC (and down-level compatibility to SPI) multiplexed with 6 of the GPIO pins.
- TTL-compatible UART (Tx and Rx only) also multiplexed to GPIO
- SPI up to 4-bit wide, multiplexed with 6 GPIO pins
These interfaces are NOT OPTIONAL for Cards. All Cards MUST provide all interfaces (at some level of speed and capability). I/O Boards on the other hand are free to implement whichever interfaces are required for the device. For example: whilst all Cards must have a 2nd USB interface, devices such as tablets or laptops into which CPU Cards are plugged are not required to use it. The only exception is I2C (due to the EOMA68 identification EEPROM): it is mandatory for all I/O Boards to provide an EOMA68 identification EEPROM.
Exactly like legacy PCMCIA Cards, EOMA68 Cards may have absolutely any functions, any additional connectors, peripherals and so on without limitation, except for compliance with the EOMA68 pinouts and physical size constraints. These additional functions, which may include access ports in the casework, may extend outwards from the user-facing end of the Card to any practical extent, exactly as with legacy PCMCIA.
Background to Interface Selection
The interfaces have been specifically chosen because they are either essential or they are multi-purpose buses, and surprisingly they are perfectly adequate despite being Lowest Common Denominator across a wide range of CPUs for at least a decade. The goal here is not to attain ultra-high-speed latest-and-greatest performance but to use proven, long-established interfaces that will be easy to find parts for mass-volume appliances in potentially hundreds of millions of units and above.
Also, some graceful degradation through negotiation at the hardware level is not only desirable but is an essential distinctive and unique feature of the EOMA68 standard, because it dramatically simplifies the "sales pitch" as well as the engineering design, user card selection ("just get one of these, plug it into any product, it will work") and so on whilst at the same time ensuring that the range of SoCs that can be used is significantly diverse and future-proof.
- I2C - I2C is only two wires, is a global bus that can address multiple devices, and is a long-established proven Industry Standard with thousands of devices available.
- USB - USB2 is only two wires; USB3.0 is six, USB3.1 is ten. USB, like I2C, is a global bus that can address multiple devices and is a long-established proven Industry Standard.
- RGB/TTL - 24-pin RGB/TTL was chosen over LVDS or MIPI so as to keep the cost down, and also to keep the signal speed down. Whilst LVDS seems initially to be a good candidate, Single-Channel LVDS is unsuitable for driving 1,920×1,080p60 LCD Panels: most 1,920×1,080 LCD panels require between 2 and 3 LVDS drivers. MIPI also requires multiple parallel channels to achieve higher data rates. Any low-cost CPU chosen which did not have LVDS or MIPI would be forced to add a converter chip, potentially on both sides of the interface (CPU card as well as motherboard). So it makes sense to choose the proven, lower-speed, reliable 24-pin interface, thus making the EOMA68 Standard suitable for use even with ultra-low-cost 320×240 RGB/TTL LCD Panels, right the way up to HDTV screen sizes.
- SD/MMC - SD/MMC has a 4-pin, 2-pin, 1-pin and SPI mode. Transfer speed negotiation is possible at the hardware level. SPI can even be implemented as "bitbanging"
Requirements for USB
All Cards are required to support the full backwards-compatible auto-negotiation USB device capabilities and speeds of all former versions of the USB Interface, up to the maximum speed and capabilities chosen to be provided. Specifically:
- Providing USB Low Speed (version 1.0 - 1.5 Mbit/s) is acceptable.
- Providing USB Full Speed (version 1.1 - 12 Mbit/s) is acceptable if Low Speed is also provided.
- Providing USB Hi Speed (version 2.0 - 480 Mbit/s) is acceptable if Full Speed and Low Speed are also provided.
- Over the 1st USB port, providing USB Super Speed (version 3.0 - 5 Gbit/s) is acceptable if all lower speeds are also provided.
- Over the 1st USB port, providing USB Super Speed (version 3.1 - 10 Gbit/s) is acceptable if all lower speeds are also provided.
- Providing a higher version only and supporting no lower speeds is not acceptable.
To emphasise: providing no USB 3.0 or USB 3.1 over the 1st USB port is acceptable as long as USB2.0, USB1.1 or USB1.0 (and downwards-compatibility) is provided.
Housings must support up to a maximum chosen USB specification and all speeds below. This guarantees that any Card will work with any device, with any combination auto-negotiating to the maximum possible speed.
As a counter-example of a SoC that is NOT acceptable, the OMAP 3500 series provides USB 2.0 Hi-speed (480mbit/s) ONLY. Use of this SoC is NOT acceptable.
Requirements for RGB/TTL
The RGB/TTL output is the one point where close attention has to be paid on the part of the CPU Card designers, because of the variance between devices in which the CPU Cards will be plugged. This will need careful monitoring and warrants a "Certification Programme" to ensure that CPU Cards are compliant with a wide range of devices.
- RGB/TTL is a parallel data bus, potentially running at up to 125 or even 150mhz. To ensure that the parallel signals are not skewed, both CPU Cards and I/O Boards MUST ensure that the length of the RGB/TTL tracks (data, HSYNC, VSYNC, CLK and DE) leading to the 68-pin connector - on either side of the 68-pin connector - are all of equal length. It is recommended that both the source (e.g the CPU) and the sink (e.g an LVDS IC) are placed as close to the 68-pin connector as possible.
- CPU Cards must provide software-programmable support for anywhere between 190x120 RGB-TTL resolutions all the way up to the maximum type (1366x768 for 5mm cards, 1920x1080 for 3.3mm cards)
- CPU Cards must be able to provide a minimum screen refresh rate of 60hz, and must be capable of driving screens at only 30hz.
- Resource-limited CPUs may reduce the number of bits used to store colour (even to the extent of using monochrome only) as long as the actual RGB/TTL output can achieve the maximum resolution.
- EOMA68's RGB/TTL interface is 18-bit-wide. If a particular SoC only has e.g. 16-bit or 15-bit RGB/TTL then the LSB (lower) bits MUST be set to logic output level 0 when the LCD interface is enabled: they must NOT be left floating or tri-state. This ensures that devices which are expecting the full 18-bits do not receive noise on the lower bits of each of the R,G and B 8-bit inputs.
Although there is no reason why individual devices should not have more than one LCD screen, allowing them to be selected, the burden of complexity for screen selection is placed onto the CPU Card software, so any company planning such a multi-screen device should contact the authors of the EOMA68 specification (email@example.com). Realistically, multi-screen devices should consider instead using USB-based screen driver technology such as that from DisplayLink, or place any number of additional Display outputs onto the user-facing end of the CPU Card (most CPU Cards will at least have a Micro-HDMI output).
Resource-limited CPUs include for example ultra-low-power embedded SoCs which would struggle with the internal memory bandwidth needed to cover a 1366x768 24bpp refresh rate at 60hz. Under such circumstances using only 8bpp (2 bits red, 2 bits green, 3 bits blue, or 255-entry lookup tables such as were used on VGA monitors 30 years ago) or even 1bpp (monochrome) is perfectly acceptable in order to bring down the internal memory bandwitdh. HOWEVER if such tricks are used the actual RGB/TTL output MUST still be at 1366x768 resolution, at up to 60hz.
Requirements for I2C
These are the requirements for provision of I2C on an EOMA68 interface. The summary is that the I2C bus must not be shared with any peripherals on the CPU Card, and the CPU Card must be able to read an on-board EEPROM (at address 0x51).
- The I2C bus that is connected to the EOMA68 interface will expect to have access to an EEPROM that is addressable (readable) at I2C address 0x51.
- Additionally, there MUST NOT be any devices on the I2C bus on the CPU Card side. The reason is that all other addresses (other than 0x51) must be available for peripherals on the I/O Board.
- If a CPU Card needs to connect internally to any I2C peripherals on the PCB inside the CPU Card, the CPU Card MUST use a completely separate I2C bus (internally), NOT the one that is connected to the EOMA68 Interface. i.e. the I2C bus that is connected to the EOMA68 interface MUST remain completely dedicated to EOMA68, and MUST NOT be shared with any peripherals on the CPU Card itself.
- The EEPROM MUST NOT be used for the storage of user data: it is reserved exclusively for EOMA68.
- The EEPROM MUST be capable of operating at anywhere from 1.8v to 5.5v, or, alternatively, bi-directional auto-detecting level-shifting MUST be performed on the I2C signals. Generally it is easier to supply the EEPROM with the variable-level voltage VREFTTL.
Please note that there is considerable confusion over the definition of addresses in I2C. The discussion page has some clarification over what consititutes an address (7-bit) and what goes into the first 8 bits (7-bit address plus 1 bit indicating read or write). Adding to the confusion it is extremely common to find datasheets even from respectable companies that directly contradict the I2C specification.
Below is an example circuit showing an AT24C64 with the address set appropriately to 0x51. PLEASE NOTE that the AT24C64 datasheet INCORRECTLY misleads people to believe that the addresses are 0xA2 (for read) and 0xA3 (for write). The address for both read and write is 0x51 (in the top 7 MSBs) with bit 0 (LSB) indicating read (0) or write (1).
Requirements for UART
Strange as it may seem to have requirements for UART this section covers practical issues regarding protection of CPU Cards. When designing I/O Boards it is important to take into consideration that many embedded SoCs do not have proper UART buffering. Typically if the SoC is powered down but the I/O Board continues to be powered up such that it continues to provide a positive voltage to the UART "RX" line this can potentially result in power leakage through the SoC and on to other areas of the PCB. It is therefore critical that I/O Boards ensure that this does not happen.
As this problem is to be taken care of on the I/O Board it is worth observing that CPU Cards do not require UART buffering. They may however require level shifting: the signal levels are, like all other Digital I/O in EOMA68, expected to be relative to VREFTTL.
Below is an example circuit which can be used to protect the UART-RX line, using MOSFETs.
Here is another example that uses schottky diodes. D1 is to reduce the voltage slightly so that it will be below the 3.3v level that is internally supplied to the CPU Card. The same effect could reasonably be achieved using a resistor-divider bridge.
There are also other options such as the use of a MAX2322 RS232 buffer IC. Other options can be found here.
Requirements for SD/MMC and SPI
SD/MMC is a little strange in that it has hardware backwards-compatibility down to SPI in most controllers. However, recently the SD/MMC standard (version 4) has excluded support for SPI. The decision is therefore to "go with the flow" of the SD/MMC standard, but with the stipulation that there is to be *NO* expectation of explicit hardware-accelerated SPI support from the SD/MMC pins. To be absolutely clear: base boards *MUST NOT* expect there to be hardware SPI support from the SD/MMC pins (but that "if pushed", there is a way in software to provide SPI support even if the hardware controller does not provide it).
For where SPI is explicitly needed, there are two available options:
- An additional and separate SPI interface is provided, on different EOMA68 pins. Use of these pins as precedence is recommended.
- Even if a hardware SD/MMC controller does not support SPI it is still possible to emulate SPI using "bitbanging". As bit-banging is quite CPU-intensive, and the transfer speed of SPI is 25mhz, designers of CPU Cards as well as designers of I/O Boards need to take this into consideration.
In essence, the SD/MMC committee have caused a bit of trouble, here, but it may be best to trust their experience in that SD/MMC Cards have probably not, for some considerable time, been actually using SPI mode, but have been offering the 2, 4 (and now 8) lane capability for a long, long time. Relative (at the time of writing) to the 80 mega-BYTES per second of the latest SD/MMC 4.0 Ultra-speed cards, 25 mega-BITS per second backwards-compatibility - some 25 times slower - would seem ridiculous to continue to maintain.
On this basis, the SD/MMC interface is therefore offered as primarily being to access SD/MMC devices (cards and peripherals), *NOT* for the explicit primary purpose of accessing SPI devices. However, if SPI hardware interoperability happens to be available, it *MAY* be used, and for all other instances bit-banging *MUST* be provided in software. Board designers *SHOULD* take into account that any SPI interoperability is *LIKELY* to be implemented as bit-banging, and should, as a result, avoid using it except as an absolute last resort, prioritising the dedicated SPI interface available on EOMA68, instead.
CPU Card designers must also take into account that both the SD/MMC and the SPI interfaces are also multiplexed onto bi-directional GPIO. As most SoCs provide exactly this kind of multiplexing by default, the requirement to offer both bi-directional GPIO as well as the other functions is not technically burdensome.
Pinouts (version 1.0)
These pinouts make no attempt to be electrically or electronically compatible with the legacy PCMCIA standard. 1 PWM GPIO, 4 explicitly EINT-capable GPIO pins, 4 dedicated GPIO pins, additional GPIO multiplexing pins on other functions, 18-pin RGB/TTL, USB2, USB3.1, I2C, SPI, SD/MMC, UART are included in the Version 1.0 specification.
Four 5.0 V power inputs must be provided: all pins are rated at 0.5 A, so the maximum power dissipation is limited to 10 watts. Design consideration: please note that to ensure that thermal dissipation in an enclosed fanless situation is not exceeded, a maximum of 3.5 watts should be respected, or the card must contain its own fan (not recommended). Most systems will not have active cooling.
All High-speed signals (USB2, USB3) are balanced lines that are still separated using GND or Power pins. All other pins are low frequency, with the exception of the LCD Pixel Clock and Pixel Data pins, which could go as high as 125 MHz for 1,920×1,080 @ 60fps (not recommended). The GPIO pins are available, for general-purpose bi-directional use of digital data only.
The output from the 24-pin LCD RGB/TTL pins must be electrically compatible with a Texas Instruments SN75LVDS83B, where VREFTTL is supplied to IOVCC.
All GPIO should be initialised at start-up as tri-state isolated, or as high-impedance (48kOhm) inputs so as not to interfere with carrier boards. Voltage levels for all GPIO are relative to VREFTTL, and follow CMOS level rules: above 0.7 times VREFTTL for a digital "1", and below 0.3 times VREFTTL for a digital "0". Digital input voltage levels *MUST NOT* exceed VREFTTL, at any time. When the CPU Card is powered off (i.e. when VREFTTL happens to drop to 0V), all Digital IO *MUST* also be powered off.
The option for a CPU Card to provide USB3.0 or USB 3.1 is also available, if a given system has it. If, however, a particular system does not have USB3, the pins must not be used for other purposes, and must be left unconnected (floating). Additionally, I/O Boards must not use the unused pins for any other purpose and must leave them unconnected (floating). This is to ensure that automatic down-negotiation of USB2 occurs correctly and that damage does not occur to USB3-capable CPU Cards when plugged into I/O Boards with only USB2 capability.
Pin 43 is used for Card-specific / implementation-specific boot, power-up or reset purposes. It is to be connected to an external switch that pulls directly down to ground to indicate "boot / power-up / reset", and otherwise is floating. The length of time or the number of times that the switch is pressed is entirely implementation-specific for any given Card, and is entirely unlimited and unrestricted in scope by this specification. Potential examples which are not the full scope of possibilities include "brief press" for "bring up an on-screen shutdown dialog" or "press and hold" for "emergency power-off" and "press and hold to power on" and "press to bring out of sleep mode".
Note also: for factory-install purposes, cards are of course permitted to use all and any pins, ports or methods required to carry out factory-installs and testing, as long as after factory-install the 68 pins are entirely EOMA68 compliant. Examples of such uses would include a test-bench with an SD/MMC interface for first firmware boot, a JTAG interface and other diagnostics.
Table of EOMA68 pinouts
|Row 1||Row 2|
|* 1 GPIO (12) / SPI_MISO(SPI_IO1)||* 35 GPIO (13) / SPI_MOSI(SPI_IO0)|
|* 2 LCD Pixel Data bit 18 (Blue2)||* 36 LCD Pixel Data bit 19 (Blue3)|
|* 3 LCD Pixel Data bit 20 (Blue4)||* 37 LCD Pixel Data bit 21 (Blue5)|
|* 4 LCD Pixel Data bit 22 (Blue6)||* 38 LCD Pixel Data bit 23 (Blue7)|
|* 5 GPIO (14) / SPI_SCK||* 39 GPIO (15) / SPI_CS|
|* 6 LCD Pixel Data bit 10 (Green2)||* 40 LCD Pixel Data bit 11 (Green3)|
|* 7 LCD Pixel Data bit 12 (Green4)||* 41 LCD Pixel Data bit 13 (Green5)|
|* 8 LCD Pixel Data bit 14 (Green6)||* 42 LCD Pixel Data bit 15 (Green7)|
|* 9 GPIO (16) / EINT1||* 43 POWER#|
|* 10 LCD Pixel Data bit 2 (Red2)||* 44 LCD Pixel Data bit 3 (Red3)|
|* 11 LCD Pixel Data bit 4 (Red4)||* 45 LCD Pixel Data bit 5 (Red5)|
|* 12 LCD Pixel Data bit 6 (Red6)||* 46 LCD Pixel Data bit 7 (Red7)|
|* 13 LCD Pixel Clock||* 47 LCD Vertical Synchronization|
|* 14 LCD Horizontal Synchronization||* 48 LCD Pixel data enable (TFT) output|
|* 15 I2C Clock (SCL)||* 49 I2C Data (SDA)|
|* 16 GPIO (0) / SDMMC-D3||* 50 GPIO (1) / SDMMC-D2|
|* 17 GPIO (2) / SPI_IO2||* 51 GPIO (3) / SPI_IO3|
|* 18 GPIO (4) / SDMMC-CMD||* 52 GPIO (5) / SDMMC-CLK|
|* 19 GPIO (6) / SDMMC-D0||* 53 GPIO (7) / SDMMC-D1|
|* 20 GPIO (18) / EINT3||* 54 GPIO (19)|
|* 21 GPIO (20)||* 55 GPIO (21)|
|* 22 GPIO (10) / PWM||* 56 GPIO (17) / EINT2|
|* 23 GPIO (8) / UART_TX||* 57 GPIO (9) / UART_RX|
|* 24 PWR (5.0 V)||* 58 PWR (5.0 V)|
|* 25 ---- not used ---- / USB3 StdA_SSRX-||* 59 ---- not used ---- / USB3 StdA_SSRX+|
|* 26 ---- not used ---- / USB3 StdA_SSTX-||* 60 ---- not used ---- / USB3 StdA_SSTX+|
|* 27 ---- not used ---- / USB3 StdB_SSTX-||* 61 ---- not used ---- / USB3 StdB_SSRX+|
|* 28 ---- not used ---- / USB3 StdB_SSTX-||* 62 ---- not used ---- / USB3 StdB_SSTX+|
|* 29 PWR (5.0 V)||* 63 PWR (5.0 V)|
|* 30 1st USB2 (Data+)||* 64 1st USB2 (Data−)|
|* 31 GROUND||* 65 GROUND|
|* 32 GPIO (11) / EINT0||* 66 VREF-TTL (GPIO TTL Voltage Reference)|
|* 33 GROUND||* 67 GROUND|
|* 34 2nd USB2 (Data+)||* 68 2nd USB2 (Data−)|
It is required that all pins be disabled (floating tri-state) with the exception of the I2C Bus, the 5.0v Power and the Ground Pins. I2C Bus Master is then enabled, to search for an I2C EEPROM at address 0x51. This EEPROM contains Linux Kernel "Device Tree" data, which specifies the devices available on the motherboard, as well as the actual pin-outs. The exact format of the EEPROM data is yet to be decided.
One important aspect of reading the I2C EEPROM is that the Card can then correctly access and initialise Housing peripherals devices. It also defines the purpose and use of the GPIO pins (if any are required). Also, the format of the LCD data is Housing-specific. For example, the pinout diagram on this page assumes 18-pin RGB TTL, but some motherboards may have LCD panels which only have a 15-pin RGB/TTL interface. Some Housings' LCD output will have EDID data (conversion to DVI, HDMI or VGA for example), whilst others will not (a fixed-resolution LCD panel where the on-board EDID data is hopelessly out-of-date is very common in mass-produced panels). The data in the I2C EEPROM therefore provides clear specifications on all the Housing's "non-self-descriptive" peripherals.
Discussion of the startup procedure is here on arm-netbooks
All LCD and GPIO pins must be tri-state floating in order that future versions of this standard can provide faster (or merely alternative) interfaces. At the time of writing (2011), the interfaces in the 1.0 Specification are "Lowest Common Denominator" yet are still present across the majority of 2011's powerful embedded SoCs (OMAP4440, Enyxos4210, Tegra 3, iMX53, iMX6, Allwinner A10, A20 etc.) However, in the future, the "Lowest Common Denominator" could well comprise MIPI instead of RGB/TTL, 2 lane PCI-express (or its successor), and USB-3 instead of USB-2 (perhaps even a faster version of ULPI).
As of 2011 however, the total number of Embedded CPUs supporting all these newer interfaces and still keeping to a 1.5 watt budget is precisely zero. Support for these high-speed interfaces will therefore be re-evaluated in 2 to 3 years time, and a future version of this standard created when a large proportion of available embedded CPUs have these or other high-speed interfaces that are available at the time.
Deliberate Mechanical Non-interoperability
The re-use of the PCMCIA standard pinouts with no electrical or electronic compatibility requires mechanical means to ensure that newer cards cannot be inserted into legacy sockets. The proposed solution is therefore to deploy a fascia plate on the EOMA68 card that is both larger in width than the standard 55 mm as well as recessed by some 8 mm, along the length of one of the 85 mm edges. The exact dimensions are yet to be determined, as specific PCMCIA housings need to be examined to ensure that one side can take the recessed "edge stop". The following part, PCMCIA Ejector Assembly from Tyco Electronics, is ideally suited: slimline and nothing at the left side.
There are three sets of acceptable dimensions: as with the legacy PCMCIA interface, these must be backwards-compatible. As with legacy PCMCIA, Cards should typically have all user-facing connectors "flush" with the standard PCMCIA size. This will ensure that when a Card is inserted into a device, the connectors of the Card appear to be part of the actual device. However: devices should cater for the possibility that an EOMA68 Card may have connectors sticking out of the end, to any practical height (just as it used to be the case with legacy PCMCIA).
As the EOMA68 pinouts have been designed to avoid matching the power lines of PCMCIA, there is no need for mechanical blocking.
The physical dimensions are a maximum of 3.3mm just as with legacy PCMCIA Type I. Power consumption is a maximum of 5.0 watts. The maximum RGB/TTL resolution permitted is 1920x1080. There is no (unreasonable) minimum resolution.
The physical dimensions are a maximum of 5.0mm just as with legacy PCMCIA Type II. Just as with Type I EOMA68 Cards, power consumption must not exceed 5.0 watts. The maximum RGB/TTL resolution permitted is 1366 x 768.
Type III Cards have a maximum height of 8mm. Power consumption is a maximum of 10.0 watts. This is typically reserved for x86-based CPUs which require up to 10 watts to operate. The maximum RGB/TTL resolution permitted is 1366 x 768, as it is the Housing that (by way of being 8mm in height) can also accept Type II (5mm) Cards, which are also restricted to a maximum of 1366 x 768.
TBC: Type III Cards should not assume that there will be fans available in the devices in which the cards are inserted, and should make arrangements for the removal of heat (including heat-sink and built-in fan, within the 8mm height limit).
Interoperability Restrictions imposed by height limits
Restrictions on interoperability with other types are protected by height. Those restrictions summarise as:
- Housings that take the Type I Cards must only accept Type I cards.
- Housings that take the Type II cards must also accept the Type I lower-power cards (and operate correctly and fully).
- Housings that take the Type III cards must also accept the Type II and Type I lower-power cards (and operate correctly and fully).
- Type II 5.0mm cards and Type III 8.0mm cards must be actively prevented from slotting into Type I (3.3mm) Housings by ensuring that there is a physical slot in the casework that is no more than 3.5mm in height.
- Type III 8.0mm cards must be actively prevented from slotting into Type I (5.0mm) Housings by ensuring that there is a physical slot in the casework that is no more than 5.5mm in height.
In this way, Cards which have lower resolutions will not be plugged into Housings which require higher LCD resolutions than the Card can provide, nor will they drain more power than the Housing can provide.
In order to reduce the cost of Motherboards and system design, Type II Cards should not exceed an average of 3.5 watts power consumption for prolonged periods of time, despite there being provision for up to 10 watts on the EOMA68 connector.
Cards and Housings that support the Type III 8mm-high cards must be designed with a Thermal Dissipation capability that takes the 10 watt TDP into consideration, as well as taking into consideration the power consumption and heat generation of the devices used on the Motherboard as well. Whilst fan-based solutions are acceptable, the use of thermally-conductive copolymer plastics (some of which have thermal dissipation capabilities exceeding that of Aluminium) are recommended.
Within the physical dimensions, there is absolutely no restriction on the number of connectors, interfaces, headers, expansion headers or antenna protruding from the end of the device. For example: a Computer-based Card may typically have, for best useability, a Micro-HDMI, a USB-OTG, a 5-pin Audio Jack and a Micro-SD Card Slot. These four interfaces fit neatly within the 54 mm × 5.5 mm fascia plate size limit, as long as mid-mount connectors are used.
Also, on an actual EOMA68 Card's PCB itself, there is no restriction on the number of internal expansion headers (populated or unpopulated) - the only consideration being that the Card clearly cannot have expansion headers protruding up from the PCB (for use by Engineers and Embedded Device Designers), and also have a metal shield installed around the Card at the same time. However, there is no reason why the expansion headers should be unpopulated, supplied without a metal shield to Embedded Engineers, yet the exact same device shipped in mass-volume with a metal shield installed, for the average end-user.
The only issue to note is that there is a maximum power budget of about 10 watts (although there are four 5.0V 0.5A pins) but also that there is a practical maximum power dissipation of EOMA68 Cards of about 4 to 5 watts. There is no provision in the standard for air-cooling (fans) in the cases: most devices will be a passive-cooled layout.
If however the EOMA68 Card is designed to operate "stand-alone", for example by being provided with a Power Connector on its user-facing edge or by making use of USB-OTG, then of course the designers are free to disregard these constraints. If however the Card is also expected to operate inside a conformant device, then it must adjust accordingly and stick within the 4-5 watt heat dissipation budget.
EOMA68 Software / OS Requirements
This section covers the extensive and comprehensive perspective of the anticipated lifecycle of EOMA68 Cards and Housings. EOMA68 products are completely unlike throw-away single-purpose SBCs (Single-Board Computers) and throw-away hermetically-sealed monolithic devices: re-use, re-purposing and upgrading is encouraged, resulting in a greatly-extended lifetime for both Cards and Housings than would normally be expected. It is perfectly reasonable to expect any Card to change hands five or more times during its useful operational lifetime. As such, the Software / OS Requirements are correspondingly but simply a natural reflection of the full lifecycle, and may therefore come as a bit of a shock to those used to the usual "fire-and-forget" epidemic and endemic processes currently being deployed for standard mass-volume manufactured products.
This section is therefore broken down into roles. Whilst it is not necessary for all parties to fulfil all roles, it is generally a good idea for all parties to be aware of the responsibilities and obligations of all "roles".
Manufacturers and OEMs
This section is broken down into the roles and responsibilities that apply separately to Cards and to Housings. However there are different kinds of Cards, so these are distinguished and dealt with separately. The term "Manufacturers" is used in the context of covering a wide variety of people who may be collaborating together. For example, there may be a "Hardware Manufacturer" and the Card is then passed on to a "Software Manufacturer", but for the purposes of this section, the word "Manufacturer" is designated to not distinguish between these roles, and assumes a perspective that such distinctions are "in-house".
Cards with on-board CPUs
Cards which contain an on-board CPU (and associated memory and storage) are where the OS and the Software is to be executed. Thus, for the role of "Manufacturer", it is the Manufacturer is primarily, immediately and directly responsible for ensuring that the Card is compliant with the EOMA68 Hardware and Software requirements. These responsibilities are permitted to be "outsourced", however it is is critical to note that Manufacturers may NOT self-certify compliance with the EOMA68 Specification, and are ONLY permitted to apply to Authorised EOMA68 Compliance Agents for validation, compliance and testing. This is primarily for safety reasons.
- A Card with a CPU MUST be capable of operating as a stand-alone computer. Therefore, logically, it MUST either have on-board or removable storage from which to boot, or it MAY have sufficient on-board resources (within the available power budget) to perform some type of "network" boot, whether that be Wired or Wireless.
- If a Manufacturer chooses some form of boot process that relies critically and exclusively on "download" of any software involved in the boot process and/or the operation of the device, whether that be over Ethernet, HDMI-Ethernet, USB-based booting or Wireless forms (including 802.11, 802.22 or other forms such as GPRS / EDGE / 3G / 4G / LTE / 5G), great care must be taken to ensure that the means and method is anticipated to be available at a reasonable cost that not only the initial end-user is happy with, but that the ongoing end-users further down the lifecycle chain of the Card may also reasonably expect to have access to. If there is any reason that is suspected why such expectations are unlikely to be met (even such as "the 3G network is DRM-locked to a particular provider"), Certification will NOT be granted. It is however acceptable to have a means and method to boot in the absence of such "network" boot methods, such that the Card's full operation and function is entirely unaffected by the absence of such "network" booting methods.
- A Card MAY utilise separate internal storage media for "BIOS" or other early self-initialisation: exact means and methods of self-bootstrapping / self-initialisation are beyond the scope of this document and are entirely at the discretion of the Card Manufacturer. Note: DRM-locking of the early self-initialisation code is NOT permitted (see DRM section).
- However, at some point in the boot chain, selection of an OS (including a default OS) MUST begin: this MUST be from either on-board or removable storage (or from internal RAM disks that happened to be initialised as part of an earlier network-boot phase). Reminder: DRM-locking is NOT permitted during any of these phases (see DRM section).
- During all and any boot phases (first early BIOS boot, post-initialisation boot) and all and any subsequent operation (including the running of OSes), the software MUST be configured so as to read the EOMA68 I2C EEPROM (format TBD) in order to ascertain the existence and presence of any "Housings" and, in the case of the early BIOS boot, the existence and presence of any external Housing boot media.
- Ordinarily, the power-on boot phase (part of the actual CPU's on-board boot-up process) is outside of the control of the Manufacturer of the Card as it is pre-specified by the CPU designer. This process could potentially be disruptive to Housings if the CPU were to be connected to a Housing that, for example, utilised certain pins for GPIO but the CPU was expecting them to be an SD/MMC "boot media" for example. It is therefore the responsibility of the MANUFACTURER to ensure that the CPU is kept under control during this power-on phase. An example is the ICubeCorp IC1t which has three hardware pins dedicated to boot selection. By analysing the IC1t datasheet, then pre-selecting the correct hardware pins and selecting only the appropriate pins to be routed through to the EOMA68 Interface, potential disruption is completely avoided of all and any Housings under all and any circumstances for normal END-USER deployment.
- If it is not a practical option for the selected CPU (alone) to be placed into a mode where its power-on boot process could result in disruption of any peripherals accessible through the EOMA68 interface, the Manufacturer MUST add suitable buffering ICs that will provide tri-state protection so as to isolate the potentially-disruptive pins, whilst also ensuring that those tri-state buffers may be returned to a mode that does not affect compliance with the rest of the EOMA68 Specification (in particular the pinouts and interfaces section). This MAY be implemented simply as a delay (using hardware), as long as the subsequent boot process can take this into account.
- It is NOT the responsibility of the Manufacturer to cater for "abnormal" circumstances, for example if the end-user discovers (and activates) a "Factory Boot Mode".
- With the exception of "genuine safety reasons", Manufacturers are NOT permitted to prevent any third party from discovering or operating the Card outside of its "normal" pre-configured mode (as deployed and sold either through them in their capacity and role as a "Retailer", or by any independent Retailer). The best way to comply with this requirement is to have an internal "jumper" or "switch" actually inside the Card which is completely inaccessible under normal circumstances, such that the Warranty (if there is one) can provably be said to have been invalidated before the Card is capable of being placed into such "modes".
- Manufacturers are NOT permitted to prevent any third party from taking any action that would invalidate the warranty.
- With the proviso that the third party accepts that they have by this point already invalidated the warranty: assuming that the Card has not been damaged by lack of care by a third party in opening it up, the Card MUST continue to be operational without reduced capacity or function, whether it is operated in its disassembled state or whether it is reassembled.
- The erasure of all and any internal media and all and any data (including but not limited to boot media) is permitted as a means or method of "tamper-resistance", but the Card MUST be "recoverable" to a known-good state (without requiring specialist software, equipment or tools). If such specialist software is required, it must be freely available and compliant with Software Libre Licenses. If specialist tools or equipment is required, it should be of a type that is commonly and readily available, or the means and method of its manufacture and assembly should also be unrestricted and commonly available. For an extremely relevant example of what is NOT permitted, see the dog's dinner mess surrounding vehicle "On-board Diagnostics" tools and equipment.
- The blowing of internal e-fuses or writing to NAND, PROMs or EEPROMs in on-board CPUs or other ICs which, as a direct consequence of those actions being taken results in the Card being reduced in capacity or function (including boot, access to media and peripherals, or otherwise restricting the Card's usefulness and/or ability to be subsequently compliant with all aspects of the EOMA68 Specification), and which would require specialist equipment to replace, is NOT permitted.
- The blowing of internal e-fuses or writing to NAND, PROMs or EEPROMs in on-board CPUs or other ICs which, as a direct consequence of those actions being taken GUARANTEES that the Card remains compliant with all aspects and requirements of the EOMA68 specification, is permitted, as long as there is a means to temporarily revert or bypass the restriction (such as a "jumper setting" or switch or other suitable method) i.e. without specialist equipment being required to replace the affected ICs. This is a particularly useful action to carry out after factory-deployment: an on-board SPI boot ROM could be set into "read-only" mode after first factory initialisation. If however the e-fuse may not be replaced without specialist equipment, it is important that it only be used for software-only detection purposes, where the software may be easily replaced by the end-user with a version that simply ignores the state of the e-fuse... WITHOUT the end-user being penalised for doing so (such as claiming that the warranty is now invalid).
- If the Card is inserted into a Housing, it MAY at any time during the boot sequence or subsequent operation look for early-boot (BIOS) media, boot media and/or boot loaders and/or OSes and/or Software through the detection, initialisation of any "media" (including network-attached media) that is discovered. However, the Card MAY NOT simply assume the existence or presence of such "media", and must have some form of "fallback" position such that it may continue to function (in effect as a stand-alone computer). In addition, Manufacturers need to be keenly aware that even their own future Cards may use processors that are completely incompatible with the software that was found on such media, especially if the media is non-removable. The only circumstances therefore under which it might be acceptable is if there are additional applications which are entirely written in processor-agnostic programming languages, or perhaps are a "Virtual OS". Great care should be taken to ensure that the required resources to run the software are not beyond the capability and resources of third party Cards, so as a general rule the entire practice of deploying software on non-removable media is discouraged.
- The Card MAY be supplied (sold direct or through chains ultimately on through to retailers) by the Manufacturer with a SINGLE EOMA68-compliant OS, where "adaptable support" for the Manufacturer's own Housings (past and present) is REQUIRED.
- If the Manufacturer utilises Libre-compliant Source for all aspects of the operation of the Card (right from boot through to normal operation) and is in FULL LEGAL COPYRIGHT COMPLIANCE with ALL SOFTWARE LICENSES, and provides FULL DOCUMENTATION without requiring NDAs for access to full information regarding the Hardware on the Card at the time of release of the Card, then Manufacturers are NOT required to provide "adaptable support" for Housings that are not manufactured specifically by them. The best way to ensure compliance with this requirement is to apply for (and successfully receive, and continue to have valid) FSF "RYF" (Respect Your Freedom) Certification.
- If during the lifetime of the Card an additional Housing is released by the Manufacturer, the Manufacturer SHOULD provide a "Software Upgrade" for the Card's OS, such that the Card now provides "adaptable support" for the newer Housing being included as part of the "present set of Housings".
- A Manufacturer is RECOMMENDED to consider supplying multiple OSes for Cards, especially given that Housings supplied by the Manufacturer itself may be for a completely different purpose, during the lifetime of the Card'
- The Manufacturer MAY allow the OS or bootloader to have a "multi-boot" option in order to support its own range of Housings. It MAY also utilise "Virtual Machine" support of the on-board CPU as a means or method to provide that "multi-boot" support. In effect: all and any available options are permitted and encouraged so as to meet the end-user's requirements and to ensure the EOMA68 tagline "Just Plug It In: It Will Work" is met, for all products that the Manufacturer designs.
- IMPORTANT EXCEPTION. If the Manufacturer utilises ANY proprietary software, the burden of support and responsibility for ALL EOMA68-compliant Housings (past, present and future including third party Housings) shifts automatically and exclusively to the MANUFACTURER. Thus, if a single piece of software is proprietary and comes pre-installed on the Card, it is REQUIRED that the Manufacturer take sole, complete and total responsibility for ensuring that the proprietary software be validated as fully-functional, in perpetuity across the entire past, present and future range of EOMA68 Housings, whether those Housings be from the Manufacturer themselves or whether they be from 3rd parties. This responsibility MAY be outsourced to Authorised EOMA68 Certifications-compliance Agents, however the Manufacturer needs to take into account that it is perfectly reasonable for such authorised agents to charge for the Certification and Testing Process of all and any proprietary software presented. Manufacturers should also be aware that the process is not a "one-off, fire-and-forget" process: continuous on-going re-certification is REQUIRED. About the only possible exemption here is if the proprietary software is run in a "virtualised container" in a similar (isolated) method as described in the "DRM" section (note: not that the virtualisation software itself is proprietary). However this may require evaluation, depending on the circumstances and method deployed, so if in doubt it is best to contact the author of the EOMA68 Specification.
Cards designed with Security features
Cards with security features have completely different requirements that are in direct conflict with the otherwise open mindset behind EOMA68. As such, there will be special exemptions made (yet to be determined). However, a critical design rule shall apply: "security through obscurity", "snake oil" and other false and misleading designs will not be tolerated. Cards with security features that are implemented incompetently with blatant disregard for actual "secure design" (in both the hardware and software) could bring EOMA68's reputation into disrepute, and thus will not be tolerated.
In general, except where it is demonstrated to be completely necessary (Classified environments for example), the source code is expected to be available for public review.
Housings range from simple break-out boards, through "peripheral-extender" style devices (similar to the old laptop "docking stations") to fully-functioning autonomous devices where the insertion of an EOMA68 Card is merely an "augmentation". With this much versatility, the burden primarily falls onto Cards. However there are still some key guidelines and requirements:
- Manufacturers are NOT permitted to self-certify Housings as being compliant with the EOMA68 Specification, and may not utilise the phrases "EOMA68 Compatible" or "EOMA68 Compliant" or any equivalents without permission from an Authorised EOMA68 Compliance and Certification Agent. The reasons are extremely simple: safety is paramount. This is hardware. Design mistakes (and design flaws) can be made.
- Manufacturers MUST apply for a unique 4-byte "Manufacturer Identification Code" (MIC) from an Authorised EOMA68 Compliance and Certification Agent only, and MUST accept that this information is both public and immediately published as a supplemental resource associated with the EOMA68 Specification (publication location TBD).
- Manufacturers MAY create Housing-specific unique 4-byte identifiers, and MUST publish these, in exactly the same fashion as is utilised for USB and PCI.
- Manufacturers MUST ensure that when the Housing leaves their factory, the EOMA68 I2C EEPROM contains the unique 4-byte MIC (location and format TBD)
- The Housing-specific unique 4-byte identifier MUST also likewise be stored in the I2C EEPROM (location and format TBD).
- When designing Housings, Manufacturers MUST be aware of their obligations wrt DRM and Tivoisation (i.e. it is simply not permitted)
- Manufacturers that design Housings containing "storage" or permitting external or internal removable storage to be plugged in (whether the socket be inside the Housing or outside the Housing) should bear in mind that, whilst it is permitted for such external media to be utilised for boot purposes, they have no obligation or requirement under the EOMA68 Specification that such storage media be present at any time (including boot time) or even provided at all, safe in the knowledge that Cards are in no way permitted to expect such media to be present for any purpose. Even a Housing which does not even have any boot or storage media, nor provides a means or method of accessing such media, is perfectly acceptable, and in the case of certain types of Security-related Housings, may actually even be desirable.
- Manufacturers that design Housings which contain internal non-removable storage intended for the purpose of "booting" or "applications" need to bear in mind that Cards have different CPUs or may not even have a CPU at all. Any such booting or application software is therefore extremely unlikely to work except on a highly limited range of Cards. This practice is therefore STRONGLY discouraged, in favour of utilising either removable media, Virtual Machines, or processor-agnostic applications (python, perl, java bytecode). However even here there is still no guarantee that the application will function correctly (missing dependencies, out-of-date dependencies) or in the case of Virtual Machines, the Card simply may not be capable of executing the software due to a lack of resources. Thus, once again, the practice is STRONGLY discouraged.
- Manufacturers are under no obligation to provide external access (except through the EOMA68 hardware interface) to any internal components or storage media (bootable or otherwise), and (apart from through the EOMA68 hardware connector itself) are perfectly at liberty to create Secure Housings or tamper-resistant Housings. However, there should be no expectation or requirement that any Card (supplied by the Manufacturer or by a party considered to be a 3rd party from the perspective of the Manufacturer) SHALL boot FROM internal or external media (secure or otherwise).
- If there is any "secure media" or other peripheral provided as part of the Housing (including detached peripherals that may reasonably said to be "part of the Housing" i.e. the Housing is functionally useless or greatly reduced in function without that peripheral, internal or external), the means by which the media or peripheral is accessed (passphrase, password, dongle, 2-factor authentication procedure) SHALL be made public, published IN FULL without NDAs, royalties or any other restrictions, either on use, implementation, distribution of implementations in source or binary form, discussion of implementations, such that any party may have the reasonable expectation of being able to access the "secure media" through the installation of a 3rd party software implementation, even if the Manufacturer no longer provides a warranty for the Housing or the peripheral, or no longer sells the Housing (or peripheral), or is simply no longer is in business. The Manufacturer shall also warrant that these conditions (in spirit as well as in reality) shall apply even if the Manufacturer sells the Housing design (or peripheral, if designed by the Manufacturer) onto a third party, or if the Manufacturer is bought by another company.
- When designing and selling a Housing, the use or reliance on 3rd party peripherals by the Manufacturer which require NDAs, binary firmware, or other restricted devices, components, peripherals or media, which could reasonably said to be in direct conflict with the tagline "Just Plug It In: It Will Work", are NOT PERMITTED. Whilst this restriction may seem extreme, a "workaround" is to make the peripheral or component end-user removable, to ensure that it is not a primary part of the Housing's marketed purpose, and to ensure that there exist third party alternative peripherals or components that perform a similar function. The most common example is WIFI peripherals, the majority of which require proprietary firmware. Even if there exists one such peripheral (such as the Atheros AR9271-based TP150N which is fully-supported by the ath9k_htc linux kernel module and has libre firmware available for it), the obligations of the Manufacturer may reasonably said to have been met. Again, the simplest way to check if the Housing is compliant is to apply for (and be successfully granted, and to maintain and not have revoked) the FSF's "RYF" (Respects Your Freedom) Certification.
- Whilst it is preferred that the Manufacturer provide a means or method by which software on associated Cards is made available (i.e. aid and assist as part of the pre-installed software a means for "upgrades" or "software" to be installed in a reasonably-easy and non-disruptive fashion), a Manufacturer MAY designate the END-USER as being wholly responsible for the installation of third party proprietary software or firmware (libre or otherwise) for any third party peripherals or components (internal or external) that the END-USER chooses to connect to the Housing (or install in the Housing, if it has internal space).
- The Manufacturer MAY NOT prevent or prohibit ANY party from doing same, in any way. Common sense shall prevail as to whether this has any effect on the Manufacturer's warranty obligations (if the Manufacturer is also acting in any capacity under the role of a Retailer).
Libre PCB and Casework Engineers
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.