Developing a FOSS / Linux friendly embedded hardware - component selection

Neng-Yu 'Tony' Tu

Hardware component selection seems like a easy job after people have google and digikey. But in real world, lots reason that make googled/digikey search result dose not mean it could be used in the mass production product. Mostly is not technical reason, but sourcing/SCM reason. Component sourcing/SCM (supply chain management) is one of the critical issue that will affect your design could go into real mass production or not.

Following are some aspect was considered during component selection process.

* Business relation:
Module vendor/chipset vendor always put business (either real money or just marketing) as first priority. Usually vendor or distributor will spent FAE/RD/support resource at confirmed customer, so it's not only about your money while you using their products into yours but also their money as well. Most hardware vendor need forecast required material quantities to
drive their upstream supply chain as well. We take LCM (LCD module) as example, if you buy module from vendor, they need to prepare:

* Flex print circuit cable
* LCM frame parts
* LCD Controller IC
* Touch panel controller chips and glass
* Many small components
* Negotiates with their factory in order assemble/delivery in time

Sometimes hardware providers will concern about of losing trading secrets/expose bugs with "open source" device. You have to clearly define about delivery target, what could release and what couldn't release to end customer, including:

* What is hardware delivery item/firmware version?
* Who should finish driver to specific firmware version?
* Documentation/source under what type license
* How to co-work on missing delivery? (Like GPL'ed version driver and re-distributable documentation).

All above will be continuous process during project period.

* Specification: Sometimes online chipset/module manuals/specifications are not updated one (or in-correct/non-function), especially those not release through official web site. There are some components I called: paper components, means not put into mass production yet or only vendor want to test the market response. Also, you have to understand specification very
well, because you also have setup acceptance standard/rules during whole process. Most embedded hardware won't fulfill every specification at design stage (durability/sensitivity/environmental tolerance/may others), you have to negotiate/track along the way.

Some vendor don't have linux friendly policy, you might not get source code of driver/testing tool. You may need to develop your own version, and find a way verify the specification before your linux driver ready.

* Unique/hard to source parts: If you using component that very unique in specification (like special cap value or fancy function). And this component could help RD simplify design or make life easier. For most developer, make mass production is not their responsibility, design good product is. Tricky part is: in many cases, using hard to source part will cause lots sourcing/logistic over head later (lead-time), and you might need to postpone whole production because of single component that seems harmless at design stage. You have to be very careful using unique/hard to source part if really want make a mass production-able device.

Some companies like using unique part as a lock (like own design function chip) to protect product, or using it as tool (like their own variation of PMU) to simplify later product design/verification cycle.

* EOL (end of life): Just like your cellar phone, electronics device chip life cycle is not long as you think. Most manufacture using the same part that "popular" device used, if "popular" device phase out (usually less than 1.5 years), sometimes component lead time will dramatically increase, because vendor will manufacture the part for you instead of moving stock around market. You your product design -> mass production period is too long (over 1 year), you must be very careful track your original deign-in part EOL date or specification change. Sometimes, you never get updated until you place next order. EOL is killer for hardware verification, for software need to have another round of test plan/driver parameter adjustment.

Some experienced people might ask: why so many industrial devices could grantee over 5 years or longer availability/replacement, answer is easy: they buy more as stock and sale product in higher price. So when manufacture stop fabricate component, they could still have on stock.

* Price: Including payment term/delivery method/tax. You could not get good price with reasonable quantities. This issue has nothing to do with software ;) but for PM, might need to keep an eye on it.

* Technical support: Most chipset/module will assign technical (FAE) and sales contact window after business cooperation. You may ask support from technical contact, usually including:

* Hardware testing/verification support
* Driver required document (may not release to public, but release to you as reference)
* Source code that under GPL license (or co-work develop one)
* Co-work on product development schedule (firmware
release/test/verification/bugfix/function add...etc)

Most of time component vendor only have driver to specific linux version (usually not updated one), and may use some strange rootfs combination. You have to double check what is "We have linux driver" means with FAE.

Component must have at least one of following charactics that makes it community/developer friendly component :)

* Full documentation, release in creative commons or re-distributable license, accessible from public Internet web site

* GPL'ed driver source, and driver already in upstream linux kernel tree is best

What is not acceptable is: binary driver and all documenation (user manual/datasheet/etc) under NDA, that developer could not easily track source and debug it. Sometimes vendor will only provide compilied/kernel specific driver, this is not acceptable format to FOSS developer.

Developing a FOSS / Linux friendly embedded hardware - documentation and source code

Neng-Yu 'Tony' Tu

During past few years, I have been through all kinds of challenge while develop an embedded hardware project. Most software people do not need to know (also don't want to know ;) ) the difficulty and potential problems/issues about design/verification/component sourcing/supply chain/factory/quality control in hardware (or embedded hardware). The reason using English in this series posts because I think it will help more community people have general ideas about how hardware industry works, and also how to make requirement if want to provide a linux/open source friendly device to community (another reason: I could type faster :P )

For FOSS/Linux projects, there will be more requirements (sometimes special support) that related to hardware vendor (component or chipset) in order to get project process smoother also avoid potential IPR issues.

Recently, open source, open platform and some make schematics publicly (like Openmoko or beagle board) already a trend nowadays, but open source itself and hardware product provide schematics is not new concept. 20 years before, most 3C electronics still provide schematics as part of product; my Apple II+ also came with several manuals that contained full product details.

Since more electronic circuit embedded into IC, also devices became more complex. Instead of fixing it, people throwing devices away once it became non-functional. And what most customers used to are: simple device, limited function, with limited way to used it. Not like camera today ;) even have wi-fi transmission/gps capability.

Also more and more IPR enforcement process inside/outside company; branding company may not own full product knowledge and rights because out source the design to ODM company, and re-distribution rights of related documents. So, there is more and more technical (trading secrets/legal/IPR) and non technical (business requirement for product) barrier make public hardware information required by software/community development become difficult.

For people developing software that related to hardware, need following information from hardware (at least one of following item will be required):

* Complete documentation about component (chipset/module), document may need
re-distribution rights, or release under creative commons

* Driver source code (boot code and kernel driver), under GPL is best. But usually you only could get reference code from vendor with other license and also under NDA

Effective documentation will contains all necessary information (initial setting/registers/gpio/usage conditions), and you have re-distribution rights. A lot of component documentations were under NDA (sometimes even you could easily acquired from Internet, but you still under NDA), and you have to communicate to right people get the approval for re-distribution rights.

Usually, component/chipset vendor will provide following solution for
FOSS/Linux hardware:

* Component/chipset vendor might provide you a striped version of document that with full required information and you could re-distribute (very common for Intel, but rare for most embedded application processor vendor)

OR
* Provide documentation and full reference code (usually Windows mobile), but you could NOT re-distribute either one, you must write your own version

OR
* Provide a stripped GPL version of driver (means, some function was hidden - you never know). This is not ideal, but acceptable, sometimes..

OR
* Provide driver porting service, provide you binary and dynamic load-able driver with limited parameter information, this is not preferred/friendly format for FOSS community.

For module like wi-fi/GSM/Bluetooth, usually you need to know interface protocol (SPI/UART/USB/I2C), initial method, commands. For component like application processor/graphics processor/power management unit, you will need full documentation to provide a community friendly hardware product.