Embedded Open Modular Architecture Initiative --------------------------------------------- Free Software Developers and Open Hardware Enthusiasts are invited to participate in an initiative to help develop low-cost, desirable mass-volume products which will be fully Free-Software and GPL-compliant prior to ramping up to mass-production. The goal is to revert the situation where mass-produced products only become GPL-compliant after they are end-of-lifed (if at all) or require reverse-engineering. Instead, the situation is anticipated to be such that low-cost mass-volume desirable products can be purchased off-the-shelf and flashed with alternative ready-made Free Software firmware, even by the average person. Introduction ------------ The success of Software Libre is more apparent through GPL Violations by mass-volume Manufacturers, and through Google's blockading of the release of Android 3 Source Code, than it is through true Community-driven Products such as the OpenPandora, OpenMoko, and Ben Nanonote. Even the Arduino-based products, although highly successful and achieving a great deal to advance Software Libre as well as Computer Science, are a limited market. To make matters worse, Linux Kernel developers are being overwhelmed by the commercial success of ARM Embedded systems (which have to be customised on a per-device basis). The complete lack of any kind of common "BIOS" in the ARM CPU world is just one of the serious concerns, yet the manufacturers who successfully sell millions of units seriously expect Linux Kernel Developers to contribute their time "for free" to integrating their modifications into the mainline kernel tree. This situation acutely highlights the dangerous double-meaning of the word "Free" in "Free Software". The situation in mass-volume manufacturing falls into two categories: deliberate and accidental GPL Violations. Many Chinese and Taiwanese Factories simply do not have any expertise in Software Engineering, and are usually supplied, unaware of the License Requirements, with GPL-violating binary Distributions by an ultra-limited number of ODM experts who have difficulty keeping their Software Engineers from finding higher-paying jobs once a project is completed. The second category is much more insidious, and is characterised by the Lawyers of such firms considering it to be a failure on their part if anyone even notices that GPL Software has been incorporated into the end-product. The EOMA Initative's aims are therefore to address these shortcomings, by turning the development cycle of mass-volume products on its head, and getting Free Software Developers more involved in the process, at every stage. The desperate shortage of Software Engineering expertise in China and Taiwan is therefore an opportunity that can be leveraged. The question is: how can this best be achieved? Defining Product Requirements ----------------------------- What defines a successful mass-volume product? Put simply: it has to be desirable! There are two primary ways in which that is expressed: price and features. If the features are desirable, people will pay any price. If however the price is low enough, the product falls into the disposable income bracket. So not only must the product have a low cost of components as well as manufacturing cost, but also, unlike any other product such as tin-openers, fridges or clothes, the success of Computing Products relies critically on its Software. Unfortunately for Software Libre, the much-talked-of upcoming success of GNU/Linux Distributions on the Desktop has not materialised, but there are plenty of Embedded Linux-Kernel-based Products (Android most notably) as well as GNU/Linux-based Embedded Products (using OpenEmbedded, EmDebian, buildroot and so on) that are commercially extremely successful: XBMC for example is available pre-installed on commercial products. Prior to that, the Linux PVR Project was deployed, in a modified form, on several mass-volume PVR and Satellite TV Products. The advantage however of developing products with the advance-involvement of the Free Software Community is that even before the mass-volume products are commercially available, Free Software Developers have, in their hands, prototypes that can be used for whatever purpose they wish. By coincidence, it happens to be in their interests to finish the job, ensure that the Prototypes end up in desirable mass-volume products, thus reducing the cost (to them) of purchasing - and potentially selling - the very products they helped to develop. The icing on the cake would be if it was possible for as much of the Prototype Hardware to be able to go straight into mass-production as possible. A Modular Architecture therefore is a natural follow-on from such. (It turns out that re-use has additional benefits, such as simplification of design, and a faster Product Development Cycle). So with this background in mind, the requirements can be expressed as follows: * A Modular Architecture is required, dividing the hardware into at least two user-upgradeable parts: simple Main Motherboard and complex Processor Card. * The cost of components shall be kept to a minimum, notably deploying Software-programmable low-cost parts instead of dedicated hardware ICs. * The PCB Designs shall, where possible, be kept to single-sided and as few layers as possible (especially the Main Motherboard). * The Software, including Linux Kernel, must reflect the component re-use and Modular Adaptibility inherent in a user-upgradeable Hardware Design. With that in mind, the EOMA Initiative has developed a hardware-software Common Standard, based around pre-existing mass-volume components as well as decade-established proven Computing Interfaces such as USB2, I2C, SATA-II and so on. Details of this Open Standard are available here, along with references to several example Motherboard Designs: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA Possibilities ------------- Within the requirements there is a great deal of scope for use by and involvement of Software Libre Communities. For example: a low-cost Arduino-like Motherboard can be designed and manufactured, potentially by simply redesigning an existing Open-Licensed PCB (such as the Leafpad Maple), and it could be plugged directly into any off-the-shelf and powerful embedded Processor Card. To take such a prototyping board and turn it into a simple Laptop, Desktop PC or Tablet Motherboard, especially once the Embedded Software has been written which supports Keyboard Matrix, Mouse, Battery, Touchpanel and LCD Backlight, becomes an easily achievable goal within the reach of the average Software Libre Developer and an Electronics Enthusiast - all using Free Software Tools. Opportunities ------------- Hinted at, above, there are several project opportunities for Free Software Developers as well as Open Hardware Companies and Enthusiasts. In no particular order, the opportunities identified to date are: * Transitioning of Open Hardware CPU Designs to the EOMA/PCMCIA Standard. Suitable existing Open Designs include the Beagleboard, Pandaboard as well as the IMX53QSB, all of which have Hardware Schematics including OrCAD files publicly accessible under Open Licenses. * Development of Prototyping and Arduino-like EOMA/PCMCIA-compliant Boards Arduino-inspired Open Hardware Products, such as the Leafpad's Maple, can be turned relatively quickly into minimalist EOMA/PCMCIA-compliant boards with the addition of very few additional components. Combining two embedded CPUs in this way results in a powerful and flexible platform. * Development of Firmware for mass-produced products using Prototype Boards EOMA/PCMCIA-compliant Prototyping Boards, or even just Arduino-inspired boards such as the Leafpad Maple, can be leveraged to develop Firmware for EOMA/PCMCIA-compliant mass-produced products. Battery Monitor and Charging, as well as input devices (Mouse, Keyboard, Touchpanel), and LCD Backlight are amongst the required Device Drivers needed. * Porting of Software and Distros to EOMA/PCMCIA-compliant Systems When entire Operating Systems, installed on a portable CPU Card that can be transplanted dynamically and regularly and at will by the owner of the CPU Card (into a tiny PDA or MID with a 3in LCD all the way up to a 36in HTDV and beyond), to say that there are Software-related challenges involved would be an understatement. Solving these challenges begins at Linux Kernel and Bootloader time, by reading Linux "Device Tree" platform configurations off of an I2C EEPROM on an EOMA/PCMCIA-compliant Motherboard, and goes on from there to include automatic booting of alternative pre-customised OSes as well as adjusting of applications to dynamically cope with a wildly differing range of screen sizes and input devices.