| | 9.1.1. Podman - コンテナ仮想化ソフトウェア9.1.1.1. Podman - コンテナ仮想化ソフトウェアとはコンテナとはホスト OS 上に展開される仮想的なユーザ空間のことです。
コンテナを使用することで複数の Armadillo-IoT ゲートウェイ G4 でも同一の環境がすぐに再現できます。
ゲスト OS を必要としない仮想化であるため、アプリケーションの起動が素早いという特徴があります。 Podman とはこのようなコンテナを管理するためのソフトウェアであり、使用方法は
コンテナ管理ソフトウェアの 1 つである Docker と互換性があります。 この章では、コンテナ仮想化ソフトウェアの 1 つである Podman の基本的な使い方について説明します。
Armadillo-IoT ゲートウェイ G4 で実行させたいアプリケーションとその実行環境自体を 1 つの Podman イメージとして扱うことで、
複数の Armadillo-IoT ゲートウェイ G4 がある場合でも、全てのポード上で同一の環境を再現させることが可能となります。 この章全体を通して、イメージの公開・共有サービスである Docker Hub から取得した、Alpine Linux のイメージを
使って説明します。 イメージからコンテナを作成するためには、podman run コマンドを実行します。
イメージは Docker Hub から自動的に取得されます。
ここでは、簡単な例として "ls /" コマンドを実行するコンテナを作成します。 "ls /" を実行するだけの "my_container" という名前のコンテナが作成されました。
コンテナが作成されると同時に "ls /" が実行され、その結果が表示されています。
ここで表示されているのは、コンテナ内部の "/" ディレクトリのフォルダの一覧です。 podman run コマンドの詳細は --help オプションで確認できます。 コンテナを作成するためのイメージは、イメージ一覧を表示する 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のイメージから作り直してください。 9.1.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 アーカイブは 「swupdate-mkimageの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 オプションで確認できます。 実行中のコンテナに接続し、コンテナ内で指定したコマンドを実行するには podman exec コマンドを実行します。
podman exec コマンドでコンテナ内部のシェルを起動すると、コンテナ内部を操作できるようになります。ここでは、cat コマンドを
実行して入力を待ち続けるだけのコンテナを作成し、そのコンテナに対して podman exec コマンドでシェルを起動する例を示します。 podman run コマンドでコンテナを作成し、その後作成したコンテナ内で /bin/sh を実行しています。
/bin/sh を実行すると、コンテナ内のプロンプトが表示されコンテナ内部を操作できるようになります。
上記ではコンテナ内で、ps コマンドを実行しています。コンテナ作成時に実行した cat と podman exec で実行した
/bin/sh がプロセスとして存在していることが確認できます。 コンテナ内のシェルから抜ける時は exit コマンドを実行します。 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) への通信が確認できます。 9.1.2.12. 開発時に有用な--privilegedオプションコンテナに、全権限と全てのデバイスへのアクセスを許可するオプション --privileged があります。このオプションを利用すると、コンテナに与えるべき最小の権限を洗い出す必要が無いため、開発時に有用です。 実運用の際、このオプションを利用することはセキュリティー上問題がある為、開発時にのみご利用ください。コンテナに必要な最低限の権限を与えることをおすすめします。 9.1.3. アットマークテクノが提供するイメージを使うアットマークテクノは、動作確認環境として使用できる Debian ベースのイメージを提供しています。
ここでは、Docker ファイルからイメージをビルドする方法と、すでにビルド済みのイメージを使う方法の 2 つについて説明します。 9.1.3.1. Docker ファイルからイメージをビルドするArmadillo-IoT ゲートウェイ G4 コンテナ から
「Debian [VERSION] サンプル Dockerfile」 ファイル (at-debian-image-dockerfile-[VERSION].tar.gz) をダウンロードします。
その後 podman build コマンドを実行します。 podman images コマンドにより at-debian-image がビルドされたことが確認できます。
library/debian イメージはベースとなっている Debian イメージです。 Armadillo-IoT ゲートウェイ G4 コンテナ から
「Debian [VERSION] サンプルコンテナイメージ」 ファイル (at-debian-image-[VERSION].tar) をダウンロードします。
その後 podman load コマンドを実行します。 podman images コマンドにより at-debian-image がビルドされたことが確認できます。 この章では、コンテナ内で動作するアプリケーションから GPIO や I2C などの入出力デバイスを扱う方法について示します。
基本的に、コンテナ内のアプリケーションからホスト OS 側のデバイスへアクセスすることはできません。
このため、コンテナ内のアプリケーションからデバイスを扱うためには、コンテナ作成時に扱いたいデバイスを指定する必要があります。
ここで示す方法は、扱いたいデバイスに関するデバイスツリーファイルが適切に設定されていることを前提としています。
デバイスツリーファイルを設定していない場合は、適切に設定してください。 コンテナ内で動作するアプリケーションから GPIO を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/gpiochipN を渡す必要があります。以下は、/dev/gpiochip2 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入ってコマンドで GPIO を操作する例を以下に示します。 
|
GPIO 番号 21 の値を取得します。
| 
|
取得した値を表示します。
| 
|
GPIO 番号 21 に 1(High) を設定します。
|
C 言語プログラムから操作する場合は、GPIO 操作ライブラリである libgpiod を使用することができます。 コンテナ内で動作するアプリケーションから I2C を扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/i2c-N を渡す必要があります。以下は、/dev/i2c-1 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、i2c-tools に含まれる i2cdetect コマンドを使ってスレーブアドレスを確認することができます。 ![[ティップ]](images/tip.png) | |
|---|
自動起動の場合はdevicesの設定でi2c-1を渡すことができます。 [armadillo ~]# vi /etc/atmark/containers/i2c_example.conf
image=localhost/i2c_example_image
devices="/dev/i2c-1"
set_command /root/do_something_with_i2c.sh |
コンテナ内で動作するアプリケーションから 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/pwmchip2 を扱う場合の動作設定例を示します。 |
pwmchip2 を export します。
| |
周期を 1 秒にします。単位はナノ秒です。
| |
PWM の ON 時間 を 0.5 秒にします。
| |
PWM 出力を有効にします。
|
コンテナ内で動作するアプリケーションから RS-232C や RS-485 などのシリアル通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN を渡す必要があります。
以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、setserial コマンドを使って現在の設定を確認することができます。 コンテナ内で動作するアプリケーションから USB 接続のデバイスを扱うための方法について示します。 USB シリアルデバイスをコンテナ内から扱う場合には、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev/ttyUSBN を渡す必要があります。
以下は、 /dev/ttyUSB0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入り、setserial コマンドを使って現在の設定を確認することができます。 USB カメラをコンテナ内から扱う場合には、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev/videoN を渡す必要があります。
以下は、 /dev/video3 を渡して 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 と SYS_RAWIO も渡しています。 コンテナ内に入り、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-IoT ゲートウェイ G4 に接続したスピーカーなどの音声出力デバイスへコンテナ内から音声を出力するためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/snd を渡す必要があります。
以下は、/dev/snd を渡して debian イメージからコンテナを作成する例です。 コンテナ内に入り、alsa-utils などのソフトウェアで音声出力を行えます。 |
alsa-utils をインストールします。
| |
alsa-utils を起動します。
| |
指定したファイル名の音声ファイルを再生します。
|
aplay の引数にある、M は音声を出力したい CARD 番号、N はデバイス番号を表しています。
CARD 番号とデバイス番号は、aplay コマンドに -l オプションを与えることで確認できます。 9.1.4.10. ユーザースイッチのイベントを取得するArmadillo-IoT ゲートウェイ G4 にはユーザースイッチが実装されています。これらのスイッチのプッシュ/リリースイベントを取得するためには、
Podman のイメージからコンテナを作成する際にホスト OS 側の /dev/input ディレクトリを渡す必要があります。
以下は、/dev/input を渡して alpine イメージからコンテナを作成する例です。ここで渡された /dev/input ディレクトリは
コンテナ内の /dev/input にマウントされます。 コンテナ内に入り、evtest コマンドでイベントを確認できます。 |
SW1のボタン プッシュ イベントを検出したときの表示
| |
SW1のボタン リリース イベントを検出したときの表示
|
Armadillo-IoT ゲートウェイ G4 には LED が実装されています。これらの LED を扱うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側の /sys ディレクトリを渡す必要があります。
以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリは
コンテナ内の /sys にマウントされます。 コンテナ内に入り、brightness ファイルに値を書き込むことで LED の点灯/消灯を行うことができます。
0 を書き込むと消灯、0 以外の値 (1〜255) を書き込むと点灯します。 この章では、コンテナ内から近距離通信デバイスを扱う方法について示します。 9.1.5.1. Bluetooth デバイスを扱うコンテナ内から Bluetooth デバイスを扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/ttymxcN を渡すと同時にネットワークとして host を、権限として NET_ADMIN を渡す必要があります。
/dev/ttymxcN は Bluetooth 通信で使用するように設定したシリアルデバイスを指定してください。
以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内で必要なソフトウェアをインストールして、Bluetooth を起動します。
btattach コマンドの引数にはコンテナ作成時に渡した ttymxc を設定してください。 これにより、bluetoothctl で Bluetooth 機器のスキャンやペアリングなどが行えるようになります。
以下に、bluetoothctl コマンドで周辺機器をスキャンしてペアリングを行う例を示します。 |
コントローラを起動します。
| |
周辺機器をスキャンします。
| |
ペアリングしたい機器の MAC アドレスを指定してペアリングします。
| |
exit で bluetoothctl のプロンプトを終了します。
|
ここでは、Wi-SUN デバイスが UART で接続されている場合の例を示します。
この場合、コンテナ内で動作するアプリケーションから Wi-SUN デバイスで通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN のうち、
Wi-SUN と対応するものを渡す必要があります。
以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内から、/dev/ttymxc0 を使って Wi-SUN データの送受信ができるようになります。 ここでは、EnOcean デバイスが UART で接続されている場合の例を示します。
この場合、コンテナ内で動作するアプリケーションから EnOcean デバイスで通信を行うためには、
Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/ttymxcN のうち、
EnOcean と対応するものを渡す必要があります。
以下は、/dev/ttymxc0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内から、/dev/ttymxc0 を使って EnOcean データの送受信ができるようになります。 この章では、コンテナ内のネットワークを扱う方法について示します。 9.1.6.1. コンテナの IP アドレスを確認する基本的にコンテナの IP アドレスは Podman イメージからコンテナを作成したときに自動的に割り振られます。
コンテナに割り振られている IP アドレスはホスト OS 側からは podman inspect コマンドを用いて、以下のように確認することができます。 コンテナ内の ip コマンドを用いて確認することもできます。 9.1.6.2. コンテナに固定 IP アドレスを設定する![[警告]](images/warning.png) | |
|---|
podman はデフォルトで 10.88.0.0/16 を使います。 他に使用しているIPアドレスと被った場合等はコンテナに別のIPアドレスを設定してください。 |
コンテナに固定 IP アドレスを設定するためには、最初にユーザ定義のネットワークを作成する必要があります。
以下に 192.168.1.0/24 にユーザ定義のネットワークを作成する例を示します。 コンテナを作成する際に、上記で作成したネットワークと設定したい IP アドレスを渡すことで、
コンテナの IP アドレスを固定することができます。
以下の例では、IPアドレスを 192.168.1.10 に固定します。 コンテナの IP アドレスが、192.168.1.10 に設定されていることが確認できます。 | |
|---|
Armadillo-IoT ゲートウェイ G4 を再起動したときにネットワークの設定ファイルが消えてしまわないように、 /etc/atmark/containers に設定する必要があります [armadillo ~]# vi /etc/atmark/containers/my_network.conf
type=network
subnet=192.168.1.0/24
[armadillo ~]# persist_file /etc/atmark/containers/my_network.conf |
この章では、コンテナ内で様々なサーバを構築する方法について示します。
この章で取り上げているサーバは 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 のプロンプトが表示され
データベースの操作ができるようになります。 この章では、コンテナ内におけるセキュリティの確保の方法について示します。 9.1.8.1. iptables コマンドを使用するコンテナ内から、iptables コマンドを使用してパケットフィルタリングを行うためには、
コンテナを作成する際に、権限として NET_ADMIN と NET_RAW を渡す必要があります。
以下は、権限を渡して alpine イメージからコンテナを作成する例です。 以下に、iptables を使用した例を示します。 この章では、コンテナ内で動作するアプリケーションから Armadillo-IoT ゲートウェイ G4 に接続されたディスプレイに
出力を行う方法について示します。 コンテナ内から、Wayland のコンポジタである weston を起動し画面表示を行う例を示します。
ここではアットマークテクノが提供するイメージからコンテナを作成します。
このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。
また、「VPU や NPU を使用する」 を実施済みであるとします。 |
weston の実行に必要な環境変数を設定します。
| |
必要なライブラリをロードするためのパスを設定します。
| |
画面描画に必要なデバイスを設定します。
| |
画面描画に必要なデバイスを設定します。
| 
|
キーボードやマウスなどを使用可能にするためのデバイスを設定します。
| 
|
weston に必要な tty を設定します。
| 
|
ホスト OS 側の /run/udev をコンテナ内からマウントするように設定します。
| 
|
ホスト OS 側の /opt/firmware をコンテナ内からマウントするように設定します。
| 
|
tty を操作するための権限を設定します。
|
次に、以下のように weston を起動します。オプションである --tty に設定する値は、
コンテナ作成時に渡した tty の数字にします。 Armadillo-IoT ゲートウェイ G4 に接続しているディスプレイ上に、デスクトップ画面が表示されます。 アットマークテクノが提供するイメージでは、weston の設定ファイルは
/etc/xdg/weston/weston.ini に配置してあります。 | |
|---|
運用の時に一つのコンテナでwestonを起動して、
XDG_RUNTIME_DIRを共有することで別のコンテナでwestonを使用する
アプリケーションを起動させることができます。 [armadillo ~]# vi /etc/atmark/containers/weston.conf
image=localhost/at-debian-image:latest
devices="/dev/dri /dev/galcore /dev/input /dev/tty1"
volumes="/run/udev:/run/udev:ro /opt/firmware:/opt/firmware:ro""
volumes="$volumes xdg_home:/run/xdg_home"
append_args --env=XDG_RUNTIME_DIR=/run/xdg_home
append_args --env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu
append_args --cap-add=SYS_TTY_CONFIG
set_command weston --tty 1
[armadillo ~]# vi /etc/atmark/containers/detect_object.conf
image=localhost/at-debian-image:latest
devices="/dev/galcore /dev/video3"
volumes="/opt/firmware:/opt/firmware:ro xdg_home:/run/xdg_home"
restart=always
append_args --env=XDG_RUNTIME_DIR=/run/xdg_home
append_args --env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu
set_command /root/start_detect_object.sh
[armadillo ~]# podman_start weston
[armadillo ~]# podman_start detect_object |
westonの設定ファイルを作成します。
| |
XDG_RUNTIME_DIR を volume で共有して、同じディレクトリを使います。
| |
例としてdetect_objectという名前のクライアントの設定ファイルを作成します。ここでは任意の名前を設定できます。
| |
アプリケーションによっては、westonが異常終了した時にエラーを出力しない場合があるため、restart=always にします。
| |
確認のためコンテナを手動で起動します。
|
|
9.1.9.2. X Window System を扱うコンテナ内から、X Window System を起動し画面表示を行う例を示します。
ここではアットマークテクノが提供するイメージからコンテナを作成します。
このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。
また、「VPU や NPU を使用する」 を実施済みであるとします。 |
必要なライブラリをロードするためのパスを設定します。
| |
X Window System に必要な tty を設定します。どこからも使われていない tty とします。
| |
画面描画先となるフレームバッファを設定します。
| |
キーボードやマウスなどを使用可能にするためのデバイスを設定します。
| |
ホスト OS 側の /run/udev をコンテナ内からマウントするように設定します。
| |
X Window System の動作に必要な権限を設定します。
|
次に、以下のように X Window System を起動します。
オプションである vt に設定する値は、コンテナ作成時に渡した tty の数字にします。 Armadillo-IoT ゲートウェイ G4 に接続しているディスプレイ上に、デスクトップ画面が表示されます。 コンテナ内で動作するアプリケーションからフレームバッファに直接描画するためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/fbN を渡す必要があります。以下は、/dev/fb0 を渡して alpine イメージからコンテナを作成する例です。 コンテナ内に入って、ランダムデータをフレームバッファに描画する例を以下に示します。
これにより、接続しているディスプレイ上の表示が変化します。 タッチパネルが組み込まれているディスプレイを接続している環境で、
コンテナ内からタッチイベントを取得するためには、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /dev/input を渡す必要があります。 Wayland などの GUI 環境と組み合わせて使うことで、タッチパネルを利用した GUI アプリケーションの操作が可能となります。 Armadillo-IoT ゲートウェイ G4 で採用している i.MX 8M Plus には、動画のエンコード/デコード処理に特化した演算ユニットである
VPU (Video Processing Unit) が搭載されています。
VPU を活用することでシステム全体のパフォーマンスを落とすことなく、動画のエンコード/デコード処理を行うことができます。
コンテナ内で動作するアプリケーションから VPU を扱うためには、コンテナ作成時にデバイスとして、
/dev/mxc_hantro と /dev/mxc_hantro_vc8000e および /dev/ion を渡す必要があります。
ここではアットマークテクノが提供するイメージからコンテナを作成します。
このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。
また、「VPU や NPU を使用する」 を実施済みであるとします。 weston と GStreamer がインストール済みのイメージと組み合わせて使うことで、
VPU を使用して動画のエンコード/デコードを行うことができます。 このようにして作成したコンテナにログインすると、
GStreamer で VPU を使用した動画のエンコード/デコードが行なえます。 USB カメラも組み合わせると、カメラからの映像をエンコードしてファイルに保存することも可能です。 上記を実行することで、USB カメラからの映像が H.264 にエンコードされてファイルに保存されます。 この章では、コンテナ内からパワーマネジメント機能を使う方法について示します。 パワーマネジメント機能を使ってサスペンド状態にするには、Podman のイメージからコンテナを作成する際に
ホスト OS 側の /sys ディレクトリを渡す必要があります。
以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリは
コンテナ内の /sys にマウントされます。 コンテナ内から、/sys/power/state に次の文字列を書き込むことにより、サスペンド状態にすることができます。 表9.1 対応するパワーマネジメント状態 | パワーマネジメント状態 | 文字列 | 説明 |
|---|
Suspend-to-RAM
| mem
| 最も消費電力を抑えることができる | Suspend-to-Idle
| freeze
| 最も短時間で復帰することができる |
サスペンド状態から起床要因として、利用可能なデバイスを以下に示します。 -
UART2 (console)
-
起床要因
-
データ受信
-
有効化
[container ~]# echo enabled > /sys/bus/platform/drivers/imx-uart/30890000.serial/tty/ttymxc1/power/wakeup
-
USB
-
起床要因
-
USBデバイスの挿抜
-
有効化
[container ~]# echo enabled > /sys/bus/platform/devices/32f10108.usb/power/wakeup
-
RTC(i.MX8MP)
-
ユーザースイッチ
-
起床要因
-
ユーザースイッチ押下
-
有効化
[container ~]# echo enabled > /sys/bus/platform/drivers/gpio-keys/gpio-keys/power/wakeup
9.1.11. コンテナからのpoweroffかrebootArmadillo Base OSはbusybox initでshutdownとrebootを対応します。 busybox initでPID 1にsignalを送ることでshutdownやrebootとなります。
コンテナからsignalを送るように、pid namespaceを共有する必要がありますが、共有されたらkillで実行できます。 この章では、コンテナ内で動作しているアプリケーションに何らかの異常が発生し停止してしまった際に、
ソフトウェアウォッチドックタイマーを使って、システムを再起動する方法について示します。 9.1.12.1. ソフトウェアウォッチドッグタイマーを扱うコンテナ内で動作するアプリケーションからソフトウェアウォッチドックタイマーを扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側の
デバイスファイル /dev/watchdogN を渡す必要があります。以下は、/dev/watchdog0 を渡して alpine イメージからコンテナを作成する例です。 ソフトウェアウォッチドックタイマーは、プログラム内からデバイスファイル /dev/watchdog0 を open した時点で起動します。
コンテナ内に入ってソフトウェアウォッチドックタイマーを echo コマンドで起動する例を以下に示します。 ソフトウェアウォッチドックタイマーを起動した後、/dev/watchdog0 に任意の文字を書き込むことで
ソフトウェアウォッチドッグタイマーをリセットすることができます。
60 秒間任意の文字の書き込みがない場合は、システムが再起動します。 ソフトウェアウォッチドックタイマーを停止したい場合は、/dev/watchdog0 に V を書き込みます。 Armadillo-IoT ゲートウェイ G4 で採用している i.MX 8M Plus には、機械学習に特化した演算処理ユニットである
NPU (Neural Processor Unit) が搭載されています。
NPU を活用することで、顔認識や物体認識などの推論処理を高速に行うことができます。
コンテナ内で動作するアプリケーションから NPU を扱うためには、コンテナ作成時にデバイスとして、
/dev/galcore を渡す必要があります。以下は、/dev/galcore を渡して アットマークテクノが提供する
イメージからコンテナを作成する例です。
このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。 具体的な機械学習アプリケーションの開発方法については、NXP Semiconductors の公式サイトを参照してください。 Armadillo Base OSでは、/etc/atmark/containers/*.confファイルに指定されているコンテナがブート時に自動的に起動します。
nginx.confの記載例を以下に示します。 .conf ファイルは以下のパラメータを設定できます。
image: コンテナイメージの名前。
*例*：image=docker.io/debian:latest, image=localhost/myimage
ports: TCPを行うポート。スペースで分けて複数設定することができます。
以下の例では、ポート80、443(web)にアクセスすることができ、コンテナのポート22(ssh)にはポート2222からアクセスすることができます。
*例*：ports="80:80 443:443 2222:22" | |
|---|
pod を使う場合、このオプションはpodの設定にしないと有効になりませんのでご注意ください。 |
devices: podman run の --device オプションで、必要なデバイスファイルのアクセス許可の設定
--device オプションに「:」を使うことでコンテナ内のパスを設定することができます。
*例*：devices="/dev/galcore /dev/v4l/by-id/usb-046d_HD_Pro_Webcam_C920_78DA8CAF-video-index0:/dev/video3" デバイスのパスに「:」を含むようなパスは設定できません。 | |
|---|
デバイスのパスに「：」がある場合、シンボリックリンクを作成すると使えます。
以下の行をコンフィグファイルに記載すると、複雑なパスでも使えます。 cp -sf /dev/v4l/by-path/platform-xhci-hcd.1.auto-usb-0:1:1.0-video-index0 /tmp/video
devices=/tmp/video:/dev/video0 |
volumes: podman run の --volume オプションで、ファイルの保存ができる場所を設定できます。
設定できる場所は以下のどちらかを指定してください。
/var/app/rollback/volumes/<folder> か <folder>:
アップデートの際に新しくコピー（snapshot）した場合、コピー先のみ変更しますので、
アップデート中でもこのデータを使うことができます。
途中で電源が落ちた場合でも、このデータに影響はありません。 SWUpdateでアップデートするデータに向いています。
/var/app/volumes/<folder>: appパーティションに書きます。
アップデートの際にコピーされませんので、アップデート中の新たな変更は
更新されたコンテナ内のアプリケーションで見れます。 ログやデータベースに向いています。
「:」はホスト側のパスとコンテナのパスを別ける意味があるため、ファイル名やデバイス名に「：」を使うことはできません。さらに最後に「:ro」を追加すると read-only にマウントされます。 *例*：`volumes="/var/app/volumes/database:/database assets:/assets:ro"`：ロールバックされないデータを/databaseで保存でき、アプリリケーションのデータを/assetsで使えます。
pod: コンテナを設定された pod の中に起動します。
「podの作成」で作成した pod の名前を入れます。 例: pod=mypod
network: ネットワークを選択することができます。
この設定に「networkの作成」で作成したネットワーク以外に none と host の特殊な設定も選べます。 none の場合、コンテナに localhost しかないネームスペースに入ります。
host の場合はOSのネームスペースをそのまま使います。
例: network=mynetwork
ip: コンテナの IP アドレスを設定します。
例: ip=10.88.0.100 | |
|---|
コンテナ間の接続が目的であれば、podを使ってlocalhostかpodの名前でアクセスすることができます。 |
readonly: podman run の --read-only オプション、コンテナのイメージを変更できないようにマウントさせます。
デフォルトで有効となっており、falseにするとtmpfsのoverlayが作成されます。 *例*：readonly=false
pull: イメージがなかったら、ダウンロードする許可の設定。 podman run の --pull オプションです。
デフォルトで never になっています。 *例*：pull=missing か pull=always
restart: コンテナが停止する時にリスタートさせます。
podman killかpodman stopで停止する場合、この設定と関係なくリスタートしません。 デフォルトで on-failure になっています。 例: restart=always か restart=no
autostart: 起動時に起動させたくない場合、 autostart=no を設定してください。
手動か別の手段で操るコンテナがあったら podman_start <name> で起動させることができます。 | |
|---|
コンフィグに記載していないイメージはアップデートの際に削除されますので、そういったイメージに対して設定してください。 |
set_command: コンテナを起動するときのコマンド。設定されなかった場合、コンテナイメージのデフォルトを使います。
*例*：set_command /bin/sh -c "echo bad example"
append_args: 他の podman run のオプションを実行できます。
*例*：append_args --privileged --restart=always
podman_start で pod 機能を使うことができます。
pod を使うことで、複数のコンテナが同じネットワークネームスペースを共有することができます。
同じ pod の中のコンテナが IP の場合 localhost で、 unix socket の場合 abstract path で相互に接続することができます。
コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 type=pod を設定することで pod を作成します。 pod を使う時にコンテナの設定ファイルに pod=[NAME] の設定を追加します。 ネットワークネームスペースは pod を作成するときに必要なため、 ports, network と ip の設定は pod
のコンフィグファイルに入れなければなりません。 ネットワーク設定の他に、 infra_image のオプションで pod のイメージも固める事ができます。 必要であれば、他の podman pod create のオプションを append_args で設定することができます。 | |
|---|
pod を使う時に podman が特殊な「infra container」も起動します（例の場合、 k8s.gcr.io/pause:3.5 を起動させました） コンフィグレーションに pod を入れるアップデートの際に自動的に podman pull でイメージをダウンロードしますが、
インターネットを使わせたくないアップデートがあれば swdesc_embed_container か swdesc_usb_container で入れてください。
その場合、 infra_image の設定も使ってください。 |
podman_start で podman の network も作成ことができます。
デフォールトの 10.88.0.0/16 が使えない場合、あるいはコンテナ同士で接続できないようにしたい場合は使ってください。 コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 type=network を設定することで network を作成します。 そのネットワークを使う時にコンテナの設定ファイルに network=[NAME] の設定をいれます。 ネットワークのサブネットは subnet=[SUBNET] で設定します。 他の podman network create のオプションが必要であれば、 append_args で設定することができます。 コンテナのイメージを配布する方法は大きく分けて二つあります： -
インターネット上のリポジトリ（dockerhub等）で登録してそこから配布する
-
SWUpdateのアップデートイメージを配布する
| |
|---|
Podmanのイメージをインストールする時に、一時データを大量に保存する必要があります。 swuイメージ内で組み込む時は3倍、pullやUSBドライブで分けてインストールすると転送するデータ量の2倍の空き容量がappパーティションに必要です。 アップデート時にアップデート前のコンテナが使われているのでご注意ください。 |
9.2.4.1. リモートリポジトリにコンテナを送信する方法
イメージをリモートリポジトリに送信する：
[armadillo ~]$ podman image push <localimage> docker://<registry>/<remoteimage>:<tag>
pull=alwaysを設定しないかぎり、SWUpdateでダウンロードの命令を送らないとアップデートを行いません。
（swupdate-mkimageについては「Armadilloのソフトウェアをアップデートする」を参考にしてください） [armadillo ~]$ cd swupdate-mkimage
[armadillo ~/swupdate-mkimage]$ cat examples/pull_container_nginx.desc
swdesc_pull_container "docker.io/nginx:alpine" --version container_nginx 1
[armadillo ~/swupdate-mkimage]$ ./mkimage.sh -o pull_container_nginx.swu examples/pull_container_nginx.desc
...
24 blocks
9.2.4.2. イメージをファイルで保存する方法
イメージをファイルに保存する：
[armadillo ~]$ podman image save -o <myimage>.tar <localimage>
ファイルをSWUpdateのイメージに入れる。
二つのやり方があります：
swuイメージ内に組み込む
[armadillo ~]$ cd swupdate-mkimage
[armadillo ~/swupdate-mkimage]$ cat examples/embed_container_nginx.desc
swdesc_embed_container "nginx_alpine.tar" --version container_nginx 1
[armadillo ~/swupdate-mkimage]$ ./mkimage.sh -o embed_container_nginx.swu examples/embed_container_nginx.desc
...
15465 blocks
USBドライブに保存する
[armadillo ~]$ cd swupdate-mkimage
[armadillo ~/swupdate-mkimage]$ cat examples/usb_container_nginx.desc
swdesc_usb_container "nginx_alpine.tar" --version container_nginx 1
[armadillo ~/swupdate-mkimage]$ ./mkimage.sh -o usb_container_nginx.swu examples/usb_container_nginx.desc
...
Copy usb_container_nginx/nginx_alpine.tar and nginx_alpine.tar.sig to USB drive along with usb_container_nginx.swu
...
24 blocks
9.3.1. GStreamer - マルチメディアフレームワーク9.3.1.1. GStreamer - マルチメディアフレームワークとはGStreamer は、オープンソースのマルチメディアフレームワークです。小さなコアライブラリに様々
な機能をプラグインとして追加できるようになっており、多彩な形式のデータを扱うことができます。
GStreamer で扱うことができるデータフォーマットの一例を下記に示します。 -
コンテナフォーマット: mp4, avi, mpeg-ps/ts, mkv/webm, ogg
-
動画コーデック: H.264/AVC, VP8, VP9
-
音声コーデック: AAC, MP3, Theora, wav
-
画像フォーマット: JPEG, PNG, BMP
-
ストリーミング: http, rtp
GStreamer では、マルチメディアデータをストリームとして扱います。
ストリームを流すパイプラインの中に、エレメントと呼ばれる処理単位を格納し、
それらを繋ぎ合わせることで、デコードやエンコードなどの処理を行います。 9.3.2. GStreamer 実行用コンテナを作成するこの章における GStreamer の実行例はアットマークテクノが提供する
debian イメージから作成したコンテナ内で実行することを想定しています。
「VPU や NPU を使用する」 を実施済みの環境で、以下のようにコンテナを作成します。 次に、コンテナにログインし画面表示を行うためのデスクトップ環境を起動します。
ここでは weston を起動します。 --tty=1 のオプションは画面表示に使用する tty の値を設定してください。 次に、音声を出力するのに必要な pulseaudio を起動します。 以上により、GSreamer をコンテナ内で実行できるようになります。 9.3.3. GStreamer パイプラインの実行例パイプラインの実行例を以下に示します。 GStreamer のパイプラインは、シェルスクリプトのパイプ構文の構造に似ています。GStreamer の
各エレメントとシェルスクリプト内のコマンドを対比することができます。構文的な違いとして、
GStreamer のパイプラインは「!」を使って各エレメントを繋ぎますが、シェルスクリプトは「|」を使います。 上記例は、GStreamer のデバッグ/プロトタイピング用のコマンドラインツールである gst-launch-1.0
を使って説明しましたが、GStreamer はライブラリとして提供されているため、GStreamer を使った
マルチメディア機能を自作のアプリケーションプログラムに組み込むことができます。API や
アプリケーション開発マニュアルは、gstreamer.freedesktop.org の Documentation ページ
(http://gstreamer.freedesktop.org/documentation/)から参照することができます。 Armadillo-IoT ゲートウェイ G4が採用している SoC である i.MX 8M Plus は、動画のデコード/エンコードを行うための Video Processing Unit(VPU) と呼ばれる
専用プロセッサを搭載しています。Armadillo-IoT ゲートウェイ G4には、この VPU を使用するための GStreamer エレメントがインストールされており、
以下の動画コーデックではメイン CPU のパフォーマンスを落とすことなく動画のデコード/エンコードが行なえます。
デコード可能なコーデック
エンコード可能なコーデック
以降の章では、これらのコーデックに対する GStreamer の実行例を紹介します。 上記で挙げたコーデック以外のものであってもデコード/エンコードは可能ですが、その場合は CPU を使ったソフトウェア処理となってしまうため、
システム全体のパフォーマンスは低下します。 GStreamer を使用して動画を再生するための実行例を、音声を含んでいる動画と含んでいない動画の 2 通りについて示します。
VPU でハードウェアデコードを行う GStreamer エレメントとして vpudec を使うことができます。 9.3.4.1. H.264/AVC 動画を再生するGStreamer を使用してネットワーク上にある動画ファイルを HTTP 及び RTSP でストリーミング再生する実行例を示します。
VPU でハードウェアデコードを行う GStreamer エレメントとして vpudec を使うことができます。 GStreamer の v4l2src エレメントを使うことで、V4L2(Video for Linux 2) デバイスとして実装されているカメラデバイスから映像を取得できます。
どのデバイスから映像を取得するかは、v4l2src エレメントの device プロパティにデバイスファイル名を指定することで変更できます。
UVC 対応 USB カメラなども同様に v4l2src で扱うことができるので、ここでは USB カメラからの映像を表示する実行例を示します。 加えて、カメラの他にマイクも接続していて、同時にマイクからの音声も出力する場合の例も示しています。
実行例中のデバイスファイル /dev/video1 の部分や、縦横サイズである width や height の値は実行する環境によって異なる可能性がありますので、適宜変更してください。
また、/dev/v4l/by-id ディレクトリの下に、接続しているカメラ名の付いた /dev/videoN へのシンボリックリンクがありますので、デバイスとしてそれを指定することも可能です。 GStreamer の v4l2src エレメントを使うことで、V4L2(Video for Linux 2) デバイスとして実装されているカメラデバイスから映像を取得できます。
どのデバイスから映像を取得するかは、v4l2src エレメントの device プロパティにデバイスファイル名を指定することで変更できます。
UVC 対応 USB カメラなども同様に v4l2src で扱うことができるので、ここでは USB カメラからの映像をファイルへ保存する実行例と、
映像を表示しながら同時にファイルへ保存する実行例を示します。 加えて、カメラの他にマイクも接続していて、映像の保存と同時にマイクからの音声も MP3 へエンコードして保存する場合の例も示しています。
実行例中のデバイスファイル /dev/video1 の部分や、縦横サイズである width や height の値は実行する環境によって異なる可能性がありますので、適宜変更してください。
また、/dev/v4l/by-id ディレクトリの下に、接続しているカメラ名の付いた /dev/videoN へのシンボリックリンクがありますので、デバイスとしてそれを指定することも可能です。 パイプライン停止時に EOS イベントを発行するように、gst-launch-1.0 コマンドに-e オプションを付けています。
エンコードを終了するには、Ctrl-C で gst-launch-1.0 コマンドを停止してください。 VPU でハードウェアエンコードを行う GStreamer エレメントとして vpuenc_h264 を使うことができます。 9.3.8. Video Processing Unit(VPU)9.3.8.1. Video Processing Unit とはVideo Processing Unit(以下、VPU) とは i.MX 8M Plus に搭載されている、動画のエンコード/デコード処理専用のプロセッサです。
動画のエンコード/デコード処理は、システムに負荷をかけることが多く、メイン CPU で処理を行うとシステム全体のパフォーマンスが低下します。
VPU を利用することでシステム全体のパフォーマンスを落とすことなく、動画のエンコード/デコード処理を行うことができます。 VPU が対応しているフォーマットは以下の通りです。
デコーダーが対応しているフォーマット
エンコーダが対応しているフォーマット
表9.2 H.264/AVC デコーダー仕様 Profile | High、Main、Baseline | Min resolution | 48x48 | Max resolution | 1920x1080 | Frame rate | 60 fps | Bitrate | 60 Mbps |
表9.3 VP8 デコーダー仕様 Profile | - | Min resolution | 48x48 | Max resolution | 1920x1080 | Frame rate | 60 fps | Bitrate | 60 Mbps |
表9.4 VP9 デコーダー仕様 Profile | Profile 0, 2 | Min resolution | 72x72 | Max resolution | 1920x1080 | Frame rate | 60 fps | Bitrate | 100 Mbps |
表9.5 H.264/AVC エンコーダー仕様 Profiles | Baseline、Main、High、High 10 | Maximum Luma pixel sample rate | 1920x1080 @ 60 fps | Slices | I, P and B slices | Frame Types | Progressive | Entropy encoding | CABAC、CAVLC | Error resilience | Slices | Maximum MV range | Horizontal (P slice) in pixels: +/-139
Horizontal (B slice) in pixels: +/-75
Vertical (P or B slice) in pixels:
-
Config1: +/-13 (planned)
-
Config2: +/-21
-
Config3: +/-29 (planned)
-
Config4: +/-45 (planned)
-
Config5: +/-61 (planned)
(= Search Window Size -3 pixels) | MV accuracy | 1/4 pixel | Supported block sizes | Macroblock and sub-macroblock partitions:
-
Intra PU: 16x16 / 8x8 / 4x4
-
Inter PU: 16x16 / 8x16 / 16x8
-
TU: 4x4 and 8x8 transforms
| Intra-prediction modes | 16x16: 4 modes
8x8: 9 modes
4x4: 9 modes | Maximum number of reference frames | 2 | Encoding picture type | Only progressive frame | IPCM encoding | Supported | Temporal scalable video coding | Up to 5 layers including the base layer | IPCM | IPCM rectangle mode | ROI / ROI_map | Absolute QP and qpoffset mode (-32 〜 31)
User controllable CU coded as IPCM CU or skip CU |
9.4. Armadilloのソフトウェアをビルドするここでは、Armadillo-IoT ゲートウェイ G4で使用するソフトウェアのビルド方法を説明します。
ブートローダーのビルドに必要なパッケージのインストール
次のコマンドを実行します。 [PC ~]$ sudo apt install build-essential git wget gcc-aarch64-linux-gnu libgcc-*-dev-arm64-cross bison flex zlib1g-dev bash python3-pycryptodome python3-pyelftools device-tree-compiler
Linuxカーネルのビルドに必要なパッケージのインストール
次のコマンドを実行します。 [PC ~]$ sudo apt install crossbuild-essential-arm64 bison flex python3-pycryptodome python3-pyelftools zlib1g-dev libssl-dev bc firmware-misc-nonfree firmware-libertas firmware-atheros wireless-regdb
ルートファイルシステムのビルドに必要な Docker のインストール
次のコマンドを実行します。 [PC ~]$ sudo apt install docker.io
ここでは、Armadillo-IoT ゲートウェイ G4向けのブートローダーイメージをビルドする方法を説明します。
ソースコードの取得
Armadillo-IoT ゲートウェイ G4 ブートローダー から
「ブートローダー ソース」ファイル (imx-boot-[VERSION].tar.gz) をダウンロードして、次のコマンドを実行します。 [PC ~]$ tar xf imx-boot-[VERSION].tar.gz
[PC ~]$ cd imx-boot-[VERSION]
ビルド
次のコマンドを実行します。 [PC ~/imx-boot-[VERSION]]$ make imx-boot_armadillo_x2
:
: (省略)
:
Second Loader IMAGE:
sld_header_off 0x58000
sld_csf_off 0x59020
sld hab block: 0x401fcdc0 0x58000 0x1020
make[1]: ディレクトリ '/home/atmark/imx-boot-[VERSION]/imx-mkimage' から出ます
cp imx-mkimage/iMX8M/flash.bin imx-boot_armadillo_x2 初めてのビルドの場合、i.MX 8M Plusに必要なファームウェアの EULA
への同意を求められます。
内容を確認の上、同意してご利用ください。[] Welcome to NXP firmware-imx-8.11.bin
You need to read and accept the EULA before you can continue.
LA_OPT_NXP_Software_License v19 February 2021
:
: (省略)
:
Do you accept the EULA you just read? (y/N)
ビルド結果の確認
次のコマンドを実行します。 [PC ~/imx-boot-[VERSION]]$ ls imx-boot_armadillo_x2
imx-boot_armadillo_x2
ここでは、Armadillo-IoT ゲートウェイ G4向けのLinuxカーネルイメージをビルドする方法を説明します。 | |
|---|
Armadillo-IoT ゲートウェイ G4では、
基本的にはLinuxカーネルイメージをビルドする必要はありません。
「Alpine Linux ルートファイルシステムをビルドする」の手順を実施することで、
標準のLinuxカーネルイメージがルートファイルシステムに組み込まれます。 標準のLinuxカーネルイメージは、アットマークテクノが提供する
linux-at というAlpine Linux用のパッケージに含まれています。 カスタマイズしたLinuxカーネルイメージを利用するには、
「Alpine Linux ルートファイルシステムをビルドする」の手順の中で、
ax2/packages から linux-at を削除し、
ax2/resources/boot/ にイメージを配置する必要があります。 |
ソースコードの取得
Armadillo-IoT ゲートウェイ G4 Linuxカーネル から
「Linuxカーネル」ファイル (linux-at-[VERSION].tar) をダウンロードして、次のコマンドを実行します。 [PC ~]$ tar xf linux-at-[VERSION].tar
[PC ~]$ tar xf linux-at-[VERSION]/linux-[VERSION].tar.gz
[PC ~]$ cd linux-[VERSION]
デフォルトコンフィギュレーションの適用
次のコマンドを実行します。 [PC ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- x2_defconfig
ビルド
次のコマンドを実行します。 [PC ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j5
ビルド結果の確認
次のコマンドを実行します。 [PC ~/linux-[VERSION]]$ ls arch/arm64/boot/Image
arch/arm64/boot/Image
[PC ~/linux-[VERSION]]$ ls arch/arm64/boot/dts/freescale/armadillo_*.dtb
arch/arm64/boot/dts/freescale/armadillo_iotg_g4-nousb.dtb
arch/arm64/boot/dts/freescale/armadillo_iotg_g4.dtb
9.4.4. Alpine Linux ルートファイルシステムをビルドするここでは、alpine/build-rootfsを使って、
Alpine Linux ルートファイルシステムを構築する方法を説明します。 alpine/build-rootfsはPCで動作しているLinux上でArmadillo-IoT ゲートウェイ G4用の
aarch64アーキテクチャに対応したAlpine Linux
ルートファイルシステムを構築することができるツールです。 9.4.4.1. デフォルトのAlpine Linux ルートファイルシステムを構築する
alpine/build-rootfsの入手
Armadillo-IoT ゲートウェイ G4 開発用ツール から
「Alpine Linuxルートファイルシステムビルドツール」 ファイル (build-rootfs-[VERSION].tar.gz) をダウンロードして、
次のコマンドを実行します。 [PC ~/]$ wget https://download.atmark-techno.com//armadillo-iot-g4/tool/build-rootfs-latest.tar.gz
[PC ~/]$ tar xf build-rootfs-latest.tar.gz
[PC ~/]$ cd build-rootfs-[VERSION]
ビルド
次のコマンドを実行します。 パッケージをインターネット上から取得するため回線速度に依存しますが、
ビルドには数分かかります。 [PC ~/build-rootfs-[VERSION]]$ sudo ./build_rootfs.sh
use default(board=ax2)
use default(arch=aarch64)
use default(outdir=/home/xxxx/at-optee-build/build-rootfs)
use default(output=baseos-x2-ATVERSION.tar.zst)
'repositories' -> '/etc/apk/repositories'
:
: (略)
:
> 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.![[注記]](images/note.png) | |
|---|
ビルド時のログにエラー
"ERROR: No such package: .make-alpine-make-rootfs"
が出ていますが、正常時でも出力されるメッセージのため、
問題はありません。 |
| |
|---|
リリース時にバージョンに日付を含めたくないときは --release を引数に追加してください。 |
| |
|---|
任意のパス、ファイル名で結果を出力することもできます。 [PC ~/build-rootfs-[VERSION]]$ ./build_rootfs.sh ~/alpine.tar.gz
:
: (略)
:
[PC ~/build-rootfs-[VERSION]]$ ls ~/alpine.tar.gz
~/alpine.tar.gz |
ビルド結果の確認
次のコマンドを実行します。 [PC ~/build-rootfs-[VERSION]]$ ls *tar.zst
baseos-x2-[VERSION].tar.zst
9.4.4.2. Alpine Linux ルートファイルシステムのカスタマイズするalpine/build-rootfsディレクトリ直下にある
ax2 ディレクトリ以下のファイルを変更し、
build.shを実行することで、
ルートファイルシステムをカスタマイズすることができます。
install
-
resources/ ディレクトリ内のファイルを、
ルートファイルシステムにインストールするためのスクリプト
resources/
-
ルートファイルシステムにインストールするファイルを含んだディレクトリ
packages
-
ルートファイルシステムにインストールするパッケージのリスト
fixup
-
パッケージのインストールや上記installスクリプトの後に実行されるスクリプト
-
ファイル/ディレクトリを追加する
ax2/resources/ 以下に配置したファイルやディレクトリは、
そのままルートファイルシステムの直下にコピーされます。
デフォルトでは、
UIDとGIDは共はroot、パーミッションは 0744(ディレクトリの場合は 0755)
となります。 ax2/install を修正することで、
ファイルのUID、GID、パーミッションを変更することができます。
UID、GIDを変更する場合はchown、
パーミッションを変更する場合はchmodを利用してください。 ax2/packages を変更することで、
ルートファイルシステムにインストールするパッケージをカスタマイズすることができます。 パッケージ名は1行に1つ書くことができます。
パッケージ名はArmadillo上で"apk add"
の引数に与えることのできる正しい名前で記載してください。
誤ったパッケージ名を指定した場合は、
ルートファイルシステムのビルドに失敗します。 | |
|---|
利用可能なパッケージは以下のページで検索することができます。 Alpine Linuxルートファイルシステム使用した
Armadilloで検索することもできます。 [armadillo ~]# apk list *ruby*
ruby-rmagick-4.1.2-r1 armhf {ruby-rmagick} (MIT)
ruby-concurrent-ruby-ext-1.1.6-r1 armhf {ruby-concurrent-ruby} (MIT)
ruby-net-telnet-2.7.2-r3 armhf {ruby} (Ruby AND BSD-2-Clause AND MIT)
:
: (省略)
:
ruby-mustache-1.1.1-r3 armhf {ruby-mustache} (MIT)
ruby-nokogiri-1.10.10-r0 armhf {ruby-nokogiri} (MIT) |
本章では、microSDカードから直接起動(以降「SDブート」と表記します)する手順を示します。
SDブートを活用すると、microSDカードを取り替えることでシステムイメージを変更することができます。
本章に示す手順を実行するためには、容量が8Gbyte以上のmicroSDカードを必要とします。 | |
|---|
SDブートを行った場合、ブートローダーの設定は microSDカード に保存されます。 |
ブートディスクイメージのビルドします
「Alpine Linux ルートファイルシステムをビルドする」 で説明されているソースツリー alpine/build-rootfs にあるスクリプト build_image と 「ブートローダーをビルドする」 でビルドした imx-boot_armadillo_x2 を利用します。 VPU や NPU も使用する場合は、 「VPU や NPU を使用する」 で用意した imx_lib.img も組み込めます。 [PC ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh \
--boot ~/imx-boot-[VERSION]/imx-boot_armadillo_x2 \
--firmware ~/at-imxlibpackage/imx_lib.img
: (省略)
[PC ~/build-rootfs-[VERSION]]$ ls baseos-x2*img
baseos-x2-[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 カードがマウントされている場合、アンマウントします。
ブートディスクイメージの書き込み
[PC ~]$ sudo dd if=~/build-rootfs-[VERSION]/baseos-x2-[VERSION].img \
of=/dev/sdb bs=1M oflag=direct status=progressmicroSDカードの性能にもよりますが、書き込みには5分程度かかります。
| |
|---|
microSDカードのパーティション構成は次のようになっています。 表9.6 microSDカードのパーティション構成 | パーティション | オフセット | サイズ | 説明 |
|---|
- | 0 | 10MiB | ブートローダー | 1 | 10MiB | 300MiB | A/B アップデートのA面パーティション | 2 | 310MiB | 300MiB | A/B アップデートのB面パーティション | 3 | 610MiB | 50MiB | ログ用パーティション | 4 | 660MiB | 200MiB | ファームウェア | 5 | 860MiB | 残り | アプリケーション用パーティション |
gdiskで確認すると次のようになります。 [PC ~]$ sudo gdisk -l /dev/mmcblk0
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/mmcblk0: 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 15319006 6.5 GiB 8300 app |
「ブートディスクの作成」で作成したブートディスクから起動する方法を説明します。 -
Armadillo-IoT ゲートウェイ G4に電源を投入する前に、ブートディスクをCON1(SD インターフェース)に挿入します。
また、JP1ジャンパーをショート(SDブートに設定)します。
電源を投入します。
U-Boot SPL 2020.04-at1 (Dec 09 2021 - 11:17:22 +0900)
rv8803 rtc woken by interrupt
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from BOOTROM
image offset 0x8000, pagesize 0x200, ivt offset 0x0
NOTICE: BL31: v2.4(release):
NOTICE: BL31: Built : 11:24:17, Dec 9 2021
U-Boot 2020.04-at1 (Dec 09 2021 - 11:17:22 +0900)
CPU: i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 40C
Model: Atmark-Techno Armadillo X2 Series
DRAM: Hold key pressed for tests: t (fast) / T (slow)
2 GiB
WDT: Started with servicing (10s timeout)
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
BuildInfo:
- ATF
- U-Boot 2020.04-at1
first boot since power on
switch to partitions #0, OK
mmc1 is current device
flash target is MMC:1
Net: eth0: ethernet@30be0000 [PRIME], eth1: ethernet@30bf0000
Fastboot: Normal
Saving Environment to MMC... Writing to MMC(1)... OK
Normal Boot
Warning: Bootlimit (3) exceeded. Using altbootcmd.
Hit any key to stop autoboot: 0
u-boot=>
ブートディスク上のLinuxカーネルを起動します。
u-boot=> boot
9.6. Armadilloのソフトウェアの初期化microSD カードを使用し、Armadillo Base OS の初期化を行えます。 | |
|---|
初期化を行っても、ファームウェアパーティション(mmcblk2p4)は変更されません。
故障が疑われる場合など、ファームウェアも初期化したい場合、
初期化してから 「VPU や NPU を使用する」 を参考にしてもう一度書き込みしてください。 |
-
512 MB 以上の microSD カードを用意してください。
-
Armadillo-IoT ゲートウェイ G4 インストールディスクイメージ から
「Armadillo Base OS」をダウンロードしてください。
-
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-x2-installer-[VERSION].zip
[ATDE ~]$ sudo dd if=baseos-x2-installer-[VERSION].img \
of=/dev/sdb bs=1M oflag=direct status=progressまた、Windowsの場合、エクスプローラー等でZipファイルからimgファイルを取り出し、「Win32 Disk Imager」などを使用してmicroSDカードに書き込むことができます。
9.6.2. インストールディスクを使用した初期化-
JP1ジャンパーをショート(SDブートに設定)し、microSDカードをCON1に挿入します。
-
電源を投入すると、1分程度でeMMCのソフトウェアの初期化が完了します。
-
完了すると電源が切れます(LED4が消灯、コンソールに
reboot: Power down が表示)。
-
電源を取り外し、続いてJP1ジャンパーとmicroSDカードを外してください。
-
10秒以上待ってから再び電源を入れると、初回起動時と同じ状態になります。
9.7. ArmadilloのソフトウェアをアップデートするArmadillo-IoT ゲートウェイ G4では、
開発・製造・運用それぞれに適した複数のソフトウェアアップデート方法を用意しています。
本章では、それぞれのソフトウェアアップデート方法について説明します。 ソフトウェアアップデートを実現するソフトウェアの概要や仕様、用語については
13章ソフトウェア仕様
を参照してください。 Armadillo Base OS ではソフトウェアアップデートのためにOS やコンテナ等を格納するためにSWUというイメージ形式を使います。 SWUイメージは swupdate (https://sbabic.github.io/swupdate/swupdate.html) によってArmadillo Base OS上で検証とインストールが実行されます。SWUイメージをArmadilloに転送するための方法は、用途や状況に合わせて様々な方法を用意しています。例えば、USBメモリから読み取る、ウェブサーバーからダウンロードする、hawkBitというWebアプリケーションを使うなどです。 SWUイメージの作成には、swupdate-mkimage というツールを使います。 swupdate-mkimage に含まれる mkimage.sh を実行すると、アップデート対象やバージョン等の情報を記載した .desc ファイルに含まれる命令を順次実行してイメージを作り上げます。 詳しくは「swupdate-mkimageのdescファイル」を参考にしてください。
swupdate-mkimage の取得
[PC ~]$ git clone https://github.com/atmark-techno/swupdate-mkimage
[PC ~]$ cd swupdate-mkimage
署名鍵の生成
genkey.sh を実行して鍵を生成します。
この鍵は、swuパッケージを署名するために使用します。 [PC ~/swupdate-mkimage]$ ./genkey.sh --cn [COMMON_NAME]
Creating signing key swupdate.key and its public counterpart swupdate.pem
Generating an EC private key
writing new private key to 'swupdate.key'
Enter PEM pass phrase:（パスワードを入力）
Verifying - Enter PEM pass phrase:（パスワードを入力）
-----
swupdate.pem must be copied over to /etc/swupdate.pem on boards.
The suggested way is using swupdate:
./mkimage.sh examples/initial_setup.desc
Please set user passwords in initial_setup.desc and generate the image.
If you would like to encrypt your updates, generate your aes key now with:
./genkey.sh --aes
[PC ~/swupdate-mkimage]$ ls swupdate.*
swupdate.key swupdate.pem |
COMMON_NAME には証明鍵の「common name」として会社や製品が分かるような任意の名称を入力ください。
| |
証明鍵を保護するパスフレーズを入力します。
| |
確認のためもう一度同じパスフレーズを入力します。
| |
swupdate.key swupdate.pem が生成されます。
|
Armadilloに証明鍵をインストールしておくと、
署名されていないswuイメージのインストールを防ぐことができます。 鍵のインストール方法には次の2つのどれかを選んでください： -
以下の手順でinitial_setupのためのアップデート用のswuイメージを作成し、インストールする
-
起動中のArmadilloで/etc/swupdate.pemに鍵を追記し、persist_fileコマンドで保存する
(オプション)暗号化鍵の作成
このステップはオプションです。swuイメージ自体を暗号化する場合は、暗号化に利用する鍵も作成します。 $ ./genkey.sh --aes
Creating encryption keyfile swupdate.aes-key
You must also enable aes encryption with initial_setup.desc or equivalent
$ vi mkimage.conf
: (省略)
# AES encryption key if set
ENCRYPT_KEYFILE="swupdate.aes-key" |
例のとおり行頭の#を削除して、暗号化鍵ファイルの利用を有効にします
|
初期設定を行うためのイメージ作成
新しく作成した鍵を転送するためにswuイメージにいれます。 このイメージは初回インストール用の署名鍵を使って、作成した鍵とユーザーのパスワードを設定します。ここでパスワードを設定しない場合、インストールできないswuイメージになるため必ず設定してください。 initial_setup.descを編集してイメージを作成します。 [PC ~/swupdate-mkimage]$ vi examples/initial_setup.desc
: (省略)
# Set your own passwords for root and atmark users.
# /!\ The install will fail if this is either are left unset
# You can generate your own hash with the following command:
# python3 -c 'import crypt,getpass;
# print(crypt.crypt(getpass.getpass(), crypt.METHOD_SHA512))'
# and update the part within the inner quotes e.g.
# "usermod -p '"'$6$hfq6eDj4DpwIbn./$E..(省略)...wBRIekdENJ1/3.'"' root"
# You can also lock the account, e.g.
# "usermod -L atmark"
swdesc_command --version extra_os.initial_setup 1 \
"usermod -p '"'$6$salt$hash'"' atmark" \
"usermod -p '"'$6$salt$hash'"' root"
# uncomment if you would like to poweroff the system after the update is complete
#POST_POWEROFF=1
$ ./mkimage.sh examples/initial_setup.desc
Enter pass phrase for swupdate.key:
: (省略)
31 blocks |
python3がなければ、Armadillo内の「mkpasswd」も使えます。
| |
これと次の行に正しいパスワードを入れます。このままだとloginできなくなりますのでご注意ください。
| |
アップデート後に停止したければコメントを外してください。
| |
イメージを作成します。
| |
genkey.sh で設定したパスフレーズを入力します。
|
| |
|---|
このイメージに他の変更も入れれます。他のexamples/ディレクトリーにある.descファイルや「swupdate-mkimageのdescファイル」を参考にして、以下の例のように同じswuにいくつかの.descを組み込めます。 例えば、opensshを有効にします。 [PC ~/swupdate-mkimage]$ cat examples/enable_sshd.desc
# add your public key in examples/enable_sshd/root/.ssh/authorized_keys
swdesc_files --version extra_os.sshd 1 \
enable_sshd
swdesc_command --version extra_os.sshd 1 \
"ssh-keygen -A" \
"rc-update add sshd"
[PC ~/swupdate-mkimage]$ cp ~/.ssh/id_rsa.pub \
examples/enable_sshd/root/.ssh/authorized_keys
[PC ~/swupdate-mkimage]$ ./mkimage.sh examples/initial_setup.desc \
examples/enable_sshd.desc
: (省略)
usermod__... (initial_setup.descによる物)
examples_enable_sshd... （enable_sshd.descによる物)
32 blocks |
イメージのインストール
「イメージのインストール」を参考に、作成したイメージをインストールしてください。
次回以降のアップデート
次回以降のアップデートは作成した証明鍵を使用してArmadillo-IoT ゲートウェイ G4 のSWUイメージを作成します。 .desc ファイルの内容は examples/ のディレクトリや「swupdate-mkimageのdescファイル」を参考にしてください。
イメージをインストールする方法として下記に示すような方法があります。
USBメモリからの自動インストール
Armadillo-IoT ゲートウェイ G4にUSBメモリを接続すると自動的にアップデートが始まります。
アップデート終了後にArmadillo-IoT ゲートウェイ G4は自動で再起動します。 USBメモリはvfatもしくはext4形式でフォーマットし、作成した.swuのファイルをディレクトリを作らずに配置してください。 [PC ~/swupdate-mkimage]$ df -h
Filesystem Size Used Avail Use% Mounted on
: (省略)
/dev/sda1 15G 5.6G 9.1G 39% /media/USBDRIVE
[PC ~/swupdate-mkimage]$ cp examples/initial_setup.swu /media/USBDRIVE/
[PC ~/swupdate-mkimage]$ 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イメージを保存して、イメージのインストールを行います。
以下は外部記憶装置が/dev/mmcblk1p1(microSDカード）として認識された場合に、イメージのインストールを行う例です。 [armadillo ~]# mount /dev/mmcblk1p1 /mnt
[armadillo ~]# swupdate -i /mnt/initial_setup.swu
[INFO ] : SWUPDATE started : Software Update started !
[INFO ] : SWUPDATE running : Installation in progress
: (省略)
[ERROR] : SWUPDATE failed [0] ERROR : swupdate triggering reboot!
[INFO ] : SWUPDATE successful ! SWUPDATE successful !
ウェブサーバーからイメージのインストール（手動）
swuイメージをウェブサーバーにアップロードして、イメージのインストールを行います。
以下は、http://server/initial_setup.swu のイメージをインストールする例です。
[armadillo ~]# swupdate -d '-u http://server/initial_setup.swu'
[INFO ] : SWUPDATE started : Software Update started !
[INFO ] : SWUPDATE running : Installation in progress
: (省略)
[ERROR] : SWUPDATE failed [0] ERROR : swupdate triggering reboot!
[INFO ] : SWUPDATE successful ! SWUPDATE successful ! |
はエラーとして赤で表示されますが、見やすくするためでエラーではありません。
|
ウェブサーバーからの定期的な自動インストール
swupdate-urlを有効にしたら、定期的にチェックしてインストールします。
以下はサービスの有効化とタイミングの設定の例です。 [armadillo ~]# rc-update add swupdate-url
[armadillo ~]# persist_file /etc/runlevels/default/swupdate-url
[armadillo ~]#
echo https://download.atmark-techno.com/armadillo-iot-g4/image/baseos-x2-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のイメージを作成の際にexamples/enable_swupdate_url.descを入れると有効にすることができます。 |
hawkBit を使用した自動インストール
hawkBit で Armadillo-IoT ゲートウェイ G4 を複数台管理してアップデートすることができます。
以下の「hawkBitサーバーから複数のArmadilloに配信する」を参考にしてください。
9.7.4. hawkBitサーバーから複数のArmadilloに配信するhawkBitサーバーを利用することで複数のArmadillo
のソフトウェアをまとめてアップデートすることができます。 手順は次のとおりです。
hawkBitサーバーの準備
Dockerを利用すると簡単にサーバーを準備できます。
Dockerの準備については https://docs.docker.com/get-docker/ を参照してください。 Dockerの準備ができたら次のコマンドを実行します。 [PC ~]$ git clone https://github.com/eclipse/hawkbit.git -b 0.3.0M6
[PC ~]$ cd hawkbit/hawkbit-runtime/docker
[PC ~/hawkbit/hawkbit-runtime/docker]$ docker-compose up -d http://<サーバーのIPアドレス>:8080 にアクセスすると、ログイン画面が表示されます。 デフォルトでは次のアカウントでログインできます。
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のアップデートの状態を確認できます。 アップデート中は黄色、アップデートが正常に完了すると緑色になります。
9.7.5. swupdate-mkimageのdescファイル.desc ファイルを編集して、いくつかのコマンドが使えます。
例 [PC ~/swupdate-mkimage]$ cat examples/usb_container_nginx.desc
swdesc_usb_container "nginx_alpine.tar" \
--version container_nginx 1
swdesc_files --version extra_os.nginx 1 \
nginx_start |
nginx_alpine.tarにあるコンテナをインストールします。
| |
nginx_startにあるファイルを転送します。
|
コマンドは書かれた順番でインストールします。インストールするかどうかの判断はバージョンで行います: swdesc_xxx --version <component> <version> [xxx options] 以下のコマンドから使ってください
swdesc_tarとswdesc_filesでファイルを転送します。
swdesc_tar --version <component> <version> [--dest <dest>] <tar_file>
swdesc_files --version <component> <version> [--dest <dest>] \
[--basedir <basedir>] <file> [<more files>]swdesc_tarの場合、予め用意されてあるtarアーカイブをこのままデバイスで展開します。 --dest <dest> で展開先を選べることができます。デフォルトは / （バージョンのcomponentはbase_osやextra_osの場合）か /var/app/rollback/volumes/ （それ以外のcomponent）
swdesc_filesの場合、mkimage.shがアーカイブを作ってくれますが同じ仕組みです。 --basedir <basedir> でアーカイブ内のパスをどこで切るかを決めます。
-
例えば、
swdesc_files --version extra_os.test 1 --basedir /dir /dir/subdir/file ではデバイスに /subdir/file を作成します。
-
デフォルトは<file>から設定されます。ディレクトリであればそのままbasedirとして使います。それ以外であれば親ディレクトリを使います。
swdesc_commandやswdesc_scriptでコマンドを実行する
swdesc_command --version <component> <version> <command> [<more commands>]
swdesc_script --version <component> <version> <script> アップデート先の環境でコマンドやスクリプトファイルを走らせます。 バージョンのcomponentはbase_osとextra_os以外の場合、 /var/app/volumes と /var/app/rollback/volumes 以外何も変更できないのでご注意ください。 コマンドが成功しないとアップデートが失敗します。
swdesc_execでファイルを配ってコマンドでそのファイルを使う
swdesc_exec --version <component> <version> <file> <command> swdesc_commandと同じくコマンドを走らせますが、<file>を先に転送してコマンド内で"$1"として使えます。
swdesc_embed_container, swdesc_usb_container, swdesc_pull_containerで予め作成したコンテナを転送します。
swdesc_embed_container --version <component> <version> <container_archive>
swdesc_usb_container --version <component> <version> <container_archive>
swdesc_pull_container --version <component> <version> <container_url> 例は「コンテナの配布」を参考にしてください。
swdesc_uboot <uboot_image>でubootを更新します。
swdesc_uboot <uboot image> このコマンドだけにバージョンは自動的に設定されます。
コマンドの他には、設定変数もあります -
DESCRIPTION: 自由なイメージの説明、ログに残ります。
-
PRIVKEY, PUBKEY: 署名鍵と証明書
PRIVKEY_PASS: 鍵のパスワード（自動用）
opensslのPass Phraseをそのまま使いますので、pass:password、env:varやfile:pathnameのどれかを使えます。
passやenvの場合他のプロセスに見られる恐れがありますのでfileをおすすめします。 -
ENCRYPT_KEYFILE: 暗号化の鍵
POST_ACTION=container: コンテナのみのアップデート後に再起動を行いません。
コンテナの中身だけをアップデートする場合、Armadillo-IoT ゲートウェイ G4を再起動せずにコンテナだけを再起動させます。 -
POST_ACTION=poweroff: アップデート後にシャットダウンを行います。
-
POST_ACTION=wait: アップデート後に自動的に再起動は行われず、次回起動時にアップデートが適用されます。
9.7.5.1. swupdate_preserve_files についてextra_os のアップデートで rootfs にファイルを配置することができますが、次の OS アップデートの際に削除される可能性があります。
デフォルトでは、 /etc/atmark と、 swupdate 、 sshd やネットワークの設定を保存しますがそれ以外はコピーされてません。 他のファイルの変更をアップデートの際に残すには /etc/swupdate_preserve_files に記載します。 コピーのタイミングによって、以下のどれかを使ってください：
単にファイルを記載する。
この場合、アップデートする前にファイルをコピーします。 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
examples/enable_sshd.descを参考にします。 descファイルを編集する必要がありませんが自分の公開鍵を指定された場所に配置してください。 [PC ~/swupdate-mkimage]$ cat examples/enable_sshd.desc
# add your public key in examples/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 examples/enable_sshd/root/.ssh/authorized_keys"
fi
swdesc_files --version extra_os.sshd 1 \
enable_sshd
swdesc_command --version extra_os.sshd 1 \
"ssh-keygen -A" \
"rc-update add sshd"
[PC ~/swupdate-mkimage]$ cp ~/.ssh/id_rsa.pub \
examples/enable_sshd/root/.ssh/authorized_keys
[PC ~/swupdate-mkimage]$ ./mkimage.sh examples/initial_setup.desc \
examples/enable_sshd.desc
Enter pass phrase for swupdate.key:
: (省略)
examples_enable_sshd... （enable_sshd.descによる物)
32 blocks |
自分の公開鍵を転送します。デフォルトのオプションなのでexamples/enable_sshdディレクトリの中身をこのまま/に転送されます。
| |
再起動する度に新しいサーバーの鍵が変わらないように、アップデートの時に一回作成します。
| |
サービスを有効にします。
| |
自分の公開鍵を指定された場所に配置します。
| |
イメージを作成します。パスワードはgenkey.shの時のパスワードです。
|
9.7.5.3. 例: Armadillo Base OSアップデートここでは、「Armadilloのソフトウェアをビルドする」でメインシステム向けのビルドで作成したファイルを使用します。 examples/OS_update.descを参考にします。 [PC ~/swupdate-mkimage]$ mkdir -p mydescs
[PC ~/swupdate-mkimage]$ cp example/OS_update.desc mydescs/update-20211012.desc
[PC ~/swupdate-mkimage]$ vi mydescs/update-20211012.desc
# uboot image can be generated with atmark imx-boot script
swdesc_uboot imx-boot_armadillo_x2
# 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-x2-[VERSION].tar.zst" \
--version base_os [VERSION]
[PC ~/swupdate-mkimage]$ ./mkimage.sh -o update-[VERSION].swu \
mydescs/update-[VERSION].desc
Enter pass phrase for swupdate.key:
sw-description
sw-description.sig
scripts.tar.zst
imx-boot_armadillo_x2.zst
baseos-x2-[VERSION].tar.zst
swupdate_post.sh.zst
126898 blocks |
imx-bootでビルドしたイメージを使います。
| |
build-rootfsでビルドしたイメージを使います。
| |
バージョンを上がるときにしかインストールされませんので、現在の/etc/sw-versionsを見て上がるように設定してください。
| |
イメージを作成します。パスワードはgenkey.shの時のパスワードです。
|
9.7.5.4. 例: swupdate_preserve_files で Linux カーネル以外の Armadillo-IoT ゲートウェイ G4 向けのイメージをインストールする方法Armadillo-IoT ゲートウェイ G4 向けのアップデートイメージに 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 を保存するように追加します。
| |
変更した設定ファイルを保存します
|
| |
|---|
examples/update_kernel*.desc を使いますと、このパスを自動的に /etc/swupdate_preserve_files に追加されます。
|
9.8. Device Treeをカスタマイズするat-dtweb を利用して Device Tree をカスタマイズする方法を説明します。at-dtweb では、
Web ブラウザ上のマウス操作でDTSおよび DTB を生成することができます。
カスタマイズの対象は拡張インターフェース(CON11、CON12)です。 ATDE9 に at-dtweb パッケージをインストールします。 [ATDE ~]$ sudo apt-get update
[ATDE ~]$ sudo apt-get install at-dtweb
at-dtweb の起動開始
at-dtweb の起動を開始するには、デスクトップ左上のアプリケーションの「システムツール」から「at-dtweb」を選択してください。
コマンドライン上からでも、at-dtweb コマンドで起動できます。 [ATDE ~]$ at-dtweb
ボードの選択
ボードを選択します。Armadillo-IoT_G4 を選択して、「OK」をクリックします。
Linux カーネルディレクトリの選択
Linux カーネルディレクトリを選択します。コンフィギュレーション済みの Linux カーネルディレクトリを選択して、「OK」をクリックします。
at-dtweb の起動完了
at-dtweb が起動し、次のように画面が表示されます。
9.8.3. Device Tree をカスタマイズ機能の選択は、ドラッグ&ドロップで行います。画面左上の「Available features」から有効にしたい機能をドラッグし、画面右側の「Armadillo-IoT Gateway G4」の白色に変化したピンにドロップします。例として CON11 8/10 ピンを UART3(RXD/TXD) に設定します。 | |
|---|
何も機能が選択されていないピンには GPIO の機能が割り当てられます。 |
いくつかの機能にプロパティを設定することができます。画面右側の「Armadillo-IoT Gateway G4」に選択した機能を左クリックすると、画面左下の「Properties」からプロパティを選択することができます。 例としてCON11 19/27 ピンの I2C5(SCL/SDA) の clock_frequency プロパティを設定します。 設定したプロパティを確定させるには「Apply」をクリックします。 全ての機能を削除する場合は、画面右上の「Reset configuration」をクリックします。機能ごとに削除する場合は、画面右側の「Armadillo-IoT Gateway G4」のピンを右クリックして「Remove」をクリックします。 DTS および DTB を生成するには、画面右上の「Save」をクリックします。 「Device tree built!」と表示されると、DTS および DTB の生成は完了です。 ビルドが終了すると、arch/arm64/boot/dts/freescale 以下に DTS/DTB が作成されています。 [ATDE ~/linux-5.10]$ ls arch/arm64/boot/dts/armadillo-iotg-g4-expansion-interface.dtsi
armadillo-iotg-g4-expansion-interface.dtsi
[ATDE ~/linux-5.10]$ ls arch/arm64/boot/dts/armadillo_iotg_g4-at-dtweb.dtb
armadillo_iotg_g4-at-dtweb.dtb eMMC は主に NAND Flash メモリから構成されるデバイスです。NAND Flash メモリには書き込みしてから1年から3年程度の長期間データが読み出されないと電荷が抜けてしまう可能性があります。その際、電荷が抜けて正しくデータが読めない場合は、eMMC 内部で ECC (Error Correcting Code) を利用してデータを訂正します。しかし、訂正ができないほどにデータが化けてしまう場合もあります。そのため、一度書いてから長期間利用しない、高温の環境で利用するなどのケースでは、データ保持期間内に電荷の補充が必要になります。電荷の補充にはデータの読み出し処理を実行し、このデータの読み出し処理をデータリテンションと呼びます。 Armadillo-IoT ゲートウェイG4に搭載のeMMCには長期間データが読み出されない状態であっても、データリテンションを自動的に行う機能を搭載しています。 データリテンションは /etc/conf.d/micron_emmc_reten というファイルに書かれた設定、use_system_time によって以下の２通りの挙動を示します。 表9.7 データリテンションの挙動 | /etc/conf.d/micron_emmc_reten | initiating condition |
|---|
use_system_time=yes | Linux 起動した時に前回のリテンションから１日以上経過していたら開始する | use_system_time=no (default) | Linux 起動した時に毎回開始する |
これで設定は完了しました。 以下は挙動ごとのシステム概略図です。 use_system_time を有効にした場合のデータリテンションの動作例を以下に示します。 9.9.2. より詳しくデータリテンションの統計情報を確認するにはMicron Technology が提供する emmcparm というツールを使うことで、データリテンションの統計情報を確認することができます。統計情報として eMMC 内部に保存されているのは実行回数、最終実行完了時のカウンター値、現在のデータリテンション処理の進捗があります。
次の手順で、emmcparmを使ってeMMCの情報を確認することができます。このツールではデータリテンション処理のことを「セルフリフレッシュ」と呼びます。
emmcparm をダウンロードする
以下の検索結果から最新の emmcparm をダウンロードする。ユーザー登録が必要になります。 | |
|---|
マニュアル作成時点では 5.0.0 を利用しました |
パッケージを展開する
[armadillo ~]# unzip emmc_emmcparm_c_code_derived_from_TN\ FC\ 25_v5.0.0 _binary.zip
SSR を取得する
[armadillo ~]# emmcparm/bin/emmcparm_arm_64bit -r /dev/mmcblk2 : (省略)
=======================================================================
| Secure Smart Report |
=======================================================================
Self Refresh progress of scan[215-212]: 0x00000000 (0)
Power Loss Counter[195-192]: 0x00000005 (5)
Current total ON time[131-128]: 0x00001b28 (6952)
Number of Blocks in Refresh Queue[99-96]: 0x00000000 (0)
Self Refresh Completion date [95-88]: 0xffffffffd8148931
(-669742799)
Self Refresh Loop Count[81-80]: 0x00000002 (2)
Written Data 100MB Size Count (from NAND)[79-76]: 0x0004889d (297117)
Cumulative Initialization Count (from NAND)[75-72]: 0x00005300 (21248)
Written Data 100MB Size Count (from RAM)[71-68]: 0x0004889d (297117)
Refresh Count[55-52]: 0x00000004 (4)
: (省略) |
現在のセルフリフレッシュ処理の進捗。0 ということは実行中ではない
| |
最後に行ったセルフリフレッシュのカウンター値
| |
セルフリフレッシュを行った回数
|
ここではデータリテンションを自動的におこなう機能の仕様について詳細に説明します。
Armadillo で採用しているeMMCには、データリテンションを自動的に実行することができる「セルフリフレッシュ」と呼ばれる機能が搭載されます。実行トリガーは２種類のうちどちらかを選択できます。OTP のため一度設定すると変更できません。この設定は出荷時に「eMMC 内部レジスタ値とコマンドに入力された値を比較して１日以上経過していると実行する」を設定しています。 -
リセット後に毎回実行する
-
eMMC 内部レジスタ値とコマンドに入力された値を比較して１日以上経過していると実行する
２の設定の場合、セルリフレッシュ機能が実行されるまでの流れは以下のとおりです。 -
ホストによって eMMC がハードウェアもしくはソフトウェアリセットされる
-
一定時間 (delay 1) 以内に、ホストから SET_TIME (CMD49)と呼ばれるコマンドが eMMC に発行される
-
eMMC コントローラは、バスの稼動状態を監視する
eMMC コントローラは、アイドルになってから一定時間 (delay 2) 経過した後にセルフリフレッシュを実行する
-
ECC エラーなどのエラーがしきい値 (2) を越えたセルに対してのみセルフリフレッシュを実行する
Armadillo でのセルフリフレッシュ機能搭載 eMMC への設定は以下のとおりです。 表9.8 Armadillo のデータリテンションの設定 | setting | value | description |
|---|
RTC | ON | eMMC 内部レジスタの値と SET_TIME の値を比較してセルフリフレッシュを実行する | Delay 1 | 60s | リセット後の SET_TIME 有効期間 | Delay 2 | 100ms | アイドル確認後のセルフリフレッシュ実行までの遅れ時間 |
| |
|---|
詳しい情報は以下を参照してください。 マイクロンのサイトの会員登録が必要になります。 |
この章では、アットマークテクノが提供するデモアプリケーションについて説明します。
デモアプリケーションは GUI アプリケーションであるため、ディスプレイを接続している必要があります。
デモアプリケーションを実行するためのコンテナイメージとして、アットマークテクノが提供する
コンテナイメージを想定しています。
このイメージに関しては 「アットマークテクノが提供するイメージを使う」 を参照してください。 デモアプリケーションは GUI アプリケーションであるため、コンテナにログイン後、
まずデスクトップ環境を起動する必要があります。ここでは weston を起動します。 --tty=1 のオプションは画面表示に使用する tty の値を設定してください。 9.10.3. デモアプリケーションランチャを起動するデモアプリケーションランチャを起動します。
個々のデモアプリケーションはこのデモアプリケーションランチャから起動できます。
このデモアプリケーションランチャは GUI フレームワークとして Qt を使用しています。
デモアプリケーションランチャのソースコードは、apt source で取得することができます。 以下のようなアプケーションが起動します。 左側のカテゴリから起動したいデモアプリケーションを選びます。 選んだアプリケーションは、右下の Launch ボタンで起動することができます。 mediaplayer は動画を再生するアプリケーションです。H.264, VP8, VP9 でエンコードされた
動画ファイルであれば、動画のデコードに VPU が使われます。File メニューから、再生したい
動画ファイルを選択することができます。
このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。 音声も出力したい場合は、pulseaudio をインストールして起動する必要があります。 video recoder は gstreamer を使用してカメラからの映像を録画することができます。
そのため、このアプリケーションを使用するためには、Armadillo 本体にカメラを接続する必要があります。
カメラが接続されていると Video device の項目でカメラを選択できるようになります。
カメラを選択し、Start ボタンを押すと別ウィンドウが表示され録画が開始されます。
アプリケーション上のテキストボックスには、Start ボタンを押したときに起動する gstreamer の
コマンドを表示しています。テキストボックスの内容はキーボードで編集可能です。
このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。 マイク付きのカメラなどで同時に音声も録音したい場合は、「mediaplayer」 を参照して
pulseaudio を起動してください。 9.10.6. led switch testerled switch tester は Armadillo 本体上の LED と SW1 を扱うアプリケーションです。
LED ボタンを押すことで Armadillo 本体上の LED の 点灯・消灯を確認することができます。
Armadillo 本体上の SW1 を押すとアプリケーションの SW1 部分の表示が変化することを確認できます。
このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。 rtc tester は Armadillo 本体上の RTC に対して日時の設定および取得が行えるアプリケーションです。
カレンダー上から日付を選び、Time に設定したい時刻を入力した後、Set ボタンを押すと RTC にその日時が
設定されます。Get ボタンを押すと、現在の日時を RTC から読み込みアプリケーション上に反映されます。
このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。 9.10.8. object detection demoobject detection demo はカメラからの映像に対して物体認識を行うアプリケーションです。
NPU を使用しているため高速に物体認識を行えます。画面の左側には認識した物体を囲む四角形が表示され、
右側には認識した物体のラベルとスコアが表示されます。
このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。 起動する前に、必要な Python ライブラリをインストールする必要があります。 このアプリケーションはカメラデバイスとしてデフォルトで /dev/video5 を使用します。
お使いの環境によって別のカメラデバイスに設定したい場合は、以下のファイルを変更してください。 |
--camera_id の値を環境に合わせて変更します。
|
| |
| | | |
| |
