Embedded Open Modular Architecture/EOMA-68 - Revision history

Lkcl: /* Table of EOMA-68 pinouts */

2013-05-23T16:40:36Z

‎Table of EOMA-68 pinouts

Lkcl: /* Start-up procedure */

2013-04-11T10:55:16Z

‎Start-up procedure

Äxl: /* Requirements for USB */ versioning

2013-01-09T16:53:26Z

‎Requirements for USB: versioning

Lkcl: bit about RGB/TTL track lengths

2012-11-29T19:49:57Z

bit about RGB/TTL track lengths

Lkcl at 16:27, 4 November 2012

2012-11-04T16:27:32Z

Lkcl at 16:25, 4 November 2012

2012-11-04T16:25:52Z

Lkcl at 16:25, 4 November 2012

2012-11-04T16:25:18Z

Lkcl at 16:24, 4 November 2012

2012-11-04T16:24:38Z

Lkcl at 16:24, 4 November 2012

2012-11-04T16:24:16Z

Lkcl at 16:20, 4 November 2012

2012-11-04T16:20:21Z

@@ Line 158: / Line 158: @@
 |-
 |* 22 ---- reserved ----
-|* 56 ---- reserved ----
+|* 56 Ethernet Feedback (transformer mid-point)
 |-
 |* 23 ---- reserved ----

@@ Line 199: / Line 199: @@
 = Start-up procedure =
-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.  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.
+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 0x70.  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 CPU card can then correctly access and initialise on-board devices.  It also defines the purpose and use of the GPIO pins (if any are required).  Also, the format of the LCD data is specified.  For example, the pinout diagram on this page assumes 24-pin RGB TTL, but some motherboards may have LCD panels which only have an 18-pin RGB/TTL interface.  The data in the I2C EEPROM therefore provides clear specifications on all the motherboard's peripherals.

@@ Line 33: / Line 33: @@
 All CPU 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 (1.5&nbsp;Mbit/s) is acceptable.
+* Providing USB Low Speed (version 1.0 - 1.5 Mbit/s) is acceptable.
-* Providing USB Full Speed (12&nbsp;Mbit/s) is acceptable if USB Low Speed is also provided
+* Providing USB Full Speed (version 1.1 - 12 Mbit/s) is acceptable if Low Speed is also provided.
-* Providing USB Hi Speed is acceptable provided that Full Speed and 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.
-* Providing USB Hi Speed (480&nbsp;Mbit/s) '''only''' and supporting no other speeds is '''not''' acceptable.
+* Providing USB Super Speed (version 3.0 - 5 Gbit/s) is acceptable if all lower speeds are also provided.
-* Providing USB2 but not USB3 is acceptable.
+* Providing a higher version '''only''' and supporting no lower speeds is '''not''' acceptable.
-* Providing USB3 only but no backwards-compatibility with USB2 is '''not''' acceptable.
+* Providing no USB 3.0 is acceptable.
-Chassis (devices) must also support up to a maximum chosen USB specification and all speeds below.  This guarantees that any CPU Card will work with any device, with any combination auto-negotiating to the maximum possible speed.
+Chassis (devices) must support up to a maximum chosen USB specification and all speeds below. This guarantees that any CPU Card will work with any device, with any combination auto-negotiating to the maximum possible speed.
 === Requirements for Ethernet ===

@@ Line 65: / Line 65: @@
 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 may warrant a "Certification Programme" to ensure that CPU Cards are compliant with a wide range of devices.
 * CPU Cards '''must''' provide software-programmable support for anywhere between 190x120 RGB-TTL resolutions all the way up to the maximum that they are capable of, with the maximum resolution being clearly marked on both the CPU Card, as well as the retail packaging in which it is sold.
 * CPU Cards '''should''' support up to at least 1920x1080 at at least 50fps.  However, some ultra-low-cost SoCs, especially those designed for mobile devices, only support up to XGA or WXGA resolutions.  The use of such SoCs is not entirely recommended.

@@ Line 264: / Line 264: @@
 = FAQ =
+The [[Embedded_Open_Modular_Architecture/EOMA-68/FAQ|FAQ]] is now on its own page.
 [[Category:Embedded Open Modular Architecture]]
 [[Category:ARM processors]]

← Older revision		Revision as of 16:25, 4 November 2012
Line 263:		Line 263:

	= FAQ =		= FAQ =
−
−	This section is more informal than the specification above. Its main purpose is to highlight, from key conversations held on the Internet, what is special about EOMA-68 when compared to other standards.
−
−
−
−	~~==== OK, but why do you want EOMA to be installed/removed more often - I want to understand why granny would want to do this? ====~~
−	* " SO-DIMM sockets have a lifecycle of about .... something like 25 cycles total. Maybe not Granny but a professional who has an EOMA-68-compliant Digital SLR Camera, as well as an EOMA-68-compliant smartphone, tablet, laptop, and 30in LCD monitor at work and a games console at home. They might end up inserting/removing their EOMA-68 CPU Cards up to 10 times a day. The potential here is huge. it covers virtually every mass-volume electronics system you can think of, in the world. With the exception of the hard-core gaming industry, the high-end server market, high-end / real-time video editing Industry and ... err... i run out of examples where EOMA-68 could not be used. oh yeah: portable watches :)"
−	* http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-October/005796.html
−	* From: http://ibot.rikers.org/%23arm-netbook/20120929.html.gz @ 18:57.53 (slightly reformatted)
−	~~==== Why are the interfaces in EOMA-68 mandatory? ====~~
−	* EOMA-68 is a mass-volume user standard, not a factory-installation standard. Imagine a situation where a customer buys a CPU Card where there was no support for SATA, for example. They would be extremely annoyed when plugging it in to a laptop, desktop or NAS box with an SATA drive, to find that the very expensive internal hard drive was inaccessible. This would result in returns of products, threatening the viability and acceptability of the standard.
−	* About the only situation where not supporting some of the interfaces would be acceptable is a "pass-through card", especially one that's pre-installed, say in an LCD product that can be upgraded to a TV or a PC. Under these circumstances, not putting on an SATA pass-through socket would for example be reasonable, especially if that LCD product did not have a built-in SATA drive. However, a "general-purpose" pass-through card not associated with a specific product really should be sold with an eSATA socket, RJ45 connector, USB connector and a DVI, HDMI or other video input along with conversion internally to 24-pin RGB/TTL, in order to comply with the EOMA-68 specification.
−	~~==== Why are there so many pins dedicated to the LCD? 28 pins out of 68 is a lot: surely some other interface such as composite video (VGA) could be used for example? ====~~
−	* VGA is surprisingly power-hungry as it is 75 ohms, and, at higher resolutions the analog R,G,B lines would be running at exceptionally high frequencies. A 24-pin parallel digital bus runs at much lower speeds, using less power. Additionally, the EOMA-68 Standard is designed for use for devices with LCD panels all the way from around 320x240 all the way up to 1920x1080 if the CPU supports that rate. If the standard required Composite Video, the cost of the ICs for converting from RGB/TTL to VGA plus the cost of converting back from VGA into RGB/TTL would threaten the viability of a low-cost product due to the additional cost. The larger products can however much easier absorb the cost of an LVDS converter IC. So the main reasons are: economics of scale. Also, the remaining 40 pins are perfectly sufficient for providing general-purpose "multi-peripheral" interfaces (I2C, SATA, Ethernet, USB).
−	~~==== We have a device where we want to save cost by assuming that all CPU Cards will come with the same ports as the very first CPU Card (the Allwinner A10). Is that ok? ====~~
−	* It would be best not make any such assumptions when developing products. Future CPU Cards will include, for example, a built-in 3G antenna at the end (just as there are now with 3G cards for the legacy PCMCIA standard), where it will be important to keep any metal away from the antenna. Such CPU Cards could not have metal connectors like HDMI, or USB-OTG or Micro-SD; Micro-SD, just like with the SIM Card, would have to be top-loaded through the case. Products should be designed with this in mind. Realistically, however, end-users will clearly be able to see from the specification of a particular CPU Card what connectors it has.
−	~~==== Could you please modify the EOMA-68 Standard so that it at least ''requires'' Micro-SD, or HDMI, or USB-OTG? ====~~
−	* Taking each of these in turn, the answer has to be no, each for different reasons:
−	* '''HDMI''' - some ultra-low-cost SoCs only have one video output (usually RGB/TTL LCD out). The cost of an RGB/TTL LCD to HDMI Converter IC is often $5 and requires a $50,000 HDMI License! To ''require'' an HDMI output, apart from R.F. interference with a 3G CPU Card's antenna, would make such low-cost SoCs prohibitively expensive.
−	* '''USB-OTG''' - again: many ultra-low-cost SoCs only have USB2. Whilst many of them have 2 USB2 interfaces, if one came along which only had 1x USB interface, then if USB-OTG user-facing was part of the EOMA-68 Standard it would be necessary to put down a $1.50 USB-OTG Hub IC and other components, automatically eliminating any competitive advantage of using that lower-cost SoC in the first place.
−	* '''Micro-SD''' here it is different, but the same story. Even Micro-SD is quite wide (16mm) so in cases where a 3rd party EOMA-68 CPU Card Manufacturer makes a card with many connectors on the end, there simply may not be space for Micro-SD, and they may choose to make the Micro-SD "top-loading", or even leave it out altogether and use NAND Flash only.

← Older revision		Revision as of 16:25, 4 November 2012
Line 1:		Line 1:
−	~~{{TOC left\|limit=0}}~~
	[[File:EOMA68-CARD00.png\|right\|frame]]		[[File:EOMA68-CARD00.png\|right\|frame]]

← Older revision		Revision as of 16:24, 4 November 2012
Line 1:		Line 1:
−	{{TOC ~~right~~\|limit=1}}	+	{{TOC left\|limit=0}}
	[[File:EOMA68-CARD00.png\|right\|frame]]		[[File:EOMA68-CARD00.png\|right\|frame]]

← Older revision		Revision as of 16:20, 4 November 2012
Line 1:		Line 1:
−	{{TOC limit\|3}}	+	{{TOC limit\|1}}
	[[File:EOMA68-CARD00.png\|right\|frame]]		[[File:EOMA68-CARD00.png\|right\|frame]]