本記事は、Cerevoスタッフが業務や趣味について思うままに書き綴るアドベントカレンダー企画「Cerevo アドベントTechBlog 2017」の第24日目です。
Cerevo アドベントTechBlog 2017
http://tech-blog.cerevo.com/archives/category/adventcalendar/2017/
まつけんです。
今年は技術的な解説という感じではないですが、SoC選定の方針をつくるための基礎情報みたいなところを書いてみたいと思います。今までで一番、CTOっぽいかもしれない。
Cerevoはハードウェアを作るメーカーです。ネットと家電で生活をもっと便利に・豊かに、をスローガンで掲げていることもあり、製品の大半はEthernet、Wi-Fi,、Bluetooth(BLE含む)など、なんらかの通信手段を搭載しています。
ある製品を作ろう、となったときに、最初によく行われる会話は「ブロック図を作ろう」です。これは電子工作をするのでも必要になるように製品を作り始めるきっかけに全体像を把握するためとして大変有用です。
このブロック図を書くときに中心に来るのが、SoC、MCU、マイコン等、ソフトウェア、ファームウェアを書き込み、動作の中心となる演算処理装置です。規模によって、OSレスだったり、RTOSなりが動いたり、LinuxやAndroidが動いたりと様々ですが、各種ペリフェラルを制御する中心となる役割を担います。製品によっては複数搭載されることもあります。
今回はこの中で「SoC」と呼ぶことが多い、比較的高性能でリッチ側の部品を選定する際にこんなことを考えていて、Cerevoとしてはこう捉えて選んでいるよ、という部分を書いてみたいと思います。何を持って、どこを境界線として、SoCと呼ぶのかは、正直、私もよく分かりません。一旦、ここではLinuxもしくはAndroidが動作するレベルのものを便宜的にそう呼びます。
さて、SoCを選定するにあたって考えることはどんなことでしょうか。コアのアーキテクチャ、動作周波数、内蔵しているペリフェラル、搭載しているバス等スペックがやはり中心でしょうか。
実際には、これに加え、Cerevoのような小規模、少量の生産をするメーカーにはこれに並んで考慮すべき、そもそも買えるのか(MOQ/SPQの条件や商流の問題)、買ったあとにどんなサポートを受けられるのか、開発時、製造時のライセンス費はどうなるのか、というのも大きくのしかかります。
これは本当に半導体メーカーによってマチマチです。TIのように比較的にデータシートなどはある程度オープンでオンラインでも買えそうなメーカーも居れば、代理店経由でなければ、そもそも何の情報もないようなメーカーがあります。また、サポートも代理店経由でやるところもあれば、こういう条件でなければサポート自体提供できないということがあったり、さらにはフォーラムなどで質問してねというスタンスもあり、本当に様々です。
そんな中で面白そうなメーカーを挙げながら今の状況を解説してみよう、というのが今回の主旨です。
まず、今の世の中、何はともあれ、現時点では、こういった家電向け製品に採用されやすいアーキテクチャはARMです。もちろん、ルーター等ネットワーク機器ではMIPSやPowerも活躍していますし、MicrochipではMIPSコアのものもあります、将来的にはRISC-Vも立ち上がってくるのかも知れません。x86も徐々にこういった分野に食指を伸ばしているようにも見えるのでどこかでシェアを奪うのかもしれませんし、車載ではルネサスがSH系を採用しているものも多いのでしょう(この辺はまったく知らないですが)が、まあ今の時点で、家電製品でLinux動かしますとなるとARMでしょ、となると思っています。
となった上で、ARMコアやIPを載せたSoCメーカーは本当に数多くあります、TI、NXP、STMicro、Freescale(NXPになったけど)などから、ラズパイが最も有名になってしまったBroadcom、スマホ向けにはQualcomm、Mediatekと二大巨頭がおり、それ以外にもSamsung、Hisiliconなどもいます。
テレビやSTB分野でもSigmaDesignやMStar(Mediatek傘下ですが)、Realtek、MARVEL(この辺はほかもいろいろやってますが)など、比較的汎用で様々なことができるメーカーから各分野に特化されたメーカーまでいろいろとあります。
それに合わせ、比較的に新興勢力で、Android搭載のSTBやタブレットなどで、一際存在感を放っているのがAmlogic、Allwinner、Rockchipです。これ以外にもソシオネクス、Actions、NuFront、Novatekなど挙げきれないメーカーは数多くありますが、今回はこの3メーカーに焦点を合わせてみたいと思います。
Amlogic、Allwinner、Rockchipともそれぞれスタンスは結構違います。Amlogicは「デザインハウス方式」と勝手に私が呼んでいますが、SoCとデータシート、リファレンスを供給する会社をある程度定めており、誰もが設計できるというよりも、そのデザインハウスがそういった業務の大半を担うことで、最終製品を作るメーカーに大きな負担を与えず、かつコントロールすることを基本としているように捉えています。
そのため、通常AmlogicのSoCを採用する場合はそういったデザインハウスを見つけ、基板とファームウェアの開発依頼をすることで製品を作り上げていきます。デザインハウスによっては、筐体設計なども含め受けるところもあるようですし、筐体を供給して最終組立も含め対応をして、台辺りいくらという形での取引をするようなケースもあるようです。
とはいえ、Le Potateなど徐々にSBC分野に出てくるなど、徐々にそこは厳格ではなくなりつつあるのかなとは思っています。Mediatekなども基本的にこの方式に近い方針をもたれているように感じます。
Allwinnerも似たようなデザインハウスを多く抱えています。ただ、Amlogicほど厳格ではなく、デザインハウス経由でSoC単体を入手することも容易です。ですので、基板設計をデザインハウスではなく自社でやりたいとなれば、サポートをどこまで得られるかは別として可能なようです。
実際、弊社でもAllwinnerのSoCを採用した基板試作をいくつか行っています。同時に、AllwinnerのSoCを採用したモジュールを搭載した自社製品もすでに発売しています。
RockchipはAllwinnerと似たようなスタンスのようです。デザインハウス中心ではあるが、SoC単体での入手もお願いすると可能です。
サポート面では、Amlogicはデザインハウス方式を厳格に運用していることもあり、ほとんどはデザインハウスを経由してのサポートになり、設計資料に関してもそれほど多くのものが提供されるわけではないようです。あくまで、デザインハウスと二人三脚でやってね、という風に理解をしています。
Allwinner、Rockchipに関してもそこは同様のようです。基本的に、デザインハウスがサポートをするよ、というスタンスで、リファレンスデザイン等の情報はもらえはしますが、直接サポートやほかの方法を提供しているわけでもないようです。
そんな3社ですが、Linuxサポートに関して、なかなか面白い動きがあります。
元々、この3社は基本的にAndroidが動作するような製品向け(RockchipはChromebookにも積極だったのでLinuxに積極的とも言えなくはないですが)であり、Linuxサポートに関してはかなり消極的であったように思います。なので、Androidであれば、それなりに情報もあり、サポートも豊富ではありましたが、Linuxを動作させるのは多少の情報と自己責任、という風潮でした。
そういう流れを受けたのか、Allwinnerで顕著に現れたのが、Linuxをポーティングするコミュニティの存在です。「linux-sunxi」というコミュニティが立ち上がり、AllwinnerのSoCの情報集約、Linuxへのポーティング、mainlineへのコミットなどの活動が行われています。
linux-sunxi.org
http://linux-sunxi.org/
これまでAllwinnerが提供するSDKやBSPは、バージョン3系の古くて何が変わっているか分からない、ビルド通すのにも一苦労というものをなんとか運用するというのがある種の常識だったところに対して、このコミュニティではmainlineへのコミットとメンテナンスが行われ、最新に近いバージョンのカーネルを、且つ、Linuxのお作法を維持したままOSを運用できるところに近づきつつあります。
これはAmlogicも同様で、「linux-meson」というサイトがあるように、mainlineへのコミットがここ最近、極めて活発になってきています。
linux-meson
http://linux-meson.com/
Rockchipは有志が先頭に立ってというよりは、メーカー自身がメンテをオープンにするように変わってきました。以下のサイトを中心に、ChromeOSなどのソースも公開され、且つ、4.4系およびmainlineへのメンテ、開発も続いているように見えます。
Rockchip open source Document
http://opensource.rock-chips.com/wiki_Main_Page
CerevoではAndroidを採用した製品もありますが実際にAndroidを採用してみて思ったいろいろなブラックボックス感、知識の足り無さ、ベースの巨大さなども痛感しており、AndroidよりはLinuxを優先していくのが現状では良いだろうと思っています。これは内部のエンジニアのスキル指向に依存するので、一般論ではなくCerevoでは、というお話です。
それにあわせ、半導体メーカーの方と話していると、ここ数年はAndroidが隆盛を極め、タブレット、STBなどを中心にどんどんと広まっていたが、製品の潮流として、音声操作を中心としたスマートスピーカーが立ち上がり、今後、こういった巨大なAndroidでは要求コストに対して答えきれないカテゴリの製品が増えていくと考えるメーカーも徐々に出ているようです。
そのため、省メモリでも動作させやすい等の理由で、ここにきて、Androidだけでなく、Linuxへのサポートもしっかりやっていこうとなっているある種の揺り戻しが起こっているメーカーもあるように見受けられます。
そんな中、サポートの方法として、自身のメーカーのSoC対応のコードをmainlineへのコミットをすることでコードを共有、誰もがメンテできる等の状態にすることで、間接的にサポートの工数を減らすという目的を持ち、そういった部分へのリソースを投入しているメーカーも増えてきたように思います。
Linaroなどは昔からそういう活動をしている部分もありますし、SUSEの人が多くのSBCに対応すべくwikiも持ち、特にRealtekやActions向けのコミットなどをしているところも見受けられます。CELinuxの成果もあるでしょうし。
というわけで、我々のような小規模でメーカーやデザインハウスのサポートを受けるにはなかなか難しかった立場からすると、この状況は渡りに船です。メーカーから提供されたクローズドなSDKやBSPではなく、オープンなmainlineのカーネルをベースに環境を構築し、ファームウェアを書くことができるようになりつつあります。
もちろん、これをやってしまうと、デメリットもあります。最低でもソフトウェア部分は完全に自己責任です。NDAを結んだ上で公開されるようなプロプライエタリな機能を使うことはできない(かもしれない)、また、サポートのためなどで別途NDAを結んでなんらかの情報やライブラリを半導体メーカーから受けた場合、ライセンスやNDAに違反しないように慎重に振る舞う必要があります。
最終的に正しい情報を得るためには結局、メーカーやデザインハウスと話す必要が出てくることもあるでしょうし、そういったところとの関係性も整理しつつ、できる限り、最新版に近いカーネルで、自分たちが内部でコードを書いていけるようにという体制を構築していくことが、これからのCerevoの方針だと思っています。もちろん、コミュニティに対する貢献もそこには含まれます。
ハードウェア面もすこし触れましょう。ここ最近、Raspberry Piからの盛り上がりで、いろいろなSBCが出ています。特にAllwinnerのSoCが搭載された製品は、NanoPiシリーズやOLinuXinoなどは我々も親しく、それ以外にもかなりの数が出ています。XXXPiという名前のものなんてもう腐るほどにある印象です。
それに併せて「SOM」と呼ばれる、モジュールタイプで製品に組み込むことが前提の製品も「SOPINE」などいろいろのものがあります。こういった製品は、その部分の基板開発の期間を短縮でき、場合によっては自社で製造するよりもコスト安になるケースもあります。こういったものに、上記のmainlineのカーネルを組み合わせ、自社で製品を開発するというスタイルは、これからは広く行われるのかなという期待をしています。
モジュールを採用すると、そこの信頼性や接続部分をどう担保するか、不要輻射にどう対応していくかなどで、電気エンジニアの皆さんとしては大変な部分もあるので、これも一概に良いと言うべきではありませんが、我々としては良い選択肢の一つとして考えています。
最後に蛇足ですが、最近社内で珍しく私が自分でハンダごてを握って作業をしていたのは、AmlogicやRockchipやRealtekのSTBを買ってきては分解し、UARTを引き出して、上記のmainlineカーネルを動かしてみたりして評価していたためでした。
AmlogicのSoCが載ったSTBは安いモノは$40を切る価格でいくらでも売っていますので、実は小さく省電力なLinuxマシンとして動かすのに最適です、うまくUARTを引き出せば筐体までついてきます。linux-mesonなどのページやMLを見て、みなさんもLinuxを動かしてみるというチャレンジをこの年末年始にやっていただくと楽しいかも知れません。
実際、私は、AWSのGreengrass Coreを動かすためにカーネルを新しくして、STB上でCoreを動かしていたりします。こちらはこちらでまたいつかどこかでやり方などを紹介したいなぁと思いながら、長くなってきてしまいましたので、今回は締めたいと思います。
みなさん、良いクリスマスを!