4.1. NORフラッシュメモリのパーティション構成
node-eye に対応したNORフラッシュメモリのパーティション構成は、Armadillo-IoT ゲートウェイ G2の出荷時の構成と異なります。また、Armadillo-IoT ゲートウェイ G2の型番によっても、パーティション構成が異なります。
Armadillo-IoT ゲートウェイ G2 の node-eye非対応構成(型番が AG42*-ではじまる場合)、
node-eye対応構成(型番が AG42*-ではじまる場合)、
Armadillo-IoT ゲートウェイ G2 の node-eye非対応構成(型番が AG43*-ではじまる場合)、
node-eye対応構成(型番が AG43*-ではじまる場合)、
それぞれを以下に示します。
表4.1 Armadillo-IoT ゲートウェイ スタンダードモデル G2 出荷時 (node-eye非対応、Armadilloの型番が AG42*-ではじまる場合)
物理アドレス | パーティション名 | サイズ | ソフトウェア |
---|
0xA0000000
|
0xA001FFFF
| bootloader | 128kByte | ブートローダーイメージ |
0xA0020000
|
0xA041FFFF
| kernel | 4MByte | Linuxカーネルイメージ |
0xA0420000
|
0xA1EFFFFF
| userland | 26.875Mbyte | ユーザーランドイメージ |
0xA1F00000
|
0xA1FFFFFF
| config | 1MByte | アプリケーションの設定情報など |
表4.2 node-eye対応(Armadilloの型番が AG42*-ではじまる場合)
物理アドレス | パーティション名 | サイズ | ソフトウェア |
---|
0xA0000000
|
0xA001FFFF
| bootloader | 128kByte | node-eye 対応ブートローダーイメージ |
0xA0020000
|
0xA081FFFF
| recovery | 8MByte | リカバリイメージ |
0xA0820000
|
0xA0C1FFFF
| kernel | 4MByte | Linuxカーネルイメージ(ユーザー作成) |
0xA0C20000
|
0xA1EDFFFF
| userland | 18.75Mbyte | ユーザーランドイメージ(ユーザー作成) |
0xA1EE0000
|
0xA1EFFFFF
| license | 128kByte | ハードウェア固有情報 |
0xA1F00000
|
0xA1FFFFFF
| config | 1MByte | アプリケーションの設定情報など |
表4.3 Armadillo-IoT ゲートウェイ スタンダードモデル G2 出荷時 (node-eye非対応、Armadilloの型番が AG43*-ではじまる場合)
物理アドレス | パーティション名 | サイズ | ソフトウェア |
---|
0xA0000000
|
0xA003FFFF
| bootloader | 256kByte | ブートローダーイメージ |
0xA0040000
|
0xA043FFFF
| kernel | 4MByte | Linuxカーネルイメージ |
0xA0440000
|
0xA1EFFFFF
| userland | 26.75Mbyte | ユーザーランドイメージ |
0xA1F00000
|
0xA1FFFFFF
| config | 1MByte | アプリケーションの設定情報など |
表4.4 node-eye対応(Armadilloの型番が AG43*-ではじまる場合)
物理アドレス | パーティション名 | サイズ | ソフトウェア |
---|
0xA0000000
|
0xA003FFFF
| bootloader | 256kByte | node-eye 対応ブートローダーイメージ |
0xA0040000
|
0xA083FFFF
| recovery | 8MByte | リカバリイメージ |
0xA0840000
|
0xA0C3FFFF
| kernel | 4MByte | Linuxカーネルイメージ(ユーザー作成) |
0xA0C40000
|
0xA1EDFFFF
| userland | 18.625Mbyte | ユーザーランドイメージ(ユーザー作成) |
0xA1EE0000
|
0xA1EFFFFF
| license | 128kByte | ハードウェア固有情報 |
0xA1F00000
|
0xA1FFFFFF
| config | 1MByte | アプリケーションの設定情報など |
node-eye 対応のパーティション構成には、新たに recovery と license を追加しています。
recovery パーティションについて詳しくは本文 「リカバリイメージ」を参照してください。license パーティションには、Distribution ID に対応したSACMとの通信に使う認証キー(LS-SA key)が格納されます。
kernel、userland パーティションは、通常の Armadillo 利用時と同様、ユーザーが自由に変更可能です。
4.2. デフォルトでインストールされるアプリケーションの違い
node-eye 対応 パーティション構成では、userland パーティションのサイズは 18.75MB です。
容量制限のためnode-eye対応のユーザーランドには、Oracle Java SE Embedded 8、LUAインタプリタ はデフォルトで組み込まれないようになっています。
また、node-eye のデバイス運用管理サービスにいくつか必要なアプリケーションが追加されています。
recovery 領域には、Linux カーネルとユーザーランド(atmark-dist)を一つにまとめたイメージを書き込みます。このイメージをリカバリイメージといいます。
リカバリイメージの目的は、次のような人為的ミスによって正常に起動できなくなった Armadillo をnode-eyeコントロールパネルからの復旧ができるようにすることです。
リカバリイメージを使って Armadillo の起動する条件を次に示します。
4.3.3.1. インストールされているアプリケーション
リカバリイメージは、Linux カーネルとユーザーランドを復旧するためにSACMに接続することのできる最小の構成となっています。そのため、インストールされているアプリケーションは標準イメージと比べ少なくなっています。
ユーザーランドにインストールされるアプリケーションの差分は以下のコマンドで確認することができます。
4.3.3.2. リカバリイメージ起動中のWebUI上の表示
リカバリイメージで Armadillo が起動すると、SACM コントロールパネル、node-eye コントロールパネル上では [切断中] と表示されます。ただし、Armadillo がリカバリイメージで起動し、SACM と通信できる場合は、SACM コントロールパネル, node-eye コントロールパネルから Ping と Traceroute を実行することができます。
Armadillo の接続/切断状態の監視は、Armadilloにインストールされたarmsdが SACM にHeartbeat パケットを送信することによって実現しています。
![[ティップ]](images/tip.png) | |
---|
リカバリーイメージは、Heartbeatを送信しません。従って、接続状態は[切断中]となりますが、Armadillo はSACMに接続可能なため復旧作業(ファームウェアアップデート等の)は実行できます。
|
node-eyeのリモートコンフィグ機能は、SACMのモジュールを使用しています。そのため、この章では "node-eye におけるモジュールについて" 説明します。
4.5.1. node-eye におけるモジュールについて
モジュールは Armadillo のユーザーランドに配置された start/stop/reconfig/command といった オペレーション を受け付けるスクリプトとして実装されています。
モジュールにはバイナリモジュール(BIN module)、コマンドラインインターフェースモジュール(CLI module)の2種類あります。 Armadillo-IoT ゲートウェイ スタンダードモデル G2 では、16個のモジュールが用意されています。
表4.5 モジュールのタイプとその用途
No. | Module type | 用途 |
---|
0 - 3 | CLI module | アットマークテクノが提供する機能に使用 |
4 - 7 | CLI module | お客様が自由に使用 |
8 - 11 | BIN module | お客様が自由に使用 |
12 - 15 | CLI module | お客様が自由に使用 |
CLI
moduleは、SACM上で直接、モジュールのコンフィグを編集、参照することができます。
バイナリモジュールは、SACM上でコンフィグの内容を直接参照することはできず、ダウンロードとアップロードのみが可能です。
また、コマンドラインインターフェースモジュールのコンフィグで扱えるのは、US-ASCII
のテキストのみに限られます。
日本語などのマルチバイト文字が含まれる場合、バイナリモジュールで取り扱う必要があります。
モジュールのコンフィグについては
SACM コンフィグの概念
を参照してください。
モジュール0 ~
3はアットマークテクノが提供する機能(ネットワーク設定、ファームウェア管理など)に使用しています。
モジュール0 ~
3に変更を加えることは可能ですが、変更を加えた場合にはアットマークテクノから提供する機能(サービス等)を受けられなくなる場合があります。
現在、アットマークテクノから提供しているモジュールを表に示します。
表4.6 アットマークテクノが提供しているモジュール一覧
No. | Module type | Module name | 用途 |
---|
0 | CLI module | ネットワークモジュール | ネットワークインターフェースの設定に使用 |
1 | CLI module | ファームウェアモジュール | ファームウェアアップデートに使用 |
モジュールに関する詳細な情報は、別途
SACM モジュールの概念
を参照してください。
node-eye 対応イメージでは armsd
がネットワーク設定を管理します。
Armadillo起動直後は、armsd
が/etc/network/interfaces
を生成してネットワーク接続を行います。
SACM
からコンフィグを取得できたら、一度、すべてのネットワークインターフェースをダウンした後、
取得したコンフィグを元に/etc/network/interfaces
を生成し、再度ネットワークインターフェースをアップします。
コンフィグの管理はネットワークモジュールが行っています。
armsd
のネットワーク設定の詳細は、本文「「リモートコンフィグを行う」」を参照してください。
4.6.1. ネットワークインターフェース設定シーケンス
Armadilloが起動してから、SACM上に設定したネットワークインターフェース設定が反映されるまでのシーケンスを説明します。
下記のシーケンスは
SACM 動作シーケンス Pull動作
に沿った動作です。
Armadilloが起動し、armsd
が起動すると/etc/armsd/scripts/line
が実行されます。
/etc/armsd/scripts/line
は
/etc/config/line.conf
を元に
/etc/network/interfaces
(以下、interfaces
と表記します)を生成します。
生成されるinterfaces
はUSBメモリーを使うことによって変更することができます。
次に、生成されたinterfaces
を使用してLS(Location
Server)に接続します。
接続が確立すると、LSからRS(Resource
Server)へ接続するために必要な情報(Location-Config)を取得します。※これをLS
Pullといいます ArmadilloはLS
Pullに成功すると、Location-Configをキャッシュします。(/etc/config/armsd.cache
として保存されます) Location-Configがある場合、LS
Pullをスキップします。
次に、再び/etc/armsd/scripts/lineでinterfaces
を生成し、これを用いてRSへ接続します。
ここで生成されるinterfaces
は、Armadilloが起動した時と同じものが生成されます。
接続が確立すると、RSからSACMのモジュールNに設定されたコンフィグ(Service-Config)を取得します。
※これをRS Pullといいます
取得したService-Configを用いて、post-pull script
がinterfaces
を生成します。
こうして、Service-Configの設定でネットワークインターフェースがアップします。
最後に接続性の確認を行います。
SACMとの接続が確認されると、ネットワーク設定のシーケンスは終了となります。
本章では node-eyeコントロールパネル の
ファームウェアアップデート機能 の仕様について説明します。
ファームウェアアップデート機能の使い方は 3章node-eye を体験する
を参照してください。
ファームウェアアップデートにより書き込むことのできる領域は以下の3つです。
kernel 領域
userland 領域
recovery 領域
※ただし、同時に書き込めるのは kernel と userland
の組み合わせのみ
また、ファームウェアアップデートの際には、Armadillo
がHTTPプロトコルでアクセス可能なwebサーバーに
イメージファイルを置き、そのURLを指定する必要があります。