ユビキタスは10月28日、同社が10月19日に発表したLinux/Android高速起動ソリューション「QuickBoot」の最新版「Ubiquitous QuickBoot R1.2」に関する組み込み事業者向けセミナーを開催し、同バージョンの主機能や実装手法などの紹介を行った。
QuickBoot(QB)の概要と、それが必要となる背景はすでに何度もお伝えしてきているので、詳細はそちらを参照していただくとして、簡単に概略を説明すると以下のようになる。従来の組込機器の高速起動手法としては、チューニングやスタンバイ/ハイバネーションなどで対応を図っていたが、LinuxやAndroid、WindowsなどのリッチOSが用いられるようになり、メモリサイズも大きくなってくると、こうした処理そのものにも時間がかかるようになり、現実的な解にならなくなってきていた。そこで、QBでは、ハイバネーション技術を独自技術により発展させることで、イメージのすべてをコピーした後に動作させるのではなく、必要とされるデータのみを優先的にRAMにコピーすることで、高速起動を実現したほか、アプリの複雑化、メモリサイズの増大などが生じても、起動時間を一定に維持することが可能としたということだ。
|
|
|
従来方式とQuickBootの比較(左)とQuickBootの構成ブロック図(右) |
|
QBを用いて組込機器を開発する場合、開発者にはSDK(ソフトウェア開発キット)が提供される。ソフトウェア要件としてサポートするOSは、Linux(Kernel 2.6.26以上)もしくはAndroid 2.2/2.3としており、それ以外については個別対応としているが、ブートローダに関してはU-boot、Redboot、Hermitなど、種類は問わず対応可能である。
一方のハードウェア要件はCPUがARMシングルコア(ARM9/11、Cortex-A8/9)で、将来的にはマルチコアへの対応も予定している。また、RAMがSDRAMもしくはSRAMで数百KB(物理メモリが連続であること)必要とするほか、スナップショットイメージを保存するストレージとして用いる不揮発性メモリはNOR/NAND問わずに、SDカードやHDDなど、その種類は問わず、Linuxで試用しているメモリサイズ分あれば使用可能だ。
|
|
|
SDKのハードウェアおよびソフトウェアの要件 |
|
今回のR1.2に対応したSDKは、想定ユーザのスキルレベルがLinuxのボードポーティング(BSP開発)が行える(同社ではブートローダ、デバイス周りにも明るいとなお良いとしている)こととしている。構成は、QBの動作・仕組み・実装のポイントの習得を目的としたQB BaseパッケージがFreescale Semiconductor i.MX51 EVK(Kernel 2.6.35、BSP R10ベース)にQuickBootを実装したQuickBoot Board Support Packageとなっているほか、実ターゲット用のコアモジュールとしてターゲットボード向けQBコアモジュールが提供される。また、オプションとして「QuickBoot Android Pack」も用意されている。
|
|
QuickBoot SDK R1.2の構成 |
ではR1.2そのものの主機能は、というと、起動モードは「スタティック」「ダイナミック」「Android(オプション)」の3種類を用意。1つのストレージをLinux(rootfs格納用)とQB(スナップショットイメージ格納用)でパーティションを区切ることで共有可能な機能はこれまで個別対応であったものを標準対応とした。また、スナップショットイメージの圧縮と、差分アップデート機能が追加された形となっている。
|
|
|
|
3種類の起動モードの概要 |
||
スナップショットイメージの圧縮イメージの圧縮アルゴリズムは、Non-GPLのものであれば、ユーザが自由に選択することが可能となっている(ハードウェア圧縮も対応可能だという)。R1.1の時は高速性を意識して、プレーンイメージで、RAMとフラッシュROMにイメージを用意してそれをコピーする形にしていた。R1.2ではPacked Imageに変更し、使っていないイメージを管理部で処理することで容量を圧縮することに成功している。圧縮そのものはリファレンスとしてはLZFもしくはLZMAを提供しており、例えばi.MX51 EVKを用いた場合では、LZFでは圧縮した方が従来に比べて50%程度の高速起動が可能になったという。ただし、CPUパワーが足りない場合は逆に時間がかかる場合があるという。また、LZMAでは40%程度に圧縮できたものの、起動時間は5.0秒と従来よりも長くなっており、どういったデータをどの程度の圧縮率を用いてどれくらいのCPUパワーで処理させるかのバランスが重要だという。
|
|
|
圧縮方式をR1.2で採用した。これにより、スナップショットイメージサイズを減らすことができるようになったが、条件によっては起動時間が遅くなる場合がある |
|
一方の差分アップデート機能は、スナップショットイメージの差分のみでのアップデートが可能で、アップデート用イメージサイズを最小化することができるというもの。圧縮のフォーマットなどの次第では全コピーの方が早い場合もあるという。同社でどういったときに効果があるか調べたところ、例えば110MBの80MBが差分だというとき、圧縮した差分イメージを作製すると5-6MB程度に抑えることに成功したという。
|
|
差分アップデート機能の概要。イメージの差分のみアップデートすることが可能となった |
このほか、R1.2ではQuickBoot Storage BIOSモジュールが追加された。従来からも同機能は存在したが、今回はこれをGPLから分離独立させる形で提供しており、これにより、プロプライエタリなコードを使うことや、GPLがついたストレージドライバを活用することも可能となった。
|
|
uickBoot Storage BIOSモジュールをGPLから分離して提供したことで、より柔軟にQuickBootを活用することが可能となった |
では、実際にどうやって実装するのか。QBの動作詳細フローを見ると、上段がスナップショットに保存するプロセス。下段がQBで処理するというプロセスで行われる。実際に開発者が作業として大変になるのは、各ドライバのハイバネーション対応と不揮発メモリのリード/ライトの部分。今回のR1.2だと、ブートローダを用いてもらえるようになったので従来に比べて楽にはなったはずだが、QBをきっちり活用しようと思うと、下位レイヤから積み重ねて動くことを確認していかないといけないとのことで、そこをしっかり動作確認してもらった後に、スナップショットイメージが保存できるようドライバ部分を作ってもらうことが重要だという。
|
|
|
QuickBootの動作詳細フロー(左)とそれに伴う開発者側の作業(右) |
|
ちなみに、同社のエンジニアがよく聞かれるのが、実装にかかる時間だというが、これはどういったデバイスをサポートしているかによるわけだが、慣れていない人でもだいたい1人月くらいで行けるという。スキルレベルによるので、慣れてくれば2週間くらいでできるが、デバイスをどこまでサポートするか、ハイバネーション対応がどのレベルまで必要になってくるかなどで微妙に実装期間が変わってくるという。
|
|
|
|
スナップショットスクリプトの例 |
デバイス初期化処理/タイミングはドライバレベルとアプリケーションレベルの2パターンある(ドライバレベルの中でさらにSuspend/Resume対応が必要な場合などもある) |
その他、QuickBoot実装に必要な各種の情報 |
なお、同社でもカスタマから要望があればNRE(受託開発)を受けているが、人的リソースの面で対応ができないことがあるために、認定エンジニアリングパートナーシステムとして、コアや日本システムウェアなどのパートナー企業が受託開発を請け負っているという。また、SDKを貸りて、実際に試してみたいと思っているSIerなど、興味がある企業があれば、相談などに乗っていきたいと思っているので、是非、連絡をもらえればということを強調していた。
