| | ここではシェルスクリプトおよび Python を使った CUI アプリケーションの開発方法を紹介します。
開発手順としてはシェルスクリプトと Python で同じであるため、シェルスクリプトの場合の例で説明します。 10.1.1. CUI アプリケーション開発の流れArmadillo 向けに CUI アプリケーションを開発する場合の流れは以下のようになります。 ここでは、開発開始時の ATDE 上でのセットアップ手順について説明します。
ATDE をお使いでない場合は、先に 「ATDEのセットアップ」 を参照して ATDE のセットアップを完了してください。 ATDE のバージョン v20230123 以上には、 VSCode がインストール済みのため新規にインストールする必要はありませんが、
使用する前には最新版へのアップデートを行ってください。 VSCode を起動するには code コマンドを実行します。 | |
---|
VSCode を起動すると、日本語化エクステンションのインストールを提案してくることがあります。
その時に表示されるダイアログに従ってインストールを行うと VSCode を日本語化できます。 |
10.1.2.2. VSCode に開発用エクステンションをインストールするVSCode 上でアプリケーションを開発するためのエクステンションをインストールします。 エクステンションはマーケットプレイスからインストールすることができます。
VSCode を起動し、左サイドバーのエクステンションを選択して、検索フォームに「abos」と入力してください。 表示された「Armadillo Base OS Development Environment」の 「Install」ボタンを押すとインストールは完了します。 VSCode の左ペインの [A600] から [Shell New Project] を実行し、表示されるディレクトリ選択画面からプロジェクトを保存する
ディレクトリを選択してください。実行するためには右に表示されている三角形ボタンを押してください。
Python の場合は [Python New Project] を実行してください。
保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。
ここでは、ホームディレクトリ直下に my_project として保存しています。 初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。 作成したプロジェクトディレクトリへ移動して VSCode を起動してください。 VSCode の左ペインの [my_project] から [Setup environment] を実行します。 選択すると、 VSCode の下部に以下のようなターミナルが表示されます。 このターミナル上で以下のように入力してください。 |
パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
| |
1 でパスフレーズを設定した場合は、確認のため再度入力してください。
| |
ここで何か任意のキーを押すとターミナルが閉じます。
|
パスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパス
フレーズの入力を求められることがあります。 | |
---|
ssh の鍵は $HOME/.ssh/id_ed25519_vscode (と id_ed25519_vscode.pub ) に保存されていますので、
プロジェクトをバックアップする時は $HOME/.ssh も保存してください。 |
10.1.2.5. アプリケーション実行用コンテナイメージの作成Armadillo 上でアプリケーションを実行するためのコンテナイメージを作成します。
ここで作成したコンテナイメージは SWU イメージを使用して Armadillo へインストールするため、
事前に mkswu を参照して SWU の初期設定を行ってください。 コンテナイメージの作成および SWU イメージの作成も VSCode で行います。
VSCode の左ペインの [my_project] から [Generate development swu] を実行します。 コンテナイメージの作成にはしばらく時間がかかります。
VSCode のターミナルに以下のように表示されるとコンテナイメージの作成は完了です。 |
Dockerfile やパッケージリストを変更した場合のみにコンテナを再作成してください。
|
作成した SWU イメージは my_project/swu ディレクトリ下に dev.swu という
ファイル名で保存されています。 10.1.3. Armadillo 上でのセットアップここでは、実際に Armadillo 上でサンプルアプリケーションを起動する場合の手順を説明します。
プロジェクトディレクトリへ移動し VSCode を起動します。 プロジェクト内のディレクトリ構成を説明します。 -
app : アプリケーションのソースです。Armadillo では /var/app/rollback/volumes/shell_app または python_app にそのままコピーされます。
-
config : 開発モードのための設定ファイルです。「ssh_config の準備」 を参照してください。
-
container : スクリプトを実行するコンテナの設定ファイルです。 packages.txt に記載されているパッケージがインストールされます。 Dockerfile を直接編集することも可能です。
-
scripts : VSCode のコマンドに使われているスクリプト類です。編集した場合はサポート対象外となります。
-
swu : mkswu のためのテンプレートとコンテナの設定ファイルがあります。 shell_app または python_app のディレクトリの内容はそのまま SWU に組み込まれます。その中の etc/atmark/containers/shell_app.conf または python_app.conf に使われているボリュームやデバイス等が記載されていますので必要に応じて編集してください。
デフォルトのコンテナの設定では app の src/main.sh または Python の場合に src/main.py を実行しますので、リネームが必要な場合はコンテナの設定も修正してください。 このサンプルアプリケーションは、 SOC の温度を /vol_data/log/temp.txt に出力し、
ユーザー LED(緑) を点滅させます。 プロジェクトディレクトリに入っている config/ssh_config ファイルを編集して
IP アドレスを書き換えてください。 |
Armadillo の IP アドレスに置き換えてください。
|
| |
---|
Armadillo を初期化した場合や、プロジェクトを実行する Armadillo を変えた場合は,
プロジェクトの config/ssh_known_hosts に保存されている公開鍵で Armadillo を認識できなくなります。
その場合はファイルを削除するか、「Setup environment」タスクを再実行してください。 |
VSCode の左ペインの [my_project] から [App run on Armadillo] を実行すると、
アプリケーションが Armadillo へ転送されて起動します。 VSCode のターミナルに以下のメッセージが表示されることがあります。
これが表示された場合は yes と入力して下さい。 アプリケーションを終了するには VSCode の左ペインの [my_project] から [App stop on Armadillo] を実行してください。 ここでは完成したアプリケーションをリリース版としてビルドする場合の手順について説明します。 VSCode の左ペインの [my_project] から [Generate release swu] を実行すると、
リリース版のアプリケーションを含んだ SWU イメージが作成されます。
事前に 「SWUイメージの作成」 を参照して SWU の初期設定を行ってください。 作成した SWU イメージは my_project/swu ディレクトリ下に release.swu というファイル名で保存されています。 この SWU イメージを 「イメージのインストール」 を参照して Armadillo へインストールすると、
Armadillo 起動時にアプリケーションも自動起動します。 10.2.1. Podman - コンテナ仮想化ソフトウェア10.2.1.1. Podman - コンテナ仮想化ソフトウェアとはコンテナとはホスト OS 上に展開される仮想的なユーザ空間のことです。
コンテナを使用することで複数の Armadillo-640 でも同一の環境がすぐに再現できます。
ゲスト OS を必要としない仮想化であるため、アプリケーションの起動が素早いという特徴があります。 Podman とはこのようなコンテナを管理するためのソフトウェアであり、使用方法は
コンテナ管理ソフトウェアの 1 つである Docker と互換性があります。 この章では、コンテナ仮想化ソフトウェアの 1 つである Podman の基本的な使い方について説明します。
Armadillo-640 で実行させたいアプリケーションとその実行環境自体を 1 つの Podman イメージとして扱うことで、
複数の Armadillo-640 がある場合でも、全てのボード上で同一の環境を再現させることが可能となります。 この章全体を通して、イメージの公開・共有サービスである Docker Hub から取得した、Alpine Linux のイメージを
使って説明します。 10.2.2.1. イメージからコンテナを作成するイメージからコンテナを作成するためには、podman_start コマンドを実行します。
podman や docker にすでに詳しいかたは podman run コマンドでも実行できますが、ここでは 「コンテナの運用」 で紹介するコンテナの自動起動の準備も重ねて podman_start を使います。
イメージは Docker Hub から自動的に取得されます。
ここでは、簡単な例として "ls /" コマンドを実行するコンテナを作成します。 |
コンテナのコンフィグを作成します。このファイルでは、コンテナのイメージやコマンド、デバイスへのアクセス権限を設定します。詳しい設定の説明には 「コンテナの自動起動」 を参照ください。
| |
コンテナのイメージを取得します。イメージが Armadillo に置いてない場合は「Error: docker.io/alpine: image not known」の様なエラーで失敗します。
| |
コンテナを起動します。これは Armadillo 起動時に自動的に起動されるコンテナと同じものになります。自動起動が不要な場合には set_autostart no で無効化できます。
| |
podman logs コマンドで出力を確認します。
|
"ls /" を実行するだけの "my_container" という名前のコンテナが作成されました。
コンテナが作成されると同時に "ls /" が実行され、その結果がログに残ります。
ここで表示されているのは、コンテナ内部の "/" ディレクトリのフォルダの一覧です。 | |
---|
podman_start でコンテナが正しく起動できない場合は podman_start -v <my_container> で podman run のコマンドを確認し、 podman logs <my_container> で出力を確認してください。
|
コンテナを作成するためのイメージは、イメージ一覧を表示する podman images コマンドで確認できます。 podman images コマンドの詳細は --help オプションで確認できます。 作成済みコンテナ一覧を表示するためには podman ps コマンドを実行します。 一覧表示により、コンテナ名やコンテナ ID を確認することができます。-a オプションを付けない場合は、動作中のコンテナのみ表示されます。
podman ps コマンドの詳細は --help オプションで確認できます。 作成済みのコンテナを起動するためには podman start コマンドを実行します。 -a オプションを与えると、コンテナ内で実行されたアプリケーションの出力を確認できます。 ここで起動している my_container は、起動時に "ls /" を実行するようになっているので、その結果が出力されます。
podman start コマンドの詳細は --help オプションで確認できます。 動作中のコンテナを停止するためには podman stop コマンドを実行します。 podman stop コマンドの詳細は --help オプションで確認できます。 コンテナに対して変更が行われた状態で、そのままコンテナを停止してしまうと変更が失なわれてしまいます。 変更を保存するには二つの方法があります。
podman commit コマンドで保存する。
podman commitで保存する度に、変更が行なわれた差分が保存されます。
繰り返し差分を保存すると、イメージサイズが大きくなってしまいます。
ストレージ容量が不足する場合は、ベースとなるOSのイメージから作り直してください。
ボリュームを使用する。
podman_start の add_volumes コマンドでコンテナに Armadillo Base OS のディレクトリをコンテナで使うことができます。
保存するデータの性質によって、保存先を選択してください。 -
/var/app/volumes/myvolume : アップデートした場合はコピーされません。
ログやデータベースなど、アプリケーションが作成し続けるようなデータの保存に向いています。
-
myvolume か /var/app/rollback/volumes/myvolume : アップデートの際にコピーしてアップデートを行うので、アップデート中でも安全に使いつづけます。
アプリケーションと一緒にアップデートするようなデータの保存に向いています。
| |
---|
コンテナを前のバージョンに戻した場合(ロールバック)、/var/app/rollback/volumes/ のデータの前のバージョンに戻ります。 その為、アプリケーションのバージョンに依存するようなデータは /var/app/rollback/volumes/ に入れることを推奨します。 mkswu の swdesc_files (--extra-os 無し)と podman_start` の add_volumes では、相対パスはそのディレクトリをベースにします。
/var/app/rollback/volumes/myvolume は myvolume で簡潔に指定できます。
|
| |
---|
Copy-on-Write (CoW) について。 この二つの volumes ディレクトリは btrfs と呼ばれるファイルシステムに保存されています。
btrfs ではデータは Copy on Write(CoW)を使ってデータ完全性を保証しますが、その保証にはコストがあります。 数百 MB のファイルに小さな変更を頻繁に行う場合 CoW を無効化することを推奨します。
CoW を無効化されたファイルにチェックサムが入らなくなりますので、極端な場合以外に残してください。
|
chattr +C でディレクトリに NoCow を設定します。これから作成されるファイルが NoCow で作成されます。すでに存在していたファイルに影響ないのでご注意ください。
| |
lsattr 確認します。リストの C の字があればファイルが「no cow」です。
|
|
10.2.2.7. コンテナの自動作成やアップデートpodman run, podman commitでコンテナを作成できますが、定期的にアップデートをする際には
コンテナの作成やアップデートを自動化できると便利です。 これを実現するために、Dockerfileとpodman buildを使います。この手順はArmadilloで実行可能です。
イメージを docker.io のイメージから作りなおします
イメージを前のバージョンからアップデートします
この場合、 podman_partial_image コマンドを使って、差分だけをインストールすることもできます。 [armadillo ~/podman-build-update]# podman_partial_image -b my_image:1 \
-o my_image_2_partial.tar my_image:2
[armadillo ~/podman-build-update]# ls -lh
-rw-r--r-- 1 root root 88 Dec 21 15:24 Dockerfile
-rw-r--r-- 1 root root 9.4M Dec 21 15:26 my_image_1.tar
-rw-r--r-- 1 root root 9.4M Dec 21 15:26 my_image_2.tar
-rw-r--r-- 1 root root 51K Dec 21 15:26 my_image_2_partial.tar
作成した .tar アーカイブは 「mkswu の desc ファイル」 の swdesc_embed_container と swdesc_usb_container で使えます。 作成済みコンテナを削除する場合は podman rm コマンドを実行します。 podman ps コマンドの出力結果より、コンテナが削除されていることが確認できます。
podman rm コマンドの詳細は --help オプションで確認できます。 podmanのイメージを削除するには podman rmi コマンドを実行します。
イメージを削除するためには、そのイメージから作成したコンテナを先に削除しておく必要があります。
podman rmi コマンドにはイメージ ID を指定する必要があるため、podman images コマンドで確認します。 podman images コマンドの出力結果より、コンテナが削除されていることが確認できます。
podman rmi コマンドの詳細は --help オプションで確認できます。 | |
---|
SWU で転送されたイメージは podman images で Read-Only として表示されますので、
podman rmi を実行するとエラーとなります。
その場合は abos-ctrl podman-rw rmi をご使用ください。 abos-ctrl podman-rw については 「イメージを eMMC に保存する方法」 を参照してください。
|
10.2.2.10. コンテナとコンテナに関連するデータを削除するabos-ctrl container-clear を使用すると、コンテナ、コンテナイメージ、コンテナに関するデータを削除することができます。
| |
---|
全てのコンテナとコンテナイメージ、コンテナに関するデータが削除されるため、充分に注意して使用してください。 |
abos-ctrl container-clear は以下の通り動作します。
実行中のコンテナに接続し、コンテナ内で指定したコマンドを実行するには podman exec コマンドを実行します。
podman exec コマンドでコンテナ内部のシェルを起動すると、コンテナ内部を操作できるようになります。ここでは、sleep infinity コマンドを
実行して待ち続けるだけのコンテナを作成し、そのコンテナに対して podman exec コマンドでシェルを起動する例を示します。 podman_start コマンドでコンテナを作成し、その後作成したコンテナ内で sh を実行しています。
sh を実行すると、コンテナ内のプロンプトが表示されコンテナ内部を操作できるようになります。
上記ではコンテナ内で、ps コマンドを実行しています。コンテナ作成時に実行した sleep と podman exec で実行した
sh がプロセスとして存在していることが確認できます。
コンテナ内のシェルから抜ける時は exit コマンドを実行します。 podman exec コマンドから抜けても、コンテナがまだ実行中です。コンテナを停止したい場合は podman stop sleep_container か podman kill sleep_container で停止して podman rm sleep_container でそのコンテナを削除してください。
podman exec コマンドの詳細は --help オプションで確認できます。 複数のコンテナを実行している環境で、それらのコンテナ間で通信を行う方法を示します。
これにより、例えば SQL サーバを実行しているコンテナに対し別のコンテナから接続するといった
使い方ができます。 コンテナには作成した時点でローカル IP アドレスが割り当てられるので、コンテナの名前かその IP アドレスで通信を行うことができます。 準備として、2 つのコンテナを作成します。 コンテナに割り当てられた IP アドレスを確認するには podman inspect コマンドを実行します。 これらの IP アドレスを使って、一方のコンテナからもう一方のコンテナへ対し ping コマンドで疎通確認を行うことができます。 このように、my_container_1(10.88.0.108) から my_container_2(10.88.0.109) への通信が確認できます。 10.2.2.13. 開発時に有用な—privilegedオプションコンテナに、全権限と全てのデバイスへのアクセスを許可するオプション --privileged があります。このオプションを利用すると、コンテナに与えるべき最小の権限を洗い出す必要が無いため、開発時に有用です。 実運用の際、このオプションを利用することはセキュリティー上問題がある為、開発時にのみご利用ください。コンテナに必要な最低限の権限を与えることをおすすめします。 10.2.3. アットマークテクノが提供するイメージを使うアットマークテクノは、動作確認環境として使用できる Debian ベースのイメージを提供しています。
ここでは、Docker ファイルからイメージをビルドする方法と、すでにビルド済みのイメージを使う方法の 2 つについて説明します。 10.2.3.1. Docker ファイルからイメージをビルドするArmadillo-640 コンテナ から
「Debian [VERSION] サンプル Dockerfile」 ファイル (at-debian-image-dockerfile-armv7-[VERSION].tar.gz) をダウンロードします。
その後 podman build コマンドを実行します。 podman images コマンドにより at-debian-image-armv7 がビルドされたことが確認できます。
docker.io/arm32v7/debian イメージはベースとなっている Debian イメージです。 10.2.3.2. ビルド済みのイメージを使用するArmadillo-640 コンテナ から
「Debian [VERSION] サンプルコンテナイメージ」 ファイル (at-debian-image-armv7-[VERSION].tar) をダウンロードします。
その後 podman load コマンドを実行します。 podman images コマンドにより at-debian-image-armv7 がビルドされたことが確認できます。 この章では、コンテナ内で動作するアプリケーションから GPIO や I2C などの入出力デバイスを扱う方法について示します。
基本的に、コンテナ内のアプリケーションからホスト OS 側のデバイスへアクセスすることはできません。
このため、コンテナ内のアプリケーションからデバイスを扱うためには、コンテナ作成時に扱いたいデバイスを指定する必要があります。
ここで示す方法は、扱いたいデバイスに関するデバイスツリーファイルが適切に設定されていることを前提としています。
デバイスツリーファイルを設定していない場合は、適切に設定してください。 コンテナ内で動作するアプリケーションから GPIO を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/gpiochipN を渡す必要があります。以下は、/dev/gpiochip0 を渡して alpine イメージからコンテナを作成する例です。
/dev/gpiochipN を渡すと、GPION+1 を操作することができます。 コンテナ内に入ってコマンドで GPIO を操作する例を以下に示します。この例では GPIO1_IO22(CON9 1ピン) を操作しています。 |
GPIO 番号 22 の値を取得します。
| |
取得した値を表示します。
| |
GPIO 番号 22 に 0(Low) を設定します。
|
他にも、gpiodetect コマンドで認識している gpiochip をリスト表示できます。
以下の例では、コンテナを作成する際に渡した /dev/gpiochip0 が認識されていることが確認できます。 gpioinfo コマンドでは、指定した gpiochip の詳細な情報を表示することができます。 CON9のピン番号とGPIOの対応を次に示します。 表10.1 CON9 ピンとGPIOの対応 ピン番号 | GPIO |
---|
1 | GPIO1_IO22 | 2 | GPIO1_IO23 | 3 | GPIO1_IO17 | 4 | GPIO1_IO31 | 5 | GPIO1_IO16 | 6 | GPIO1_IO30 | 13 | GPIO3_IO23 | 14 | GPIO3_IO24 | 15 | GPIO3_IO25 | 16 | GPIO3_IO26 | 17 | GPIO3_IO27 | 18 | GPIO3_IO28 | 25 | GPIO4_IO06 | 26 | GPIO4_IO07 | 27 | GPIO4_IO08 | 28 | GPIO4_IO09 |
C 言語プログラムから操作する場合は、GPIO 操作ライブラリである libgpiod を使用することができます。 コンテナ内で動作するアプリケーションから I2C を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/i2c-N を渡す必要があります。以下は、/dev/i2c-4 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、i2c-tools に含まれる i2cdetect コマンドを使ってスレーブアドレスを確認することができます。 コンテナ内で動作するアプリケーションから SPI を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/spidevN.N を渡す必要があります。以下は、/dev/spidev1.0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、spi-tools に含まれる spi-config コマンドを使って現在の設定を確認することができます。 コンテナ内で動作するアプリケーションから CAN 通信を行うためには、
Podman のイメージからコンテナを作成する際に、コンテナを実行するネットワークとして host を、
権限として NET_ADMIN を指定する必要があります。
以下は、ネットワークとして host を、権限として NET_ADMIN を指定して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、ip コマンドで CAN を有効にすることができます。
以下に、設定例を示します。 |
CAN の設定のために必要な iproute2 をインストールします。すでにインストール済みの場合は不要です。
| |
CAN の通信速度を 125000 kbps に設定します。
| |
can0 インターフェースを起動します。
| |
can0 インターフェースの現在の使用状況を表示します。
|
コンテナ内で動作するアプリケーションから PWM を扱うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側の /sys ディレクトリを渡す必要があります。デフォルト状態でもマウントされてますが、読み取り専用になって使えませんのでご注意ください。
以下は、 /sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリは
コンテナ内の同じ /sys にマウントされます。 コンテナ内に入り、/sys/class/pwm/pwmchipN ディレクトリ内の export ファイルに 0 を書き込むことで扱えるようになります。
以下に、/sys/class/pwm/pwmchip0 を扱う場合の動作設定例を示します。 |
pwmchip0 を export します。
| |
周期を 1 秒にします。単位はナノ秒です。
| |
PWM の ON 時間 を 0.5 秒にします。
| |
PWM 出力を有効にします。
|
10.2.4.6. シリアルインターフェースを扱うコンテナ内で動作するアプリケーションから RS-232C や RS-485 などのシリアル通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN を渡す必要があります。
以下は、/dev/ttymxc2 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、setserial コマンドを使って現在の設定を確認することができます。 コンテナ内で動作するアプリケーションから USB 接続のデバイスを扱うための方法について示します。 USB シリアルデバイスをコンテナ内から扱う場合には、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev/ttyUSBN を渡す必要があります。
以下は、 /dev/ttyUSB0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、setserial コマンドを使って現在の設定を確認することができます。 USB カメラをコンテナ内から扱う場合には、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev/videoN を渡す必要があります。
以下は、 /dev/video0 を渡して alpine イメージからコンテナを作成する例です。 GStreamer などのマルチメディアフレームワークと組み合わせることで、USB カメラからの映像のキャプチャが可能となります。 ここでは、USB メモリを扱う方法について 2 つの例を示します。 -
ホスト OS 側でマウントした USB メモリをコンテナから扱う
あらかじめホスト OS 側でマウントしてある USB メモリをコンテナから扱う場合には、Podman のイメージから
コンテナを作成する際にホスト OS 側で USB メモリをマウントしてるディレクトリを渡す必要があります。 上記の例では、USB メモリを /mnt にマウントしました。以下は、 /mnt を渡して alpine イメージからコンテナを作成する例です。 ホスト OS 側の /mnt ディレクトリをコンテナ内の /mnt にマウントしています。
これにより、コンテナ内からも /mnt ディレクトリを通して USB メモリを扱うことができます。 USB メモリをコンテナ内からマウントして扱う場合には、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev ディレクトリを渡すと同時に、適切な権限も渡す必要があります。
以下は、 /dev を渡して alpine イメージからコンテナを作成する例です。権限として SYS_ADMIN を渡しています。 コンテナ内に入り、mount コマンドで USB メモリを /mnt にマウントし、保存されているデータを確認することができます。 コンテナ内から RTC を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/rtcN を渡すと同時に、RTC への時刻の設定を行うための権限も渡す必要があります。
以下は、/dev/rtc0 を渡して alpine イメージからコンテナを作成する例です。権限として SYS_TIME も渡しています。 コンテナ内に入り、hwclock コマンドで RTC の時刻表示と設定ができます。 |
RTC に設定されている現在時刻を表示します。
| |
システム時刻を 2021 年 4 月 1 日 9 時 0 分 0 秒に設定します。
| |
システム時刻を RTC に反映させます。
| |
RTC に設定されている時刻が変更されていることを確認します。
|
Armadillo-640 に接続したスピーカーなどの音声出力デバイスへコンテナ内から音声を出力するためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/snd を渡す必要があります。
以下は、/dev/snd を渡して debian イメージからコンテナを作成する例です。 コンテナ内に入り、alsa-utils などのソフトウェアで音声出力を行えます。 |
alsa-utils をインストールします。
| |
alsa-utils を起動します。
| |
指定したファイル名の音声ファイルを再生します。
|
aplay の引数にある、M は音声を出力したい CARD 番号、N はデバイス番号を表しています。
CARD 番号とデバイス番号は、aplay コマンドに -l オプションを与えることで確認できます。 10.2.4.10. ユーザースイッチのイベントを取得するArmadillo-640 にはユーザースイッチが実装されています。これらのスイッチのプッシュ/リリースイベントを取得するためには、
Podman のイメージからコンテナを作成する際にホスト OS 側の /dev/input ディレクトリを渡す必要があります。
以下は、/dev/input を渡して alpine イメージからコンテナを作成する例です。ここで渡された /dev/input ディレクトリは
コンテナ内の /dev/input にマウントされます。 コンテナ内に入り、evtest コマンドでイベントを確認できます。 |
SW1のボタン プッシュ イベントを検出したときの表示
| |
SW1のボタン リリース イベントを検出したときの表示
|
Armadillo-640 には LED が実装されています。これらの LED を扱うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側の /sys ディレクトリを渡す必要があります。
以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリは
コンテナ内の /sys にマウントされます。 コンテナ内に入り、brightness ファイルに値を書き込むことで LED の点灯/消灯を行うことができます。
0 を書き込むと消灯、0 以外の値 (1〜255) を書き込むと点灯します。 LEDクラスディレクトリと LED の対応は、表7.5「LED クラスディレクトリと LED の対応」 を参照してください。 この章では、コンテナ内から近距離通信デバイスを扱う方法について示します。 10.2.5.1. Bluetooth デバイスを扱うコンテナ内から Bluetooth を扱うには、コンテナ作成時にホストネットワークを使用するために、
NET_ADMIN の権限を渡す必要があります。図10.77「Bluetooth デバイスを扱うためのコンテナ作成例」、alpineイメージから Bluetooth を扱うコンテナを作成する例を示します。 コンテナ内で必要なソフトウェアをインストールして、Bluetooth を起動します。 これにより、bluetoothctl で Bluetooth 機器のスキャンやペアリングなどが行えるようになります。
以下に、bluetoothctl コマンドで周辺機器をスキャンしてペアリングを行う例を示します。 |
コントローラを起動します。
| |
周辺機器をスキャンします。
| |
ペアリングしたい機器の MAC アドレスを指定してペアリングします。
| |
exit で bluetoothctl のプロンプトを終了します。
|
ここでは、Wi-SUN デバイスが UART で接続されている場合の例を示します。
この場合、コンテナ内で動作するアプリケーションから Wi-SUN デバイスで通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN のうち、
Wi-SUN と対応するものを渡す必要があります。
以下は、/dev/ttymxc1 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内から、/dev/ttymxc1 を使って Wi-SUN データの送受信ができるようになります。 10.2.5.3. EnOcean デバイスを扱うここでは、EnOcean デバイスが UART で接続されている場合の例を示します。
この場合、コンテナ内で動作するアプリケーションから EnOcean デバイスで通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN のうち、
EnOcean と対応するものを渡す必要があります。
以下は、/dev/ttymxc1 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内から、/dev/ttymxc1 を使って EnOcean データの送受信ができるようになります。 ここでは、Thread デバイスが UART で接続されている場合の例を示します。
この場合、コンテナ内で動作するアプリケーションから Thread デバイスで通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttyACMN や /dev/ttymxcN のうち、
Thread と対応するものを渡す必要があります。
以下は、/dev/ttyACM0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内から、/dev/ttyACM0 を使って Thread データの送受信ができるようになります。 この章では、コンテナ内のネットワークを扱う方法について示します。 10.2.6.1. コンテナの IP アドレスを確認する基本的にコンテナの IP アドレスは Podman イメージからコンテナを作成したときに自動的に割り振られます。
コンテナに割り振られている IP アドレスはホスト OS 側からは podman inspect コマンドを用いて、以下のように確認することができます。 コンテナ内の ip コマンドを用いて確認することもできます。 10.2.6.2. コンテナに固定 IP アドレスを設定する | |
---|
podman はデフォルトで 10.88.0.0/16 を使います。 他に使用しているIPアドレスと被った場合等はコンテナに別のIPアドレスを設定してください。 |
コンテナに固定 IP アドレスを設定するためには、最初にユーザ定義のネットワークを作成する必要があります。
以下に 192.0.2.0/24 にユーザ定義のネットワークを作成する例を示します。 コンテナを作成する際に、上記で作成したネットワークと設定したい IP アドレスを渡すことで、
コンテナの IP アドレスを固定することができます。
以下の例では、IPアドレスを 192.0.2.1 に固定します。 コンテナの IP アドレスが、192.0.2.1 に設定されていることが確認できます。 この章では、コンテナ内で様々なサーバを構築する方法について示します。
この章で取り上げているサーバは alpine の apk コマンドでインストールすることが可能です。 ここでは、HTTP サーバとして Apache と lighttpd の 2 種類を使用する場合について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に Apache をインストールします。
コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。 他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると、
動作確認用ページが表示されます。
デフォルトでは、/var/www/localhost/htdocs ディレクトリにファイルを置くことで Web ブラウザから閲覧できます。
Apache の詳細な設定は、/etc/apache2 ディレクトリにある設定ファイルを編集することで変更可能です。 alpine イメージからコンテナを作成し、そのコンテナ内に lighttpd をインストールします。
コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。 lighttpd はデフォルトでは動作確認用ページが用意されていないため、上記の手順では簡単なページを
/var/www/localhost/htdocs ディレクトリの下に配置しています。
他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると表示されます。
lighttpd の詳細な設定は、/etc/lighttpd ディレクトリにある設定ファイルを編集することで変更可能です。 ここでは、FTP サーバとして vsftp を使用する場合について説明します。
alpine イメージからコンテナを作成し、そのコンテナ内に vsftpd をインストールします。
コンテナ作成の際に、FTP 通信で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定と、
コンテナ内の環境変数として PASV_ADDRESS にホスト OS 側の IP アドレスの指定を行っています。 コンテナ内にユーザアカウントを作成し、このユーザで ftp ログインできるようにします。 作成したユーザで ftp ログインできるように、vsftpd の設定ファイルを編集します。 編集した設定ファイルを指定して vftpd を起動することにより、ftp 接続可能となります。
ftp ログイン時のアカウントは前述の手順で作成したものを使用します。 ここでは、Samba サーバの構築方法について説明します。
alpine イメージからコンテナを作成し、そのコンテナ内に samba をインストールします。
コンテナ作成の際に、samba で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定を行っています。 コンテナ内にユーザアカウントを作成し、このユーザで samba にログインできるようにします。 samba を起動すると、前述の手順で作成したユーザアカウントで他の PC などからログインすることができます。 共有するディレクトリの指定などの詳細設定は /etc/samba/smb.conf ファイルを編集することで変更可能です。 ここでは、RDMS として sqlite を使用する場合について説明します。
alpine イメージからコンテナを作成し、そのコンテナ内に sqlite をインストールします。 コンテナ内に入り、sqlite3 コマンドを実行すると sqlite のプロンプトが表示され
データベースの操作ができるようになります。 この章では、コンテナ内で動作するアプリケーションから Armadillo-640 に接続されたディスプレイに
出力を行う方法について示します。 10.2.8.1. X Window System を扱うコンテナ内から、X Window System を起動し画面表示を行う例を示します。
ここではアットマークテクノが提供するイメージからコンテナを作成します。
このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。 |
X Window System に必要な tty を設定します。どこからも使われていない tty とします。
| |
画面描画先となるフレームバッファを設定します。
| |
キーボードやマウスなどを使用可能にするためのデバイスを設定します。
| |
ホスト OS 側の /run/udev をコンテナ内からマウントするように設定します。
| |
X Window System の動作に必要な権限を設定します。
|
次に、以下のように X Window System を起動します。
オプションである vt に設定する値は、コンテナ作成時に渡した tty の数字にします。 Armadillo-640 に接続しているディスプレイ上に、デスクトップ画面が表示されます。 10.2.8.2. フレームバッファに直接描画するコンテナ内で動作するアプリケーションからフレームバッファに直接描画するためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/fbN を渡す必要があります。以下は、/dev/fb0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入って、ランダムデータをフレームバッファに描画する例を以下に示します。
これにより、接続しているディスプレイ上の表示が変化します。 タッチパネルが組み込まれているディスプレイを接続している環境で、
コンテナ内からタッチイベントを取得するためには、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev/input を渡す必要があります。 X Window System などの GUI 環境と組み合わせて使うことで、タッチパネルを利用した GUI アプリケーションの操作が可能となります。 この章では、コンテナ内からパワーマネジメント機能を使う方法について示します。 パワーマネジメント機能を使ってサスペンド状態にするには、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /sys ディレクトリを渡す必要があります。
以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリは
コンテナ内の /sys にマウントされます。 コンテナ内から、/sys/power/state に次の文字列を書き込むことにより、サスペンド状態にすることができます。 表10.2 対応するパワーマネジメント状態 パワーマネジメント状態 | 文字列 | 説明 |
---|
Suspend-to-RAM
| mem
| 最も消費電力を抑えることができる | Power-On Suspend
| standby
| Suspend-to-RAM よりも短時間で復帰することができ、Suspend-to-Idle よりも消費電力を抑えることができる | Suspend-to-Idle
| freeze
| 最も短時間で復帰することができる |
| |
---|
サスペンド状態を128秒以上継続する場合は、Suspend-to-RAM か +Power-On Suspend+を利用してください。 +Suspend-to-Idle+を利用している状態で128秒経過すると再起動してしまいます。 |
サスペンド状態から起床要因として、利用可能なデバイスを以下に示します。 -
UART1 (CON9)
-
起床要因
-
データ受信
-
有効化
[container ~]# echo enabled > /sys/bus/platform/drivers/imx-uart/2020000.serial/tty/ttymxc0/power/wakeup
-
USB OTG1 (下段)
-
起床要因
-
USBデバイスの挿抜
-
有効化
[container ~]# echo enabled > /sys/bus/platform/devices/2184000.usb/power/wakeup
[container ~]# echo enabled > /sys/bus/platform/drivers/ci_hdrc/ci_hdrc.0/power/wakeup
[container ~]# echo enabled > /sys/bus/platform/drivers/ci_hdrc/ci_hdrc.0/usb1/power/wakeup
-
USB OTG2 (上段)
-
起床要因
-
USBデバイスの挿抜
-
有効化
[container ~]# echo enabled > /sys/bus/platform/devices/2184200.usb/power/wakeup
[container ~]# echo enabled > /sys/bus/platform/drivers/ci_hdrc/ci_hdrc.1/power/wakeup
[container ~]# echo enabled > /sys/bus/platform/drivers/ci_hdrc/ci_hdrc.1/usb2/power/wakeup
-
RTC(i.MX6ULL)
-
起床要因
-
アラーム割り込み
-
有効化
[container ~]# echo enabled > /sys/bus/platform/devices/20cc000.snvs\:snvs-rtc-lp/power/wakeup -
実行例
10.2.10. コンテナからのpoweroffかrebootArmadillo Base OSはbusybox initでshutdownとrebootを対応します。 busybox initでPID 1にsignalを送ることでshutdownやrebootとなります。
コンテナからsignalを送るように、pid namespaceを共有する必要がありますが、共有されたらkillで実行できます。 この章では、コンテナ内で動作しているアプリケーションに何らかの異常が発生し停止してしまった際に、
ソフトウェアウォッチドックタイマーを使って、システムを再起動する方法について示します。 10.2.11.1. ソフトウェアウォッチドッグタイマーを扱うコンテナ内で動作するアプリケーションからソフトウェアウォッチドックタイマーを扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/watchdogN を渡す必要があります。以下は、/dev/watchdog0 を渡して alpine イメージからコンテナを作成する例です。 ソフトウェアウォッチドックタイマーは、プログラム内からデバイスファイル /dev/watchdog0 を open した時点で起動します。
コンテナ内に入ってソフトウェアウォッチドックタイマーを echo コマンドで起動する例を以下に示します。 ソフトウェアウォッチドックタイマーを起動した後、/dev/watchdog0 に任意の文字を書き込むことで
ソフトウェアウォッチドッグタイマーをリセットすることができます。
10 秒間任意の文字の書き込みがない場合は、システムが再起動します。 ソフトウェアウォッチドックタイマーを停止したい場合は、/dev/watchdog0 に V を書き込みます。 Armadillo Base OSでは、/etc/atmark/containers/*.confファイルに指定されているコンテナがブート時に自動的に起動します。
nginx.confの記載例を以下に示します。 .conf ファイルは以下のパラメータを設定できます。
コンテナイメージの選択: set_image [イメージ名]
イメージの名前を設定できます。 例: set_image docker.io/debian:latest , set_image localhost/myimage イメージをrootfsとして扱う場合に --rootfs オプションで指定できます。 例: set_image --rootfs /var/app/volumes/debian
ポート転送: add_ports [ホストポート]:[コンテナポート]
設定したポートで外部からコンテナへのアクセスが可能となります。 デフォルトはTCPで、UDPも /udp を付けて使えます。スペースで分けて複数のポートを設定することができます。 以下の例では、ポート80、443(web)、UDPの69(tftp)にアクセスすることができ、コンテナのポート22(ssh)にはポート2222からアクセスすることができます。 例: add_ports 80:80 443:443 2222:22 69:69/udp | |
---|
pod を使う場合、このオプションはpodの設定にしないと有効になりませんのでご注意ください。 |
デバイスファイル作成: add_devices [ホストパス]:[コンテナパス]
コンテナでデバイスを作成して、使用可能となります。 コンテナパスを設定しない場合はホストと同じパスを使います。 複数のデバイスを作成したい場合はスペースで分けて設定してください。 例: add_devices /dev/ttymxc2 /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_78DA8CAF-video-index0:/dev/video3 ホストパスに「:」を含む場合は add_device "[ホストパス]" "[コンテナパス]" で追加できます。 例: add_device "/dev/v4l/by-path/platform-xhci-hcd.1.auto-usb-0:1.1:1.0-video-index1" "/dev/video3" コンテナパスに「:」を含むようなパスは設定できません。
ボリュームマウント: add_volumes [ホストパス]:[コンテナパス]:[オプション]
指定するパスをコンテナ内でマウントして、データの保存や共有することができます。 ホストパスは以下のどちらかを指定してください。
/var/app/rollback/volumes/<folder> か <folder> :
アップデートの際に新しくコピー(snapshot)した場合、コピー先のみ変更しますので、
アップデート中でもこのデータを使うことができます。
途中で電源が落ちた場合でも、このデータに影響はありません。 SWUpdateでアップデートするデータに向いています。
/var/app/volumes/<folder> : appパーティションに書きます。
アップデートの際にコピーされませんので、アップデート中の新たな変更は
更新されたコンテナ内のアプリケーションで見れます。 ログやデータベースに向いています。 -
/tmp/<folder> : 複数のコンテナでメモリファイルシステムを共有したい場合に使ってください。
-
/opt/firmware : 学習能力に必要なファムウェアライブラリーのパス。
コンテナパスを設定しない場合はホストパスと同じパスを使います。 オプションは podman run の --volume のオプションになりますので、 ro (read-only), nodev , nosuid , noexec , shared , slave 等を設定できます。 例:add_volumes /var/app/volumes/database:/database : ロールバックされないデータを/databaseで保存します。 例: add_volumes assets:/assets:ro,nodev,nosuid /opt/firmware : アプリケーションのデータを/assetsで読み取り、/opt/firmwareのファームウェアを使えます。 「:」はホスト側のパスとコンテナのパスを別ける意味があるため、ファイル名やデバイス名に「:」を使うことはできません。 | |
---|
複数のコンテナでマウントコマンドを実行することがあれば、shared のフラグで起動後のマウントを共有することができます。
|
マウントを行うコンテナに shared の設定とマウント権限 (SYS_ADMIN ) を与えます。
| |
マウントを使うコンテナに slave だけを設定すれば一方にしか共有されません。
| |
USB デバイスをマウントします。
| |
マウントされたことを確認します。
|
|
ホットプラグデバイスの追加: add_hotplugs [デバイスタイプ]
コンテナ起動後に挿抜を行なっても認識される(ホットプラグ)デバイスを設定できます。 通常、コンテナ内からデバイスを扱うためには、あらかじめ Armadillo 本体に当該のデバイスを接続した状態で、コンテナを起動する必要がありますが、 add_hotplugs を使用することでホットプラグに対応できます。 例: add_hotplugs input add_hotplugs に指定できる主要な文字列とデバイスファイルの対応について、表10.3「add_hotplugsオプションに指定できる主要な文字列」に示します。
表10.3 add_hotplugsオプションに指定できる主要な文字列 文字列 | 引数の説明 | 対象のデバイスファイル |
---|
input | マウスやキーボードなどの入力デバイス | /dev/input/mouse0, /dev/input/event0 など | video4linux | USB カメラなどの video4linux デバイスファイル | /dev/video0 など | sd | USB メモリなどの SCSI ディスクデバイスファイル | /dev/sda1 など |
表10.3「add_hotplugsオプションに指定できる主要な文字列」に示した文字列の他にも、/proc/devicesの数字から始まる行に記載されている文字列を指定することができます。
図10.114「/proc/devicesの内容例」に示す状態の場合、デバイスタイプを示す文字列としては、各行の先頭の数字を除いた mem や tty などを指定できることがわかります。
デバイスタイプと実際のデバイスファイルの対応については、 カーネルドキュメント: devices.txt(Github) を参照してください。 複数のデバイスタイプを指定したい場合はスペースで分けて設定してください。 例: add_hotplugs input usb sd
pod の選択: set_pod [ポッド名]
「podの作成」で作成した pod の名前を入れてコンテナを pod 内で起動します。 例: set_pod mypod
ネットワークの選択: set_network [ネットワーク名]
この設定に「networkの作成」で作成したネットワーク以外に none と host の特殊な設定も選べます。 none の場合、コンテナに localhost しかないネームスペースに入ります。
host の場合はOSのネームスペースをそのまま使います。
例: set_network mynetwork
IP アドレスの設定: set_ip [アドレス]
コンテナの IP アドレスを設定することができます。 例: set_ip 10.88.0.100 | |
---|
コンテナ間の接続が目的であれば、podを使ってlocalhostかpodの名前でアクセスすることができます。 |
読み取り専用設定: set_readonly yes
コンテナ内からのファイルシステムへの書き込み許可を設定します。 デフォルトで書き込み可能となっています。 コンテナ内からのファイルシステムへの書き込みを禁止することで、
tmpfs として使うメモリの消費を明示的に抑えることができますが、
アプリケーションによっては読み込み専用のファイルシステムでは動作しない可能性もあります。
イメージの自動ダウンロード設定: set_pull [設定]
この設定を missing にすると、イメージが見つからない場合にイメージを自動的にダウンロードします。 always にすると、イメージがすでにダウンロード済みでも起動前に必ず更新の確認を取ります。
デフォルトでは never で、イメージが見つからない場合にエラーを表示します。 例:set_pull missing か set_pull always
コンテナのリスタート設定: set_restart [設定]
コンテナが停止した時にリスタートさせます。 podman kill か podman stop で停止する場合、この設定と関係なくリスタートしません。
デフォルトで on-failure になっています。 例: set_restart always か set_restart no
信号を受信するサービスの無効化: set_init no
コンテナのメインプロセスが PID 1 で起動していますが、その場合のデフォルトの信号の扱いが変わります: SIGTERM などのデフォルトハンドラが無効です。 そのため、init 以外のコマンドを set_command で設定する場合は podman-init のプロセスを PID 1 として立ち上げて、設定したコマンドをその子プロセスとして起動します。 例: set_init no
自動起動の無効化: set_autostart no
手動かまたは別の手段で操作するコンテナがある場合、Armadillo の起動時に自動起動しないようにします。 その場合、 podman_start <name> で起動させることができます。 | |
---|
コンフィグに記載していないイメージはアップデートの際に削除されますので、そういったイメージに対して設定してください。 |
実行コマンドの設定: set_command [コマンド]
コンテナを起動するときのコマンド。設定されなかった場合、コンテナイメージのデフォルトを使います。 例: set_command /bin/sh -c "echo bad example"
podman run に引数を渡す設定: add_args [引数]
ここまでで説明した設定項目以外の設定を行いたい場合は、この設定で podman run に直接引数を渡すことができます。 例:add_args --cap-add=SYS_TTY_CONFIG --env=XDG_RUNTIME_DIR=/run/xdg_home
podman_start で pod 機能を使うことができます。
pod を使うことで、複数のコンテナが同じネットワークネームスペースを共有することができます。
同じ pod の中のコンテナが IP の場合 localhost で、 unix socket の場合 abstract path で相互に接続することができます。
コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type pod を設定することで pod を作成します。 pod を使う時にコンテナの設定ファイルに set_pod [NAME] の設定を追加します。 ネットワークネームスペースは pod を作成するときに必要なため、 ports , network と ip の設定は pod
のコンフィグファイルに入れなければなりません。 必要であれば、他の podman pod create のオプションを add_args で設定することができます。 podman_start で podman の network も作成ことができます。
デフォルトの 10.88.0.0/16 が使えない場合、あるいはコンテナ同士で接続できないようにしたい場合は使ってください。 コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type network を設定することで network を作成します。 そのネットワークを使う時にコンテナの設定ファイルに set_network [NAME] の設定をいれます。 ネットワークのサブネットは set_subnet [SUBNET] で設定します。
この設定は set_type network の後しか使えませんので、set_type はファイルの最初のところに使ってください 他の podman network create のオプションが必要であれば、 add_args で設定することができます。 podman では REST API による管理アクセスも可能です。 自分のコンテナから他のコンテナの管理が必要な場合に、ホストの podman サービスを有効にして、
コンテナに /run/podman をボリュームマウントすれば podman --remote で管理できます。 podman_start をインストールすればそちらも --remote で使えます。
このオプションは Armadillo のホスト側の udev rules からコンテナを扱う時にも必要です。 コンテナのイメージを配布する方法は大きく分けて二つあります: -
インターネット上のリポジトリ(dockerhub等)で登録してそこから配布する
-
SWUpdateのアップデートイメージを配布する
| |
---|
Podmanのイメージをインストールする時に、一時データを大量に保存する必要があります。 swuイメージ内で組み込む時は3倍、pullやUSBドライブで分けてインストールすると転送するデータ量の2倍の空き容量がappパーティションに必要です。 アップデート時にアップデート前のコンテナが使われているのでご注意ください。 |
10.3.5.1. リモートリポジトリにコンテナを送信する方法
イメージをリモートリポジトリに送信する:
[armadillo ~]$ podman image push <localimage> docker://<registry>/<remoteimage>:<tag>
set_pull always を設定しないかぎり、SWUpdateでダウンロードの命令を送らないとアップデートを行いません。
(mkswuについては「Armadilloのソフトウェアをアップデートする」を参考にしてください) [ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/pull_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat pull_container_nginx.desc
swdesc_option version=1
swdesc_pull_container "docker.io/nginx:alpine"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ mkswu pull_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
pull_container_nginx.swu を作成しました。
10.3.5.2. イメージを eMMC に保存する方法Armadillo Base OS のデフォルトでは、Podman のデータは tmpfs に保存されます。 起動時にコンテナを起動するにはイメージを eMMC に書き込む必要があります。
開発が終わって運用の場合は 「イメージを SWUpdate で転送する方法」 でコンテナのイメージを転送します。この場合は読み取り専用の app パーティションのサブボリュームに展開します。 開発の時に以下の abos-ctrl podman-rw か abos-ctrl podman-storage --disk のコマンドを使って直接にイメージを編集することができます。 | |
---|
ここで紹介する内容はコンテナのイメージの管理の説明です。データベース等のコンテナから書き込みが必要な場合には 「コンテナの変更を保存する」 にあるボリュームの説明を参照してください。 |
abos-ctrl podman-rw を使えば、read-only になっているイメージを扱う事ができます。
abos-ctrl podman-storage はメモリとディスクの切り替えの他に、読み書きストレージから読み取り専用ストレージへのコピーもできます。
|
イメージを書き込み可能ストレージに取得します。
| |
abos-ctrl podman-storage をオプション無しで実行します。
| |
書き込み可能ストレージにイメージがある場合に対応を聞かれます。今回はコピー(copy)します。
| |
abos-ctrl podman-storage にオプションを指定しなかったので、ストレージが tmpfs のままになります。すでに --disk で切り替えた場合にディスクのままでも可能です。
| |
コピーの確認します。イメージが読み取り専用(R/O, Read only)になりました。
|
| |
---|
podman が壊れやすいので、デフォルトの「abos-ctrl podman-storage --tmpfs」で運用することを推奨しますが、tmpfs の容量が小さくてイメージの操作には向いてません。 開発時には「abos-ctrl podman-storage --disk」の状態で作業を行い、運用時には「abos-ctrl podman-storage --tmpfs」に戻してください。
戻る際に「copy」を選択肢する場合は一時的なストレージをそのまま使いつづけますので、すべての変更が残ります。 |
| |
---|
SWUpdate でアップデートをインストールする際には、/var/lib/containers/storage_readonly ディレクトリの不要になったイメージを自動的に削除します。 自動起動させる予定がなくても、「コンテナの自動起動」 を参考にして、 /etc/atmark/containers/*.conf を使ってください。 set_autostart no を設定することで自動実行されません。 |
10.3.5.3. イメージを SWUpdate で転送する方法
イメージをファイルに保存する:
[armadillo ~]$ podman image save -o <myimage>.tar <localimage>
ファイルをSWUpdateのイメージに入れる。
二つのやり方があります:
swuイメージ内に組み込む
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/embed_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat embed_container_nginx.desc
swdesc_option version=1
swdesc_embed_container "nginx_alpine.tar"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ podman pull --arch arm --variant v7 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
armv7l
[ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar
[ATDE ~/mkswu]$ mkswu embed_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
embed_container_nginx.swu を作成しました
USBドライブに保存する
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/usb_container_nginx.desc .
[ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start .
[ATDE ~/mkswu]$ cat usb_container_nginx.desc
swdesc_option version=1
swdesc_usb_container "nginx_alpine.tar"
swdesc_files --extra-os nginx_start
[ATDE ~/mkswu]$ podman pull --arch arm --variant v7 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
armv7l
[ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar
[ATDE ~/mkswu]$ mkswu -o usb_container_nginx.swu usb_container_nginx.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
以下のファイルをUSBメモリにコピーしてください:
'/home/atmark/mkswu/usb_container_nginx.swu'
'/home/atmark/mkswu/nginx_alpine.tar'
'/home/atmark/mkswu/.usb_container_nginx/nginx_alpine.tar.sig'
usb_container_nginx.swu を作成しました。
10.4. Armadilloのソフトウェアをビルドするここでは、Armadillo-640で使用するソフトウェアのビルド方法を説明します。 ここでは、Armadillo-640向けのブートローダーイメージをビルドする方法を説明します。
ソースコードの取得
Armadillo Base OS対応 Armadillo-640 ブートローダー から
「ブートローダー ソース」ファイル (uboot-[VERSION].tar.gz) を次のようにダウンロードします。 [ATDE ~]$ https://armadillo.atmark-techno.com/files/downloads/armadillo-640/source/u-boot-[VERSION].tar.gz
[ATDE ~]$ tar xf uboot-[VERSION].tar.gz
[ATDE ~]$ cd uboot-[VERSION]
デフォルトコンフィギュレーションの適用
図10.119「デフォルトコンフィギュレーションの適用」に示すコマンドを実行します。
ビルド
次のコマンドを実行します。 [ATDE ~/u-boot-[VERSION]]$ make CROSS_COMPILE=arm-linux-gnueabihf-
:
: (省略)
:
LD u-boot
OBJCOPY u-boot-nodtb.bin
CAT u-boot-dtb.bin
MKIMAGE u-boot-dtb.imx
OBJCOPY u-boot.srec
COPY u-boot.bin
SYM u-boot.sym
CFGCHK u-boot.cfg
インストール
ビルドしたブートローダーは、以下に示すどちらかの方法でインストールしてください。
swupdate でインストールする
mkswu の初期化を行った後に 提供されているスクリプトを使ってSWUイメージを作成してください。 [ATDE ~/u-boot-[VERSION]]$ echo 'swdesc_boot u-boot-dtb.imx' > boot.desc
[ATDE ~/u-boot-[VERSION]]$ mkswu boot.desc
boot.swu を作成しました。 作成された boot.swu のインストールについては 「イメージのインストール」 を参照ください。
「ブートディスクの作成」 でインストールする
手順を参考にして、ビルドされた u-boot-dtb.imx を使ってください。
ここでは、Armadillo-640向けのLinuxカーネルイメージをビルドする方法を説明します。 | |
---|
Armadillo-640では、
基本的にはLinuxカーネルイメージをビルドする必要はありません。
「Alpine Linux ルートファイルシステムをビルドする」の手順を実施することで、
標準のLinuxカーネルイメージがルートファイルシステムに組み込まれます。 標準のLinuxカーネルイメージは、アットマークテクノが提供する
linux-at というAlpine Linux用のパッケージに含まれています。 カスタマイズしたLinuxカーネルイメージを利用する場合は、
以下に示す手順を参照してください。 |
ソースコードの取得
Armadillo Base OS対応 Armadillo-640 Linuxカーネル から
「Linuxカーネル」ファイル (linux-at-a6-[VERSION].tar) をダウンロードして、次のコマンドを実行します。 [ATDE ~]$ tar xf linux-at-a6-[VERSION].tar
[ATDE ~]$ tar xf linux-at-a6-[VERSION]/linux-[VERSION].tar.gz
[ATDE ~]$ cd linux-[VERSION]
デフォルトコンフィギュレーションの適用
次のコマンドを実行します。 [ATDE ~/linux-[VERSION]]$ make ARCH=arm armadillo-640_defconfig
カーネルコンフィギュレーションの変更
次のコマンドを実行します。
カーネルコンフィギュレーションの変更を行わない場合はこの手順は不要です。 [ATDE ~]$ make ARCH=arm menuconfig コマンドを実行するとカーネルコンフィギュレーション設定画面が表示されます。
カーネルコンフィギュレーションを変更後、"Exit"を選択して
「Do you wish to save your new kernel configuration? (Press <ESC><ESC> to continue kernel configuration.)」で"Yes"とし、
カーネルコンフィギュレーションを確定します。 .config - Linux/arm 5.10.145 Kernel Configuration
─────────────────────────────────────────────
┌────────── Linux/arm 5.10.145 Kernel Configuration ──────────┐
│ Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty submenus │
│ ----). Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, <M>│
│ modularizes features. Press <Esc><Esc> to exit, <?> for Help, </> for Search. │
│ Legend: [*] built-in [ ] excluded <M> module < > module capable │
│ ┌───────────────────────────────────────┐ │
│ │ General setup ---> │ │
│ │ System Type ---> │ │
│ │ Bus support ---> │ │
│ │ Kernel Features ---> │ │
│ │ Boot options ---> │ │
│ │ CPU Power Management ---> │ │
│ │ Floating point emulation ---> │ │
│ │ Power management options ---> │ │
│ │ Firmware Drivers ---> │ │
│ │ [ ] ARM Accelerated Cryptographic Algorithms ---- │ │
│ │ General architecture-dependent options ---> │ │
│ │ [*] Enable loadable module support ---> │ │
│ │ [*] Enable the block layer ---> │ │
│ │ IO Schedulers ---> │ │
│ │ Executable file formats ---> │ │
│ │ Memory Management options ---> │ │
│ │ [*] Networking support ---> │ │
│ │ Device Drivers ---> │ │
│ │ File systems ---> │ │
│ │ Security options ---> │ │
│ │ -*- Cryptographic API ---> │ │
│ │ Library routines ---> │ │
│ │ Kernel hacking ---> │ │
│ │ │ │
│ └───────────────────────────────────────┘ │
├──────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└──────────────────────────────────────────┘ | |
---|
Linux Kernel Configuration メニューで"/"キーを押下すると、カーネルコンフィギュレーションの検索を行うことができます。
カーネルコンフィギュレーションのシンボル名(の一部)を入力して"Ok"を選択すると、
部分一致するシンボル名を持つカーネルコンフィギュレーションの情報が一覧されます。 |
ビルド
次のコマンドを実行します。 [ATDE ~/linux-[VERSION]]$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
[ATDE ~/linux-[VERSION]]$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x82000000 uImage
インストール
ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください。
swupdate でインストールする
mkswu の初期化を行った後に 提供されているスクリプトを使ってSWUイメージを作成してください。
作成された kernel.swu のインストールについては 「イメージのインストール」 を参照ください。
build_rootfs で新しいルートファイルシステムをビルドする場合は build_rootfs を展開した後に以下のコマンドでインストールしてください。
|
build_rootfs のディレクトリ名を設定します。これによって、長いディレクトリ名を何度も入力する必要が無くなります。
| |
アットマークテクノが提供するカーネルをインストールしない様に、 linux-at-a6@atmark と記載された行を削除します。
| |
別のカーネルをすでにインストールしている場合は、新しいモジュールをインストールする前に古いモジュールを削除する必要があります。
|
10.4.3. Alpine Linux ルートファイルシステムをビルドするここでは、alpine/build-rootfsを使って、
Alpine Linux ルートファイルシステムを構築する方法を説明します。 alpine/build-rootfs は、ATDE 上で Armadillo-640 用の Alpine Linux ルートファイルシステムを構築することができるツールです。
ルートファイルシステムのビルドに必要な Podman のインストール
次のコマンドを実行します。 [ATDE ~]$ sudo apt install podman btrfs-progs xxhash
alpine/build-rootfsの入手
Armadillo Base OS対応 Armadillo-640 開発用ツール から
「Alpine Linuxルートファイルシステムビルドツール」 ファイル (build-rootfs-[VERSION].tar.gz) を次のようにダウンロードします。 [ATDE ~/]$ wget https://armadillo.atmark-techno.com/files/downloads/armadillo-640/tool/build-rootfs-latest.tar.gz
[ATDE ~/]$ tar xf build-rootfs-latest.tar.gz
[ATDE ~/]$ cd build-rootfs-[VERSION]
Alpine Linux ルートファイルシステムの変更
a600ディレクトリ以下のファイルを変更することで、
ルートファイルシステムをカスタマイズすることができます。 | |
---|
commonとa600 ディレクトリ直下にあるfixupやpackagesなどの同名ファイルは、それぞれのファイルを連結して利用されます。パッケージの削除などを行う場合は、commonディレクトリ以下のファイルも確認してください。 commonとa600内のサブディレクトリにある同名ファイルは、a600のファイルが利用されます。 |
build-rootfsに含まれるファイルの説明は次の通りです。 表10.4 build-rootfsのファイル説明 ファイル | 説明 |
---|
a600/resources/* | 配置したファイルやディレクトリは、そのままルートファイルシステム直下にコピーされます。
ファイルを追加する場合は、このディレクトリに入れてください。 | a600/packages | このファイルに記載されているパッケージはルートファイルシステムにインストールされます。
パッケージを追加する場合はこのファイルに追加してください。 | a600/fixup | このファイルに記載されているコマンドはパッケージのインストールが完了した後に実行されます。 | a600/image_firstboot/* | 配置したファイルやディレクトリは、「ブートディスクの作成」や「初期化インストールディスクの作成」の手順
のようにブートディスクイメージを作成する際、そのままルートファイルシステム直下にコピーされます。 | a600/image_installer/* | 配置したファイルやディレクトリは、「初期化インストールディスクの作成」の手順
のようにインストールディスクイメージを作成する際、
そのままインストーラーにコピーされます。ルートファイルシステムに影響はありません。 | a600/image_common/* | 配置したファイルやディレクトリは、ブートディスクイメージおよびインストールディスクイメージを
作成する際、ルートファイルシステム、インストーラにそれぞれコピーされます。 |
| |
---|
利用可能なパッケージは以下のページで検索することができます。 Alpine Linuxルートファイルシステムを起動している
Armadilloでも検索することができます。 [armadillo ~]# apk update
[armadillo ~]# apk search ruby
ruby-test-unit-rr-1.0.5-r0
ruby-rmagick-5.1.0-r0
ruby-public_suffix-5.0.0-r0
:
: (省略)
:
ruby-mustache-1.1.1-r5
ruby-nokogiri-1.13.10-r0 |
ビルド
次のコマンドを実行します。 パッケージをインターネット上から取得するため回線速度に依存しますが、
ビルドには数分かかります。 [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh -b a600
use default(outdir=/home/atmark/git/build-rootfs)
use default(output=baseos-640-ATVERSION.tar.zst)
:
: (略)
:
> Creating rootfs archive
-rw-r--r-- 1 root root 231700480 Nov 26 07:18 rootfs.tar
ERROR: No such package: .make-alpine-make-rootfs
============================================
footprint[byte] tarball[byte] packages
229904000 74942331 alpine-base coreutils chrony ...(省略)
============================================
done. | |
---|
リリース時にバージョンに日付を含めたくないときは --release を引数に追加してください。 |
| |
---|
任意のパス、ファイル名で結果を出力することもできます。 [ATDE ~/build-rootfs-[VERSION]]$ ./build_rootfs.sh -b a600 ~/alpine.tar.zst
:
: (略)
:
[ATDE ~/build-rootfs-[VERSION]]$ ls ~/alpine.tar.zst
~/alpine.tar.zst |
インストール
ビルドしたルートファイルシステムは、以下に示すどちらかの方法でインストールしてください。
swupdate でインストールする
mkswu の初期化を行った後に 提供されているスクリプトを使ってSWUイメージを作成してください。 [ATDE ~/build-rootfs-[VERSION]]$ vi OS_update.desc
swdesc_tar --version base_os [VERSION] \
--preserve-attributes baseos-640-[VERSION].tar.zst
[ATDE ~/build-rootfs-[VERSION]]$ mkswu OS_update.desc
OS_update.swu を作成しました。 作成された OS_update.swu のインストールについては 「イメージのインストール」 を参照ください。
「ブートディスクの作成」 でインストールする
手順を実行すると、ビルドされた baseos-640-[VERSION].tar.zst が自動的に利用されます。
本章では、microSDカードから直接起動(以降「SDブート」と表記します)する手順を示します。
SDブートを活用すると、microSDカードを取り替えることでシステムイメージを変更することができます。
本章に示す手順を実行するためには、容量が8Gbyte以上のmicroSDカードを必要とします。 | |
---|
SDブートを行った場合、ブートローダーの設定は microSDカード に保存されます。 |
ブートディスクイメージのビルドします
「Alpine Linux ルートファイルシステムをビルドする」 で説明されているソースツリー alpine/build-rootfs にあるスクリプト build_image と 「ブートローダーをビルドする」 でビルドした u-boot-dtb.imx を利用します。 [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \
--boot ~/u-boot-[VERSION]/u-boot-dtb.imx
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-640*img
baseos-640-[VERSION].img -
ATDE に microSD カードを接続します。詳しくは「取り外し可能デバイスの使用」を参考にしてください。
microSD カードのデバイス名を確認します
[ATDE ~]$ ls /dev/sd?
/dev/sda /dev/sdb
[ATDE ~]$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.22 GiB, 7751073792 bytes, 15138816 sectors
Disk model: SD/MMC
: (省略)
microSD カードがマウントされている場合、アンマウントします。
ブートディスクイメージの書き込み
[ATDE ~]$ sudo dd if=~/build-rootfs-[VERSION]/baseos-640-[VERSION].img \
of=/dev/sdb bs=1M oflag=direct status=progress microSDカードの性能にもよりますが、書き込みには5分程度かかります。
| |
---|
microSDカードのパーティション構成は次のようになっています。 表10.5 microSDカードのパーティション構成 パーティション | オフセット | サイズ | 説明 |
---|
- | 0 | 10MiB | ブートローダー | 1 | 10MiB | 300MiB | A/B アップデートのA面パーティション | 2 | 310MiB | 300MiB | A/B アップデートのB面パーティション | 3 | 610MiB | 50MiB | ログ用パーティション | 4 | 660MiB | 200MiB | ファームウェア | 5 | 860MiB | 残り | アプリケーション用パーティション |
gdiskで確認すると次のようになります。 [ATDE ~]$ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk1: 15319040 sectors, 7.3 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 309AD967-470D-4FB2-835E-7963578102A4
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15319006
Partitions will be aligned on 2048-sector boundaries
Total free space is 20446 sectors (10.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 20480 634879 300.0 MiB 8300 rootfs_0
2 634880 1249279 300.0 MiB 8300 rootfs_1
3 1249280 1351679 50.0 MiB 8300 logs
4 1351680 1761279 200.0 MiB 8300 firm
5 1761280 60485632 28.0 GiB 8300 app |
「ブートディスクの作成」で作成したブートディスクから起動する方法を説明します。 -
Armadillo-640に電源を投入する前に、ブートディスクをCON1(microSD スロット)に挿入します。
また、JP1 と JP2 を共にジャンパでショートします。
電源を投入します。
U-Boot 2020.04-at15 (Jun 09 2023 - 18:46:32 +0900)
CPU: i.MX6ULL rev1.1 at 396 MHz
Model: Atmark Techno Armadillo-640
DRAM: 512 MiB
setup_rtc_disarm_alarm: Can't find bus
WDT: Started with servicing (10s timeout)
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In: mxc_serial
Out: mxc_serial
Err: mxc_serial
switch to partitions #0, OK
mmc1 is current device
flash target is MMC:1
Net: eth0: ethernet@2188000
Fastboot: Normal
Saving Environment to MMC... Writing to MMC(1)... OK
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
Cannot lookup file boot/boot.scr
6859976 bytes read in 1420 ms (4.6 MiB/s)
Booting from mmc ...
37363 bytes read in 93 ms (391.6 KiB/s)
Loading fdt boot/armadillo.dtb
Cannot lookup file boot/overlays.txt
## Booting kernel from Legacy Image at 80800000 ...
Image Name: Linux-5.10.180-2-at
Created: 2023-06-09 9:48:24 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6859912 Bytes = 6.5 MiB
Load Address: 82000000
Entry Point: 82000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 83500000
Booting using the fdt blob at 0x83500000
Loading Kernel Image
Loading Device Tree to 9ef1d000, end 9ef49fff ... OK
Starting kernel ...
...中略...
Welcome to Alpine Linux 3.17
Kernel 5.10.180-2-at on an armv7l (/dev/ttymxc0)
armadillo login:
10.6. Armadilloのソフトウェアの初期化microSD カードを使用し、Armadillo Base OS の初期化を行えます。 | |
---|
初期化を行っても、ファームウェアパーティション(mmcblk0p4)は変更されません。 |
インストールディスクは二つの種類があります: 10.6.1.1. 初期化インストールディスクの作成-
512 MB 以上の microSD カードを用意してください。
標準のインストールディスクイメージを使用する場合は、
Armadillo Base OS対応 Armadillo-640 インストールディスクイメージ から
「Armadillo Base OS」をダウンロードしてください。
「Armadilloのソフトウェアをビルドする」 でビルドしたイメージを使用してインストールディスクを作成したい場合は、
以下のコマンドを実行して、インストールディスクイメージを作成してください。 [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh \
--firmware ~/at-imxlibpackage/imx_lib.img
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-a640*img
baseos-640-[VERSION].img
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \
--boot ~/u-boot-[VERSION]/u-boot-dtb.imx \
--installer ./baseos-640-[VERSION].img コマンドの実行が完了すると、baseos-640-[VERSION]-installer.img というファイルが作成されていますので、
こちらを使用してください。 -
ATDE に microSD カードを接続します。詳しくは「取り外し可能デバイスの使用」を参考にしてください。
microSD カードのデバイス名を確認します
[ATDE ~]$ ls /dev/sd?
/dev/sda /dev/sdb
[ATDE ~]$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.22 GiB, 7751073792 bytes, 15138816 sectors
Disk model: SD/MMC
: (省略)
microSD カードがマウントされている場合、アンマウントします。
[ATDE ~]$ mount
: (省略)
/dev/sdb1 on /media/52E6-5897 type ext2 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks)
[ATDE ~]$ sudo umount /dev/sdb1
ダウンロードしたファイルを展開し、imgファイルをmicroSDカードに書き込んでください。
Linux PCの場合、以下のようにmicroSDカードに書き込むことができます。 [ATDE ~]$ unzip baseos-600-installer-[VERSION].zip
[ATDE ~]$ sudo dd if=baseos-600-installer-[VERSION].img \
of=/dev/sdb bs=1M oflag=direct status=progress また、Windowsの場合、エクスプローラー等でZipファイルからimgファイルを取り出し、「Win32 Disk Imager」などを使用してmicroSDカードに書き込むことができます。
10.6.1.2. 開発が完了した Armadillo をクローンするインストールディスクの作成-
microSD カードを用意してください。Armadillo-640 にインストールされてるソフトウェアをコピーしますので、場合によって 8GB 以上のカードが必要です。
-
初期化インストールディスクをベースとしますので、「初期化インストールディスクの作成」 でビルドしたSDカードを使用できますが、用意されていなければ次のステップで自動的にダウンロードされます。
abos-ctrl make-installer を実行してください
[armadillo ~]# abos-ctrl make-installer
It looks like your SD card does not contain an installer image
Download base SD card image from https://armadillo.atmark-techno.com (~200MB) ? [y/N]
WARNING: it will overwrite your sd card!!
y
Downloading installer image
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 167M 100 167M 0 0 104M 0 0:00:01 0:00:01 --:--:-- 104M
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 70 100 70 0 0 1441 0 --:--:-- --:--:-- --:--:-- 1458
Writing baseos-600-installer-3.17.3-at.7.img to SD card (442M)
439353344 bytes (439 MB, 419 MiB) copied, 134 s, 3.3 MB/s
421+0 records in
421+0 records out
441450496 bytes (441 MB, 421 MiB) copied, 134.685 s, 3.3 MB/s
Verifying written image is correct
436207616 bytes (436 MB, 416 MiB) copied, 46 s, 9.5 MB/s
421+0 records in
421+0 records out
441450496 bytes (441 MB, 421 MiB) copied, 46.8462 s, 9.4 MB/s
Checking and growing installer main partition
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Setting name!
partNum is 0
The operation has completed successfully.
e2fsck 1.46.4 (18-Aug-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs_0: 2822/102400 files (0.5% non-contiguous), 352391/409600 blocks
(1/1) Installing e2fsprogs-extra (1.46.4-r0)
Executing busybox-1.34.1-r5.trigger
OK: 202 MiB in 197 packages
resize2fs 1.46.4 (18-Aug-2021)
Resizing the filesystem on /dev/mmcblk1p1 to 15547884 (1k) blocks.
The filesystem on /dev/mmcblk1p1 is now 15547884 (1k) blocks long.
Currently booted on /dev/mmcblk0p1
Copying boot image
Copying rootfs
301989888 bytes (302 MB, 288 MiB) copied, 10 s, 30.1 MB/s
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 10.3915 s, 30.3 MB/s
Copying /opt/firmware filesystem
Copying appfs
At subvol app/snapshots/volumes
At subvol app/snapshots/boot_volumes
At subvol app/snapshots/boot_containers_storage
Cleaning up and syncing changes to disk...
Installer updated successfully!
-
JP1とJP2を共にジャンパーでショート(SDブートに設定)し、microSDカードをCON1に挿入します。
-
電源を投入すると、1分程度でeMMCのソフトウェアの初期化が完了します。
-
完了すると電源が切れます(全てのLEDが消灯、コンソールに
reboot: Power down が表示)。
-
電源を取り外し、続いてJP1とJPジャンパーとmicroSDカードを外してください。
-
10秒以上待ってから再び電源を入れると、初回起動時と同じ状態になります。
10.7. ArmadilloのソフトウェアをアップデートするArmadillo-640では、
開発・製造・運用それぞれに適した複数のソフトウェアアップデート方法を用意しています。
本章では、それぞれのソフトウェアアップデート方法について説明します。 ソフトウェアアップデートを実現するソフトウェアの概要や仕様、用語については
13章ソフトウェア仕様
を参照してください。 Armadillo Base OS ではソフトウェアアップデートのためにOS やコンテナ等を格納するためにSWUというイメージ形式を使います。 SWUイメージは swupdate (https://sbabic.github.io/swupdate/swupdate.html) によってArmadillo Base OS上で検証とインストールが実行されます。SWUイメージをArmadilloに転送するための方法は、用途や状況に合わせて様々な方法を用意しています。例えば、USBメモリから読み取る、ウェブサーバーからダウンロードする、hawkBitというWebアプリケーションを使うなどです。 SWUイメージの作成には、mkswu というツールを使います。 mkswu に含まれる mkswu を実行すると、アップデート対象やバージョン等の情報を記載した .desc ファイルに含まれる命令を順次実行してイメージを作り上げます。 詳しくは「mkswu の desc ファイル」を参考にしてください。
mkswu の取得
[ATDE ~]$ sudo apt update && sudo apt install mkswu インストール済みの場合は、以下のコマンドを実行し最新版への更新を行ってください。 [ATDE ~]$ sudo apt update && sudo apt upgrade | |
---|
git のバージョンからアップデートする場合、 mkswu --import で以前使っていたコンフィグをロードしてください。 [ATDE ~/swupdate-mkimage]$ mkswu --import
コンフィグファイルを更新しました:/home/atmark/swupdate-mkimage/mkswu.conf
/home/atmark/swupdate-mkimage/mkswu.conf のコンフィグファイルとその鍵を
/home/atmark/mkswu にコピーします。
mkdir: ディレクトリ '/home/atmark/mkswu' を作成しました
'/home/atmark/swupdate-mkimage/swupdate.key' -> '/home/atmark/mkswu/swupdate.key'
'/home/atmark/swupdate-mkimage/swupdate.pem' -> '/home/atmark/mkswu/swupdate.pem'
/home/atmark/swupdate-mkimage/mkswu.conf のコンフィグファイルを
/home/atmark/mkswu/mkswu.conf にコピーしました。
mkswu でイメージ作成を試してから前のディレクトリを消してください。 |
最初に行う設定
mkswu --init を実行して鍵や最初の書き込み用のイメージを生成します。
作成する鍵は、swuパッケージを署名するために使用します。
過去に本手順を行っている場合、再度初回アップデート作業を行う必要はありません。
再度アップデートを行う際には、Armadilloに配置した公開鍵に対応する秘密鍵でアップデートを行いますので、 「mkswu の desc ファイル」 を参考にしてください。 [ATDE ~]$ mkswu --init
mkdir: ディレクトリ '/home/atmark/mkswu' を作成しました
コンフィグファイルを更新しました:/home/atmark/mkswu/mkswu.conf
証明書のCommon nameを入力してください: [COMMON_NAME]
証明書の鍵のパスワードを入力ください(4-1024文字)
証明書の鍵のパスワード(確認):
Generating an EC private key
writing new private key to '/home/atmark/mkswu/swupdate.key'
-----
アップデートイメージを暗号化しますか? (N/y)
アットマークテクノが作成したイメージをインストール可能にしますか? (Y/n)
rootパスワード:
rootパスワード(確認):
atmarkユーザのパスワード(空の場合はアカウントをロックします):
atmarkユーザのパスワード(確認):
BaseOSイメージのarmadillo.atmark-techno.comサーバーからの自動アップデートを行いますか? (y/N)
/home/atmark/mkswu/initial_setup.swu を作成しました。
"/home/atmark/mkswu/initial_setup.swu" をそのまま使うことができますが、
モジュールを追加してイメージを再構築する場合は次のコマンドで作成してください:
mkswu "/home/atmark/mkswu/initial_setup.desc" [他の.descファイル]
インストール後は、このディレクトリを削除しないように注意してください。
鍵を失うと新たなアップデートはデバイスの /etc/swupdate.pem
を修正しないとインストールできなくなります。
[ATDE ~]$ ls ~/mkswu
initial_setup.desc initial_setup.swu mkswu.conf
swupdate.aes-key swupdate.key swupdate.pem |
COMMON_NAME には証明鍵の「common name」として会社や製品が分かるような任意の名称を入力してください。
| |
証明鍵を保護するパスフレーズを2回入力します。
| |
swuイメージ自体を暗号化する場合に「y」を入力します。詳細は 「SWUpdate と暗号化について」 を参考にしてください。
| |
アットマークテクノのアップデートをインストールしない場合は「n」を入力します。
| |
rootのパスワードを2回入力します。
| |
atmarkユーザーのパスワードを2回入力します。何も入力しない場合はユーザーをロックします。
| |
自動アップデートを無効のままで進みます。ここで「y」を入れると、定期的に
アットマークテクノのサーバーからアップデートの有無を確認し、自動的にインストールします。
| |
作成したファイルを確認します。「swupdate.aes-key」は暗号化の場合にのみ作成されます。
|
このイメージは初回インストール用の署名鍵を使って、作成した鍵とユーザーのパスワードを設定します。 インストール後にコンフィグの mkswu.conf と鍵の swupdate.* をなくさないようにしてください。 | |
---|
このイメージに他の変更も入れれます。他の /usr/share/mkswu/examples/ ディレクトリにある.descファイルや「mkswu の desc ファイル」を参考にして、以下の例のように同じswuにいくつかの.descを組み込めます。 例えば、opensshを有効にします。 [ATDE ~/mkswu]$ cp -rv /usr/share/mkswu/examples/enable_sshd* .
: (省略)
'/usr/share/mkswu/examples/enable_sshd/root/.ssh/authorized_keys'
-> './enable_sshd/root/.ssh/authorized_keys'
'/usr/share/mkswu/examples/enable_sshd.desc' -> './enable_sshd.desc'
[ATDE ~/mkswu]$ cp ~/.ssh/id_rsa.pub \
enable_sshd/root/.ssh/authorized_keys
[ATDE ~/mkswu]$ mkswu initial_setup.desc enable_sshd.desc
enable_sshd.desc を組み込みました。
initial_setup.swu を作成しました。 |
イメージのインストール
「イメージのインストール」を参考に、作成したイメージをインストールしてください。
次回以降のアップデート
次回以降のアップデートは作成した証明鍵を使用してArmadillo-640 のSWUイメージを作成します。 .desc ファイルの内容は /usr/share/mkswu/examples/ のディレクトリや「mkswu の desc ファイル」を参考にしてください。
イメージをインストールする方法として以下に示すような方法があります。
もし、作成した SWU イメージのインストールに失敗する場合は、「swupdate がエラーする場合の対処」をご覧ください。
USBメモリまたはSDカードからの自動インストール
Armadillo-640にUSBメモリまたはSDカードを接続すると自動的にアップデートが始まります。
アップデート終了後にArmadillo-640は自動で再起動します。 USBメモリやSDカードをvfatもしくはext4形式でフォーマットし、作成した.swuのファイルをディレクトリを作らずに配置してください。 [ATDE ~/mkswu]$ df -h
Filesystem Size Used Avail Use% Mounted on
: (省略)
/dev/sda1 15G 5.6G 9.1G 39% /media/USBDRIVE
[ATDE ~/mkswu]$ cp initial_setup.swu /media/USBDRIVE/
[ATDE ~/mkswu]$ umount /media/USBDRIVE |
USBメモリがマウントされている場所を確認します。
| |
ファイルをコピーします。
| |
/media/USBDRIVEをアンマウントします。コマンド終了後にUSBメモリを取り外してください。
|
エラーの場合、/var/log/messageに保存されます。例えば、コンソールで証明の間違ったイメージのエラーを表示します: [armadillo ~]# tail /var/log/messages
Nov 19 10:48:42 user.notice swupdate-auto-update: Mounting sda0 on /mnt
Nov 19 10:48:42 user.notice swupdate-auto-update: Trying update /mnt/initial_setup.swu
Nov 19 10:48:42 user.info swupdate: START Software Update started !
Nov 19 10:48:42 user.err swupdate: FAILURE ERROR : Signature verification failed
Nov 19 10:48:42 user.err swupdate: FAILURE ERROR : Compatible SW not found
Nov 19 10:48:42 user.err swupdate: FATAL_FAILURE Image invalid or corrupted. Not installing ... |
証明が間違ったメッセージ。
|
外部記憶装置からイメージのインストール(手動)
USBメモリやmicroSDカード等の外部記憶装置のルートディレクトリ以外にswuイメージを保存して、イメージのインストールを行います。
ルートディレクトリに保存すると自動アップデートが行われますので、/var/log/messagesを確認してください。 以下は外部記憶装置が/dev/mmcblk1p1(microSDカード)として認識された場合に、イメージのインストールを行う例です。 [armadillo ~]# mount /dev/mmcblk1p1 /mnt
[armadillo ~]# swupdate -i /mnt/swu/initial_setup.swu
SWUpdate v5f2d8be-dirty
Licensed under GPLv2. See source distribution for detailed copyright notices.
[INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1
[INFO ] : SWUPDATE started : Software Update started !
[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over
[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers
[INFO ] : SWUPDATE running : [read_lines_notify] : swupdate triggering reboot!
Killed
ウェブサーバーからイメージのインストール(手動)
swuイメージをウェブサーバーにアップロードして、イメージのインストールを行います。
以下は、http://server/initial_setup.swu のイメージをインストールする例です。
[armadillo ~]# swupdate -d '-u http://server/initial_setup.swu'
SWUpdate v5f2d8be-dirty
Licensed under GPLv2. See source distribution for detailed copyright notices.
[INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1
[INFO ] : SWUPDATE running : [channel_get_file] : Total download size is 25 kB.
[INFO ] : SWUPDATE started : Software Update started !
[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over
[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers
[INFO ] : SWUPDATE running : [read_lines_notify] : swupdate triggering reboot!
Killed
ウェブサーバーからの定期的な自動インストール
swupdate-urlを有効にしたら、定期的にチェックしてインストールします。
以下はサービスの有効化とタイミングの設定の例です。 [armadillo ~]# rc-update add swupdate-url
[armadillo ~]# persist_file /etc/runlevels/default/swupdate-url
[armadillo ~]#
echo https://download.atmark-techno.com/armadillo-640/image/baseos-640-latest.swu \
> /etc/swupdate.watch
[armadillo ~]# echo 'schedule="0 tomorrow"' > /etc/conf.d/swupdate-url
[armadillo ~]# echo 'rdelay="21600"' >> /etc/conf.d/swupdate-url
[armadillo ~]# persist_file /etc/swupdate.watch /etc/conf.d/swupdate-url |
swupdate-urlサービスを有効します。
| |
サービスの有効化を保存します。
| |
イメージのURLを登録します。一行ごとにイメージのURLを設定することができ、複数行にイメージのURLを設定することができます。
| |
チェックやインストールのスケジュールを設定します。
| |
変更した設定ファイルを保存します。
|
USBメモリからのアップデートと同様に、ログは/var/log/messagesに保存されます。 | |
---|
initial_setupのイメージを作成の際に /usr/share/mkswu/examples/enable_swupdate_url.desc を入れると有効にすることができます。 |
hawkBit を使用した自動インストール
hawkBit で Armadillo-640 を複数台管理してアップデートすることができます。
「hawkBitサーバーから複数のArmadilloに配信する」を参考にしてください。
10.7.4. swupdate がエラーする場合の対処SWU イメージのインストール動作は、「SWUイメージとは」で述べたように swupdate が実行します。
mkswu で作成した SWU イメージの内容が適切でなかったり、あるいは、ストレージの空き容量が不足していたりするなど、いくつかの理由で swupdate のインストール動作が失敗することがあります。
インストールに失敗すると、swupdate は /var/log/messages にエラーメッセージのログを残しますので、エラーメッセージを見ると、エラーの内容・原因が分かります。 エラーの原因ごとに、エラーメッセージとエラーの内容および対処方法を記した FAQ ページ (https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos) を公開しています。
SWU イメージのインストールに失敗して対処法が分からないときは、この FAQ ページをご覧ください。 10.7.5. hawkBitサーバーから複数のArmadilloに配信するhawkBitサーバーを利用することで複数のArmadillo
のソフトウェアをまとめてアップデートすることができます。 手順は次のとおりです。
コンテナ環境の準備
Dockerを利用すると簡単にサーバーを準備できます。
Dockerの準備については https://docs.docker.com/get-docker/ を参照してください。 Dockerの準備ができたら、要件に合わせてコンテナの設定を行います。
hawkBitサーバーの準備
/usr/share/mkswu/hawkbit-compose/setup_container.sh を実行して、質問に答えてください。
以下に簡単な(TLSを有効にしない)テスト用の場合と、
TLSを有効にした場合の例を示します。 setup_container.sh を一度実行した場合はデータのディレクトリにある
setup_container.sh のリンクを実行して、ユーザーの追加等のオプション変更を行うこともできます。
詳細は`--help` を参考にしてください。
|
コンテナのコンフィグレーションとデータベースの場所を設定します。
| |
dockerの設定によってsudoが必要な場合もあります。
| |
admin ユーザーのユーザー名を入力します。
| |
admin ユーザーのパスワードを二回入力します。
| |
追加のユーザーが必要な場合に追加できます。
| |
examples/hawkbit_register.desc で armadillo を登録する場合に作っておいてください。
詳細は 「SWU で hawkBit を登録する」 を参考にしてください。
| |
hawkbit_push_update でアップデートを CLI で扱う場合は、「Y」を入力してください。
詳細は 「hawkBit のアップデート管理を CLI で行う」 を参照してください。
| |
hawkbit_push_update でアップデートを実行する場合は、「Y」を入力してください。
| |
ここでは http でテストのコンテナを作成するので、「N」のままで進みます。
| |
コンテナを起動します。初期化が終わったら <IP>:8080 でアクセス可能になります。
|
|
今回は TLS を有効にするので、「y」を入力します。
| |
lighttpd サービスが起動している場合に聞かれます。不要なので、停止します。
| |
証明書の common name を入力してください。ATDE の場合、
ポート転送によってホストのIPアドレスで接続しますのでそのアドレスを入力します。
Let’s encrypt を使用する場合には外部からアクセス可能なDNSを入力してください。
| |
証明書の有効期間を設定します。デフォルトでは10年になっています。
Let’s encryptを使用する場合には使われていません。
| |
クライアント側では x509 証明書で認証をとることができますが、この例では使用しません。
| |
Let’s encrypt による証明書を作成できます。
ATDE の場合は外部からのアクセスが難しいので、この例では使用しません。
| |
自己署名証明書を作成したので、 Armadillo に設置する必要があります。
この証明書の取扱いは 「SWU で hawkBit を登録する」 を参照してください。
|
hawkBitへのログイン
作成したコンテナによって http://<サーバーのIPアドレス>:8080 か
https://<サーバーのアドレス> にアクセスすると、ログイン画面が表示されます。 デフォルトでは次のアカウントでログインできます。
ArmadilloをTargetに登録する
左側のメニューから Deployment をクリックして、Deployment の画面に移ります。 "+"をクリックしてTargetを作成します。 作成したターゲットをクリックすると、
下のペインに "Security token:<文字列>" と表示されるので、
<文字列>の部分をメモします。 メモした<文字列>をArmadilloの /etc/swupdate.cfg に設定すると Hawkbit への接続認証が通るようになります。
Target Filterを作成する
左側のメニューから"Target Filters"をクリックして、Target Filters の画面に移ります。 "+" をクリックして新規にTarget Filterを作成します。 Filter name と フィルタリング条件を入力して保存します。
Software moduleを作成する
左側のメニューから"Upload"をクリックして、Upload Managementの画面に移ります。 "+" をクリックしてSoftware moduleを作成します。
type には OS/Application、
version には 任意の文字列を指定します。
swuパッケージをアップロードしてSoftware moduleに関連付ける
先程作成した Software module を選択して、ハイライトされた状態で、
"Upload File"ボタンをクリックするか、ファイルをドラッグアンドドロップしてアップロードします。
Distributionを作成してSoftware moduleを関連付ける
左側のメニューから"Distribution"をクリックして、Distribution Managementの画面に移ります。 "+" をクリックしてDistributionを作成します。
type には OS/OSwithApp/Apps、
version には任意の文字列を指定します。 "Software module"のペインから先程作成した
Softwareをドラッグして、作成したDistributionの上にドロップします。
Rolloutを作成してアップデートを開始する
左側のメニューから"Rollout"をクリックして、Rollout Managementの画面に移ります。 "+"をクリックしてRolloutを作成します。
アップデートの状態を確認する
Rollout Managementの画面のDetail Statusで、各Rolloutのアップデートの状態を確認できます。 アップデート中は黄色、アップデートが正常に完了すると緑色になります。
10.7.5.1. hawkBit のアップデート管理を CLI で行う一つのアップデートを登録するには、hawkBit の Web UI で必要な手順が長いので CLI で行うことで
効率よく実行できます。 サーバーの設定の段階では、「mkswu」のユーザーを作成する必要があります。
作成していない場合は setup_container.sh --add-user mkswu で作成してください。 [ATDE ~/mkswu]$ ls enable_sshd.swu
enable_sshd.swu
[ATDE ~/mkswu]$ hawkbit_push_update --help
Usage: /usr/bin/hawkbit_push_update [options] file.swu
rollout creation:
--no-rollout: only upload the file without creating a rollout
--new: create new rollout even if there already is an existing one
--failed: Apply rollout only to nodes that previously failed update
post action:
--start: start rollout immediately after creation
[ATDE ~/mkswu]$ hawkbit_push_update --start enable_sshd.swu
Uploaded (or checked) image extra_os.sshd 1 successfully
Created rollout extra_os.sshd 1 successfully
Started extra_os.sshd 1 successfully |
この例ではあらかじめ作成されている enable_sshd.swu を hawkBit に登録します。
| |
--no-rollout を使う場合に SWU を「distribution」として登録します。
デフォルトでは rollout も作成します。
テストする際、デバイスがまだ登録されていなければ rollout の段階で失敗します。
| |
同じ SWU で rollout を二回作成した場合にエラーが出ます。
もう一度作成する場合は --new を使ってください。
| |
一度 rollout をスタートして、 Armadillo で失敗した場合には
失敗したデバイスだけに対応した rollout を作れます。
| |
作成した rollout をすぐ実行します。このオプションには追加の権限を許可する必要があります。
| |
スタートまで行う実行例です。実行結果は Web UI で表示されます。
|
10.7.5.2. SWU で hawkBit を登録するデバイスが多い場合は、SWUを一度作って armadillo を自己登録させることができます。 サーバーの設定の段階では、「device」のユーザーを作成する必要があります。
作成していない場合は setup_container.sh --add-user device で作成してください。 -
hawkbit_register.desc で hawkBit の自己登録を行う例
[ATDE ~]$ cd mkswu/
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/hawkbit_register.* .
[ATDE ~/mkswu]$ vi hawkbit_register.sh
# Script configuration: edit this if required!
# user given here must have CREATE_TARGET,READ_TARGET_SECURITY_TOKEN permissions
HAWKBIT_USER=device
HAWKBIT_PASSWORD="CS=wC,zJmrQeeKT.3"
HAWKBIT_URL=https://10.1.1.1
HAWKBIT_TENANT=default
# set custom options for suricatta block or in general in the config
CUSTOM_SWUPDATE_SURICATTA_CFG="" # e.g. "polldelay = 86400;"
CUSTOM_SWUPDATE_CFG=""
# set to non-empty if server certificate is invalid
SSL_NO_CHECK_CERT=
# or set to cafile that must have been updated first
SSL_CAFILE=
# ... or paste here base64 encoded crt content
SSL_CA_BASE64="
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJlakNDQVNHZ0F3SUJBZ0lVYTMvYXpNSHZ0
bFFnaFZnZDhIZWhMaEwxNm5Bd0NnWUlLb1pJemowRUF3SXcKRXpFUk1BOEdBMVVFQXd3SU1UQXVN
UzR4TGpFd0hoY05Nakl3TWpFNE1EVTFNakV6V2hjTk16SXdNakUyTURVMQpNakV6V2pBVE1SRXdE
d1lEVlFRRERBZ3hNQzR4TGpFdU1UQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VICkEwSUFC
RFJGcnJVV3hHNnBHdWVoejRkRzVqYkVWTm5scHUwYXBHT1c3UVBPYUF4cWp1ZzJWYjk2UHNScWJY
Sk8KbEFDVVo2OStaMHk3clBqeDJHYnhDNms0czFHalV6QlJNQjBHQTFVZERnUVdCQlJtZzhxL2FV
OURRc3EvTGE1TgpaWFdkTHROUmNEQWZCZ05WSFNNRUdEQVdnQlJtZzhxL2FVOURRc3EvTGE1TlpY
V2RMdE5SY0RBUEJnTlZIUk1CCkFmOEVCVEFEQVFIL01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lB
ZTRCQ0xKREpWZnFTQVdRcVBqNTFmMjJvQkYKRmVBbVlGY2VBMU45dE8rN0FpQXVvUEV1VGFxWjhH
UFYyRUg1UWdOMFRKS05SckJDOEtpNkZWcFlkRUowYWc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0t
LS0tCg==
"
# ... or add your own options if required
CURLOPT=-s
: (省略)
[ATDE ~/mkswu]$ cat hawkbit_register.desc
: (省略)
swdesc_script hawkbit_register.sh --version extra_os.hawkbit 1
[ATDE ~/mkswu]$ mkswu hawkbit_register.desc
hawkbit_register.swu を作成しました。
[ATDE ~/mkswu]$ mkswu initial_setup.desc hawkbit_register.desc
hawkbit_register.desc を組み込みました。
initial_setup.swu を作成しました。 |
hawkbit_register.sh と .desc ファイルをカレントディレクトリにコピーします。
| |
hawkbit_register.sh を編集して、設定を記載します。
| |
hawkBit の設定の時に入力した「device」ユーザーのパスワードを入力します。この例のパスワードは使用しないでください。
| |
hawkBit サーバーのURLを入力します。
| |
TLS を使用の場合に、コンテナ作成の時の証明書を base64 で入力します。
| |
hawkbit_register.desc の中身を確認します。hawkbit_register.sh を実行するだけです。
| |
SWU を作成して、initial_setupがすでにインストール済みの Armadillo にインストールできます。
| |
または、initial_setup.desc と合わせて hawkbit_register を含んだ initial_setup.swu を作成します。
|
10.7.6. mkswu の desc ファイル.desc ファイルを編集すると、いくつかのコマンドが使えます。
例 [ATDE ~/mkswu]$ tree /usr/share/mkswu/examples/nginx_start
/usr/share/mkswu/examples/nginx_start
└── etc
└── atmark
└── containers
└── nginx.conf
[ATDE ~/mkswu]$ cat /usr/share/mkswu/examples/usb_container_nginx.desc
swdesc_option version=1
swdesc_usb_container "nginx_alpine.tar"
swdesc_files --extra-os "nginx_start" |
nginx_alpine.tar ファイルに保存されたコンテナをインストールします。
| |
nginx_start ディレクトリの中身を転送します。
|
コマンドは書かれた順番でインストールされます。インストールするかどうかの判断はバージョンで行います: swdesc_option component=<component>
swdesc_option version=<version>
か
swdesc_xxx --version <component> <version> [options]
<component>は以下のどれかにしてください (デフォルトでは .desc ファイルのファイル名を使います)
base_os : rootfs (Armadillo Base OS)を最初から書き込む時に使います。現在のファイルシステムは保存されていない。
この場合、/etc/swupdate_preserve_filesに載ってるファイルのみをコピーして新しいbase OSを展開します。 このcomponentがないと現在のrootfsのすべてがコピーされます。
extra_os.<文字列> : rootfsの変更を行う時に使います。<文字列> には任意の文字列を指定します。
rootfsを変更を行う時に使います。 swdesc_* コマンドに --extra-os オプションを追加すると、 component に自動的に extra_os. を足します。
<文字列> (コンテナの名前などの任意の文字列): rootfsの変更がないときに使います。
このcomponentを使うとrootfsの変更ができませんのでご注意ください。
アップデートを行う際にこのバージョンと現在のバージョンを比べてアップデートの判断を行います。
<component> がまだインストールされてなかった時や <version> が上がる時にインストールします。 デフォルトではダウングレードはできませんが、 --install-if=different オプションを追加することで <version> が変わる際にインストール可能になります。 アップデートの一部をインストールすることもありますので、複数の component で管理し、いくつかの古いバージョンに対応するアップデートも作成可能です。
以下のコマンドから使ってください
swdesc_tar と swdesc_files でファイルを転送します。
swdesc_tar [--dest <dest>] <tar_file>
swdesc_files [--dest <dest>] [--basedir <basedir>] \
<file> [<more files>] swdesc_tar の場合、予め用意されてあるtarアーカイブをこのままデバイスで展開します。
--dest <dest> で展開先を選ぶことができます。デフォルトは / (--extra-os を含め、バージョンの component は base_os か extra_os.* の場合)か /var/app/rollback/volumes/ (それ以外のcomponent)。
後者の場合は /var/app/volumes と /var/app/rollback/volumes 以外は書けないので必要な場合に --extra-os を使ってください。
swdesc_files の場合、mkswu がアーカイブを作ってくれますが同じ仕組みです。
--basedir <basedir> でアーカイブ内のパスをどこで切るかを決めます。
-
例えば、
swdesc_files --extra-os --basedir /dir /dir/subdir/file ではデバイスに /subdir/file を作成します。
-
デフォルトは <file> から設定されます。ディレクトリであればそのまま basedir として使います。それ以外であれば親ディレクトリを使います。
swdesc_command や swdesc_script でコマンドを実行する
swdesc_command <command> [<more commands>]
swdesc_script <script> アップデート先の環境でコマンドやスクリプトファイルを走らせます。 バージョンの component は base_os と extra_os 以外の場合、 /var/app/volumes と /var/app/rollback/volumes 以外は変更できないのでご注意ください。 コマンドの実行が失敗した場合、アップデートも失敗します。
swdesc_exec でファイルを配ってコマンドでそのファイルを使う
swdesc_exec <file> <command> swdesc_command と同じくコマンドを走らせますが、<file> を先に転送してコマンド内で"$1"として使えます。
swdesc_command_nochroot , swdesc_script_nochroot , swdesc_exec_nochroot で起動中のシステム上でコマンドを実行します。
このコマンドは nochroot なしのバージョンと同じ使い方で、現在起動中のシステムに変更や確認が必要な場合にのみ使用してください。 | |
---|
nochroot コマンドは確認を一切しないため、Armadillo が起動できない状態になる可能性もあります。充分にご注意ください。
例が必要な場合は /usr/share/mkswu/examples/firmware_update.desc を参考にしてください。 |
swdesc_embed_container , swdesc_usb_container , swdesc_pull_container で予め作成したコンテナを転送します。
swdesc_embed_container <container_archive>
swdesc_usb_container <container_archive>
swdesc_pull_container <container_url> 例は「コンテナの配布」を参考にしてください。
swdesc_boot で u-boot を更新します。
swdesc_boot <boot image> このコマンドだけにバージョンは自動的に設定されます。
コマンドの他には、設定変数もあります。以下の設定は /home/atmark/mkswu/mkswu.conf に設定できます。 -
DESCRIPTION="<text>" : イメージの説明、ログに残ります。
-
PRIVKEY=<path> , PUBKEY=<path> : 署名鍵と証明書
PRIVKEY_PASS=<val> : 鍵のパスワード(自動用)
openssl のPass Phraseをそのまま使いますので、pass:password , env:var や file:pathname のどれかを使えます。
pass や env の場合他のプロセスに見られる恐れがありますのでfileをおすすめします。
-
ENCRYPT_KEYFILE=<path> : 暗号化の鍵
以下のオプションも mkswu.conf に設定できますが、.descファイルにも設定可能です。swdesc_option で指定することで、
誤った使い方した場合 mkswu の段階でエラーを出力しますので、必要な場合は使用してください。 以下のオプションは Armadillo 上の /etc/atmark/baseos.conf に、例えば MKSWU_POST_ACTION=xxx として設定することができます。 その場合に swu に設定されなければ /etc の設定で実行されますので、
アットマークテクノが用意している Base OS のアップデートでも動作の変更は可能です。
swu に特定のオプションが設定された場合は設定されたオプションが優先されますので、一時的な変更も可能です。 -
swdesc_option POST_ACTION=container : コンテナのみのアップデート後に再起動を行いません。
コンテナの中身だけをアップデートする場合、Armadillo-640を再起動せずにコンテナだけを再起動させます。
-
swdesc_option POST_ACTION=poweroff : アップデート後にシャットダウンを行います。
-
swdesc_option POST_ACTION=wait : アップデート後に自動的に再起動は行われず、次回起動時にアップデートが適用されます。
-
swdesc_option POST_ACTION=reboot : デフォルトの状態に戻します。アップデートの後に再起動します。
swdesc_option NOTIFY_STARTING_CMD="command" , swdesc_option NOTIFY_SUCCESS_CMD="command" , swdesc_option NOTIFY_FAIL_CMD="command" : アップデートをインストール中、成功した場合と失敗した場合に実行されるコマンドです。
コマンドを実行する事で、アプリケーションやユーザーにアップデートを知らせることができます。 LEDで知らせる例を /usr/share/mkswu/examples/enable_notify_led.desc に用意してあります。
/usr/share/mkswu/examples/enable_sshd.desc を参考にします。
descファイルを編集する必要がありませんが自分の公開鍵を指定された場所に配置してください。 [ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/enable_sshd* .
[ATDE ~/mkswu]$ cat enable_sshd.desc
swdesc_option component=extra_os.sshd version=1
# add your public key in enable_sshd/root/.ssh/authorized_keys
if [ -z "$SWDESC_TEST" ]; then
grep -qE '^ssh-' enable_sshd/root/.ssh/authorized_keys \
|| error "Add your keys in enable_sshd/root/.ssh/authorized_keys"
fi
swdesc_files --dest /root enable_sshd/root
swdesc_command "ssh-keygen -A" \
"rc-update add sshd"
[ATDE ~/mkswu]$ cp ~/.ssh/id_rsa.pub \
enable_sshd/root/.ssh/authorized_keys
[ATDE ~/mkswu]$ mkswu enable_sshd.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
enable_sshd.swu を作成しました。 |
自分の公開鍵を転送します。デフォルトのオプションなので enable_sshd/root ディレクトリの中身をこのまま /root に転送されます。
| |
再起動する度に新しいサーバーの鍵が変わらないように、アップデートの時に一回作成します。
| |
サービスを有効にします。
| |
自分の公開鍵を指定された場所に配置します。
| |
イメージを作成します。パスワードは証明鍵のパスワードです。
|
10.7.6.2. 例: Armadillo Base OSアップデートここでは、「Armadilloのソフトウェアをビルドする」でメインシステム向けのビルドで作成したファイルを使用します。 /usr/share/mkswu/examples/OS_update.desc を参考にします。
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/OS_update.desc update-[VERSION].desc
[ATDE ~/mkswu]$ vi update-[VERSION].desc
# uboot image can be generated with atmark u-boot script
swdesc_uboot u-boot-dtb.imx
# base OS is a tar that will be extracted on a blank filesystem,
# after copying just a few key config files.
#
# OS updates are only installed if version is greater than previous update
# so if you install your own updates atmark-techno provided Armadillo Base OS
# updates might not get installed
swdesc_tar "baseos-640-[VERSION].tar.zst" \
--version base_os [VERSION]
[ATDE ~/mkswu]$ mkswu update-[VERSION].desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
update-[VERSION].swu を作成しました。 |
「ブートローダーをビルドする」でビルドしたイメージを使います。
| |
build-rootfsでビルドしたイメージを使います。
| |
バージョンが上がるときにしかインストールされませんので、現在の/etc/sw-versionsを確認して適切に設定してください。
| |
イメージを作成します。パスワードは証明鍵の時のパスワードです。
|
10.7.6.3. 例: swupdate_preserve_files で Linux カーネル以外の Armadillo-640 向けのイメージをインストールする方法Armadillo-640 向けのアップデートイメージに Linux カーネルが含まれています。 swupdate_preserve_files を使って、以下のコマンドでインストール後に現在のカーネルをコピーして更新させないようにします。
[armadillo ~]# echo 'POST /boot' >> /etc/swupdate_preserve_files
[armadillo ~]# echo 'POST /lib/modules' >> /etc/swupdate_preserve_files
[armadillo ~]# persist_file /etc/swupdate_preserve_files |
swupdate_preserve_files に /boot と /lib/modules を保存するように追加します。
| |
変更した設定ファイルを保存します
|
| |
---|
/usr/share/mkswu/examples/kernel_update*.desc のように update_preserve_files.sh のヘルパーで、パスを自動的に /etc/swupdate_preserve_files に追加することができます。
[ATDE ~/mkswu]$ cat example.desc
swdesc_script "$SCRIPT_DIR/examples/update_preserve_files.sh" -- \
"POST /boot" \
"POST /lib/modules" |
スクリプトの内容確認する場合は /usr/share/mkswu/examples/update_preserve_files.sh を参照してください。
|
|
| |
---|
Armadillo Base OS のカーネルを再び使用したい場合は同じスクリプトの --del オプションで行を削除することができます。 [ATDE ~/mkswu]$ cat example.desc
swdesc_script "$SCRIPT_DIR/examples/update_preserve_files.sh" -- \
--del "POST /boot" "POST /lib/modules" |
10.7.7. swupdate_preserve_files についてextra_os のアップデートで rootfs にファイルを配置することができますが、次の OS アップデートの際に削除される可能性があります。
デフォルトでは、 /etc/atmark と、 swupdate 、 sshd やネットワークの設定を保存しますがそれ以外はコピーされてません。 そうでないファイルを更新する際には /etc/swupdate_preserve_files に記載します。「例: swupdate_preserve_files で Linux カーネル以外の Armadillo-640 向けのイメージをインストールする方法」 を参考にしてください。 コピーのタイミングによって、以下のどれかを使用してください:
単にファイルを記載する
この場合、アップデートする前にファイルをコピーします。 baseos のイメージと同じ swu にアップデートしたいファイルを記載していても、
このファイルが Armadillo Base OS に含まれないのであれば問題なくアップデートできます。 例: echo "/root/.profile" >> /etc/swupdate_preserve_files
POST のキーワードの後に記載する
この場合、アップデートの最後でコピーします。 Armadillo Base OS に含まれてるファイルであれば、インストール前にコピーしても保存されないのでコピーのタイミングをずらします。 そのコピーが最後に行われるので、同じアップデートでファイルの変更ができません。アップデートを別けて、 baseos のイメージをインストールしてからこのファイルを更新することができます。 例: echo "POST /etc/conf.d/podman-atmark" >> /etc/swupdate_preserve_files
mkswu --show [file.swu] で SWU イメージの内容を確認することができます。
出力は desc ファイルに似ていますが、そのまま desc ファイルとして利用できませんので確認用としてお使いください。 [ATDE ~/mkswu]$ mkswu --show enable_sshd.swu
enable_sshd.swu
# built with mkswu 4.1
swdesc_files --dest /root enable_sshd/root
--version extra_os.sshd 1
(encrypted)
swdesc_command ssh-keygen -A && rc-update add sshd default
--version extra_os.sshd 1 10.7.9. SWUpdate と暗号化についてmkswu --init の時に暗号化を有効にする場合は AES でファイルを暗号化します。
現在使われてる SWUpdate の暗号化はコマンドやメタデータを含む sw-description ファイルは暗号化されてません。
そのため、通信の暗号化(HTTPSで送信するなど)を使うことを推奨します。 10.8. Armadillo Base OS の操作Armadillo Base OS は Alpine Linux をベースとして作られています。 このセクションでは Armadillo Base OS の機能を紹介します。 Armadillo Base OS は SWUpdate によってアップデートすることができます。 アップデートする際には、rootfs ファイルシステムにインストールされたファイルをすべて消して、アップデートの中身と /etc/swupdate_preserve_files に記載されているファイルで新しい rootfs を作ります。「swupdate_preserve_files について」 を参照してください。 アップデートでファイルを削除してしまった場合に abos-ctrl mount-old で前のシステムを read-only でマウントして、
削除されたファイルをコピーすることもできます。 10.8.2. overlayfs と persist_file についてArmadillo BaseOS ではルートファイルシステムに overlayfs を採用しています。 そのため、ファイルを変更した後 Armadillo の電源を切ると変更内容は保持されません。
開発中などに rootfs の変更内容を保持するには、変更したファイルに対して persist_file コマンドを使用します。 開発以外の時は安全のため、ソフトウェアアップデートによる更新を実行してください。
アップデート手順に関しては 「Armadilloのソフトウェアをアップデートする」 を参照してください。 rootfs の内容を変更しても、ソフトウェアアップデートを実施した際に変更した内容が保持されない可能性があります。
ソフトウェアアップデート実施後も変更内容を保持する手順に関しては 「swupdate_preserve_files について」 を参照してください。 persist_file コマンドの概要を 図10.125「persist_file のヘルプ」 に示します。
ファイルの保存・削除手順例
|
追加・変更したファイルを rootfs へコピーします。
| |
-r を指定すると、ひとつ前の rm -f コマンドで削除したファイルがrootfsからも削除されますのでご注意ください。
| |
すでに rootfs に存在するファイルも一度削除してからコピーするため、このようなメッセージが表示されます。
|
ソフトウェアアップデート後も変更を維持する手順例
|
何らかのファイルの内容を変更します。
| |
-P オプションを付与して persist_file を実行します。
| |
swupdate_preserve_files に追加されたことを確認します。
|
変更ファイルの一覧表示例
|
rootfs のファイルを見せないディレクトリは opaque directory と表示されます。
| |
削除したファイルは whiteout と表示されます。
|
パッケージをインストールする時はapkコマンドを使用してメモリ上にインストールできますが、
persist_file コマンドで rootfs に直接インストールすることも可能です。
|
この例では Armadillo を再起動せずにインストールしたコマンドを使用できましたが、Armadillo の再起動が必要となるパッケージもありますので、その場合は Armadillo を再起動してください。
|
Armadillo Base OS の ルートファイルシステムが壊れて起動できなくなった場合に自動的に前のバージョンで再起動します。 自分で確認する必要がある場合に abos-ctrl status でロールバックされてるかどうかの確認ができます。 必要な場合(例えば、自分のアプリケーションがアップデート直後に問題があった場合)、 abos-ctrl rollback で手動のロールバックも可能です。ロールバックにエラーがなければ、再起動してロールバックを完了します。 なお、/var/at-log/atlog に切り替えの際に必ずログを書きますので、調査の時に使ってください。 自分のアプリケーションで直接入力の処理ができない場合に Base OS から簡単な処理ができます。 buttond サービスで指定されたイベントでコマンドを実行します。
/etc/atmark/buttond.conf に BUTTOND_ARGS を指定することで、動作を指定することができます:
以下にデフォルトを維持したままで SW1 の早押しと長押しにそれぞれの場合にコマンドを実行させます。 |
buttond の設定ファイルを編集します。この例では、短押しの場合 /tmp/shotpress に、5 秒以上の長押しの場合 /tmp/longpress に日付を出力します。
| |
設定ファイルを保存します。
| |
buttond サービスを再起動させます。ここでは再起動後短押しを 2 回、長押しを 1 回行ったとします。
| |
押された回数を確認します。
|
USB キーボードや他の入力デバイスにも対応できます。
デバイスを接続してから、 buttond でデバイス名とキーコードを確認します。
[armadillo ~]# buttond -vvv /dev/input/* /dev/input/by-*/*
Skipping directory /dev/input/by-id
Skipping directory /dev/input/by-path
[78972.042] /dev/input/event2 4 4 458976: non-keyboard event ignored
[78972.042] /dev/input/event2 LEFTCTRL (29) pressed: ignored
[78972.042] /dev/input/by-id/usb-0566_3029-event-kbd 4 4 458976: non-keyboard event ignored
[78972.042] /dev/input/by-id/usb-0566_3029-event-kbd LEFTCTRL (29) pressed: ignored
[78972.042] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd 4 4 458976: non-keyboard event ignored
[78972.042] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd LEFTCTRL (29) pressed: ignored
[78972.130] /dev/input/event2 4 4 458976: non-keyboard event ignored
[78972.130] /dev/input/event2 LEFTCTRL (29) released: ignored
[78972.130] /dev/input/by-id/usb-0566_3029-event-kbd 4 4 458976: non-keyboard event ignored
[78972.130] /dev/input/by-id/usb-0566_3029-event-kbd LEFTCTRL (29) released: ignored
[78972.130] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd 4 4 458976: non-keyboard event ignored
[78972.130] /dev/input/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-event-kbd LEFTCTRL (29) released: ignored |
buttond を -vvv で冗長出力にして、すべてのデバイスを指定します。
| |
希望のキーを押すと、LEFTCTRL が三つのパスで認識されました。 一番安定する by-id のパスを控えておきます。
|
USB デバイスを外すこともありますので、-i (inotify) で管理されてる入力デバイスとして追加します。
そうしないとデバイスを外したときにbuttondが停止します。
[armadillo ~]# vi /etc/atmark/buttond.conf
BUTTOND_ARGS="$BUTTOND_ARGS -i /dev/input/by-id/usb-0566_3029-event-kbd"
BUTTOND_ARGS="$BUTTOND_ARGS -s LEFTCTRL -a 'podman_start button_pressed_container'"
[armadillo ~]# persist_file /etc/atmark/buttond.conf
[armadillo ~]# rc-service buttond restart
10.8.5. Armadillo Base OS 側の起動スクリプト起動時に何かスクリプトを走らせるためにはコンテナとして実行することを推奨します。 「コンテナの自動起動」 を参照してください。 コンテナで実行不可能な場合に、「local」サービスを使うことができます: /etc/local.d ディレクトリに
.start ファイルを置いておくと起動時に実行されて、 .stop ファイルは終了時に実行されます。 |
スクリプトを作ります。
| |
スクリプトを実行可能にします。
| |
スクリプトを保存して、再起動します。
| |
実行されたことを確認します。
|
u-boot の環境変数を変更するには /boot/uboot_env.d/ ディレクトリに環境変数が書かれた設定ファイルを配置します。 ファイルの構文は fw_setenv が扱うことができるもので、以下のとおりです: -
# で始まる行はコメントと扱われる為、無視されます。また、 環境変数への代入を示す = がない場合も無視されます。
-
[変数]=[値] で変数を設定します。スペースや引用符を含め他の文字は有効ですので、変数の名前と値に不要な文字を入れないように注意してください。
-
[変数]= で変数を消します。値がない場合に変数が消去されます。
このファイルによるアップデート内容は swupdate でアップデートする際に適用されます。 実行中のシステムに影響がありませんので、設定ファイルを swupdate で転送しない場合はファイル永続化後に fw_setenv -s /boot/uboot_env.d/[ファイル名] で変数を書き込んでください。 swupdate でファイルを転送した場合には、変数はすぐに利用されます。 |
コンフィグファイルを生成します。
| |
ファイルを永続化します。
| |
変数を書き込みます。
| |
書き込んだ変数を確認します。
|
| |
---|
mkswu バージョン 4.4 以降が必要です。必要な場合はアップデートしてください。 [ATDE ~]$ sudo apt update && sudo apt upgrade 書き方は、 /usr/share/mkswu/examples/uboot_env.desc を参考にしてください。 |
| |
---|
「ブートローダーをビルドする」 の際に u-boot のデフォルトを変更した場合や、u-boot のプロンプトで「setenv」や「saveenv」を実行しても、 /boot/uboot_env.d/00_defaults によって変更がアップデートの際にリセットされます。 00_defaults のファイルは Base OS の一部で更新されることもありますので、変更を望む場合は別のファイルを作って設定してください。
ファイルはアルファベット順で処理されます。 00_defaults にある変数を後のファイルにも設定した場合はそのファイルの値だけが残ります。
|
主要なu-bootの環境変数を以下に示します。 表10.6 u-bootの主要な環境変数 環境変数 | 説明 | デフォルト値 |
---|
console | U-BootとLinuxで利用するコンソールのデバイスノードと、UARTのボーレート等を指定します。 | ttymxc0,115200 | bootcount | 起動回数を示します。初回起動時に1となり、起動に失敗する度にインクリメントされます。ユーザーランドのbootcountサービスが起動されると、この値はクリアされます。この値が"bootlimit"を越えた場合はロールバックします。ロールバックの詳細については、「ロールバック(リカバリー)」を参照してください。 | 1 | bootlimit | "bootcount"のロールバックを行うしきい値を指定します。 | 3 | bootdelay | 保守モードに遷移するためのキー入力を待つ時間を指定します(単位:秒)。次の値は特別な意味を持ちます。
-
-1: キー入力の有無に関らず保守モードに遷移します。
-
-2: キー入力の有無に関らず保守モードに遷移しません。
| 2 | image | Linuxカーネルイメージファイルのパスです。"mmcdev"で指定されたデバイスの、"mmcpart"で指定されたパーティションのルートディレクトリからの相対パスで指定します。 | boot/Image | fdt_file | DTBファイルのパスです。"mmcdev"で指定されたデバイスの、"mmcpart"で指定されたパーティションのルートディレクトリからの相対パスで指定します。 | boot/armadillo.dtb | overlays_list | DT overlayの設定ファイルのパスです。"mmcdev"で指定されたデバイスの、"mmcpart"で指定されたパーティションのルートディレクトリからの相対パスで指定します。DT overlayの詳細については、「DT overlay によるカスタマイズ」を参照してください。 | boot/overlays.txt | mmcautodetect | mmcデバイスの自動検出機能の有効/無効を指定します。yesを指定した場合のみ、u-bootが起動されたmmcデバイスが自動的にmmcdevとして利用されます。 | yes | mmcdev | "image"や"fdt_file"で指定されたファイルが配置してあるmmcデバイスのインデックスを指定します。インデックスとmmcデバイスの対応は次の通りです。
-
0: eMMC
-
1: microSD/microSDHC/microSDXC カード
"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。 | 2 | mmcpart | "image"や"fdt_file"で指定されたファイルが配置してある、"mmcdev"で指定されたmmcデバイスのパーティション番号を指定します。"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。 | 1 | mmcroot | ルートファイルシステムが配置されているデバイスノードと、マウントオプションを指定します。"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。overlayfsが正しく機能しなくなる場合があるので、roの指定は変更しないでください。 | /dev/mmcblk0p1 rootwait ro | optargs | Linuxカーネル起動時パラメータを指定します。"quiet"を削除すると、コンソールに起動ログが出力されるようになりますが、起動時間が長くなります。nokaslrを削除すると、KASLR(Kernel Adress Space Layout Randomization)が有効となり、Linuxカーネルの仮想アドレス空間がランダム化されます。 | quiet | loadaddr | LinuxカーネルがRAMにロードされる物理アドレスを指定します。 | 0x80800000 | fdt_addr | DTBがRAMにロードされる物理アドレスを指定します。 | 0x83500000 | overlay_addr | DT overlayのワーク領域として利用されるRAMの物理アドレスを指定します。 | 0x83520000 |
10.8.7. Network Time Protocol (NTP, ネットワーク・タイム・プロトコル)Armadillo Base OS では chronyd を使っています。 デフォルトの設定(使用するサーバーなど)は /etc/chrony/conf.d/ にあり、
変更用に /etc/atmark/chrony.conf.d/ のファイルも読み込みます。
/etc/atmark/chrony.conf.d ディレクトリに /etc/chrony/conf.d/ と同じファイル名の
設定ファイルを置いておくことで、デフォルトのファイルを読まないようになります。 例えば、 NTP サーバーの設定は servers.conf に記載されてますので、変更する際はに
/etc/atmark/chrony.conf.d/servers.conf のファイルに記載します: |
コンフィグファイルを作ります。
| |
ファイルを保存します
| |
chronyd サービスを再起動します。
| |
chronyc で新しいサーバーが使用されていることを確認します。
|
10.9. Device Treeをカスタマイズするat-dtweb を利用して Device Tree をカスタマイズする方法を説明します。at-dtweb では、
Web ブラウザ上のマウス操作で dtbo ファイルおよび desc ファイルを生成することができます。
カスタマイズの対象は拡張インターフェース(CON9/CON14)およびLCD 拡張インターフェース(CON11)です。 ATDE9 に at-dtweb パッケージをインストールします。 [ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt install at-dtweb インストール済みの場合は、以下のコマンドを実行し最新版への更新を行ってください。 [ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt upgrade
at-dtweb の起動開始
at-dtweb の起動を開始するには、デスクトップ左上のアプリケーションの「システムツール」から「at-dtweb」を選択してください。
コマンドライン上からでも、at-dtweb コマンドで起動できます。 [ATDE ~]$ at-dtweb
ボードの選択
ボードを選択します。Armadillo-640 を選択して、「OK」をクリックします。
Linux カーネルディレクトリの選択
Linux カーネルディレクトリを選択します。コンフィギュレーション済みの Linux カーネルディレクトリを選択して、「OK」をクリックします。
at-dtweb の起動完了
at-dtweb が起動し、次のように画面が表示されます。
10.9.3. Device Tree をカスタマイズ機能の選択は、ドラッグ&ドロップで行います。画面左上の「Available features」から有効にしたい機能をドラッグし、画面右側の「Armadillo-640」の白色に変化したピンにドロップします。例としてCON9 3/5ピンをUART1(RXD/TXD)に設定します。 | |
---|
何も機能が選択されていないピンには GPIO の機能が割り当てられます。 |
画面右側の「Armadillo-640」にドロップして設定したピンを左クリックすると信号名が表示されます。
どのピンがどの信号に対応しているのかを確認することができます。 例として UART1(RXD/TXD) の信号名を確認します。 | |
---|
再度ピンを左クリックすると機能名の表示に戻ります。 |
いくつかの機能にプロパティを設定することができます。画面右側の「Armadillo-640」に選択した機能を左クリックすると、画面左下の「Properties」からプロパティを選択することができます。 例としてCON9 4/6ピンのI2C2(SCL/SDA)のclock_frequencyプロパティを設定します。 設定したプロパティを確定させるには「Apply」をクリックします。 全ての機能を削除する場合は、画面右上の「Reset configuration」をクリックします。機能ごとに削除する場合は、画面右側の「Armadillo-640」のピンを右クリックして「Remove」をクリックします。 10.9.3.5. Device Tree のファイルの生成Device Tree のファイルを生成するには、画面右上の「Save」をクリックします。 以下の画面ようなメッセージが表示されると、dtbo ファイルおよび desc ファイルの生成は完了です。 ビルドが完了するとホームディレクトリ下の mkswu/at-dtweb-Armadillo-640
ディレクトリに、DT overlay ファイル(dtboファイル)と desc ファイルが生成されます。
Armadillo-640 本体に書き込む場合は、mkswu コマンドで desc ファイルから SWU イメージを生成してアップデートしてください。 [ATDE ~]$ ls ~/mkswu/at-dtweb-Armadillo-640
armadillo-640-at-dtweb.dtbo update_overlays.sh
at-dtweb.desc update_preserve_files.sh
[ATDE ~]$ cd ~/mkswu/at-dtweb-Armadillo-640
[ATDE ~]$ mkswu at-dtweb.desc
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
at-dtweb.swu を作成しました。 |
SWU イメージを生成します。
|
SWU イメージを使ったアップデートの詳細は 「Armadilloのソフトウェアをアップデートする」 を参照してください。 10.9.4. DT overlay によるカスタマイズDevice Treeは「DT overlay」(dtbo) を使用することでも変更できます。 DT overlay を使用することで、通常の dts の更新が自動的に入りつづける状態で
dts の変更でしかできない設定を行うことができます。 /boot/overlays.txt に fdt_overlays を dtbo 名で設定することで、
u-bootが起動時にその DT overlay を通常の dtb と結合して起動します。
複数の DT overlay を使う場合は以下の例のようにスペースで別けたファイル名を記載することができます。 |
/boot/overlays.txt ファイルに「armadillo-640-at-dtweb.dtbo」を追加します。
ファイルが存在しない場合は新規に作成してください。
このファイルの詳細については 「DT overlay によるカスタマイズ」 を参照してください。
| |
/boot/overlays.txt を保存し、アップデートの場合でも保存します。
| |
overlay の実行のために再起動します。
| |
シリアルコンソールの場合に、u-bootによるメッセージを確認できます。
|
10.9.4.1. 提供している DT overlay以下の DT overlay を用意しています: -
armadillo-640-lcd70ext-l00.dtbo: LCD オプションセット(7 インチタッチパネル WVGA 液晶を接続する場合にご使用ください。
-
armadillo-640_con9_thread.dtb: Armadillo-600シリーズ BT/THオプションモジュールを接続する場合にご使用ください。
-
armadillo-640-con9-thread-lwb5plus.dtbo: Armadillo-600シリーズ WLANコンボオプションモジュール または、Armadillo-600シリーズBT/THオプションモジュールWLANコンボ対応を接続する場合にご使用ください。
10.10. LCD オプションセット(7 インチタッチパネル WVGA 液晶)を利用するこの章では、「LCDオプションセット(7インチタッチパネルWVGA液晶)」の利用方法について説明します。 10.10.1. LCD オプションセット(7 インチタッチパネル WVGA 液晶)を利用する準備LCD オプションセット(7 インチタッチパネル WVGA 液晶)を利用するには、DT overlayの設定が必要です。 10.10.2. LCD オプションセット(7 インチタッチパネル WVGA 液晶)を利用する「画面表示を行う」を参照して画面表示を行うことができます。 10.11. Armadillo-600 シリーズ WLAN コンボオプションモジュールを利用するこの章では、「Armadillo-600シリーズ WLANコンボ、BT/THオプションモジュール」に搭載されているSterling LWB5+ を使って様々なネットーワークを構成する例を紹介します。 「Armadillo-600シリーズ WLANコンボ、BT/THオプションモジュール」の組み立てを行う前に、コンソールをCON3に移動します。図15.25「オプションモジュールのCON2をシリアルコンソールとして使用する場合の接続例」のように接続する場合は、この設定は不要です。 | |
---|
Armadillo-600 シリーズ WLAN コンボオプションモジュールを利用しなくなった場合は、次のようにコンソールをCON9に戻すことができます。 [armadillo ~]# vi /boot/uboot_env.d/console_con9
console=ttymxc0,115200
[armadillo ~]# persist_file -v /boot/uboot_env.d/console_con9
'/boot/uboot_env.d/console_con9' -> '/mnt/boot/uboot_env.d/console_con9'
[armadillo ~]# fw_setenv -s /boot/uboot_env.d/console_con9
Environment OK, copy 1
[armadillo ~]# fw_printenv | grep console=ttymxc
console=ttymxc0,115200 |
また、WLAN機能を利用するには、DT overlayの設定が必要です。 10.11.2. 無線 LAN アクセスポイント (AP) に接続するArmadilloを子機として、無線 LAN AP に接続する方法を説明します。 以下は、WPA2-PSK(AES) の AP に接続する例です。
ここでは、AP の ESSID を [essid]、パスフレーズを [passphrase] と表記します。 |
設定ファイルを永続化することで、Armadillo 起動時に自動的に AP に接続するようになります。
|
nmtui というツールを使用するとテキストユーザーインターフェースで設定を行うことができます。 表示された画面上で設定が行なえます。 Activate a connection を選択します。 Wi-Fi の下に表示される AP 一覧の中から、接続したいものを選択します。 表示された画面で、接続のためのパスフレーズを入力します。 入力後に OK を押すと接続されます。 10.11.3. 無線 LAN アクセスポイント (AP) として設定するArmadilloを無線 LAN AP として設定する
方法を説明します。AP を設定するには hostapd というソフトウェアと、
DNS/DHCP サーバである dnsmasq というソフトウェアを使用します。 hostapd と dnsmasq は Armadillo Base OS にデフォルトでインストール済みとなっているため、
インストール作業は不要です。
インストールされていない場合は、 Armadillo Base OS を最新バージョンに更新してください。 | |
---|
アクセスポイントモード (AP) と ステーションモード (STA) の同時利用はできません。
Armadilloを子機として無線 LAN AP に接続しながら、
hostapd を起動するような使い方は避けてください。 |
10.11.3.1. hostapd を使用して設定するNetworkManager で bridge インターフェース (br0) を追加します。
同時に IP アドレスも設定します。ここでは 192.0.2.1 を設定しています。 |
設定ファイルを永続化します。
|
また、NetworkManager のデフォルト状態では定期的に wlan0 のスキャンを行っています。
スキャン中は AP の性能が落ちてしまうため wlan0 を NetworkManager の管理から外します。 |
nmcli で NetworkManager をリスタートせずに設定します。
|
| |
---|
hostapd が使用するインターフェース (wlan0 ) は /etc/NetworkManager/conf.d/00_disable_ap.conf
ファイルによってデフォルトで NetworkManager の管理から外しております。 |
hostapd の設定ファイルの雛形として用意してある /etc/hostapd/hostapd.conf.example を
コピーして使用します。 |
5GHz であれば a を、2.4GHz であれば g を設定します。
| |
使用するチャンネルを設定します。
| |
子機から接続するための任意の SSID を設定します。この例では myap を設定しています。
| |
子機から接続するための任意のパスフレーズを設定します。この例では myap_pass を設定しています。
| |
wlan0 を設定します。
| |
IEEE802.11ax に非対応のため、0 を指定します。
| |
設定ファイルを永続化します。
| |
hostapd を起動します。
| |
Armadillo 起動時に hostapd が自動的に起動されるようにします。
| |
hostapd 自動起動の設定を永続化します。
|
dnsmasq の設定ファイルを以下の内容で作成し /etc/dnsmasq.d/ 下に配置します。
ファイル名は任意ですが、拡張子は .conf としてください。ここでは dhcp.conf としています。 |
子機に割り当てる IP アドレスの範囲とリース期間を設定します。
| |
設定ファイルを永続化します。
| |
dnsmasq を再起動します。
|
hostapd と dnsmasq の起動完了後、子機から hostapd.conf で設定した SSID とパスフレーズで接続できます。 Armadilloをルータとして設定して外部ネットワークに接続する
方法を説明します。ここでは外部ネットワークの例として一般的なインターネットを設定しています。 10.11.4.1. 無線 LAN 側に接続した機器から Ethernet 経由でインターネットに接続するArmadilloを無線 LAN AP として設定し、
AP に接続した子機から、 Ethernet(eth0) を経由してインターネットに接続する方法を説明します。 最初に、「無線 LAN アクセスポイント (AP) として設定する」 を参照して AP の設定を完了させてください。 ルータとして機能させるために、 ip_forward を有効にします。
sysctl の設定ファイルを以下の内容で作成し /etc/sysctl.d/ 下に配置します。
ファイル名は任意ですが、拡張子は .conf としてください。ここでは router.conf としています。 |
1 (有効) に設定します。
| |
設定ファイルを永続化します。
| |
sysctl を再起動して設定を反映させます。
|
|
ここで設定する IP アドレスのネットワーク部は AP に設定したものと合わせてください。
| |
iptables の設定を保存します。
| |
サービスを有効にします
| |
保存した設定ファイルを永続化します。
|
設定完了後、AP を起動して子機を接続すると子機からインターネットに接続することができます。 10.11.4.2. Ethernet 側に接続した機器から無線 LAN 経由でインターネットに接続するArmadilloの Ethernet(eth0) に接続した機器から、無線 LAN を経由してインターネットに接続する方法を説明します。 図10.158「ip_forward を有効にする」 と同様の手順で設定します。 -
bridge インターフェースを追加して eth0を割り当てる
|
デフォルトで存在しているコネクションを down します。
| |
bridge インターフェースを作成します。
| |
作成した bridge-br0 に任意の IP アドレスを設定し STP を無効にします。
| |
eth0 を bridge-br0 に割り当てます。
| |
それぞれの設定ファイルを永続化します。
|
dnsmasq の設定ファイルを以下の内容で作成し /etc/dnsmasq.d/ 下に配置します。
ファイル名は任意ですが、拡張子は .conf としてください。ここでは dhcp.conf としています。 |
接続した機器に割り当てる IP アドレスの範囲とリース期間を設定します。
| |
dnsmasq を再起動します。
|
|
ここで設定する IP アドレスのネットワーク部は bridge-br0 に設定したものと合わせてください。
| |
iptables の設定を保存します。
| |
サービスを有効にします
| |
保存した設定ファイルを永続化します。
|
「無線 LAN アクセスポイント (AP) に接続する」 と同様の手順で、無線 LAN アクセスポイントに接続します。 設定完了後、eth0 ポートに機器を接続すると無線 LAN 経由でインターネットに接続することができます。 10.12. Armadillo-600 シリーズ BT/TH オプションモジュールを利用するこの章では、「Armadillo-600シリーズ WLANコンボ、BT/THオプションモジュール」に搭載されているEYSKBNZWBの利用方法について説明します。 EYSKBNZWBは、BT または Thread 機能を選択して利用することができます。 10.12.1. Armadillo-600 シリーズ BT/TH オプションモジュールを利用する準備「Armadillo-600シリーズ WLANコンボ、BT/THオプションモジュール」の組み立てを行う前に、コンソールをCON3に移動します。図15.25「オプションモジュールのCON2をシリアルコンソールとして使用する場合の接続例」のように接続する場合は、この設定は不要です。 | |
---|
Armadillo-600 シリーズ BT/TH オプションモジュールを利用しなくなった場合は、次のようにコンソールをCON9に戻すことができます。 [armadillo ~]# vi /boot/uboot_env.d/console_con9
console=ttymxc0,115200
[armadillo ~]# persist_file -v /boot/uboot_env.d/console_con9
'/boot/uboot_env.d/console_con9' -> '/mnt/boot/uboot_env.d/console_con9'
[armadillo ~]# fw_setenv -s /boot/uboot_env.d/console_con9
Environment OK, copy 1
[armadillo ~]# fw_printenv | grep console=ttymxc
console=ttymxc0,115200 |
また、Armadillo-600 シリーズ BT/TH オプションモジュールを利用するには、DT overlayの設定が必要です。 BT 機能を有効化するためのコンテナを、 Armadillo-640 コンテナ からダウンロードします。 BT 機能を有効化するには、以下のコマンドを入力します。 | |
---|
一度 BT 機能を有効化すると、再起動後も BT 機能が有効化された状態を維持します。再起動する度に BT 機能を有効化する必要はありません。 |
| |
---|
Bluetooth® version 5.0以降で追加されたCoded PHY(Long Range)などの機能は、この章に記載の手順では利用することができません。これは、BlueZが非対応の為です。 |
EYSKBNZWBとSterling LWB5+のBT機能は同時に利用することができません。デフォルトではEYSKBNZWBのBT機能が利用できないようになっています。次のように、idVendorとidProductの値を変更して再起動してください。 これでEYSKBNZWBの BT 機能を利用する準備は完了です。「Bluetooth デバイスを扱う」を参照してBT機能を利用できます。 Thread 機能を有効化するためのコンテナを、 Armadillo-640 コンテナ からダウンロードします。 Thread 機能を有効化するには、以下のコマンドを入力します。 | |
---|
一度 Thread 機能を有効化すると、再起動後も Thread 機能が有効化された状態を維持します。再起動する度に Thread 機能を有効化する必要はありません。 |
これでEYSKBNZWBの Thread 機能を利用する準備は完了です。「Thread デバイスを扱う」を参照してThread機能を利用できます。デバイスファイルは /dev/ttyACM0 です。 | |
---|
TTYデバイスは検出された順番にインデックスが割り振られます。USBシリアルデバイスなどを接続してしている場合は、
デバイスファイルのインデックスが異なる可能性があります。 |
10.13. 動作中の Armadillo の温度を測定するこの章では、Armadillo Base OS 搭載製品を組み込んだユーザー製品の熱設計時に役立つ温度プロファイラツールである「atmark-thermal-profiler」について紹介します。 Armadillo は製品ごとに動作温度範囲が設定されていますが、それらはあくまでも標準筐体に放熱材と共に取り付けて使用した場合の目安であり、実運用時には自作の筐体の使用や放熱の有無などで記載のスペック通りにならない場合があります。
また、 Armadillo には CPU または SoC が特定の温度以上になると、自動的にシャットダウンするサーマルシャットダウン機能が搭載されています。
そのため、現実的には Armadillo を組み込んだ製品を運用時と同等の環境で動作させつつ、実際に温度を計測して実運用時の CPU 及び SoC 温度がどの程度まで上がるか、サーマルシャットダウンは起こらないかを確かめる必要があります。 Armadillo Base OS 搭載製品では、動作中の Armadillo の各種温度等を取得しCSV形式で出力する atmark-thermal-profiler を利用することができますので、温度測定に役立てることができます。 10.13.2. atmark-thermal-profiler をインストールするatmark-thermal-profiler は apk パッケージで公開されていますので、apk add コマンドでインストールすることが可能です。 | |
---|
atmark-thermal-profiler はデバッグ(開発)用途で温度情報を収集及び解析するツールです。
atmark-thermal-profiler は、他の apk パッケージと同様に persist_file -a コマンドで永続的にインストールしておくことが可能ですが、
ログの保存のために Armadillo が起動している間 eMMC への書き込みを続けるので、 Armadillo を組み込んだ製品の運用時に動かしたままにしておくことは推奨しません。 atmark-thermal-profiler を永続的にインストールする場合は、運用時には必ず削除してください。 |
10.13.4. atmark-thermal-profiler が出力するログファイルを確認するatmark-thermal-profiler は、インストール直後から自動的に温度やCPU負荷率、Load Averageなどの情報を30秒に1度の周期で集め、/var/log/thermal_profile.csvに追記していきます。 thermal_profile.csv の1行目はヘッダ行です。
各列についての説明を表10.7「thermal_profile.csvの各列の説明」に記載します。 表10.7 thermal_profile.csvの各列の説明 ヘッダ | 説明 |
---|
DATE | その行のデータ取得日時です。 "年-月-日T時:分:秒+タイムゾーン" の形式で出力されます。 | ONESHOT | この列が1の行のデータは、サーマルシャットダウンを含むシャットダウンが実行された時に取得されたことを示します。 | CPU_TEMP | 計測時点の CPU 温度を示します。単位は℃です。 | SOC_TEMP | 計測時点の SoC 温度を示します。単位は℃です。製品よっては非対応で、その場合は空白になります。 | LOAD_AVE | 計測時点から直近1分間のLoad Averageです。 | CPU_1 | 計測時点のCPU使用率1位のプロセスです。 | CPU_2 | 計測時点のCPU使用率2位のプロセスです。 | CPU_3 | 計測時点のCPU使用率3位のプロセスです。 | CPU_4 | 計測時点のCPU使用率4位のプロセスです。 | CPU_5 | 計測時点のCPU使用率5位のプロセスです。 | USE_1 | 計測時点のCPU使用率1位のプロセスのCPU使用率です。 | USE_2 | 計測時点のCPU使用率2位のプロセスのCPU使用率です。 | USE_3 | 計測時点のCPU使用率3位のプロセスのCPU使用率です。 | USE_4 | 計測時点のCPU使用率4位のプロセスのCPU使用率です。 | USE_5 | 計測時点のCPU使用率5位のプロセスのCPU使用率です。 |
atmark-thermal-profiler を使用して得られたログファイルの内容を分析してみます。 10.13.5.1. サーマルシャットダウン温度の確認予め、使用している Armadillo が何℃でサーマルシャットダウンするか確認しておきます。
ここでは、 Armadillo Base OS を搭載している Armadillo-IoT ゲートウェイ G4 を例とします。
他の製品では得られる結果が異なる場合があることに注意してください。 |
CPU のサーマルシャットダウン温度です。ミリ℃で表記されているので、105℃でサーマルシャットダウンすることがわかります。
| |
SoC のサーマルシャットダウン温度です。ミリ℃で表記されているので、105℃でサーマルシャットダウンすることがわかります。
|
atmark-thermal-profiler が出力するログ(thermal_profile.csv)はCSVファイルなので、各種表計算ソフトでインポートしてグラフ化することが可能です。
これにより Armadillo 動作中の温度の変化が可視化され、得られる情報が見やすくなります。 図10.173「Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ」は Armadillo-IoT ゲートウェイ G4上で一定期間 atmark-thermal-profiler を実行して取得した thermal_profile.csv を Google スプレッドシートでグラフ化したものです。
例のために、途中で stress-ng コマンドを実行して CPU に負荷を与えた後、 stress-ng コマンドを停止して CPU と SoC の温度が下がるのを待った際のデータです。 グラフの縦軸は温度(℃)で、横軸は時間です。青い線は CPU の温度、赤い線は SoC の温度を表しています。
このグラフと、「サーマルシャットダウン温度の確認」で得たサーマルシャットダウン温度を見比べると、 CPU に負荷をかけた際であっても SoC の温度は 60℃ 前後ほどまでしか上がらず、 この条件で動く Armadillo が温度的にどれほど余裕を持っているかをひと目で確認できます。 atmark-thermal-profiler は、時間毎の温度だけでなく CPU 使用率と CPU 使用率の高いプロセスについても取得して記録します。
CPU 使用率については thermal_profile.csv の CPU_1〜CPU_5 列と、 USE_1〜USE_5 列を参照してください。
各列について詳しくは表10.7「thermal_profile.csvの各列の説明」にまとまっています。 一般的に CPU 使用率が高くなると、 CPU 周辺の温度も高くなります。
そのため、測定した温度が高い場合は、 CPU 使用率の高いプロセスに注目して、 CPU を無駄に使用している意図しない処理が行なわれていないかなどを確認することをおすすめします。 10.14. eMMC の GPP(General Purpose Partition) を利用するGPP に squashfs イメージを書き込み、Armadillo の起動時に自動的にマウントする方法を紹介します。 10.14.1. squashfs イメージを作成するこの作業は ATDE 上で行います。 squashfs-tools パッケージに含まれている mksquashfs コマンドを使用して squashfs イメージを作成します。 10.14.2. squashfs イメージを書き込む以降の作業は Armadillo 上で行います。 「squashfs イメージを作成する」で作成した squashfs イメージを、USB メモリ利用するなどして Armadillo-640 にコピーし、GPP に書き込みます。 | |
---|
ユーザー領域として使用可能なGPPは /dev/mmcblk0gp3 のみです。 GPPへの書き込みを行う際は、誤って /dev/mmcblk0gp0 などに書き込みを行わないよう、十分に注意してください。 |
[armadillo]# mount /dev/sda1 /mnt
[armadillo]# dd if=/mnt/squashfs.img of=/dev/mmcblk0gp3 conv=fsync
[armadillo]# umount /mnt GPP の全ブロックに対して Temporary Write Protection をかけることにより、GPP への書き込みを制限することができます。
Temporary Write Protection は電源を切断しても解除されません。 Temporary Write Protection をかけるには、mmc-utils パッケージに含まれている mmc コマンドを使用します。 GPP の全ブロックに対して Temporary Write Protection をかけるには、次のようにコマンドを実行します。 |
/dev/mmcblk0gp3 のブロック数を確認します。コマンドの出力を見ると /dev/mmcblk0gp3 が 16384 ブロックあることがわかります。
| |
/dev/mmcblk0gp3 の全ブロックに Temporary Write Protection をかけます。
|
| |
---|
Temporary Write Protection を解除するには、次のコマンド実行します。 [armadillo]# mmc writeprotect user set none 0 16384 /dev/mmcblk0gp3 |
10.14.4. 起動時に squashfs イメージをマウントされるようにする/etc/fstab を変更し、起動時に squashfs イメージがマウントされるようにします。
[armadillo]# mkdir -p /opt/sample
[armadillo]# persist_file /opt/sample/
[armadillo]# vi /etc/fstab
:
:(省略)
:
/dev/mmcblk0gp3 /opt/sample squashfs defaults,nofail 0 0
[armadillo]# persist_file /etc/fstab |
squashfs イメージをマウントするディレクトリを作成します
| |
最終行にこの行を追加します。これで、/dev/mmcblk0gp3 が /opt/sample にマウントされるようになります。
|
Armadillo の再起動後、 /opt/sample/README の内容が正しければ完了です。 [armadillo]# reboot
:
: (省略)
:
[armadillo]# ls /opt/sample
README
[armadillo]# cat /opt/sample/README
complete mounting squashfs on eMMC(GPP) Armadillo-610 で採用している CPU (i.MX6ULL) には、一度しか書き込むことのできない eFuse が搭載されています。 eFuse には、 CPUがブートする時の設定や MAC アドレスなどが書かれます。Armadillo-610 は組み込み機器を作り込むエンジニアを対象にした製品ですので、 eFuse もユーザーに開放し、細かな制御を可能にしています。しかし eFuse はその性質上、一度書き間違うと直すことができません。十分に注意してください。 | |
---|
eFUSEは一度書き込むと元に戻すことができません。eFUSEの設定によってはArmadillo-610が正常に動作しなくなる可能性がありますので、書き込みを行う際には細心の注意を払うようお願いいたします。eFUSEの設定によって異常が起こった場合は保証対象外となります。 |
MACアドレスは Armadillo-610 の出荷時に書き込まれているので、新たに書き込む必要はありません。この章では U-Boot を使って eFuse の書き換えを行い、ブートモードを制御する方法を説明します。 eFuse を変更する場合は、必ず「i.MX 6ULL Applications Processor Reference Manual」を参照してください。重要な章は、以下の 4つです。 -
Chapter 5: Fusemap
-
Chatper 8: System Boot
-
Chapter 37: On-Chip OTP Controller
-
Chapter 58: Ultra Secured Digital Host Controller
以降、本章では i.MX 6ULL Applications Processor Reference Manual を「リファレンスマニュアル」と呼びます。 | |
---|
章番号や章タイトルは、i.MX 6ULL Applications Processor Reference Manual Rev. 1, 11/2017 現在の情報です。異るリビジョンのリファレンスマニュアルでは、章番号およびタイトルが異なる場合があります。 |
i.MX6ULL にはブートモードを決める BOOT_MODE0 と BOOT_MODE1 というピンがあります。 Armadillo-610 では、BOOT_MODE0 は 0 、BOOT_MODE1 は 1 となるよう回路が設計されており、ブートモードは必ず Internal Boot モードとなります。 10.15.1.1. Internal Boot モードInternal Bootモードでは、 on-chip boot ROMに書き込まれているコードが実行し、ブート可能なデバイスを検索します。リファレンスマニュアル「8.5 Boot devices (internal boot)」に、i.MX6ULL がブートできるデバイスの一覧が記載されています。Armadillo-610 では、そのうちオンボードeMMC と microSDカードに対応しています。 Internal Bootモードでは、GPIO によって eFuseの設定を上書き (override) できるようになっています。この機能は eFuse の BT_FUSE_SEL が 0 の場合のみ有効となります。eFuse の設定とは異なり何度も再設定できる点では便利ですが、overrideに対応したピンには i.MX6ULL の電源投入時に決まった信号を入力しておかなければいけないため、ハードウェア設計上は不便になります。 Armadillo-610では、GPIO による override を利用することで、仕様が確定していない段階ではブートデバイスを自由に何度も切り替えることを可能にしつつ、BT_FUSE_SEL を 1 にして GPIO による override を無効化することで、仕様が確定した段階では自由なハードウェア設計が可能になるよう配慮しています。また、GPIO による override を無効化することで、フィールドに出した製品が悪意ある人によって意図していないブートをし、被害が出ることを防ぐことができます。(もちろん、ブート後に root アカウントを乗っ取られるような作りでは、意味がありませんが…) Internal Bootモードでは、GPIO によって eFuseの設定を上書き (override) できるようになってると紹介しましたが、Armadillo-610 では、Armadillo-610 拡張ボードの JP1 はまさにこの機能を使っています。 JP1 は BJP1(Armadillo-610 CON2_42ピン) に接続されており、 LCD1_DATA05 と LCD1_DATA11 の制御をしていますが、これらのピンはそれぞれ BOOT_CFG1[5] と BOOT_CFG2[3] を override しています。「8.3.2 GPIO boot overrides」の 表「8-3. GPIO override contact assignments」を確認してください。 ややこしい事に、この BOOT_CFG で始まる eFUSE は、リファレンスマニュアルの中では eFuse のアドレスでも表記されています。 BOOT_CFG1 は eFuse のアドレスで言うと 0x450 の下位 8 bit つまり 0x450[7:0] であり、 BOOT_CFG2 は上位 8 bit つまり 0x450[15:8] にあたります。これは「5.1 Boot Fusemap」の表「5-5. SD/eSD Boot Fusemap」または表「5-6. MMC/eMMC Boot Fusemap」を確認することでわかります。 さらにややこしい事に、eFuse を書き込む場合にはこれら全ての値が使えず、On-Chip OTP Controller の bank と word の値が必要になります。これらの値は リファレンスマニュアルの「On-Chip OTP Controller」を参照してください。後で出てきますが Boot From Fuses で使用する BT_FUSE_SEL という eFuse のように GPIO による override ができないものもあります。 表10.8 GPIO override と eFuse 信号名 | eFuse名 | eFuseアドレス | OCOTP名 | Bank | Word |
---|
LCD1_DATA05
| BOOT_CFG1[5]
| 0x450[5]
| OCOTP_CFG4 | 0 | 5 | LCD1_DATA11
| BOOT_CFG2[3]
| 0x450[11]
| OCOTP_CFG4 | 0 | 5 | N/A | BT_FUSE_SEL
| 0x460[4]
| OCOTP_CFG5 | 0 | 6 |
Armadillo-610 ではSDカード または eMMC からのブートになるので、ブートデバイスを選択する eFuse BOOT_CFG1[7:4] は、010x または 011x になります。 リファレンスマニュアル「8.5.3.1 Expansion device eFUSE configuration」には、さらに詳しく SD/MMCデバイスの設定について記載されています。テーブル「8-15. USDHC boot eFUSE descriptions」によれば、eFuse の 0x450[7:6] が 01 の場合に SD/MMC デバイスからブートすることを決めています。さらに 0x450[5] が 0 なら SDが、 0x450[5] が 1 なら MMC が選択されます。つまり、4から 7 bit までの間で 5 bit 目だけが MMC か SD かを決めています。 BOOT_CFG1[5] が 0 の場合はコントローラーは SDデバイスが繋がっている前提で、 BOOT_CFG1[5] が 1 の場合は MMCデバイスが繋っている前提で動作します。 i.MX6ULL には、SD/MMC のコントローラーである uSDHC が 2つ搭載されています。 Armadillo-610では、eMMC が uSDHC1に、 microSDカードが uSDHC2 に接続されています。ブート時にどちらのコントローラーからブートするかを決めている eFuse が 0x450[12:11] です。 0x450[12:11] が 00 であれば uSDHC1 つまりオンボード eMMC から、01 であれば uSDHC2 つまり microSDカードからブートします。言い換えると Armadillo-610 でオンボード eMMC からブートしたい場合は、0x450[5] を 1 に、 0x450[12:11] を 00 にします。逆に microSDカードから起動したい場合は 0x450[5] を 0 に、0x450[12:11] を 01 にします。 表10.9 ブートデバイスと eFuse ブートデバイス | eFuse 0x450[5] | 0x450[12:11] |
---|
オンボード eMMC | 1
| 00
| microSDカード | 0
| 01
|
Armadillo-610 では、U-Boot のコマンドによって eFuseの書き換えをサポートしています。 「スライドスイッチの設定について」 を参照してU-Boot を保守モードで起動してください。 eFuse の書き換えは、 fuse コマンドを使います。 | |
---|
U-Boot の fuse コマンドのソースコードは、以下の 2つです。 -
cmd/fuse.c
-
drivers/misc/mxc_ocotp.c
|
=> help fuse
fuse - Fuse sub-system
Usage:
fuse read <bank> <word> [<cnt>] - read 1 or 'cnt' fuse words,
starting at 'word'
fuse sense <bank> <word> [<cnt>] - sense 1 or 'cnt' fuse words,
starting at 'word'
fuse prog [-y] <bank> <word> <hexval> [<hexval>...] - program 1 or
several fuse words, starting at 'word' (PERMANENT)
fuse override <bank> <word> <hexval> [<hexval>...] - override 1 or
several fuse words, starting at 'word'
=> -
fuse read
-
eFuse の値を Shadow Registerから読み出します。i.MX6ULL の eFuse は、すべて Shadow Register を持ち、起動時に eFuse から Shadow Register に値がコピーされます。詳しくはリファレンスマニュアル「37.3.1.1 Shadow Register Reload」を確認してください。
-
fuse sense
-
eFuse の値を eFuse から読み出します
-
fuse prog
-
eFuse の値を書き換えます
fuse コマンドは、 bank 、 word 、cnt 、 hexval を引数に取ります。
-
bank
-
eFuse のバンク番号
-
word
-
eFuse のワード番号
-
cnt
-
eFuse を読み出す個数
-
hexval
-
書き込む値
10.15.4. eFuse の設定によるブートデバイスの選択eFuse の設定によるブートデバイスの選択を可能にするには、 eFuse に書き込んだ値が正しいことを i.MX6ULL に教える必要があります。そのための eFuse が BT_FUSE_SEL (0x460[4] ) です。Armadillo-610 では、このビットが 1 であれば、GPIO による override が無効になり eFuse の設定にしたがってブートデバイスが選択されるようになります。 10.15.4.2. eMMC からのブートに固定オンボード eMMC からだけブートさせたい場合は、ブートデバイスの種類で MMC と、コントローラーで uSDHC1 を選択することで可能です。忘れずに BT_FUSE_SEL を 1 にします。 オンボード eMMC のスペックは、以下の通りです。リファレンスマニュアル 8.5.3 Expansion device および 表「5-6. MMC/eMMC Boot Fusemap」を確認してください。「可変」列が「不」となっている値は、変更しないでください。例えば、オンボード eMMC は 1.8 V に対応していません。 bit 9 の SD Voltage Selection で 1 の 1.8 V では動作しません。 表10.10 オンボード eMMC のスペック 名前 | Bit | eFuse | 値 | bit列 | 可変 |
---|
BOOT_CFG2
| [15:13]
| Bus Width | 8 bit | 010
| 不 | [12:11]
| Port Select | uSDHC1 | 00
| 不 | [10]
| Boot Frequencies | 500 / 400 MHz | 00
| 可 | [9]
| SD Voltage Selection | 3.3 V | 0
| 不 | [8]
| - | - | 0
| - | BOOT_CFG1
| [7:5]
| eMMC | - | 011
| 不 | [4]
| Fast Boot | Regular | 0
| 可 | [3]
| SD/MMC Speed | High | 0
| 不 | [2]
| Fast Boot Acknowledge Disable | Enabled | 0
| 可 | [1]
| SD Power Cycle Enable | Enabled | 1
| 可 | [0]
| SD Loopback Clock Source Sel | SD Pad | 0
| 不 |
値を見易いように、 BOOT_CFG2 を上にしています。 BOOT_CFG1 と BOOT_CFG2 は、OCOTP_CFG4 にマップされており Bank 0 Word 5 です。つまり 010000000 01100010 の 16 bit (0x4062 ) を Bank 0 Word 5 に書き込めば良いことが分ります。 BOOT_CFG3 と BOOT_CFG4 はここでは無視します。 BT_FUSE_SEL は Bank 0 Word 6 の 4 bit 目になるので 0x10 を書き込みます。
=> fuse read 0 5
Reading bank 0:
Word 0x00000005: 00000000
=> fuse prog 0 5 0x4060
Programming bank 0 word 0x00000005 to 0x00004060...
Warning: Programming fuses is an irreversible operation!
This may brick your system.
Use this command only if you are sure of what you are doing!
Really perform this fuse programming? <y/N>
y
=> fuse read 0 6
Reading bank 0:
Word 0x00000006: 00000000
=> fuse prog -y 0 6 0x10
Programming bank 0 word 0x00000006 to 0x00000010...
=> fuse read 0 6
Reading bank 0:
Word 0x00000006: 00000010
(電源入れなおしても、SDからブートしない) | |
---|
fuse prog にオプション -y を付けると 「 Really perform this fuse programming? <y/N> 」と聞かれません。
|
これで eMMC からしか起動しない Armadillo-610 ができあがりました。 | |
---|
eMMC からしか起動しないので、あやまって eMMCに書き込まれている U-Boot を消してしまうと、二度と起動しないようになります。注意してください。 |
| |
---|
eMMC Fast Boot機能を使う場合や Power Cycle を Enable にする場合は、当該ビットを 1 に変更してください。 |
同じ要領で、SDからだけしかブートしないようにすることも可能です。しかし eFuse によるブートデバイスの固定は、意図しないブートを防ぐことが目的です。 Armadillo-610 で microSDからのブートに固定することは可能ですが、別の microSDカードを挿入されてしまうと、その別の microSDカードからブートしてしまうので目的を達成できません。理解してお使いください。 書き込んだ eFuse の値を変更されてしまっては、Boot From Fuseモードにしている意味がありません。i.MX6ULLでは eFuse を変更できなくするビットも用意されています。 リファレンスマニュアル「5.3 Fusemap Descriptions Table」を確認してください。 | |
| | | |
| |