輪迴的遊戲 - Nokia + Microsoft...SO?

剛開始聽到 burning platform 加上跳北海的這個形容的時候, 只想到這個形容真好, 芬蘭人一定了解 sauna 的感覺, 這個例子 N 公司員工一定是感同身受啊. 沒想到接著就聽到 Nokia 棄守 symbian 跟 Meego, 投向 Windows phone 陣營起來. 連 Intel 都一副被拋棄的樣子, 更不要說 Nokia 剛領養的 QT 只能安靜的在旁邊嘆息了, 應該大家都傻眼吧. 我看 Nokia 跟 Symbian 的 twit 上, 一片罵聲連連, 員工示威. 看到 CEO stephen 還自己跳出來回 twit 說不是 M 的 trojan horse, 差點噗滋一聲笑出來. 我可以充分了解這個心情...BUT, 因為從小看過太多這類灑狗血賺人熱淚 (N 為何要棄我們而去找 M 啊...淚...)的合作案, 長大比較能冷眼旁觀 :P 不過, 還是蠻有感觸的, 所以趕快 blog 一下.

現實層面來看, Nokia 雖然在被 Android + iphone + 山寨的夾擊下, 2010 還是能保有 28% 市佔率, 其實怎麼樣看都不算弱者. M 公司雖然智慧手機被殺到只剩個位數零頭 (因為只有所謂智慧型....), 但是 Windows phone 7 的確跟 Windows mobile 6.x 完全不同. 網路上一堆把這兩間公司標成 Loser +Loser, 但是明明兩間某方面都有 dominate 市場的能力, 所以裝什麼弱啊!!! 應該反托拉斯先要準備調查一下吧! 我個人覺得Windows phone 7 跟 Zune 比較像, 很簡潔. 這年頭大家都在瘋 apple, 其實 M 的 Zune type UI 就跟 xbox 一樣, 真的用過其實會覺得還不錯 (well, 除了 my xbox 出現過多次三紅, 跟 kinect 需要大客廳外). 我個人還蠻期待 M 跟 N 做出 impress 的東西. 以及這個 marriage (營運 cost down vs. 重拾 MS platform 信心) 可以撐多久 :P

Nokia 當初跟 Intel 合作 Meego 也是蠻奇怪的事, 因為 Maemo/symbian/QT 跟 moblin 當初每個 target 不太一樣. 不過 Intel (butnot only Intel)也一直打著 x86 based mobile device 的主意,想想看, 所有的 x86 wintel 的 app 都不用 cross compile 啊, 多麼美好的世界! N 應該也寄望彌補 mobile device 上 roadmap 的空缺. x86 當然不單指小筆電的 atom, 還包括真正的 mobile device = PHONE 在內, 不過 x86 的 embedded mobile CPU solution 一直難產, 眼看 2011 年中一堆的 ARM cortex A9 dual core tablet 量產, 年底 PSP 2 的 quad-core cortex A9 量產, intel 應該不會讓 mobile computing 的餅全部被 ARMs 聯軍 吃掉吧 ;)

現代三國 (Android/iOS/Windows) 還真是值得期待. 不過 x86 跟 ARM 的雲端對決應該也是觀戰重點.......低頭做筆記.

一個情人節的無聊 nerd blog...haha

取得 Freerunner 原始碼及編譯完整 image 的方式 - 使用 mokomakefile

原本當初 Openmoko 新手手冊預計會寫 20 篇, 前 10 篇是基本操作, 後 10 篇預計是寫 tool/build 相關的. 最早會想寫的原因有幾個, 包含: 減少大家問重複問題的機會, 補充網路上一些中文資料不完整的地方, 還有順便當自己備忘錄 :)

後 10 篇最後沒寫是因為覺得網路上資料其實夠多, 像 OpenEmbedded (OE) 跟 git 都很多說明資料在 blog (英文很多) 或是有 PDF 格式可供下載, 一般 developer 如果這類閱讀問題沒辦法解決, 要真正加入 FOSS community development 的開發會很困難. 另外有公司組織上功能區分的原因 ;-)

原先 document team 有 "理想" 要把 wiki 內容整理到 Floss manuals 這個 project (http://en.flossmanuals.net/), 這樣只要再把整理的文件, 翻譯成中文, 這樣也比較會有一致性. 而 Flossmanuals 是另一個希望能讓 open source software 工具, 能有一個清楚説明公開文件的 project.

最早 Openmoko 在公開 wiki 時, 就提供了 SVN 的 u-boot/kernel 及 based on OpenEmbedded (OE) 的 package 在網路上供人下載. 同一時間, 少量的 Neo1973 的工程樣品, 也免費送到各個重要的 Open source community (phase 0 user) 的開發人員手上, Rod Whitby 是其中的一位, 他就幫 Openmoko 寫了一個非常強力的 makefile, 目的是讓 developer 能夠用簡單的方式, 透過 OE 能讓每個 developer 都能用 "一樣" 的 code base, 自己 build 完整的 distribution (kernel + rootfs). 早期的 mokomakefile 需要先自行安裝及設定 monotone (版本管理軟體, OE 在 2008 年前使用), 後來 OE 改用 git 當版本管理程式, mokomakefile 幾乎能全自動的完成所有 build image 的程序. 個人第一次使用時覺得: 這個 Makefile 真是超神奇跟強大的工具, 雖然當初在我的舊 PIII 1.2 G NB 編了快 3 天, 但自動化跟穩定程度真是神奇, 值得大家試試看.

* Mokomakefile 的主要說明網址: http://wiki.openmoko.org/wiki/MokoMakefile

Mokemakefile 全自動完成以下的幾件事:

* 下載 OpenEmbedded 的 Bitbake, 及相關設定檔原始檔

* 從網路上各個 bitbake recipt 指定的 git/svn 位置, 及下載套件指定訂版本原始碼

* 下載 recipt 裏的 patch 及相關設定

* 設定/建立 Host 端 OpenEmbedded 所需的設定, 包含工作目錄, 暫存目錄, image 存放目錄, 套件存放目錄...等等

* 依照編譯設定檔, 套用 recipt 指定的 patch 後, 編譯所有的套件, 包含 kernel 及建立 rootfs 所需的所有套件

* 根據設定檔的設定, 編譯套件的 ipk/opk 檔

* 將編譯好 rootfs, 根據設定, 做成 flash 可接受的 image 格式, 以及完整 rootfs.tar.gz 壓縮檔

OE 的系統龐大, 如果工具不熟, 對於開發人員是很大的負擔. 熟悉後, 它的優點及缺點大致如下:

* 優點: 能夠快速而且彈性的建立新的跨平台 embedded 專案套件, 不需要自己trace OE 套件都維持在最新的版本. 分散式開發架構, 國外開放/嵌入社群熟悉的工具及交流模式.

* 缺點: 學習曲線長, 速度慢, 開發工作易被外部的套件更新影響, 把原先簡單的工作複雜化 (如不是自己開發的套件發生 bug, 原本只需要在 local patch, 重 build, 重新 package. 使用 OE 協調多個 team 可能要繞一大圈, 效率低而且容易溝通出錯)

如果要使用 OE, 我建議還是讀一次 OE 的手冊, 尤其是第 7 跟第 8 章講授的系統概念部份.除了 OE 官方的英文外, 大陸 developer 有翻一份中文的, 如果習慣大陸編程語法的程式員們, 可以參考 http://blog.chinaunix.net/u1/52172/showart_1346396.html

Openmoko 版的 mokomakefile 現在由於無專職人員 maintain 加上 download path 有變更, 所以如果使用網站上的 mokomakefile (from freesmartphone) 會出現一些目錄找不到導致的 bitbake python 錯誤. 但是不用緊張, 還是有 community 的 team 負責維護相似的 mokomakefile. 目前主要有法國 Bearstech 的 SHR (http://shr.bearstech.com/ or http://shr-project.org/trac) 跟德國 Micky 帶領的 freesmartphone.org http://www.freesmartphone.org/index.php/Main_Page . 不過據最近 (2009.8) mailing list 討論, Freesmartphone (FSO) team 未來可能會 based on SHR 的 distribution 開發上層 dbus based application framework, 不會自己再發行 FSO distribution.

使用 mokomakefile (或是 SHR 的 Makefile) 很簡單, 但是時間可能很長 (一般來說, C2D 機器第一次 build 可能會到一整天), 大概步驟如下:

* 在 ~ 下建立一個屬於該 distro 的目錄
* 用 wget 把 http://shr.bearstech.com/ Makefile 檔案抓下來, 放到目錄下
* 根據自己 OS, 參考 http://wiki.openmoko.org/wiki/MokoMakefile 的說明, 安裝 host 端 (PC) 所需要的基本編譯套件. 每個 distribution 不太一樣, 例如 SHR 還需要額外的 curl. 基本上編譯時請先看 download site 對應的 readme, 以及編譯時的訊息, 缺什麼補什麼.
* 然後 make 或是 make "套件名稱" 像是 make shr-testing 之類的
* 然後第一次大概需要等一天, 依所使用的機器不同而不同. C2D E6420 大須需要 18-24 小時. 同時 download 套件可能需要數 G 的容量.

編譯完後, 可以在 deploy 目錄找到, 如圖.

如果你有多台電腦, OM 的 developer 會使用 icecc 來做編譯的工作, 靠著 5-7 台左右的 quad-core 電腦網路分散編譯, 把完整編譯時間縮短到一小時內. 這算一個很不錯的使用 linux 編東西 hint 跟 technique.

在 2008 資策會創新應用服務研究所的開放原始碼行動平台研討會上, 我有整理一份 Openmoko 相關環境的介紹 http://t0ny.net/openmoko/doc/Openmoko_enviorment_n.pdf 可以當參考.

社群開發與嵌入式產品開發流程的衝突與妥協

Neng-Yu 'Tony' Tu

前幾個禮拜, 參加了資策會 OSS (經濟部工業局自由軟體產業應用推動計畫) http://www.oss.org.tw/ 主辦的 FreedomHEC2009 (http://www.oss.org.tw/dokuwiki/doku.php?id=freedomhec2009) . 今年在 Android 與 Moblin 的市場光環加持下, 加上工作人員也很努力的拉國外 key developer 來演講, 現場人數大概比去年多了一倍 (完全感覺不出來產業不景氣...哈哈).

Greg Kroah-Hartman 跟其他主要幾位主講人, 其實講授的內容都很實在, 對 kernel developer 來說, 有很多有用的 tips, 例如這篇 kernel report:
http://www.oss.org.tw/dokuwiki/lib/exe/fetch.php?media=kreport.pdf

提到以最近的 release 30 來說, 每天 kernel 平均增加 6500 行 131 個 changes, 這個數字看起來對一班人來說只是數字而已, 但是對很多公司的開發人員來說, 一直 trace 最新的 kernel 其實是有負擔的. 就台灣開發硬體產品的 cycle 來說, 大約開發一個全新的產品平均需要 6-8 個月, 以新 linux kernel release 週期為 15 週來看, 這一段時間 kernel 起碼已經跳了 1 到 2 個版本.

換句話說, 即使產品一開始如果就使用最新 vanilla kernel, 到出貨時, 先為了符合 GPL 而開放原始碼, 然後更有心一點再作相關 driver/patch upstream 的工作, 但為了適應新的 kernel 變更, developer 也還是需要額外的工作時間去適應新版本. 如果有公司想要像 beagle board (http://elinux.org/BeagleBoard) 一樣, 能夠讓產品直接 make omap3_beagle_defconfig 就可以透過 toolchain 編出 kernel 其實是需要時間了解 upstream 的模式. 主要包含:

* porting 前先註冊硬體資訊 (mach id..etc)
* 加入討論區, 適應 Linux community 的 coding/討論習慣
* 你要送 code 到哪邊 upstream (這顆 AP (Samsung/TI/Freescale) 的 maintainer 是誰, review 流程大概是怎麼樣)

這些都要實際 "加入" community (社群), 才能了解更多的細節. 這邊又卡到兩點 1. 開發人員本身的意願及英文能力 2. 製作產品的 RD 資源投入的時間是否應該在產品出貨後結束.

我在網路上找到一篇還不錯介紹 arm linux porting white paper 的放在這裡, 有興趣的可以參考一下. http://www.t0ny.net/foss/doc/porting/PortingLinuxKernel.pdf

因為 OEM/ODM 特性做習慣的關係, 不需要面對終端客戶, 在台灣典型的都把產品出貨當成是產品投入 RD 資源週期的結束. 但這一點, 對 community 來說, 產品到手 (hacking) 才是軟體應用可能性階段的開始, 是不太一樣的. Community base 公司的產品 (buglabs/beagleboard or LEGO like!!!), 等於把第一個產品當成是產品線的頭, 再慢慢展開看 community 需要哪些產品, 再逐漸充實產品的內容, 軟體可能增加支援的 platform (Android/Linux/Windows CE...) or 硬體 (更多的模組). 雖然這類的應用模式, 早就存在於常需要客製化的工業電腦產業中, 但是包括 Openmoko 在內, 蠻多的 (or 一部分) 趨勢都是朝著將原先客製化的模式, 帶到標準消費性產品中. 當然, 以目前這幾年的景氣 (2009-), 跟這些公司目前的狀況來看, 整個 biz model 都還在試水溫的階段, 但是最起碼提供一個產品開發的有趣方向.

一般只是拿 linux 當成是免費的 OS + 一堆好用的 utility 的一般硬體廠商而言, 是完全 or 至少一部分誤解了開放硬體的精神. 大部分廠商都停留在擔心自己的產品有違反 了 GPL 規定. 而不是利用 community 來開拓可能的市場, 及需要開放硬體專案的合作機會.

另一個矛盾就是, linux kernel "community" 只會一直 maintain 最新 2-3 個 kernel 版本, 與個例子來說, kernel.org 是不會一直幫 2.6.18 上 patch, 而是只會 maintain 目前 (2009.06) 最新的 2.6.28-30, 然後以極快的速度 (跟 MS 系統比較) 繼續往新的 release 前進. 這也是與業界的一般方式, fork 一份 2.6.24/26 的 kernel 下來, 然後自己 maintain 自己的 tree 的一般開發 (非 community) 方式有很大不同. 一般完全 fork 然後 maintain 自己藏起來的 tree 方式最大的問題就是公司最後只有少數 RD 能 maintain/patch 整個 tree, 所以公司的產品能力跟擴充方向, 也會直接或間接會受到這些 keyman 的限制. Maintain 一個 distribution 其實就是一件 "事", 如果又有其他的工作 overlap, 自己 maintain distribution 只好挖東牆補西牆, result 跟 quality 都不會太好.

當然在兩天的研討會過程中, 也反映出許多業界使用 Linux 開發, 跟融入 Linux 社群中的矛盾點, 主要的就是 release 原始碼 (源代碼) 的問題. 又想要 community 幫忙解決, 或是快速接受自己的硬體, 另一方面又不想或非常被動的 release source code. 當然 release source 有許多的問題, OM 都遇過. 包括產品中有相關 chipset 廠商的 NDA 問題. 不過這並不是無解, 或者說, 在產品開發選料前就要跟廠商談好, 不是產品要出了才進行 community friendly 工作.

在 OM 專案中, 最好的例子就是 wi-fi driver source code, 因為 FOSS community 不喜歡 binary 的 driver, Atheros 當時又是以非常 community friendly 的方式 release wi-fi 的驅動程式原始碼 (align with mainline source), 所以就溝通協調專案內容後 (我們使用的 AR6k fw 版本是 2.x), 就請 Atheros 新 release 一份對應的 GPL driver 給 OM. 當然除了 GPL 版本外, Atheros 還有另一份只能 release binary 版的 driver, 這也是 chipset vendor 經營開放軟體 community 常見的手法.

總而言之, 如果希望 Open Source Community 支援你想要接近 community 的產品, 我個人的建議是:

* 提交硬體 community 開發時, 底線是開放 kernel 部分的 source code, 最簡單的 release 方式打成 tar ball, 或文明一點放在公開 git/svn 上.
* 想辦法幫 community 或是對你的硬體有興趣的人, 解決他們的問題 (提供 documentation/跟 vendor 談 release 文件)
* 了解跟 community 成員的溝通方式
* 讓 key community member 盡早拿到硬體 (每間公司的策酪及考量不一樣, 但這的確是目前國際大廠 (you name it!!!) 為了接近 FOSS community 都在做的事), 但是不能期望這些 community key member 能提供有用的 feedback.

當然, 以上純就有興趣建立品牌或是接觸社群開發的專案. 若只是 OEM/ODM, 只要 spec 跟 term 清楚, 問題很單純, 大部分的公司, 都不缺乏這類的經驗.

很高興能在這類大拜拜場合 :) 遇到像是 matt_hsu 及 jserv, 以及目前在 0xlab 的 前 OM 優秀 developer (FOSS or not FOSS...haha). Real FOSS will be a life long way ;)

Open Platform Player

Neng-Yu 'Tony' Tu

最近所謂的開放平台解決方案真是越來越多了, base on linux 的, 數一數已經有下面幾家 player:

* Intel: Moblin
* Nokia: QT, oFono, maemo
* Google: Android
* Palm Pre (http://opensource.palm.com/)

很多人可能不知道, Palm 的核心也是 linux, Palm 也有把 kernel 相關的 patch release 出來. 當然還有 LiMo 跟其他的 foundation, 但是 LiMo 是採會員制的 (Samsung's 採用 LiMo 後做出的 OMNIA), 會員才能取得完整的 source tree).

就連學習曲線很高的 OpenEmbedded 都有蠻多 company 開始 adopt (包括 MontaVista 開始用 bitbake), 雖然 OE 有時不見得是開發嵌入產品最適合的工具.

下面這幾間都是這幾年(最近)比較受到注意的公司, 也有用到 package system (like OE).

* Beagleboard http://beagleboard.org/
* Gumstix
* Bug Labs http://www.buglabs.net/

這幾間公司都有一些蠻有趣玩 embedded 的 idea 跟 community 互動的方式. 大家對 open source 及 community development 有興趣可以參考.

另外, 最近有一家做 open hardware 的樂器公司還蠻 inspire 我的, 他不是做一般的 embedded, 他是做樂器類的應用 http://www.zoybar.net/ . 我一直覺得做音樂的很多工具/模擬器/社群經營都比一般的 embedded 進步 :-P 軟體類如 propellerhead 的 reason 跟 ableton live, 硬體類也有一堆, 例如 http://www.generalguitargadgets.com/ , 可能是音樂跟流行本身就是需要交流產生新的火花吧, 跟單向的生產 -> 銷售是不太一樣的行為.

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.