応用編

本章では、ここまでの内容で紹介しきれなかった、より細かな Armadillo の設定方法や、開発に役立つヒントなどを紹介します。

各トピックを羅列していますので、目次の節タイトルからやりたいことを探して辞書的にご使用ください。

6.1. persist_file について

Armadillo BaseOS ではルートファイルシステムに overlayfs を採用しています。

そのため、ファイルを変更した後 Armadillo の電源を切ると変更内容は保持されません。開発中などに rootfs の変更内容を保持するには、変更したファイルに対して persist_file コマンドを使用します。

開発以外の時は安全のため、ソフトウェアアップデートによる更新を実行してください。 SWUpdate に関しては「アップデート機能について」を参照してください。

rootfs の内容を変更しても、ソフトウェアアップデートを実施した際に変更した内容が保持されない可能性があります。ソフトウェアアップデート実施後も変更内容を保持する手順に関しては「swupdate_preserve_files について」を参照してください。

persist_file コマンドの概要を図6.1「persist_file のヘルプ」に示します。

[armadillo ~]# persist_file -h
Usage: /usr/bin/persist_file [options] file [more files...]

Mode selection:
  (none) single entry copy
  -d, --delete   delete file
  -l, --list     list content of overlay
  -a, --apk      apk mode: pass any argument after that to apk on rootfs
  -R, --revert   revert change: only delete from overlay, making it
                 look like the file was reverted back to original state

Copy options:
  -r, --recurse  recursive copy (note this also removes files!)
  -p, --preserve make the copy persist through baseos upgrade
                 by adding entries to /etc/swupdate_preserve_files
  -P, --preserve-post   same, but copy after upgrade (POST)

Delete options:
  -r, --recurse  recursively delete files

Common options:
  -v, --verbose  verbose mode for all underlying commands

Note this directly manipulates overlayfs lower directories
so might need a reboot to take effect

図6.1 persist_file のヘルプ

ファイルの保存・削除手順例

[armadillo ~]# echo test > test
[armadillo ~]# persist_file -rv /root
'/root/test' -> '/mnt/root/test' 
'/root/.ash_history' -> '/mnt/root/.ash_history'
[armadillo ~]# rm -f test
[armadillo ~]# persist_file -rv /root
removed '/mnt/root/test' 
removed '/mnt/root/.ash_history' 
'/root/.ash_history' -> '/mnt/root/.ash_history'

図6.2 persist_file 保存・削除手順例

	追加・変更したファイルを rootfs へコピーします。
	-r を指定すると、ひとつ前の rm -f コマンドで削除したファイルがrootfsからも削除されますのでご注意ください。
	すでに rootfs に存在するファイルも一度削除してからコピーするため、このようなメッセージが表示されます。

ソフトウェアアップデート後も変更を維持する手順例
```
[armadillo ~]# vi /etc/conf.d/podman-atmark 
[armadillo ~]# persist_file -P /etc/conf.d/podman-atmark 
[armadillo ~]# tail -n 2 /etc/swupdate_preserve_files 
# persist_file 20211216
POST /etc/conf.d/podman-atmark
```
図6.3 persist_file ソフトウェアアップデート後も変更を維持する手順例
何らかのファイルの内容を変更します。

-P オプションを付与して persist_file を実行します。

swupdate_preserve_files に追加されたことを確認します。

変更ファイルの一覧表示例

[armadillo ~]# mkdir dir
[armadillo ~]# persist_file -l
directory          /
directory          /root
opaque directory   /root/dir 
whiteout           /root/test 
regular file       /root/.ash_history
directory          /etc
regular file       /etc/resolv.conf
directory          /var
symbolic link      /var/lock
: (省略)

図6.4 persist_file 変更ファイルの一覧表示例

	rootfs のファイルを見せないディレクトリは `opaque directory` と表示されます。
	削除したファイルは `whiteout` と表示されます。

パッケージをインストールする時はapkコマンドを使用してメモリ上にインストールできますが、 persist_file コマンドで rootfs に直接インストールすることも可能です。

[armadillo ~]# persist_file -a add strace
(1/3) Installing fts (1.2.7-r1)
(2/3) Installing libelf (0.185-r0)
(3/3) Installing strace (5.14-r0)
Executing busybox-1.34.1-r3.trigger
OK: 251 MiB in 188 packages
Install succeeded, but might not work in the running system
Please reboot if installed program does not work 
[armadillo ~]# strace ls
: (省略)
exit_group(0)                           = ?
+++ exited with 0 +++

図6.5 persist_file でのパッケージインストール手順例

この例では Armadillo を再起動せずにインストールしたコマンドを使用できましたが、Armadillo の再起動が必要となるパッケージもありますので、その場合は Armadillo を再起動してください。

6.2. コンテナ

Armadillo Base OS において、ユーザーアプリケーションは基本的にコンテナ内で実行されます。 3章開発編で紹介した開発手順では、基本的に SWUpdate を使用してコンテナを生成・実行していました。

以下では、より自由度の高いコンテナの操作のためにコマンドラインからの操作方法について紹介します。

6.2.1. Podman - コンテナ仮想化ソフトウェアとは

コンテナとはホスト OS 上に展開される仮想的なユーザ空間のことです。コンテナを使用することで複数の Armadillo-X2 でも同一の環境がすぐに再現できます。ゲスト OS を必要としない仮想化であるため、アプリケーションの起動が素早いという特徴があります。

Podman とはこのようなコンテナを管理するためのソフトウェアであり、使用方法はコンテナ管理ソフトウェアの 1 つである Docker と互換性があります。

6.2.2. コンテナの基本的な操作

この章では、コンテナ仮想化ソフトウェアの 1 つである Podman の基本的な使い方について説明します。 Armadillo-X2 で実行させたいアプリケーションとその実行環境自体を 1 つの Podman イメージとして扱うことで、複数の Armadillo-X2 がある場合でも、全てのボード上で同一の環境を再現させることが可能となります。

この章全体を通して、イメージの公開・共有サービスである Docker Hub から取得した、Alpine Linux のイメージを使って説明します。

6.2.2.1. イメージからコンテナを作成する

イメージからコンテナを作成するためには、podman_start コマンドを実行します。 podman や docker にすでに詳しいかたは podman run コマンドでも実行できますが、ここでは「コンテナ起動設定ファイルを作成する」で紹介するコンテナの自動起動の準備も重ねて podman_start を使います。イメージは Docker Hub から自動的に取得されます。ここでは、簡単な例として "ls /" コマンドを実行するコンテナを作成します。

[armadillo ~]# vi /etc/atmark/containers/my_container.conf 
set_image docker.io/alpine
set_command ls /
[armadillo ~]# podman pull docker.io/alpine 
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
:（省略）
Writing manifest to image destination
Storing signatures
a6215f271958c760a2975a6765016044115dbae4b90f414eba3a448a6a26b4f6
[armadillo ~]# podman_start my_container 
Starting 'my_container'
b141e899b5ef7c9ec5434bda8f6a83d3e6bfc94f74bfb5dcef2a22041c71fdbf
[armadillo ~]# podman logs my_container 
bin
dev
:（省略）
usr
var
[armadillo ~]#

図6.6 コンテナを作成する実行例

	コンテナのコンフィグを作成します。このファイルでは、コンテナのイメージやコマンド、デバイスへのアクセス権限を設定します。詳しい設定の説明には「コンテナ起動設定ファイルを作成する」を参照ください。
	コンテナのイメージを取得します。イメージが Armadillo に置いてない場合は「Error: docker.io/alpine: image not known」の様なエラーで失敗します。
	コンテナを起動します。これは Armadillo 起動時に自動的に起動されるコンテナと同じものになります。自動起動が不要な場合には `set_autostart no` で無効化できます。
	`podman logs` コマンドで出力を確認します。

"ls /" を実行するだけの "my_container" という名前のコンテナが作成されました。コンテナが作成されると同時に "ls /" が実行され、その結果がログに残ります。ここで表示されているのは、コンテナ内部の "/" ディレクトリのフォルダの一覧です。

コンフィグファイルの直接な変更と podman pull によるコンテナの取得はデフォルト状態ではメモリ上でしか保存されません。

ファイルは persist_file で必ず保存し、コンテナイメージは abos-ctrl podman-storage --disk で podman のストレージを eMMC に切り替えるか abos-ctrl podman-rw で一時的に eMMC に保存してください。

運用中の Armadillo には直接に変更をせず、 SWUpdate でアップデートしてください。

コンフィグファイルを保存して、 set_autostart no を設定しない場合は自動起動します。


	`podman_start` でコンテナが正しく起動できない場合は `podman_start -v <my_container>` で `podman run` のコマンドを確認し、 `podman logs <my_container>` で出力を確認してください。

6.2.2.2. イメージ一覧を表示する

コンテナを作成するためのイメージは、イメージ一覧を表示する podman images コマンドで確認できます。

[armadillo ~]# podman images
REPOSITORY                TAG     IMAGE ID      CREATED      SIZE
docker.io/library/alpine  latest  9c74a18b2325  2 weeks ago  4.09 MB

図6.7 イメージ一覧の表示実行例

podman images コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman images --help

図6.8 podman images --help の実行例

6.2.2.3. コンテナ一覧を表示する

作成済みコンテナ一覧を表示するためには podman ps コマンドを実行します。

[armadillo ~]# podman ps -a
CONTAINER ID  IMAGE                            COMMAND    CREATED         STATUS                    PORTS    NAMES
d6de5881b5fb  docker.io/library/alpine:latest  ls /       12 minutes ago  Exited (0) 11 minutes ago          my_container

図6.9 コンテナ一覧の表示実行例

一覧表示により、コンテナ名やコンテナ ID を確認することができます。-a オプションを付けない場合は、動作中のコンテナのみ表示されます。 podman ps コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman ps --help

図6.10 podman ps --help の実行例

6.2.2.4. コンテナを起動する

作成済みのコンテナを起動するためには podman start コマンドを実行します。

[armadillo ~]# podman start my_container
podman start my_container
[ 3119.081068] IPv6: ADDRCONF(NETDEV_CHANGE): vethe172e161: link becomes ready
[ 3119.088214] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 3119.094812] cni-podman0: port 1(vethe172e161) entered blocking state
[ 3119.101231] cni-podman0: port 1(vethe172e161) entered disabled state
[ 3119.107745] device vethe172e161 entered promiscuous mode
[ 3119.113185] cni-podman0: port 1(vethe172e161) entered blocking state
[ 3119.119546] cni-podman0: port 1(vethe172e161) entered forwarding state
my_container
[ 3119.620731] cni-podman0: port 1(vethe172e161) entered disabled state
[ 3119.627696] device vethe172e161 left promiscuous mode
[ 3119.632762] cni-podman0: port 1(vethe172e161) entered disabled state

図6.11 コンテナを起動する実行例

-a オプションを与えると、コンテナ内で実行されたアプリケーションの出力を確認できます。

[armadillo ~]# podman start -a my_container
[ 3150.303962] IPv6: ADDRCONF(NETDEV_CHANGE): vetha9ef8f8e: link becomes ready
[ 3150.311106] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 3150.317703] cni-podman0: port 1(vetha9ef8f8e) entered blocking state
[ 3150.324139] cni-podman0: port 1(vetha9ef8f8e) entered disabled state
[ 3150.330687] device vetha9ef8f8e entered promiscuous mode
[ 3150.336085] cni-podman0: port 1(vetha9ef8f8e) entered blocking state
[ 3150.342443] cni-podman0: port 1(vetha9ef8f8e) entered forwarding state
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr
[ 3150.804164] cni-podman0: port 1(vetha9ef8f8e) entered disabled state
[ 3150.811249] device vetha9ef8f8e left promiscuous mode
[ 3150.816349] cni-podman0: port 1(vetha9ef8f8e) entered disabled state

図6.12 コンテナを起動する実行例(a オプション付与)

ここで起動している my_container は、起動時に "ls /" を実行するようになっているので、その結果が出力されます。 podman start コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman start --help

図6.13 podman start --help 実行例

6.2.2.5. コンテナを停止する

動作中のコンテナを停止するためには podman stop コマンドを実行します。

[armadillo ~]# podman stop my_container
my_container

図6.14 コンテナを停止する実行例

podman stop コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman stop --help

図6.15 podman stop --help 実行例

6.2.2.6. コンテナの変更を保存する

コンテナに対して変更が行われた状態で、そのままコンテナを停止してしまうと変更が失なわれてしまいます。

変更を保存するには二つの方法があります。

podman commit コマンドで保存する。
```
[armadillo ~]# podman commit my_container image_name:latest
Getting image source signatures
Copying blob f4ff586c6680 skipped: already exists
Copying blob 3ae0874b0177 skipped: already exists
Copying blob ea59ffe27343 done
Copying config 9ca3c55246 done
Writing manifest to image destination
Storing signatures
9ca3c55246eaac267a71731bad6bfe4b0124afcdd2b80c4f730c46aae17a88f3
```
図6.16 my_containerを保存する例
podman commitで保存する度に、変更が行なわれた差分が保存されます。繰り返し差分を保存すると、イメージサイズが大きくなってしまいます。ストレージ容量が不足する場合は、ベースとなるOSのイメージから作り直してください。
「電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)」を使用する。
podman_start の add_volumes コマンドでコンテナに Armadillo Base OS のディレクトリをコンテナで使うことができます。
保存するデータの性質によって、保存先を選択してください。
1. /var/app/volumes/myvolume: アップデートした場合はコピーされません。ログやデータベースなど、アプリケーションが作成し続けるようなデータの保存に向いています。
2. myvolume か /var/app/rollback/volumes/myvolume: アップデートの際にコピーしてアップデートを行うので、アップデート中でも安全に使いつづけます。アプリケーションと一緒にアップデートするようなデータの保存に向いています。

6.2.2.7. コンテナの自動作成やアップデート

podman run, podman commitでコンテナを作成できますが、定期的にアップデートをする際にはコンテナの作成やアップデートを自動化できると便利です。

これを実現するために、Dockerfileとpodman buildを使います。この手順はArmadilloで実行可能です。

イメージを docker.io のイメージから作りなおします

[armadillo ~/podman-build]# cat Dockerfile
FROM docker.io/arm64v8/alpine:latest

# update & install dependencies (example: usbutils)
RUN apk upgrade && apk add usbutils && rm -f /var/cache/apk/*

# copy our application and set it to run on start
COPY my_application /my_application
ENTRYPOINT /my_application

[armadillo ~/podman-build]# podman build -t my_image:1 -t my_image:latest .
STEP 1: FROM docker.io/arm64v8/alpine:latest
STEP 2: RUN apk upgrade && apk add usbutils && rm -f /var/cache/apk/*
--> 234bf79175e
STEP 3: COPY my_application /my_application
--> 05ab31bb278
STEP 4: ENTRYPOINT /my_application
STEP 5: COMMIT my_image:latest
--> 590e3ba6d55
Successfully tagged localhost/my_image:1
Successfully tagged localhost/my_image:latest
590e3ba6d55f3e29bdef158d7283e9c4f7515567b2d3f978cfab2510dc02376b

[armadillo ~/podman-build]# podman save my_image:latest -o my_image_1.tar

図6.17 podman buildの実行例

イメージを前のバージョンからアップデートします

[armadillo ~/podman-build-update]# cat Dockerfile
FROM localhost/my_image:latest

# update OS packages
RUN apk upgrade --no-cache

# update application
COPY my_application /my_application
[armadillo ~/podman-build-update]# podman build -t my_image:2 -t my_image:latest .
STEP 1: FROM localhost/my_image:latest
STEP 2: RUN apk upgrade --no-cache
--> cf1dc0d7296
STEP 3: COPY my_application /my_application
STEP 4: COMMIT my_image:latest
--> 9e9d9366072
Successfully tagged localhost/my_image:2
Successfully tagged localhost/my_image:latest
9e9d9366072751007b2e70544d76c46b95a7a5a02df658ef0fa3f7dcccf8850a

[armadillo ~/podman-build-update]# podman save -o my_image_2.tar my_image:2

図6.18 podman buildでのアップデートの実行例

この場合、 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 で使えます。

6.2.2.8. コンテナを削除する

作成済みコンテナを削除する場合は podman rm コマンドを実行します。

[armadillo ~]# podman rm my_container
d6de5881b5fb973227b84d1d74abf269ac3183aad7e18b7a9d85208632641d94
[armadillo ~]# podman ps -a
CONTAINER ID  IMAGE                            COMMAND    CREATED         STATUS                    PORTS    NAMES

図6.19 コンテナを削除する実行例

podman ps コマンドの出力結果より、コンテナが削除されていることが確認できます。 podman rm コマンドの詳細は --help オプションで確認できます。

podman rm --help 実行例

[armadillo ~]# podman rm --help

6.2.2.9. イメージを削除する

podmanのイメージを削除するには podman rmi コマンドを実行します。イメージを削除するためには、そのイメージから作成したコンテナを先に削除しておく必要があります。 podman rmi コマンドにはイメージ ID を指定する必要があるため、podman images コマンドで確認します。

[armadillo ~]# podman rm my_container
[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE
docker.io/library/alpine  latest     02480aeb44d7  2 weeks ago  5.62 MB
[armadillo ~]# podman rmi 02480aeb44d7
Untagged: docker.io/library/alpine:latest
Deleted: 02480aeb44d78f1a44b8791af7edf7d6e1b18707397a1dfb3ff4f21c5ce4a44f
[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE

図6.20 イメージを削除する実行例

podman images コマンドの出力結果より、コンテナが削除されていることが確認できます。 podman rmi コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman rmi --help

図6.21 podman rmi --help 実行例

SWU で転送されたイメージは podman images で Read-Only として表示されますので、 podman rmi を実行するとエラーとなります。その場合は abos-ctrl podman-rw rmi をご使用ください。 abos-ctrl podman-rw については「イメージを eMMC に保存する」を参照してください。

[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE       R/O
docker.io/library/alpine  latest     02480aeb44d7  2 weeks ago  5.62 MB    true
[armadillo ~]# podman rmi docker.io/alpine
Error: cannot remove read-only image "02480aeb44d78f1a44b8791af7edf7d6e1b18707397a1dfb3ff4f21c5ce4a44f"
[armadillo ~]# abos-ctrl podman-rw rmi docker.io/alpine
Untagged: docker.io/library/alpine:latest
Deleted: 02480aeb44d78f1a44b8791af7edf7d6e1b18707397a1dfb3ff4f21c5ce4a44f
[armadillo ~]# podman images
REPOSITORY                TAG        IMAGE ID      CREATED      SIZE

図6.22 Read-Onlyのイメージを削除する実行例

6.2.2.10. 実行中のコンテナに接続する

実行中のコンテナに接続し、コンテナ内で指定したコマンドを実行するには podman exec コマンドを実行します。 podman exec コマンドでコンテナ内部のシェルを起動すると、コンテナ内部を操作できるようになります。ここでは、sleep infinity コマンドを実行して待ち続けるだけのコンテナを作成し、そのコンテナに対して podman exec コマンドでシェルを起動する例を示します。

[armadillo ~]# vi /etc/atmark/containers/sleep_container.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# podman_start sleep_container
Starting 'test'
f62e7a666d7156d261905c8406c72fc271534fa29e69771c76f4f6660a2da41a
[armadillo ~]# podman exec -it sleep_container sh
[container ~]# ps
PID   USER     TIME  COMMAND
    1 root      0:00 /run/podman-init -- sleep infinity
    2 root      0:00 sleep infinity
    3 root      0:00 sh
    4 root      0:00 ps

図6.23 コンテナ内部のシェルを起動する実行例

podman_start コマンドでコンテナを作成し、その後作成したコンテナ内で sh を実行しています。 sh を実行すると、コンテナ内のプロンプトが表示されコンテナ内部を操作できるようになります。上記ではコンテナ内で、ps コマンドを実行しています。コンテナ作成時に実行した sleep と podman exec で実行した sh がプロセスとして存在していることが確認できます。

コンテナ内のシェルから抜ける時は exit コマンドを実行します。

[container ~]# exit

図6.24 コンテナ内部のシェルから抜ける実行例

podman exec コマンドから抜けても、コンテナがまだ実行中です。コンテナを停止したい場合は podman stop sleep_container か podman kill sleep_container で停止して podman rm sleep_container でそのコンテナを削除してください。

podman exec コマンドの詳細は --help オプションで確認できます。

[armadillo ~]# podman exec --help

図6.25 podman exec --help 実行例

6.2.2.11. コンテナ間で通信をする

複数のコンテナを実行している環境で、それらのコンテナ間で通信を行う方法を示します。これにより、例えば SQL サーバを実行しているコンテナに対し別のコンテナから接続するといった使い方ができます。

コンテナには作成した時点でローカル IP アドレスが割り当てられるので、コンテナの名前かその IP アドレスで通信を行うことができます。

準備として、2 つのコンテナを作成します。

[armadillo ~]# vi /etc/atmark/containers/my_container_1.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# vi /etc/atmark/containers/my_container_2.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# podman_start my_container_1 my_container_2
Starting 'my_container_1'
cbe0802f4e2d2fec88f4e300dabeba3b48865359dc02cbd99375b1b38c2c28eb
Starting 'my_container_2'
5e645f5e40fc096ad0bea323a00bebebbda4bd825a5e8d12103f752d8868692e

図6.26 コンテナを作成する実行例

コンテナに割り当てられた IP アドレスを確認するには podman inspect コマンドを実行します。

[armadillo ~]# podman inspect --format='{{.NetworkSettings.IPAddress}}' my_container_1
10.88.0.108
[armadillo ~]# podman inspect --format='{{.NetworkSettings.IPAddress}}' my_container_2
10.88.0.109

図6.27 コンテナの IP アドレスを確認する実行例

これらの IP アドレスを使って、一方のコンテナからもう一方のコンテナへ対し ping コマンドで疎通確認を行うことができます。

[armadillo ~]# podman exec -it my_container_1 sh
[container ~]# ping -c 2 my_container_2
PING my_container_2 (10.88.0.109): 56 data bytes
64 bytes from 10.88.0.109: seq=0 ttl=42 time=0.144 ms
64 bytes from 10.88.0.109: seq=1 ttl=42 time=0.210 ms

--- my_container_2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.144/0.177/0.210 ms
[container ~]# ping -c 2 10.88.0.109
PING 10.88.0.109 (10.88.0.109): 56 data bytes
64 bytes from 10.88.0.109: seq=0 ttl=42 time=0.140 ms
64 bytes from 10.88.0.109: seq=1 ttl=42 time=0.138 ms

--- 10.88.0.109 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.138/0.139/0.140 ms

図6.28 ping コマンドによるコンテナ間の疎通確認実行例

このように、my_container_1(10.88.0.108) から my_container_2(10.88.0.109) への通信が確認できます。

6.2.2.12. podでコンテナのネットワークネームスペースを共有する

podman_start で pod 機能を使うことができます。

pod を使うことで、複数のコンテナが同じネットワークネームスペースを共有することができます。同じ pod の中のコンテナが IP の場合 localhost で、 unix socket の場合 abstract path で相互に接続することができます。

[armadillo ~]# cat /etc/atmark/containers/mypod.conf
set_type pod
add_ports 80:80

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
set_readonly no
set_pod mypod

[armadillo ~]# podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED      STATUS          PORTS               NAMES
0cdb0597b610  localhost/podman-pause:4.3.1-1683096588               2 hours ago  Up 2 hours ago  0.0.0.0:80->80/tcp  5ba7d996f673-infra
3292e5e714a2  docker.io/library/nginx:alpine  nginx -g daemon o...  2 hours ago  Up 2 hours ago  0.0.0.0:80->80/tcp  nginx

図6.29 podを使うコンテナを自動起動するための設定例

コンテナと同じく、 /etc/atmark/containers/[NAME].conf ファイルを作って、 set_type pod を設定することで pod を作成します。

pod を使う時にコンテナの設定ファイルに set_pod [NAME] の設定を追加します。

ネットワークネームスペースは pod を作成するときに必要なため、 ports, network と ip の設定は pod のコンフィグファイルに入れなければなりません。

必要であれば、他の podman pod create のオプションを add_args で設定することができます。

.conf ファイルで使用できる各種パラメータについては、「コンテナ起動設定ファイルを作成する」を参照してください。

6.2.2.13. networkの作成

podman_start で podman の network も作成できます。

デフォルトの 10.88.0.0/16 が使えない場合、あるいはコンテナ同士で接続できないようにしたい場合は使ってください。

[armadillo ~]# cat /etc/atmark/containers/mynetwork.conf
set_type network
set_subnet 198.51.100.0/24

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
add_ports 80:80
set_ip 198.51.100.10
set_network mynetwork

[armadillo ~]# podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED      STATUS          PORTS               NAMES
3292e5e714a2  docker.io/library/nginx:alpine  nginx -g daemon o...  2 hours ago  Up 2 hours ago  0.0.0.0:80->80/tcp  nginx

図6.30 networkを使うコンテナを自動起動するための設定例

コンテナと同じく、 /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 で設定することができます。

.conf ファイルで使用できる各種パラメータについては、「コンテナ起動設定ファイルを作成する」を参照してください。

6.2.2.14. コンテナからのコンテナ管理

podman では REST API による管理アクセスも可能です。

自分のコンテナから他のコンテナの管理が必要な場合に、ホストの podman サービスを有効にして、コンテナに /run/podman をボリュームマウントすれば podman --remote で管理できます。


	コンテナの設定によって podman の socket へのパスが自動設定されない場合もあります。 `podman --remote` でエラーが発生した場合に `CONTAINER_HOST=unix:/path/to/podman.sock` で socket へのパスを設定してください。

Armadillo のホスト側の udev rules からコンテナを起動する場合は podman_start 等を直接実行すると udev の子プロセス管理によってコンテナが停止されますので、その場合はサービスを有効にし、 podman_start --create <container> コマンドまたは set_autostart create　の設定でコンテナを生成した上 podman --remote start <container> で起動してください。

6.2.2.15. リモートリポジトリにコンテナを送信する

イメージをリモートリポジトリに送信する：

[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 を作成しました。

6.2.2.16. イメージを eMMC に保存する

Armadillo Base OS のデフォルトでは、Podman のデータは tmpfs に保存されます。

起動時にコンテナを起動するにはイメージを eMMC に書き込む必要があります。開発が終わって運用の場合は「イメージを SWUpdate で転送する」でコンテナのイメージを転送します。この場合は読み取り専用の app パーティションのサブボリュームに展開します。

開発の時に以下の abos-ctrl podman-rw か abos-ctrl podman-storage --disk のコマンドを使って直接にイメージを編集することができます。


	ここで紹介する内容はコンテナのイメージの管理の説明です。データベース等のコンテナから書き込みが必要な場合には「コンテナの変更を保存する」にあるボリュームの説明を参照してください。

abos-ctrl podman-rw

abos-ctrl podman-rw を使えば、read-only になっているイメージを扱う事ができます。

[armadillo ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED            SIZE        R/O
[armadillo ~]# mount /dev/sda1 /mnt
[armadillo ~]# abos-ctrl podman-rw load -i /mnt/at-debian-image.tar
Getting image source signatures
Copying blob 63c098a71e7b done
Copying blob 837e73dd4d20 done
Copying blob a25086e65f63 done
Copying config b5a30f8581 done
Writing manifest to image destination
Storing signatures
Loaded image(s): localhost/at-debian-image:latest
[armadillo ~]# podman image list
REPOSITORY                 TAG         IMAGE ID      CREATED      SIZE        R/O
localhost/at-debian-image  latest      b5a30f8581cc  2 hours ago  233 MB      true

図6.31 abos-ctrl podman-rw の実行例

abos-ctrl podman-storage

abos-ctrl podman-storage はメモリとディスクの切り替えの他に、読み書きストレージから読み取り専用ストレージへのコピーもできます。

[armadillo ~]# podman pull docker.io/alpine 
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob f97344484467 done
Copying config 3d81c46cd8 done
Writing manifest to image destination
Storing signatures
3d81c46cd8756ddb6db9ec36fa06a6fb71c287fb265232ba516739dc67a5f07d
[armadillo ~]# abos-ctrl podman-storage 
List of images configured on development storage:
REPOSITORY                TAG         IMAGE ID      CREATED     SIZE
docker.io/library/alpine  latest      3d81c46cd875  3 days ago  5.56 MB

What should we do? ([C]opy (default), [N]othing, [D]elete)
copy 
Create a snapshot of '/mnt/boot_1/containers_storage' in '/mnt/new_storage'
Getting image source signatures
Copying blob 8ec3165d6e61 done
Copying config 4a49b68e7c done
Writing manifest to image destination
Storing signatures
Delete subvolume (no-commit): '/mnt/new_storage'
Merging development images to readonly storage succeeded
Feel free to adjust the result with abos-ctrl podman-rw commands

Now freeing up original data...
Podman is in tmpfs mode 
[armadillo ~]# podman image list 
REPOSITORY                TAG         IMAGE ID      CREATED     SIZE        R/O
docker.io/library/alpine  latest      3d81c46cd875  3 days ago  5.56 MB     true

図6.32 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 を設定することで自動実行されません。

6.2.2.17. イメージを 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 arm64 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
aarch64
[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 arm64 docker.io/nginx:alpine
[ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m
aarch64
[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 を作成しました。

6.2.2.18. 開発時に有用な—privilegedオプション

コンテナに、全権限と全てのデバイスへのアクセスを許可するオプション --privileged があります。このオプションを利用すると、コンテナに与えるべき最小の権限を洗い出す必要が無いため、開発時に有用です。

実運用の際、このオプションを利用することはセキュリティー上問題がある為、開発時にのみご利用ください。コンテナに必要な最低限の権限を与えることをおすすめします。

6.2.3. コンテナとコンテナに関連するデータを削除する


	全てのコンテナとコンテナイメージ、コンテナに関するデータが削除されるため、充分に注意して使用してください。

6.2.3.1. VS Code から実行する

VS Code 上で ABOSDE(Armadillo Base OS Development Environment) から、 Armadillo のコンテナイメージを全て削除する SWU イメージを作成することができます。

VS Code の左ペインの [COMMON PROJECT COMMAND] から [Generate Container Clear Swu] を実行すると、SWU イメージが作成されます。 SWU イメージは ~/mkswu/container_clear.swu に保存されます。

この SWU イメージを「SWU イメージのインストール」を参照して Armadillo へインストールしてください。

images/common-images/vscode_container_clear.png

図6.33 Armadillo 上のコンテナイメージを削除する

6.2.3.2. コマンドラインから実行する

abos-ctrl container-clear を使用すると、コンテナ、コンテナイメージ、コンテナに関するデータを削除することができます。

abos-ctrl container-clear は以下の通り動作します。

以下のファイル、ディレクトリ配下のファイルを削除
- /var/app/rollback/volumes/
- /var/app/volumes/
- /etc/atmark/containers/*.conf
以下のファイルで container を含む行を削除
- /etc/sw-versions
- /etc/swupdate.watch

[armadillo ~]# abos-ctrl container-clear
This command will remove all containers and related data.
 - The following file and directories will be removed:
   - /var/app/rollback/volumes/
   - /var/app/volumes/
   - /etc/atmark/containers/*.conf
 - Lines containing the word "container" will be deleted from the following files:
   - /etc/sw-versions
   - /etc/swupdate.watch
Continue? [y/N]
y
Remove all container data succeeded

図6.34 abos-ctrl container-clear 実行例

6.2.4. コンテナ起動設定ファイルを作成する

Armadillo Base OSでは、/etc/atmark/containers/*.confファイルに指定されているコンテナがブート時に自動的に起動します。 nginx.confの記載例を以下に示します。

[armadillo ~]# cat /etc/atmark/containers/nginx.conf
set_image docker.io/library/nginx:alpine
set_readonly no
add_ports 80:80

図6.35 コンテナを自動起動するための設定例

.conf ファイルに設定可能なパラメーターの説明を以下に記載します。 podman_start --long-help コマンドでも詳細を確認できます。

6.2.4.1. コンテナイメージの選択

set_image [イメージ名]

イメージの名前を設定できます。

例: set_image docker.io/debian:latest, set_image localhost/myimage

イメージをrootfsとして扱う場合に --rootfs オプションで指定できます。

例: set_image --rootfs /var/app/volumes/debian

6.2.4.2. ポート転送

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の設定にしないと有効になりませんのでご注意ください。

6.2.4.3. デバイスファイル作成

add_devices [ホストパス]:[コンテナパス]

コンテナでデバイスを作成して、使用可能となります。

コンテナパスを設定しない場合はホストと同じパスを使います。

複数のデバイスを作成したい場合はスペースで分けて設定してください。

例: add_devices /dev/galcore /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"

コンテナパスに「:」を含むようなパスは設定できません。

6.2.4.4. ボリュームマウント

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のファームウェアを使えます。

「:」はホスト側のパスとコンテナの側のパスを分割する意味があるため、ファイル名に「:」を使用することはできません。ホスト側のパスにのみ「:」が含まれてる場合は「 add_volumes "[ホストパス]" "[コンテナパス]" "[オプション]" 」と指定することで設定できます。

複数のコンテナでマウントコマンドを実行することがあれば、shared のフラグで起動後のマウントを共有することができます。

[armadillo ~]# cat /etc/atmark/containers/mounter.conf
set_image docker.io/alpine
add_args -ti
add_volumes /tmp/mnt:/mnt:shared 
add_args --cap-add SYS_ADMIN
add_devices /dev/sda1
[armadillo ~]# cat /etc/atmark/containers/client.conf
set_image docker.io/alpine
add_volumes /tmp/mnt:/mnt:slave 
add_args -ti
[armadillo ~]# podman exec mounter mount /dev/sda1 /mnt 
[armadillo ~]# podman exec client ls /mnt 
file_on_usb

図6.36 ボリュームを shared でサブマウントを共有する例

	マウントを行うコンテナに `shared` の設定とマウント権限 (`SYS_ADMIN`) を与えます。
	マウントを使うコンテナに `slave` だけを設定すれば一方にしか共有されません。
	USB デバイスをマウントします。
	マウントされたことを確認します。

6.2.4.5. ホットプラグデバイスの追加

add_hotplugs [デバイスタイプ]

コンテナ起動後に挿抜を行なっても認識される(ホットプラグ)デバイスを設定できます。

通常、コンテナ内からデバイスを扱うためには、あらかじめ Armadillo 本体に当該のデバイスを接続した状態で、コンテナを起動する必要がありますが、 add_hotplugs を使用することでホットプラグに対応できます。

例: add_hotplugs input

add_hotplugs に指定できる主要な文字列とデバイスファイルの対応について、表6.1「add_hotplugsオプションに指定できる主要な文字列」に示します。

表6.1 add_hotplugsオプションに指定できる主要な文字列

文字列	引数の説明	対象のデバイスファイル
input	マウスやキーボードなどの入力デバイス	/dev/input/mouse0, /dev/input/event0 など
video4linux	USB カメラなどの video4linux デバイスファイル	/dev/video0 など
sd	USB メモリなどの SCSI ディスクデバイスファイル	/dev/sda1 など

表6.1「add_hotplugsオプションに指定できる主要な文字列」に示した文字列の他にも、/proc/devicesの数字から始まる行に記載されている文字列を指定することができます。図6.37「/proc/devicesの内容例」に示す状態の場合、デバイスタイプを示す文字列としては、各行の先頭の数字を除いた mem や pty などを指定できることがわかります。

[armadillo ~]# cat /proc/devices
Character devices:
  1 mem
  2 pty
  3 ttyp
  4 /dev/vc/0
  4 tty
  4 ttyS
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 29 fb
 81 video4linux
: (省略)

図6.37 /proc/devicesの内容例

デバイスタイプと実際のデバイスファイルの対応については、カーネルドキュメント: devices.txt(Github) を参照してください。

複数のデバイスタイプを指定したい場合はスペースで分けて設定してください。

例: add_hotplugs input video4linux sd

6.2.4.6. 個体識別情報の環境変数の追加

add_armadillo_env

アットマークテクノが設定した個体識別情報をコンテナの環境変数として追加することができます。

例: add_armadillo_env

add_armadillo_env を設定することで追加されるコンテナの環境変数について、表6.2「add_armadillo_envで追加される環境変数」に示します。

表6.2 add_armadillo_envで追加される環境変数

環境変数	環境変数の説明	表示例
AT_ABOS_VERSION	ABOSのバージョン	3.18.4-at.5
AT_LAN_MAC1	アットマークテクノが設定したLAN1（eth0）のMACアドレス	00:11:0C:12:34:56
AT_PRODUCT_NAME	製品名	Armadillo-X2
AT_SERIAL_NUMBER	個体番号	00C900010001

表6.2「add_armadillo_envで追加される環境変数」に示した環境変数をコンテナ上で確認する場合、図6.38「add_armadillo_envで設定した環境変数の確認方法」に示すコマンドを実行してください。ここでは、個体番号の環境変数を例に示します。

[container ~]# echo $AT_SERIAL_NUMBER
00C900010001

図6.38 add_armadillo_envで設定した環境変数の確認方法

お客様が独自の環境変数をコンテナに追加する場合は図5.4「個体番号の環境変数をconfファイルに追記」を参考にconfファイルを編集してください。

6.2.4.7. pod の選択

set_pod [ポッド名]

「podでコンテナのネットワークネームスペースを共有する」で作成した pod の名前を入れてコンテナを pod 内で起動します。

例: set_pod mypod

6.2.4.8. ネットワークの選択

set_network [ネットワーク名]

この設定に「networkの作成」で作成したネットワーク以外に none と host の特殊な設定も選べます。

none の場合、コンテナに localhost しかないネームスペースに入ります。

host の場合はOSのネームスペースをそのまま使います。

例: set_network mynetwork

6.2.4.9. IP アドレスの設定

set_ip [アドレス]

コンテナの IP アドレスを設定することができます。

例: set_ip 10.88.0.100


	コンテナ間の接続が目的であれば、podを使ってlocalhostかpodの名前でアクセスすることができます。

6.2.4.10. 読み取り専用設定

set_readonly yes

コンテナ内からのファイルシステムへの書き込み許可を設定します。

デフォルトで書き込み可能となっています。

コンテナ内からのファイルシステムへの書き込みを禁止することで、 tmpfs として使うメモリの消費を明示的に抑えることができますが、アプリケーションによっては読み込み専用のファイルシステムでは動作しない可能性もあります。

6.2.4.11. イメージの自動ダウンロード設定

set_pull [設定]

この設定を missing にすると、イメージが見つからない場合にイメージを自動的にダウンロードします。

always にすると、イメージがすでにダウンロード済みでも起動前に必ず更新の確認を取ります。

デフォルトでは never で、イメージが見つからない場合にエラーを表示します。

例：set_pull missing か set_pull always

6.2.4.12. コンテナのリスタート設定

set_restart [設定]

コンテナが停止した時にリスタートさせます。

podman kill か podman stop で停止する場合、この設定と関係なくリスタートしません。

デフォルトで on-failure になっています。

例: set_restart always か set_restart no

6.2.4.13. 信号を受信するサービスの無効化

set_init no

コンテナのメインプロセスが PID 1 で起動していますが、その場合のデフォルトの信号の扱いが変わります: SIGTERM などのデフォルトハンドラが無効です。

そのため、init 以外のコマンドを set_command で設定する場合は podman-init のプロセスを PID 1 として立ち上げて、設定したコマンドをその子プロセスとして起動します。

例: set_init no

6.2.4.14. podman logs 用のログサイズ設定

set_log_max_size <サイズ>

podman logs でログを表示するために /run にログファイルを保存しています。そのログのサイズが設定したサイズを越えるとクリアされます。デフォルトは「1MB」です。

6.2.4.15. podman のフックの仕組み

add_hook --stage <ステージ> [--] コマンド [コマンド引数]

コンテナが起動されるなど、動作ステージの変化をフックとしてコマンドを実行します。複数のステージで実行したい場合は --stage オプションを複数設定してください。

指定可能なステージは precreate, prestart, createRuntime, createContainer, startContainer, poststart, と poststop です。ステージの意味や使用方法の詳細は podman のドキュメンテーションを参照してください。


	Armadillo Base OS 3.19.1-at.4 現在では `set_restart` によるコンテナの再起動でも 1 度目の停止時のみ `poststop` フックが実行されます。 2 度目以降の停止では実行されませんのでご注意ください。

6.2.4.16. ヘルスチェック機能の設定

set_healthcheck [引数] [--] コマンド [コマンド引数]

定期的にコマンドを実行して、コンテナの正常性を確認します。指定可能な引数は以下のとおりです：

--retries <リトライ数>: エラーを検知するまでのリトライ回数。(デフォルト: 3)
--action <none|restart|kill|stop|reboot|rollback>: 指定したリトライ回数分連続でチェックが失敗したときのアクション (デフォルト: restart )：
- none: set_healthcheck_fail_command に指定した処理を実行する以外何もしません。
- restart: コンテナを再起動します。 set_restart オプションと異なり、コンテナを起動しなおし初期状態で再起動します。
- kill/stop: コンテナを停止します。
- reboot: Armadillo を再起動します。
- rollback: ロールバック可能の場合はロールバックして Armadillo を再起動します。ロールバック不可能な場合はそのまま Armadillo を再起動します。
--interval <時間>: チェックする時間間隔です。(デフォルト: 1 min)
--start-period <時間>: 最初のチェックを実行する前の待ち時間です。(デフォルト: interval 設定の値)
--timeout <秒数>: 設定された時間以内にヘルスチェックが終了しなかった場合は失敗となります。(デフォルト: 無し)

また、いくつかのタイミングでコマンドを実行させることができます：

set_healthcheck_start_command コマンド [コマンド引数]: コンテナ起動後にヘルスチェックが初めて成功した際に実行されるコマンドです。
set_healthcheck_fail_command コマンド [コマンド引数]: ヘルスチェックが retries 回失敗した後に実行されるコマンドです。このコマンドは set_healthcheck の --action 設定の前に実行されますので、コマンドだけを実行したい場合は --action none で無効化してください。
set_healthcheck_recovery_command コマンド [コマンド引数]: ヘルスチェックが retries 回失敗した後に再び成功した際に実行されるコマンドです。コンテナを起動する際に成功せずに失敗した場合は、その 1 回目の成功の際に set_healthcheck_start_command で設定されたコマンドのみが実行されます。

例: set_healtcheck -- curl -s --fail http://localhost:8080/status
例: set_healthcheck_start_command abos-ctrl rollback-clone

armadillo:~# grep podman_atmark /var/log/messages
Jun 20 11:33:21 armadillo user.notice podman_atmark: my_container healthcheck is now healthy (was starting)
Jun 20 11:33:21 armadillo user.notice podman_atmark: my_container first healthy check: running abos-ctrl rollback-clone
Jun 20 11:40:21 armadillo user.notice podman_atmark: my_container healthcheck failed (from healthy, 1 / 3)
Jun 20 11:41:21 armadillo user.notice podman_atmark: my_container healthcheck failed (from healthy, 2 / 3)
Jun 20 11:42:21 armadillo user.notice podman_atmark: my_container healthcheck failed (from healthy, 3 / 3)
Jun 20 11:42:21 armadillo user.notice podman_atmark: my_container is unhealthy, restarting container
Jun 20 11:43:21 armadillo user.notice podman_atmark: my_container healthcheck is now healthy (was failed)

図6.39 上記の例でエラーを発生させた際の起動ログ

6.2.4.17. 自動起動の無効化

set_autostart no または set_autostart create

Armadillo の起動時にコンテナを自動起動しないように設定できます。

create を指定した場合はコンテナは生成されており、podman start <name> で起動させることができます。

no を指定した場合は podman_start <name> で起動させることができます。


	コンフィグに記載していないイメージはアップデートの際に削除されますので、そういったイメージに対して設定してください。

6.2.4.18. 実行コマンドの設定

set_command [コマンド]

コンテナを起動するときのコマンド。設定されなかった場合、コンテナイメージのデフォルトを使います。

例: set_command /bin/sh -c "echo bad example"

6.2.4.19. コンテナ起動前にコマンドを実行する

add_pre_command [コマンド]

コンテナを起動する直前に設定したコマンドを実行します。

Armadillo Base OS の環境で実行されてますので、ハードウェアの設定等に適切です。

また、複数のコマンドを実行する場合は順番に実行されます。設定したコマンドが1つでも失敗した場合は、コンテナは起動されません。

例: add_pre_command gpioset gpiochipX Y=1

6.2.4.20. `podman run` に引数を渡す設定

add_args [引数]

ここまでで説明した設定項目以外の設定を行いたい場合は、この設定で podman run に直接引数を渡すことができます。

例：add_args --cap-add=SYS_TTY_CONFIG --env=XDG_RUNTIME_DIR=/run/xdg_home

6.2.5. アットマークテクノが提供するイメージを使う

アットマークテクノは、動作確認環境として使用できる Debian ベースのイメージを提供しています。ここでは以下の 3 つの手順について説明します。

ABOSDE からインストールする方法
Docker ファイルからイメージをビルドする方法
すでにビルド済みのイメージを使う方法

6.2.5.1. ABOSDE からインストールする

インストール用のプロジェクトを作成する
VS Code の左ペインの [G4/X2] から [Atmark Container New Project] を実行し、表示されるディレクトリ選択画面からプロジェクトを保存するディレクトリを選択してください。保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。この操作により、選択した保存先に、入力したプロジェクト名と同名のディレクトリが作成されます。
また、ここでは次のように設定しています。
- 保存先 : ホームディレクトリ
- プロジェクト名 : my_project
  図6.40 インストール用のプロジェクトを作成する
SWU イメージを作成する
VS Code の左ペインの [my_project] から [Generate at-debian-image container setup swu] を実行してください。
図6.41 at-debian-image のコンテナイメージをインストールする SWU ファイルを作成する

作成した SWU ファイルは container_setup/at-debian-image/at-debian-image.swu に保存されています。この SWU イメージを「SWU イメージのインストール」を参照して Armadillo へインストールしてください。
SBOM 生成に関わる設定を行う
ABOSDE から作成した場合は SBOM が同時に生成されます。詳細は「SBOM 生成に関わる設定を行う」をご確認ください。 SBOM の生成には以下の二つのファイルが必要です。
- コンフィグファイル
- desc ファイル
  SBOM の生成にはライセンス情報を示したコンフィグファイルを使用します。コンフィグファイルは container_setup/at-debian-image.sbom_config.yaml.tmpl になります。 SWU イメージ作成時にこのコンフィグファイルからバージョン番号をアップデートした container_setup/at-debian-image.sbom_config.yaml が生成されます。
  リリース時にはコンフィグファイルの内容を確認し、正しい内容に変更してください。各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。 SBOM に含めるコンテナイメージ等の情報については desc ファイルに記載されています。各項目の説明については「desc ファイルを編集する」をご覧ください。

6.2.5.2. Docker ファイルからイメージをビルドする

Armadillo-X2 コンテナから「Debian [VERSION] サンプル Dockerfile」ファイル (at-debian-image-dockerfile-[VERSION].tar.gz) をダウンロードします。その後 podman build コマンドを実行します。

[armadillo ~]# tar xzf at-debian-image-dockerfile-[VERSION].tar.gz
[armadillo ~]# cd at-debian-image-dockerfile-[VERSION]
[armadillo ~]# abos-ctrl podman-storage --disk
[armadillo ~]# podman build -t at-debian-image:latest .
:
: (省略)
:
[armadillo ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED             SIZE
localhost/at-debian-image  latest      c8e8d2d55456  About a minute ago  233 MB
docker.io/library/debian   bullseye    723b4a01cd2a  18 hours ago        123 MB

図6.42 Docker ファイルによるイメージのビルドの実行例

podman images コマンドにより at-debian-image がビルドされたことが確認できます。 library/debian イメージはベースとなっている Debian イメージです。

6.2.5.3. ビルド済みのイメージを使用する

Armadillo-X2 コンテナから「Debian [VERSION] サンプルコンテナイメージ」ファイル (at-debian-image-[VERSION].tar) をダウンロードします。その後 podman load コマンドを実行します。

[armadillo ~]# podman load -i at-debian-image-[VERSION].tar
:
: (省略)
:
[armadillo ~]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED       SIZE
localhost/at-debian-image  [VERSION]   93a4ec873ac5  17 hours ago  233 MB
localhost/at-debian-image  latest      93a4ec873ac5  17 hours ago  233 MB

図6.43 ビルド済みイメージを load する実行例

podman images コマンドにより at-debian-image がビルドされたことが確認できます。

6.2.6. alpine のコンテナイメージをインストールする

alpine のコンテナイメージは、 ABOSDE を用いてインストールすることが可能です。「ABOSDE からインストールする」を参照して、インストール用のプロジェクトを作成しておいてください。

VS Code の左ペインの [my_project] から [Generate alpine container setup swu] を実行してください。

images/abos-images/armadillo_setup_vscode_alpine_container_setup.png

図6.44 alpine のコンテナイメージをインストールする SWU ファイルを作成する

作成した SWU ファイルは container_setup/alpine/alpine.swu に保存されています。この SWU イメージを「SWU イメージのインストール」を参照して Armadillo へインストールしてください。

6.2.6.1. SBOM 生成に関わる設定を行う

ABOSDE から作成した場合は SBOM が同時に生成されます。詳細は「SBOM 生成に関わる設定を行う」をご確認ください。 SBOM の生成には以下の二つのファイルが必要です。

コンフィグファイル
desc ファイル

SBOM の生成にはライセンス情報を示したコンフィグファイルを使用します。コンフィグファイルは container_setup/alpine.sbom_config.yaml.tmpl になります。 SWU イメージ作成時にこのコンフィグファイルからバージョン番号をアップデートした container_setup/alpine.sbom_config.yaml が生成されます。

リリース時にはコンフィグファイルの内容を確認し、正しい内容に変更してください。各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。 SBOM に含めるコンテナイメージ等の情報については desc ファイルに記載されています。各項目の説明については「desc ファイルを編集する」をご覧ください。

6.2.7. コンテナのネットワークを扱う

この章では、コンテナ内のネットワークを扱う方法について示します。

6.2.7.1. コンテナの IP アドレスを確認する

基本的にコンテナの IP アドレスは Podman イメージからコンテナを作成したときに自動的に割り振られます。コンテナに割り振られている IP アドレスはホスト OS 側からは podman inspect コマンドを用いて、以下のように確認することができます。

[armadillo ~]# vi /etc/atmark/containers/net_example.conf
set_image docker.io/alpine
set_command sleep infinity
[armadillo ~]# podman_start net_example
Starting 'net_example'
48ae479af65445674323567c17c5418dd4624292351e061bd2bd8a0add4cf150
[armadillo ~]# podman inspect --format '{{ .NetworkSettings.IPAddress }}' net_example
10.88.0.17

図6.45 コンテナの IP アドレス確認例

コンテナ内の ip コマンドを用いて確認することもできます。

[armadillo ~]# podman exec net_example ip addr show eth0
3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.88.0.17/16 brd 10.88.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::40e5:98ff:feec:4b17/64 scope link
       valid_lft forever preferred_lft forever

図6.46 ip コマンドを用いたコンテナの IP アドレス確認例

6.2.7.2. コンテナに固定 IP アドレスを設定する

podman はデフォルトで 10.88.0.0/16 を使います。

他に使用しているIPアドレスと被った場合等はコンテナに別のIPアドレスを設定してください。

コンテナに固定 IP アドレスを設定するためには、最初にユーザ定義のネットワークを作成する必要があります。以下に 198.51.100.0/24 にユーザ定義のネットワークを作成する例を示します。

[armadillo ~]# vi /etc/atmark/containers/my_network.conf
set_type network
set_subnet 198.51.100.0/24
[armadillo ~]# podman_start my_network
Creating network 'my_network'
my_network

図6.47 ユーザ定義のネットワーク作成例

コンテナを作成する際に、上記で作成したネットワークと設定したい IP アドレスを渡すことで、コンテナの IP アドレスを固定することができます。以下の例では、IPアドレスを 198.51.100.10 に固定します。

[armadillo ~]# vi /etc/atmark/containers/network_example.conf
set_image docker.io/alpine
set_command sleep infinity
set_network my_network
set_ip 198.51.100.10
[armadillo ~]# podman_start network_example
Starting 'network_example'
3ea8c9031bf833228908bd73d8929b1d543b189b436c218e0634e0d39409e100

図6.48 IP アドレス固定のコンテナ作成例

コンテナの IP アドレスが、198.51.100.10 に設定されていることが確認できます。

[armadillo ~]# podman inspect --format '{{ .NetworkSettings.Networks.my_network.IPAddress }}' network_example
198.51.100.10

図6.49 コンテナの IP アドレス確認例

6.2.8. コンテナ内にサーバを構築する

この章では、コンテナ内で様々なサーバを構築する方法について示します。この章で取り上げているサーバは alpine の apk コマンドでインストールすることが可能です。

6.2.8.1. HTTP サーバを構築する

ここでは、HTTP サーバとして Apache と lighttpd の 2 種類を使用する場合について説明します。

Apache を使用する

alpine イメージからコンテナを作成し、そのコンテナ内に Apache をインストールします。コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/apache_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 8080:80
[armadillo ~]# podman_start apache_example
Starting 'apache_example'
ea0a1ed9c2fe170a6db02e480300467510f4e844900efb35c7a24cc1a8653af2
[armadillo ~]# podman exec -it apache_example sh
[container ~]# apk upgrade && apk add apache2
[container ~]# httpd
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.88.0.2. Set the 'ServerName' directive globally to suppress this message

図6.50 コンテナに Apache をインストールする例

他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると、動作確認用ページが表示されます。デフォルトでは、/var/www/localhost/htdocs ディレクトリにファイルを置くことで Web ブラウザから閲覧できます。 Apache の詳細な設定は、/etc/apache2 ディレクトリにある設定ファイルを編集することで変更可能です。

lighttpd を使用する

alpine イメージからコンテナを作成し、そのコンテナ内に lighttpd をインストールします。コンテナ作成の際に、ホスト OS の 8080 番ポートをコンテナ内の 80 番ポートに転送する指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/lighttpd_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 8080:80
[armadillo ~]# podman_start lighttpd_example
Starting 'lighttpd_example'
fd7ea338d09c5e8962654ed54bba17fb6a9ed4fca1b344e350bbf8f943d2f12b
[armadillo ~]# podman exec -it lighttpd_example sh
[container ~]# apk upgrade && apk add lighttpd
[container ~]# echo "<html><body>It works!</body></html>" > /var/www/localhost/htdocs/index.html
[container ~]# lighttpd -f /etc/lighttpd/lighttpd.conf

図6.51 コンテナに lighttpd をインストールする例

lighttpd はデフォルトでは動作確認用ページが用意されていないため、上記の手順では簡単なページを /var/www/localhost/htdocs ディレクトリの下に配置しています。他の PC などの Web ブラウザから、ホスト OS の IP アドレスの 8080 番ポートに接続すると表示されます。 lighttpd の詳細な設定は、/etc/lighttpd ディレクトリにある設定ファイルを編集することで変更可能です。

6.2.8.2. FTP サーバを構築する

ここでは、FTP サーバとして vsftp を使用する場合について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に vsftpd をインストールします。コンテナ作成の際に、FTP 通信で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定と、コンテナ内の環境変数として PASV_ADDRESS にホスト OS 側の IP アドレスの指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/ftp_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 21:21 21100-21110:21100-21110
add_args --env=PASV_ADDRESS=<ホストの IP アドレス>
[armadillo ~]# podman_start ftp_example
Starting 'ftp_example'
efcf1ba752c2db9ae1a33ac11af3be71d95ac7b737ce9734730ebca602e57796
[armadillo ~]# podman exec -it ftp_example sh
[container ~]# apk upgrade && apk add vsftpd

図6.52 コンテナに vsftpd をインストールする例

コンテナ内にユーザアカウントを作成し、このユーザで ftp ログインできるようにします。

[container ~]# adduser atmark
Changing password for atmark
New password: （パスワードを入力）
Retype password: （パスワードを入力）
passwd: password for atmark changed by root

図6.53 ユーザを追加する例

作成したユーザで ftp ログインできるように、vsftpd の設定ファイルを編集します。

[container ~]# sed -i -e 's/anonymous_enable=YES/#anonymous_enable=YES/g' /etc/vsftpd/vsftpd.conf
[container ~]# sed -i -e 's/#local_enable=YES/local_enable=YES/g' /etc/vsftpd/vsftpd.conf
[container ~]# sed -i -e 's/#write_enable=YES/write_enable=YES/g' /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_enable=YES" >> /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_min_port=21100" >> /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_max_port=21110" >> /etc/vsftpd/vsftpd.conf
[container ~]# echo "pasv_address=$PASV_ADDRESS" >> /etc/vsftpd/vsftpd.conf

図6.54 設定ファイルの編集例

編集した設定ファイルを指定して vftpd を起動することにより、ftp 接続可能となります。 ftp ログイン時のアカウントは前述の手順で作成したものを使用します。

[container ~]# vsftpd /etc/vsftpd/vsftpd.conf

図6.55 vsftpd の起動例

6.2.8.3. Samba サーバを構築する

ここでは、Samba サーバの構築方法について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に samba をインストールします。コンテナ作成の際に、samba で使用するポートについてホスト OS 側からコンテナ内のポートに転送する指定を行っています。

[armadillo ~]# vi /etc/atmark/containers/smb_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_ports 139:139 445:445
[armadillo ~]# podman_start smb_example
Starting 'smb_example'
6d81c01fe27b5a92ee6ea69de2f9a8dbb569d420c2f5f630ece1966c81824a1f
[armadillo ~]# podman exec -it smb_example sh
[container ~]# apk upgrade && apk add samba

図6.56 コンテナに samba をインストールする例

コンテナ内にユーザアカウントを作成し、このユーザで samba にログインできるようにします。

[container ~]# adduser atmark
Changing password for atmark
New password: （パスワードを入力）
Retype password: （パスワードを入力）
passwd: password for atmark changed by root
[container ~]# pdbedit -a atmark
new password: （パスワードを入力）
retype new password: （パスワードを入力）

図6.57 ユーザを追加する例

samba を起動すると、前述の手順で作成したユーザアカウントで他の PC などからログインすることができます。

[container ~]# smbd

図6.58 samba の起動例

共有するディレクトリの指定などの詳細設定は /etc/samba/smb.conf ファイルを編集することで変更可能です。

6.2.8.4. SQL サーバを構築する

ここでは、RDMS として sqlite を使用する場合について説明します。 alpine イメージからコンテナを作成し、そのコンテナ内に sqlite をインストールします。

[armadillo ~]# vi /etc/atmark/containers/sqlite_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_volumes /var/app/volumes/sqlite_db:/db
[armadillo ~]# podman_start sqlite_example
Starting 'sqlite_example'
114c5f1dbb7e81293dcb8fbe0c600b861626375b14cfe4023761acaa84fdcad1
[armadillo ~]# podman exec -it sqlite_example sh
[container ~]# apk upgrade && apk add sqlite

図6.59 コンテナに sqlite をインストールする例

コンテナ内に入り、sqlite3 コマンドを実行すると sqlite のプロンプトが表示されデータベースの操作ができるようになります。

[container ~]# sqlite3 /db/mydb.sqlite
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite>

図6.60 sqlite の実行例

6.2.9. 画面表示を行う

この章では、コンテナ内で動作するアプリケーションから Armadillo-X2 に接続されたディスプレイに出力を行う方法について示します。

6.2.9.1. Wayland を扱う

コンテナ内から、Wayland のコンポジタである weston を起動し画面表示を行う例を示します。ここではアットマークテクノが提供するイメージからコンテナを作成します。このイメージに関しては「アットマークテクノが提供するイメージを使う」を参照してください。

[armadillo ~]# vi /etc/atmark/containers/wayland_example.conf
set_image localhost/at-debian-image:latest
add_args --env=XDG_RUNTIME_DIR=/tmp 
add_devices /dev/dri /dev/galcore /dev/tty7 
add_devices /dev/input 
add_volumes /run/udev:/run/udev:ro 
add_volumes /opt/firmware:/opt/firmware:ro 
add_args --cap-add=SYS_TTY_CONFIG 
set_command weston --tty 7 
[armadillo ~]# podman_start wayland_example
Starting 'wayland_example'
654fe87422f85e8835b00761071347bafa632f969645db5fa835c88e2a55e2cc

図6.61 Wayland を扱うためのコンテナ作成例

	weston の実行に必要な環境変数を設定します。
	画面描画に必要なデバイスを設定します。
	キーボードやマウスなどを使用可能にするためのデバイスを設定します。
	ホスト OS 側の /run/udev をコンテナ内からマウントするように設定します。
	ホスト OS 側の /opt/firmware をコンテナ内からマウントするように設定します。
	tty を操作するための権限を設定します。
	weston を起動します。ここで設定する tty は `add_devices` の tty7 を使います。

次に、以下のように weston を起動します。オプションである --tty に設定する値は、コンテナ作成時に渡した tty の数字にします。

[armadillo ~]# podman logs wayland_example
Date: 2021-11-21 UTC
[23:46:52.823] weston 9.0.0
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: lf-5.10.35-2.0.0-rc2-0-g230e9bc+
[23:46:52.825] Command line: weston --tty=7
[23:46:52.825] OS: Linux, 5.10.52-1-at, #2-Alpine SMP PREEMPT Thu Nov 18 09:10:13 UTC 2021, aarch64
[23:46:52.826] Using config file '/etc/xdg/weston/weston.ini'
[23:46:52.829] Output repaint window is 16 ms maximum.
[23:46:52.831] Loading module '/usr/lib/aarch64-linux-gnu/libweston-9/drm-backend.so'
[23:46:52.897] initializing drm backend
[23:46:52.897] logind: not running in a systemd session
[23:46:52.897] logind: cannot setup systemd-logind helper (-2), using legacy fallback
[23:46:52.902] using /dev/dri/card1
[23:46:52.902] DRM: supports atomic modesetting
[23:46:52.902] DRM: does not support GBM modifiers
[23:46:52.902] DRM: supports picture aspect ratio
[23:46:52.903] Loading module '/usr/lib/aarch64-linux-gnu/libweston-9/g2d-renderer.so'
[23:46:52.982] event1  - gpio-keys: is tagged by udev as: Keyboard
[23:46:52.983] event1  - gpio-keys: device is a keyboard
[23:46:52.986] event0  - audio-hdmi HDMI Jack: is tagged by udev as: Switch
[23:46:53.027] event0  - not using input device '/dev/input/event0'
[23:46:53.066] libinput: configuring device "gpio-keys".
[23:46:53.067] DRM: head 'LVDS-1' found, connector 39 is connected, EDID make 'unknown', model 'unknown', serial 'unknown'
[23:46:53.067] DRM: head 'HDMI-A-1' found, connector 40 is disconnected.
[23:46:53.067] Registered plugin API 'weston_drm_output_api_v1' of size 24
[23:46:53.067] Compositor capabilities:
               arbitrary surface rotation: yes
               screen capture uses y-flip: yes
               presentation clock: CLOCK_MONOTONIC, id 1
               presentation clock resolution: 0.000000001 s
[23:46:53.070] Loading module '/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so'
[23:46:53.073] launching '/usr/libexec/weston-keyboard'
[23:46:53.079] Loading module '/usr/lib/aarch64-linux-gnu/libweston-9/xwayland.so'
[23:46:53.210] Registered plugin API 'weston_xwayland_v1' of size 32
[23:46:53.210] Registered plugin API 'weston_xwayland_surface_v1' of size 16
[23:46:53.210] xserver listening on display :0
[23:46:53.211] launching '/usr/libexec/weston-desktop-shell'
[armadillo ~]# podman exec -ti wayland_example bash
[container ~]# weston-terminal

図6.62 コンテナ内で weston を起動したログの出力とアプリケーションの実行例

Armadillo-X2 に接続しているディスプレイ上に、デスクトップ画面が表示されます。

weston の設定

アットマークテクノが提供するイメージでは、weston の設定ファイルは /etc/xdg/weston/weston.ini に配置してあります。

[container ~]# cat /etc/xdg/weston/weston.ini
[core]
idle-time=0
use-g2d=1
xwayland=true
repaint-window=16

[shell]
panel-position=none

[output]
name=HDMI-A-1
mode=1920x1080 

[output]
name=LVDS-1
mode=off

図6.63 weston.ini

この行でHDMIモニタに出力する画像の解像度指定を行うことができます。初期値は1920x1080です。

weston.ini で解像度を指定しない場合や、指定した解像度にモニタが対応していない場合は、モニタが対応している別な解像度に自動的に切り替わります。その場合、意図しない解像度で描画されることがあります。 GUIアプリケーションの描画の乱れにつながる場合がありますので、予め使用するモニタに合わせて解像度を指定しておくことをお勧めします。

設定ファイルを更新するにはコンテナイメージを新しく保存することもできますが、ボリュームを使ってこのファイルだけを更新することができます。

[armadillo ~]# vi /etc/atmark/containers/wayland_example.conf
...
add_volumes weston_conf:/etc/xdg/weston 
[armadillo ~]# mkdir /var/app/rollback/volumes/weston_conf
[armadillo ~]# cp weston.ini /var/app/rollback/volumes/weston_conf/ 
[armadillo ~]# podman_start wayland_example 
Starting 'wayland_example'
654fe87422f85e8835b00761071347bafa632f969645db5fa835c88e2a55e2cc
7a1e74510b14012110bfc4daf6f56cb0554378f513bc77554016b616e7452d58
[armadillo ~]# persist_file -v /etc/atmark/containers/wayland_example.conf 
'/etc/atmark/containers/wayland_example.conf' -> '/mnt/etc/atmark/containers/wayland_example.conf'

図6.64 weston.ini をボリュームで渡す実行例

	コンフィグファイルにボリュームを追加します。 `weston_conf` は相対パスなので `/var/app/rollback/volumes/weston_conf` がマウントされます。ボリュームの選択については「コンテナの変更を保存する」を参照ください。
	コンフィグをコピーします。
	コンテナを再起動させます。
	動作確認ができた後にコンフィグファイルを保存します。

weston の運用

コンテナの管理として、一つのコンテナで一つのアプリケーションを動かす事を推奨します。

一つのコンテナでwestonを起動して、 XDG_RUNTIME_DIRを共有することで別のコンテナでwestonを使用するアプリケーションを起動させることは以下のコンフィグで可能です。

[armadillo ~]# vi /etc/atmark/containers/weston.conf 
set_image localhost/at-debian-image:latest
add_devices /dev/dri /dev/galcore /dev/input /dev/tty7
add_volumes /run/udev:/run/udev:ro /opt/firmware:/opt/firmware:ro
add_volumes /tmp/xdg_home:/run/xdg_home
add_args --env=XDG_RUNTIME_DIR=/run/xdg_home 
add_args --cap-add=SYS_TTY_CONFIG
set_command weston --tty=7
[armadillo ~]# vi /etc/atmark/containers/detect_object.conf 
set_image localhost/at-debian-image:latest
add_devices /dev/galcore /dev/video3
add_volumes /opt/firmware:/opt/firmware:ro /tmp/xdg_home:/run/xdg_home
set_restart always 
add_args --env=XDG_RUNTIME_DIR=/run/xdg_home
set_command /root/start_detect_object.sh
[armadillo ~]# podman_start weston 
[armadillo ~]# podman_start detect_object

	westonの設定ファイルを作成します。
	XDG_RUNTIME_DIR を `volume` で共有して、同じディレクトリを使います。
	例としてdetect_objectという名前のクライアントの設定ファイルを作成します。ここでは任意の名前を設定できます。
	アプリケーションによっては、westonが異常終了した時にエラーを出力しない場合があるため、`set_restart always` にします。
	確認のためコンテナを手動で起動します。

ユーザを指定して weston を起動する

アットマークテクノが提供するイメージ at-debian-image にはデフォルトで atmark ユーザが存在しています。 at-weston-launch コマンドを使うと、 root ユーザではなく atmark ユーザで weston を起動することができます。

[armadillo ~]# vi /etc/atmark/containers/weston.conf 
set_image localhost/at-debian-image:latest
add_devices /dev/dri /dev/galcore /dev/input /dev/tty7 
add_volumes /run/udev:/run/udev:ro /opt/firmware:/opt/firmware:ro
add_volumes /tmp/xdg_home:/run/xdg_home
add_args --env=XDG_RUNTIME_DIR=/run/xdg_home
add_args --cap-add=SYS_TTY_CONFIG
set_command at-weston-launch --tty /dev/tty7 --user atmark 
[armadillo ~]# podman_start weston

	westonの設定ファイルを作成します。
	使用する tty として /dev/tty7 を追加します。
	at-weston-launch コマンドのオプションとして使用する tty とユーザ名を渡します。
	確認のためコンテナを手動で起動します。

--tty と --user を指定しなかった場合は、デフォルトで /dev/tty7 と atmark ユーザが使われます。

スクリーンショットを保存する

weston を起動する際に、--debug オプションを渡すと weston-screenshooter コマンドでスクリーンショットを保存することができます。

[armadillo ~]# vi /etc/atmark/containers/weston.conf 
set_image localhost/at-debian-image:latest
add_devices /dev/dri /dev/galcore /dev/input /dev/tty7
add_volumes /run/udev:/run/udev:ro /opt/firmware:/opt/firmware:ro
add_volumes /tmp/xdg_home:/run/xdg_home
add_args --env=XDG_RUNTIME_DIR=/run/xdg_home
add_args --cap-add=SYS_TTY_CONFIG
set_command weston --tty=7 --debug 
[armadillo ~]# podman_start weston 
[armadillo ~]# podman exec -it weston /bin/bash 
[container ~]# weston-screenshooter 
[container ~]# ls
wayland-screenshot-[date].png

	westonの設定ファイルを作成します。
	--debug オプションを渡します。
	確認のためコンテナを手動で起動します。
	起動した weston コンテナ内で /bin/bash を起動してログインします。
	weston-screenshooter コマンドを実行します。
	カレントディレクトリ内に wayland-screenshot-[date].png というファイル名で保存されます。


	--debug オプションは開発時にのみ使用してください。正式運用時の使用は非推奨です。


	Armadillo-X2 にキーボードを接続している場合は、--debug オプションを渡さなくても Windows キー + s を押下することによりスクリーンショットを保存することができます。この場合、スクリーンショットはコンテナ内の /proc/[weston の PID]/cwd 下に保存されます。

6.2.9.2. X Window System を扱う

コンテナ内から、X Window System を起動し画面表示を行う例を示します。ここではアットマークテクノが提供するイメージからコンテナを作成します。このイメージに関しては「アットマークテクノが提供するイメージを使う」を参照してください。

[armadillo ~]# vi /etc/atmark/containers/x_example.conf
set_image at-debian-image
set_command sleep infinity
add_devices /dev/tty7 
add_devices /dev/fb0 
add_devices /dev/input 
add_volumes /run/udev:/run/udev:ro 
add_args --cap-add=SYS_ADMIN 
[armadillo ~]# podman_start x_example
Starting 'x_example'
26847e21bd519f99466af32fdf0d809e2216d3e8ddf05c185e5428fe46e6a09b

図6.65 X Window System を扱うためのコンテナ起動例

	X Window System に必要な tty を設定します。どこからも使われていない tty とします。
	画面描画先となるフレームバッファを設定します。
	キーボードやマウスなどを使用可能にするためのデバイスを設定します。
	ホスト OS 側の /run/udev をコンテナ内からマウントするように設定します。
	X Window System の動作に必要な権限を設定します。

次に、以下のように X Window System を起動します。オプションである vt に設定する値は、コンテナ作成時に渡した tty の数字にします。

[armadillo ~]# podman exec -ti x_example bash
[container ~]# apt install xorg
[container ~]# X vt7 -retro

X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: linux Debian
Current Operating System: Linux 25297ceb226c 5.10.52-1-at #2-Alpine SMP PREEMPT Thu Nov 18 09:10:13 UTC 2021 aarch64
Kernel command line: console=ttymxc1,115200 root=/dev/mmcblk2p1 rootwait ro
Build Date: 13 April 2021  04:07:31PM
xorg-server 2:1.20.11-1 (https://www.debian.org/support)
Current version of pixman: 0.40.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov 21 23:51:18 2021
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

図6.66 コンテナ内で X Window System を起動する実行例

Armadillo-X2 に接続しているディスプレイ上に、デスクトップ画面が表示されます。

6.2.9.3. フレームバッファに直接描画する

コンテナ内で動作するアプリケーションからフレームバッファに直接描画するためには、Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/fbN を渡す必要があります。以下は、/dev/fb0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/fb_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/fb0
[armadillo ~]# podman_start fb_example
Starting 'fb_example'
e8a874e922d047d5935350cd7411682dbbeb90fa828cef94af36acfb6d77476e

図6.67 フレームバッファに直接描画するためのコンテナ作成例

コンテナ内に入って、ランダムデータをフレームバッファに描画する例を以下に示します。これにより、接続しているディスプレイ上の表示が変化します。

[armadillo ~]# podman exec -it fb_example sh
[container ~]# cat /dev/urandom > /dev/fb0
cat: write error: No space left on device

図6.68 フレームバッファに直接描画する実行例

6.2.9.4. タッチパネルを扱う

タッチパネルが組み込まれているディスプレイを接続している環境で、コンテナ内からタッチイベントを取得するためには、Podman のイメージからコンテナを作成する際にホスト OS 側の /dev/input を渡す必要があります。

[armadillo ~]# vi /etc/atmark/containers/touch_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/input
[armadillo ~]# podman_start touch_example
Starting 'touch_example'
cde71165076a413d198864899b64ff9c5fecdae222d9ee6646e189b5e976d94a

図6.69 タッチパネルを扱うためのコンテナ作成例

Wayland などの GUI 環境と組み合わせて使うことで、タッチパネルを利用した GUI アプリケーションの操作が可能となります。

6.2.9.5. VPU を扱う

Armadillo-X2 で採用している i.MX 8M Plus には、動画のエンコード/デコード処理に特化した演算ユニットである VPU (Video Processing Unit) が搭載されています。 VPU を活用することでシステム全体のパフォーマンスを落とすことなく、動画のエンコード/デコード処理を行うことができます。コンテナ内で動作するアプリケーションから VPU を扱うためには、コンテナ作成時にデバイスとして、 /dev/mxc_hantro と /dev/mxc_hantro_vc8000e および /dev/ion を渡す必要があります。ここではアットマークテクノが提供するイメージからコンテナを作成します。このイメージに関しては「アットマークテクノが提供するイメージを使う」を参照してください。

[armadillo ~]# vi /etc/atmark/containers/vpu_example.conf
set_image at-debian-image
set_command sleep infinity
add_devices /dev/mxc_hantro /dev/mxc_hantro_vc8000e
add_devices /dev/ion
[armadillo ~]# podman_start vpu_example
Starting 'vpu_example'
2aeea66c6f54abddc7d4dbdca915b279acd6962ce0c06b36c7173ec36f1c88ee
[armadillo ~]# podman exec -it vpu_example /bin/bash
[container ~]# ls /dev/mxc_hantro /dev/mxc_hantro_vc8000e /dev/ion
/dev/ion  /dev/mxc_hantro  /dev/mxc_hantro_vc8000e

図6.70 VPU を扱うためのコンテナ作成例

weston と GStreamer がインストール済みのイメージと組み合わせて使うことで、 VPU を使用して動画のエンコード/デコードを行うことができます。

[armadillo ~]# vi /etc/atmark/containers/gst_example.conf
set_image at-debian-image
set_command sleep infinity
add_devices /dev/dri /dev/galcore
add_devices /dev/mxc_hantro /dev/mxc_hantro_vc8000e
add_devices /dev/ion /dev/video3
add_devices /dev/input /dev/tty7
add_volumes /run/udev:/run/udev:ro
add_volumes /opt/firmware:/opt/firmware:ro
add_args --cap-add=SYS_TTY_CONFIG
[armadillo ~]# podman_start gst_example
Starting 'gst_example'
1332389d3c7004b623cee4227545c62aefd17b363c9a0a494d7bb217341c38ae

図6.71 weston と GStreamer を扱うためのコンテナ作成例

このようにして作成したコンテナにログインすると、 GStreamer で VPU を使用した動画のエンコード/デコードが行なえます。

[armadillo ~]# podman exec -ti gst_example bash
[container ~]# apt install gstreamer1.0-imx libgstreamer-imx gstreamer1.0-plugins-bad \
libgstreamer-plugins-bad1.0-0 gstreamer1.0-plugins-base libgstreamer-plugins-base1.0-0 \
gstreamer1.0-plugins-good libgstreamer1.0-0 gstreamer1.0-tools gstreamer1.0-imx-tools
[container ~]# weston --tty=7 &
[container ~]# gst-launch-1.0 filesrc location=<ファイル名> ! qtdemux ! h264parse ! vpudec ! queue ! waylandsink

図6.72 GStreamer によるデコード実行例

USB カメラも組み合わせると、カメラからの映像をエンコードしてファイルに保存することも可能です。

[container ~]# gst-launch-1.0 -e v4l2src device=/dev/video3 ! video/x-raw,width=640,height=480,framerate=30/1 ! queue ! vpuenc_h264 ! h264parse ! queue ! qtmux ! filesink location=./output.mp4

図6.73 GStreamer によるエンコード実行例

上記を実行することで、USB カメラからの映像が H.264 にエンコードされてファイルに保存されます。この例ではカメラデバイスを /dev/video3 としていますが、環境によって異なりますので適切なものを設定してください。

6.2.10. パワーマネジメント機能を使う

この章では、コンテナ内からパワーマネジメント機能を使う方法について示します。

6.2.10.1. サスペンド状態にする

パワーマネジメント機能を使ってサスペンド状態にするには、Podman のイメージからコンテナを作成する際にホスト OS 側の /sys ディレクトリを渡す必要があります。以下は、/sys を渡して alpine イメージからコンテナを作成する例です。ここで渡された /sys ディレクトリはコンテナ内の /sys にマウントされます。

[armadillo ~]# vi /etc/atmark/containers/pm_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_volumes /sys
[armadillo ~]# podman_start pm_example
Starting 'pm_example'
ab656f08a6cba2dc5919dbc32f8a6209782ba04baa0c6c21232a52046a21337e

図6.74 パワーマネジメント機能を使うためのコンテナ作成例

コンテナ内から、/sys/power/state に次の文字列を書き込むことにより、サスペンド状態にすることができます。

表6.3 対応するパワーマネジメント状態

パワーマネジメント状態	文字列	説明
`Suspend-to-RAM`	`mem`	最も消費電力を抑えることができる
`Suspend-to-Idle`	`freeze`	最も短時間で復帰することができる

[armadillo ~]# podman exec -it pm_example sh
[container ~]# echo mem > /sys/power/state

図6.75 サスペンド状態にする実行例

6.2.10.2. 起床要因を有効化する

サスペンド状態からの起床要因として、利用可能なデバイスを以下に示します。

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/32f10100.usb/power/wakeup

RTC(i.MX8MP)

起床要因

アラーム割り込み

実行例

[armadillo ~]# vi /etc/atmark/containers/rtc_pm_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_volumes /sys
add_devices /dev/rtc0
[armadillo ~]# podman_start rtc_pm_example
Starting 'rtc_pm_example'
8fbef3edda3b7fcea5b1f8cbf960cf469b7e82c4d1ecd35477076e81fc24e39f
[armadillo ~]# podman exec -ti rtc_pm_example sh
[container ~]# apk add util-linux
[container ~]# rtcwake -m mem -s 5
: (省略)
[  572.720300] printk: Suspending console(s) (use no_console_suspend to debug)
<ここで5秒を待つ>
[  573.010663] Disabling non-boot CPUs ...
...

図6.76 サスペンド状態にする実行例、rtcで起こす


	RV-8803-C7は、毎分 0 秒にしかアラーム割り込みを発生させることができません。 0 時 0 分 30 秒の時に、1 秒後にアラームが鳴るように設定しても、実際にアラーム割り込みが発生するのは 0 時 1 分 0 秒となります。

ユーザースイッチ

起床要因

ユーザースイッチ押下

有効化

[armadillo ~]# vi /boot/overlays.txt 
fdt_overlays=armadillo_iotg_g4-sw1-wakeup.dtbo

[armadillo ~]# persist_file -vp /boot/overlays.txt 
'/boot/overlays.txt' -> '/mnt/boot/overlays.txt'
Added "/boot/overlays.txt" to /etc/swupdate_preserve_files

[armadillo ~]# reboot 
: (省略)
Applying fdt overlay: armadillo_iotg_g4-sw1-wakeup.dtbo 
: (省略)

[armadillo ~]# cat /sys/devices/platform/gpio-keys/power/wakeup 
enabled

	`/boot/overlays.txt` ファイルに「armadillo_iotg_g4-sw1-wakeup.dtbo」を追加します。ファイルが存在しない場合は新規に作成してください。このファイルの詳細については「DT overlay によるカスタマイズ」を参照してください。
	`/boot/overlays.txt` を保存し、アップデートの場合でも保存します。
	overlay の実行のために再起動します。
	シリアルコンソールの場合に、u-bootによるメッセージを確認できます。
	Linux からも確認できます。

SMS 受信(LTE モデルのみ)

起床要因: SMS 受信

6.2.10.3. パワーマネジメントの仕様

Armadillo-X2のパワーマネジメント機能は、LinuxのSPM(System Power Management)およびDPM(Device Power Management)を利用しています。パワーマネジメント状態を省電力モードに遷移させることにより、Armadillo-X2の消費電力を抑えることができます。

パワーマネジメント状態を省電力モードに遷移させると、アプリケーションの実行は一時停止し、Linuxカーネルはサスペンド状態となります。起床要因が発生すると、Linuxカーネルのリジューム処理が行われた後、アプリケーションの実行を再開します。

sysfsファイル

/sys/power/state

Armadillo-X2が対応するパワーマネジメント状態と、/sys/power/stateに書き込む文字列の対応を次に示します。

表6.4 対応するパワーマネジメント状態

パワーマネジメント状態	文字列	説明
`Suspend-to-RAM`	`mem`	Suspend-to-Idleよりも消費電力を抑えることができる
`Suspend-to-Idle`	`freeze`	suspend-to-ramよりも短時間で復帰することができる

起床要因として利用可能なデバイスは次の通りです。

USBコンソールインターフェース(CON6)

起床要因

データ受信

有効化

[armadillo ~]# echo enabled > /sys/class/tty/ttymxc1/power/wakeup

USBインターフェース(CON4)

起床要因

USBデバイスの挿抜

有効化

[armadillo ~]# echo enabled > /sys/devices/platform/soc@0/32f10100.usb/power/wakeup
[armadillo ~]# echo enabled > /sys/bus/usb/devices/usb1/power/wakeup

RTC(SNVS_HP Real Time Counter)

起床要因

アラーム割り込み

有効化

デフォルトで有効化されています

RTC(RV-8803-C7)

起床要因

アラーム割り込み

有効化

デフォルトで有効化されています

6.2.11. コンテナからのpoweroff及びreboot

Armadillo Base OSはbusybox initでshutdownとrebootを対応します。

busybox initでPID 1にsignalを送ることでshutdownやrebootとなります。コンテナからsignalを送るように、pid namespaceを共有する必要がありますが、共有されたらkillで実行できます。

[armadillo ~]# vi /etc/atmark/containers/shutdown_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_args --pid=host
[armadillo ~]# podman_start shutdown_example
Starting 'shutdown_example'
c8e3b9b418fc72395db9f3c22b1eb69eb41eaaf790d3b7151047ef066cc4c8ff
[armadillo ~]# podman exec -ti shutdown_example sh
[container ~]# kill -USR2 1  (poweroff)
[container ~]# kill -TERM 1  (reboot)

図6.77 コンテナからshutdownを行う

6.2.12. 異常検知

この章では、コンテナ内で動作しているアプリケーションに何らかの異常が発生し停止してしまった際に、ソフトウェアウォッチドッグタイマーを使って、システムを再起動する方法について示します。

6.2.12.1. ソフトウェアウォッチドッグタイマーを扱う

コンテナ内で動作するアプリケーションからソフトウェアウォッチドッグタイマーを扱うためには、Podman のイメージからコンテナを作成する際にホスト OS 側のデバイスファイル /dev/watchdogN を渡す必要があります。以下は、/dev/watchdog0 を渡して alpine イメージからコンテナを作成する例です。

[armadillo ~]# vi /etc/atmark/containers/watchdog_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/watchdog0
[armadillo ~]# podman_start watchdog_example
Starting 'watchdog_example'
a5d329cca49d60423ce4155d72a119b8049a03dbd1d0277817a253e96dce7bc7

図6.78 ソフトフェアウォッチドッグタイマーを使うためのコンテナ作成例

ソフトウェアウォッチドッグタイマーは、プログラム内からデバイスファイル /dev/watchdog0 を open した時点で起動します。コンテナ内に入ってソフトウェアウォッチドッグタイマーを echo コマンドで起動する例を以下に示します。

[armadillo ~]# podman exec -it watchdog_example sh
[container ~]# echo > /dev/watchdog0

図6.79 コンテナ内からソフトウェアウォッチドッグタイマーを起動する実行例

ソフトウェアウォッチドッグタイマーを起動した後、/dev/watchdog0 に（ V 以外の）任意の文字を書き込むことでソフトウェアウォッチドッグタイマーをリセットすることができます。 60 秒間（ V 以外の）任意の文字の書き込みがない場合は、システムが再起動します。

[armadillo ~]# podman exec -it watchdog_example sh
[container ~]# echo a > /dev/watchdog0

図6.80 ソフトウェアウォッチドッグタイマーをリセットする実行例

ソフトウェアウォッチドッグタイマーを停止したい場合は、/dev/watchdog0 に V を書き込みます。

[armadillo ~]# podman exec -it watchdog_example sh
[container ~]# echo V > /dev/watchdog0

図6.81 ソフトウェアウォッチドッグタイマーを停止する実行例

6.2.13. NPU を扱う

Armadillo-X2 で採用している i.MX 8M Plus には、機械学習に特化した演算処理ユニットである NPU (Neural Processor Unit) が搭載されています。 NPU を活用することで、顔認識や物体認識などの推論処理を高速に行うことができます。

コンテナ内で動作するアプリケーションから NPU を扱うためには、アットマークテクノが提供するコンテナイメージである at-debian-image を使用する必要があります。また、コンテナ作成時にデバイスとして、/dev/galcore を渡す必要があります。以下は、/dev/galcore を渡して at-debian-image からコンテナを作成する例です。このイメージに関しては「アットマークテクノが提供するイメージを使う」を参照してください。

[armadillo ~]# vi /etc/atmark/containers/npu_example.conf
set_image at-debian-image
set_command sleep infinity
add_devices /dev/galcore
add_volumes /opt/firmware:/opt/firmware:ro
[armadillo ~]# podman_start npu_example
Starting 'npu_example'
cf27a327d19d8bc37e3722fe6101c7d52fbf984351056e1c0ca4e89ff041cfbb
[armadillo ~]# podman exec -it npu_example sh
[container ~]# ls /dev/galcore
/dev/galcore

図6.82 NPU を扱うためのコンテナ作成例


	i.MX 8M Plus に搭載されている NPU は INT8 で量子化された学習済みモデルを高速に推論するように設計されています。 INT8 で量子化されていないモデルの場合、正常に推論できない、または推論実行速度の低下が発生する場合があります。

具体的な機械学習アプリケーションの開発方法については、NXP Semiconductors の公式サイトを参照してください。

アットマークテクノからも機械学習に関する開発ガイドを公開していますので、そちらも参照してください。 Armadillo Base OS 開発ガイド。

6.2.13.1. ONNX Runtime を使う

ONNX Runtime は学習済みの ONNX モデルを使って推論を行うためのソフトウェアです。^[13] Armadillo-X2 では、NPU を使って ONNX Runtime を実行することができます。

ONNX Runtime をインストールする

at-debian-image から作成したコンテナであれば、apt install でインストールすることができます。

[armadillo ~]# vi /etc/atmark/containers/onnxruntime_example.conf
set_image at-debian-image
set_command sleep infinity
add_devices /dev/galcore
add_volumes /opt/firmware:/opt/firmware:ro
[armadillo ~]# podman_start onnxruntime_example
Starting 'onnxruntime_example'
3aaefa9bdc4d7423385ee249b022ed4056a40cd66ce52b9d3eb8363379907d00
[armadillo ~]# podman exec -ti onnxruntime_example bash
[container ~]# apt install onnxruntime onnxruntime-dev onnxruntime-tools python3-onnxruntime

図6.83 ONNX Runtime をインストールする例

python から ONNX Runtime を使う

python から ONNX Runtime を使うためには onnxruntime モジュールを import します。また、NPU を使うために InferenceSession オブジェクトを作成する際に、Providers として「VsiNpuExecutionProvider」を指定します。

[container ~]# python3
>>> import onnxruntime
: (省略)
>>> sess = onnxruntime.InferenceSession('model.onnx', providers=['VsiNpuExecutionProvider'])

図6.84 python から ONNX Runtime を使う例

以上により、python から ONNX Runtime を使うことができます。

6.2.13.2. TensorFlow Lite を使う

TensorFlow Lite からも NPU を使って高速に推論を行うことができます。

TensorFlow Lite をインストールする

at-debian-image から作成したコンテナであれば、apt install でインストールすることができます。

[armadillo ~]# vi /etc/atmark/containers/tflite_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/galcore
add_volumes /opt/firmware:/opt/firmware:ro
[armadillo ~]# podman_start tflite_example
Starting 'tflite_example'
1b7cc807b7f2857a406528f295040c817e24572f7c8abf7e6a32a62fc4f3793b
[armadillo ~]# podman exec -ti tflite_example bash
[container ~]# apt install tensorflow-lite tensorflow-lite-dev python3-tflite-runtime \
tim-vx tensorflow-lite-vx-delegate

図6.85 TensorFlow Lite をインストールする例

python から TensorFlow Lite を使う

python から TensorFlow Lite を使うためには Interpreter モジュールを import します。 python から TensorFlow Lite を使う場合は特別な設定をしなくても、自動的に NPU が使われます。

[container ~]# python3
>>> from tflite_runtime.interpreter import Interpreter
: (省略)
>>> interpreter = Interpreter('model.tflite')

図6.86 python から TensorFlow Lite を使う例

以上により、python から TensorFlow Lite を使うことができます。

tflite-runtime パッケージと、ライブラリイメージ(imx_lib)のバージョンの組み合わせによっては、使用する delegate とライブラリの整合性が取れずに TensorFlow Liteを用いたアプリケーションが正しく動作しない場合があります。

バージョン 2.6.0-1 以降の tflite-runtime パッケージを使用する際には、必ずバージョン 2.2.0 以降のライブラリイメージ(imx_lib)を使用してください。

ライブラリイメージのアップデート方法については「VPU や NPU を使用する」を参照してください。

それぞれのバージョンと動作の関係を表6.5「ライブラリと tflite-runtime のバージョンと NPU を用いたアプリケーションの動作の関係」に示します。

表6.5 ライブラリと tflite-runtime のバージョンと NPU を用いたアプリケーションの動作の関係

	tflite-runtime のバージョンが 2.6.0-1 以降	tflite-runtime のバージョンが 2.6.0-1 未満
ライブラリのバージョンが確認できる(2.2.0 以降)	VX delegateで動作	NNAPI delegate で動作
ライブラリのバージョンが確認できない(2.2.0 未満)	正しく動作しない場合あり	NNAPI delegate で動作

ライブラリのバージョン確認手順については、「ライブラリイメージのバージョンを確認する」を参照してください。

tflite-runtime パッケージのバージョンは、コンテナ内で以下のコマンドを実行することで確認できます。

[container ~]# dpkg -l python3-tflite-runtime
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version      Architecture Description
+++-======================-============-============-===============================================
ii  python3-tflite-runtime 2.6.0-1      arm64        deep learning framework for on-device inference

図6.87 tflite-runtime のバージョンを確認する

推奨はしませんが、 tflite-runtime のバージョンを 2.6.0-1 未満に下げたい場合は表6.6「2.6.0-1 未満の TensorFlow Lite 関連 deb パッケージ」に示す deb パッケージを全てコンテナ内にダウンロードして、図6.88「tflite-runtime のバージョンを下げる」のコマンドを実行してください。

表6.6 2.6.0-1 未満の TensorFlow Lite 関連 deb パッケージ

パッケージ名	バージョン	URL
python3-tflite-runtime	2.4.0-1	https://download.atmark-techno.com/debian/pool/main/t/tensorflow-lite/python3-tflite-runtime_2.4.0-1_arm64.deb
python3-tflite-runtime-dbgsym	2.4.0-1	https://download.atmark-techno.com/debian/pool/main/t/tensorflow-lite/python3-tflite-runtime-dbgsym_2.4.0-1_arm64.deb
tensorflow-lite	2.4.0-1	https://download.atmark-techno.com/debian/pool/main/t/tensorflow-lite/tensorflow-lite_2.4.0-1_arm64.deb
tensorflow-lite-dev	2.4.0-1	https://download.atmark-techno.com/debian/pool/main/t/tensorflow-lite/tensorflow-lite-dev_2.4.0-1_arm64.deb

[container ~]# ls ./*.deb 
python3-tflite-runtime_2.4.0-1_arm64.deb
python3-tflite-runtime-dbgsym_2.4.0-1_arm64.deb
tensorflow-lite_2.4.0-1_arm64.deb
tensorflow-lite-dev_2.4.0-1_arm64.deb
[container ~]# apt purge \
tensorflow-lite \
tensorflow-lite-dev \
tensorflow-lite-vx-delegate \
tensorflow-lite-vx-delegate-dev \
python3-tflite-runtime \
tim-vx \
tim-vx-dev 
[container ~]# apt install ./*.deb

図6.88 tflite-runtime のバージョンを下げる

	カレントディレクトリに表6.6「2.6.0-1 未満の TensorFlow Lite 関連 deb パッケージ」の deb パッケージのみ存在していることを確認します。
	2.6.0-1 以上のインストールされているパッケージを削除します。
	ダウンロードした deb パッケージをインストールします。

6.2.13.3. Arm NN を使う


	Arm NN はコンテナイメージ at-debian-image のバージョン 1.0.6 以降では、動作非対応となります。現在利用中の at-debian-image のバージョンは以下のコマンドで確認できます。 [armadillo ~]# podman inspect --format='{{.Config.Labels.version}}' localhost/at-debian-image 1.0.6 図6.89 at-debian-image のバージョンを確認する

Arm NN とは TensorFlow Lite および ONNX のモデル形式をサポートしている推論用ソフトウェアです。 Arm NN からも NPU を使って高速に推論を行うことができます。

Arm NN をインストールする

at-debian-image から作成したコンテナであれば、apt install でインストールすることができます。

[armadillo ~]# vi /etc/atmark/containers/armnn_example.conf
set_image docker.io/alpine
set_command sleep infinity
add_devices /dev/galcore
add_volumes /opt/firmware:/opt/firmware:ro
[armadillo ~]# podman_start armnn_example
Starting 'armnn_example'
18892fb9fc82f36a6de1bb9036af6e76ee552cf66e1537d70666319bb35af1e1
[armadillo ~]# podman exec -ti armnn_example bash
[container ~]# apt install libarmnn22 libarmnn-dev python3-pyarmnn armnn-examples

図6.90 Arm NN をインストールする例

python から Arm NN を使う

python から Arm NN を使うためには pyarmnn モジュールを import します。また、NPU を使うために BackendId として「VsiNpu」を指定して、Optimize オブジェクトを作成します。

[container ~]# python3
>>> import pyarmnn as ann
: (省略)
>>> options = ann.CreationOptions()
>>> runtime = ann.IRuntime(options)
>>> parser = ann.ITfLiteParser()
>>> network = parser.CreateNetworkFromBinaryFile('model.tflite')
>>> preferred_backends = []
>>> preferred_backends.append(ann.BackendId('VsiNpu'))
>>> opt_network, _ = ann.Optimize(network, preferred_backends, runtime.GetDeviceSpec(), ann.OptimizerOptions())
>>> net_id, _ = runtime.LoadNetwork(opt_network)

図6.91 python から Arm NN を使う例

以上により、python から Arm NN を使うことができます。

6.3. swupdateを使用してアップデートする

6.3.1. swupdate で可能なアップデート

swupdate を実行する目的としては以下が考えられます。

コンテナをアップデートしたい
開発したコンテナのアップデートが可能です。

ユーザーデータディレクトリや Armadillo Base OS のファイルを差分アップデートしたい

ユーザーデータをアップデートする場合は、以下のディレクトリを更新します。

/var/app/rollback/volumes

ユーザーディレクトリについては「電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)」を参照してください。

SWUpdate による /var/app/volumes の更新は推奨しません。

/var/app/volumes が二面化されていないため、書込みの途中で問題が発生した場合、不完全な書込みになる恐れがあります。

また、アップデート中にアプリケーションがそのデータにアクセスすると、書込み中のデータにアクセスすることになります。

/var/app/volumes のデータに対して更新が必要な場合、SWUpdate では /var/app/rollback/volumes に更新するデータを書き込んでください。その後、次回起動時にアプリケーション側から /var/app/rollback/volumes に書き込んだデータを /var/app/volumes に移動するようにしてください。

Armadillo Base OS を一括アップデートしたい
アットマークテクノがリリースする Armadillo Base OS の機能追加、更新、セキュリティパッチの追加が可能です。
ブートローダーをアップデートしたい
アットマークテクノがリリースするブートローダーのアップデートが可能です。

「Armadillo Base OSとは」で示すように、Armadillo Base OS は OS・ブートローダー・コンテナ部分の安全性を担保するため二面化しています。

それにより、万が一アップデートに失敗した場合でも起動中のシステムに影響ありません。

以降、それぞれの目的ごとに swupdate によるアップデートの流れを示します。

a, b の場合
「コンテナのアップデート、ユーザーデータディレクトリや Armadillo Base OS の差分アップデート」を参照してください。
c の場合
「Armadillo Base OS の一括アップデート」を参照してください。
d の場合
「ブートローダーのアップデート」を参照してください。

6.3.2. コンテナのアップデート、ユーザーデータディレクトリや Armadillo Base OS の差分アップデート

以下にアップデートの流れを示します。

ここでは、boot して起動中の面を A 面、アップデート先の面を B 面とします。

Armadillo Base OS を B 面へコピー
Armadillo Base OS を B 面にコピーする流れを図6.92「Armadillo Base OS を B 面にコピー」に示します。
A 面と B 面の Armadillo Base OS が同期しているか確認します。
同期していない場合、 A 面の Armadillo Base OS を B 面にコピーします。
同期している場合はコピーしません。
swdesc_option version で指定するバージョンの書き方については「インストールバージョンを指定する」を参照してください。
図6.92 Armadillo Base OS を B 面にコピー

コマンドを順番に実行

図6.93「desc ファイルに記述したswudesc_* コマンドを実行」に示すように、desc ファイルに記述した順番に従って swudesc_* コマンドを実行します。

「インストールバージョンを指定する」に示すように、swdesc_* コマンドによって Armadillo Base OS に対して書き込みをする場合は --extra-os オプションをつけてください。

images/abos-images/swupdate/swupdate_exec_command_string_extra_os.png

図6.93 desc ファイルに記述したswudesc_* コマンドを実行

swudesc_* コマンドの種類を表6.7「swudesc_* コマンドの種類」に示します。

表6.7 swudesc_* コマンドの種類

おおまかな機能	コマンド名	説明
ファイル転送参照先：「Armadillo へファイルを転送する」	swdesc_files	指定したファイルをアップデート先の環境にコピー
ファイル転送参照先：「Armadillo へファイルを転送する」	swdesc_tar	指定した tar アーカイブをアップデート先の環境に展開してコピー
コマンド実行参照先：「Armadillo 上で任意のコマンドを実行する」	swdesc_command	指定したコマンドをアップデート先の環境で実行
コマンド実行参照先：「Armadillo 上で任意のコマンドを実行する」	swdesc_script	指定したスクリプトをアップデート先の環境で実行
ファイル転送 + コマンド実行参照先：「Armadillo にファイルを転送し、そのファイルをコマンド内で使用する」	swdesc_exec	指定したファイルをアップデート先の環境にコピーした後、そのファイル名を"$1"としてコマンドを実行
起動中の面に対してコマンド実行（非推奨）参照先：「動作中の環境でのコマンドの実行」	swdesc_command_nochroot	指定したコマンドを起動中の環境で実行
起動中の面に対してコマンド実行（非推奨）参照先：「動作中の環境でのコマンドの実行」	swdesc_script_nochroot	指定したスクリプトを起動中の環境で実行
起動中の面に対してファイル転送 + コマンド実行（非推奨）参照先：「動作中の環境でのコマンドの実行」	swdesc_exec_nochroot	指定したファイルを起動中の環境にコピーした後、そのファイル名を"$1"としてコマンドを実行
コンテナイメージの転送参照先：「Armadillo にコンテナイメージを転送する」	swdesc_embed_container	SWU ファイルに含まれるコンテナイメージの tar アーカイブをアップデート先の環境に展開
	swdesc_pull_container	アップデート先の環境でコンテナイメージをダウンロード
	swdesc_usb_container	SWU ファイルに含めない形で用意したコンテナイメージの tar アーカイブをアップデート先の環境に展開

アップデート完了後の挙動

デフォルトではアップデート後に再起動（ POST_ACTION=reboot ）が行われます。

images/abos-images/swupdate/swupdate_post_action_string_extra_os.png

図6.94 アップデート完了後の挙動

アップデート後の挙動を変更するには desc ファイルに swdesc_option POST_ACTION を追加してください。

swdesc_option POST_ACTION に指定できる挙動の種類を表6.8「アップデート完了後の挙動の種類」に示します。

表6.8 アップデート完了後の挙動の種類

オプション名	説明
container	アップデート後にコンテナのみを再起動（ただし、アップデート時に --extra_os オプションを指定したコマンドが実行された場合は reboot になる）
poweroff	アップデート後にシャットダウン
reboot	アップデートの後に再起動
wait	アップデート後に再起動は行われず、次回起動時に B 面に切り替わる

swdesc_option POST_ACTION の詳細は「SWUpdate 実行中/完了後の挙動を指定する」を参照してください。

B 面への切り替え
図6.95「B 面への切り替え」に示すように、正常にアップデートが行われると、次回起動時に B 面に切り替わります。
図6.95 B 面への切り替え
desc ファイルの書き方の例
下記に SWUpdate を用いたアップデートの例を示します。
- コンテナイメージとコンテナ自動設定ファイルのアップデート：「イメージを SWUpdate で転送する」
- sshdの設定：「例: sshdを有効にする」

6.3.3. Armadillo Base OS の一括アップデート

アップデートの流れを示します。

ここでは、boot して起動中の面を A 面、アップデート先の面を B 面とします。

Armadillo Base OS とアップデート後に保持するファイルを B 面へコピー
Armadillo Base OS とアップデート後に保持するファイルを B 面にコピーする流れを図6.96「Armadillo Base OS とファイルを B 面にコピー」に示します。
「インストールバージョンを指定する」に示すように、Armadillo Base OS の tar アーカイブを展開する swdesc_tar コマンドに --base-os オプションをつけてください。
swdesc_option version で指定するバージョンの書き方については「インストールバージョンを指定する」を参照してください。
図6.96 Armadillo Base OS とファイルを B 面にコピー
1. /etc/swupdate_preserve に記載された POST 指定以外のファイルを B 面にコピーします。
2. SWU ファイル内にある Armadillo Base OS を B 面に展開します。
3. /etc/swupdate_preserve に記載された POST 指定のファイルを B 面にコピーします。
/etc/swupdate_preserve への追記方法については「swupdate_preserve_files について」と「/etc/swupdate_preserve_fileへの追記」を参照してください。

コマンドを順番に実行

図6.97「desc ファイルに記述したswudesc_* コマンドを実行」に示すように、desc ファイルに記述した順番に従って swudesc_* コマンドを実行します。

images/abos-images/swupdate/swupdate_exec_command_base_os.png

図6.97 desc ファイルに記述したswudesc_* コマンドを実行

swudesc_* コマンドの種類を表6.9「swudesc_* コマンドの種類」に示します。

表6.9 swudesc_* コマンドの種類

おおまかな機能	コマンド名	説明
ファイル転送参照先：「Armadillo へファイルを転送する」	swdesc_files	指定したファイルをアップデート先の環境にコピー
ファイル転送参照先：「Armadillo へファイルを転送する」	swdesc_tar	指定した tar アーカイブをアップデート先の環境に展開してコピー
コマンド実行参照先：「Armadillo 上で任意のコマンドを実行する」	swdesc_command	指定したコマンドをアップデート先の環境で実行
コマンド実行参照先：「Armadillo 上で任意のコマンドを実行する」	swdesc_script	指定したスクリプトをアップデート先の環境で実行
ファイル転送 + コマンド実行参照先：「Armadillo にファイルを転送し、そのファイルをコマンド内で使用する」	swdesc_exec	指定したファイルをアップデート先の環境にコピーした後、そのファイル名を"$1"としてコマンドを実行
起動中の面に対してコマンド実行（非推奨）参照先：「動作中の環境でのコマンドの実行」	swdesc_command_nochroot	指定したコマンドを起動中の環境で実行
起動中の面に対してコマンド実行（非推奨）参照先：「動作中の環境でのコマンドの実行」	swdesc_script_nochroot	指定したスクリプトを起動中の環境で実行
起動中の面に対してファイル転送 + コマンド実行（非推奨）参照先：「動作中の環境でのコマンドの実行」	swdesc_exec_nochroot	指定したファイルを起動中の環境にコピーした後、そのファイル名を"$1"としてコマンドを実行
コンテナイメージの転送参照先：「Armadillo にコンテナイメージを転送する」	swdesc_embed_container	SWU ファイルに含まれるコンテナイメージの tar アーカイブをアップデート先の環境に展開
	swdesc_pull_container	アップデート先の環境でコンテナイメージをダウンロード
	swdesc_usb_container	SWU ファイルに含めない形で用意したコンテナイメージの tar アーカイブをアップデート先の環境に展開
ブートローダーの更新参照先：「Armadillo のブートローダーを更新する」	swdesc_boot	SWU ファイルに含まれるブートローダーをアップデート先の環境に展開

アップデート完了後の挙動

デフォルトではアップデート後に再起動（ POST_ACTION=reboot ）が行われます。

images/abos-images/swupdate/swupdate_post_action_base_os.png

図6.98 アップデート完了後の挙動

アップデート後の挙動を変更するには desc ファイルに swdesc_option POST_ACTION を追加してください。

swdesc_option POST_ACTION に指定できる挙動の種類を表6.10「アップデート完了後の挙動の種類」に示します。

表6.10 アップデート完了後の挙動の種類

オプション名	説明
poweroff	アップデート後にシャットダウン
reboot	アップデートの後に再起動
wait	アップデート後に再起動は行われず、次回起動時に B 面に切り替わる

swdesc_option POST_ACTION の詳細は「SWUpdate 実行中/完了後の挙動を指定する」を参照してください。

B 面への切り替え
図6.99「B 面への切り替え（component=base_os）」に示すように、正常にアップデートが行われると、次回起動時に B 面に切り替わります。
図6.99 B 面への切り替え（component=base_os）
desc ファイルの書き方の例
下記に SWUpdate を用いたアップデートの例を示します。
- Armadillo Base OS のアップデート：「例: Armadillo Base OSアップデート」
- Alpine Linux ルートファイルシステムのアップデート：「Alpine Linux ルートファイルシステムをビルドする」

6.3.4. ブートローダーのアップデート

swdesc_* コマンドには、swdesc_boot を指定してください。

swdesc_boot については「Armadillo のブートローダーを更新する」を参照してください。

ブートローダーのアップデートの流れは以下の通りです。

desc ファイルに swdesc_boot がある場合
SWU ファイルに含まれるブートローダーを B 面に書き込む
desc ファイルに swdesc_boot がない場合
A 面のブートローダーを B 面にコピーする

下記に SWUpdate を用いたアップデートの例を示します。

ブートローダーのアップデート：「ブートローダーをビルドする」

6.3.5. swupdate がエラーする場合の対処

SWU イメージのインストール動作は、「SWU イメージとは」で述べたように swupdate が実行します。 mkswu で作成した SWU イメージの内容が適切でなかったり、あるいは、ストレージの空き容量が不足していたりするなど、いくつかの理由で swupdate のインストール動作が失敗することがあります。インストールに失敗すると、swupdate は /var/log/messages にエラーメッセージのログを残しますので、エラーメッセージを見ると、エラーの内容・原因が分かります。

エラーの原因ごとに、エラーメッセージとエラーの内容および対処方法を記した FAQ ページ (https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos) を公開しています。 SWU イメージのインストールに失敗して対処法が分からないときは、この FAQ ページをご覧ください。

6.4. mkswu の .desc ファイルを編集する

mkswu で SWU イメージを生成するためには、 desc ファイルを正しく作成する必要があります。以下では、 desc ファイルの記法について紹介します。

6.4.1. インストールバージョンを指定する

swdesc_option component=<component>
swdesc_option version=<version>
か
swdesc_xxx --version <component> <version> [options]

<component>は以下のどれかにしてください (デフォルトでは .desc ファイルのファイル名を使います）
1. base_os: rootfs (Armadillo Base OS)を最初から書き込む時に使います。現在のファイルシステムは保存されないです。
  この場合、/etc/swupdate_preserve_filesに載ってるファイルのみをコピーして新しいbase OSを展開します。
  このcomponentがないと現在のrootfsのすべてがコピーされます。
  swdesc_tar コマンドで rootfs (Armadillo Base OS) の tar アーカイブを展開する時に、--base-os オプションをつけることで component に base_os を指定したときと同じ動作となります。
2. extra_os.<文字列>: rootfsの変更を行う時に使います。<文字列> には任意の文字列を指定します。
  rootfsを変更を行う時に使います。 swdesc_* コマンドに --extra-os オプションを追加すると、 component に自動的に extra_os. を足します。
3. <文字列> (コンテナの名前などの任意の文字列）: rootfsの変更がないときに使います。
  このcomponentを使うとrootfsの変更ができませんのでご注意ください。
アップデートを行う際にこのバージョンと現在のバージョンを比べてアップデートの判断を行います。
<component> がまだインストールされてなかった時や <version> が上がる時にインストールします。
デフォルトではダウングレードはできませんが、 --install-if=different オプションを追加することで <version> が変わる際にインストール可能になります。
アップデートの一部をインストールすることもありますので、複数の component で管理し、いくつかの古いバージョンに対応するアップデートも作成可能です。
バージョンの指定方法
swdesc_option version で指定可能なバージョンのフォーマットは以下の 2 種類があります。
- x[.y[.z[-t]]]
  x, y, z にはそれぞれ 0 ～ 2147483647 の整数を適用してください。 t には任意のアルファベットまたは 0 ～ 147483647 の整数を適用してください。
  成功例は以下です：
  - 1
  - 1.2.3
  - 1.2.3-4
  - 1.2.3-abc.4
  - 1.2.3-a.b.c.4
  失敗例は以下です：
  - 2147483648
    x には 0 ～ 2147483647 の整数を適用してください。
  - 1.2.3-a.2147483648
    t には 0 ～ 2147483647 の整数を適用してください。
  - 1.2.3-abc123
    t には数字とアルファベットを混在しないでください。 1.2.3-abc.123 ならば可能です。
  - a.2.3
    x にはアルファベットではなく 0 ～ 2147483647 の整数を適用してください。
  - 1.1.1.1-a
    x[.y[.z[-t]]]の形式で書いてください。
- x.y.z.t
  x, y, z, t にはそれぞれ 0 ～ 65535 の整数を適用してください。
  成功例は以下です：
  - 1.2.3.4
  - 65535.65535.65535.65535
  - 65535.2.3.4
  失敗例は以下です：
  - 65536.2.3.4
    x には 0 ～ 65535 の整数を適用してください。
  - 1.2.3.a
    t にはアルファベットではなく 0 ～ 65535 の整数を適用してください。
  - 1.2.3.4.5
    x.y.z.t の形式で書いてください。

6.4.2. Armadillo へファイルを転送する

swdesc_tar と swdesc_files でファイルを転送します。
```
swdesc_tar [--dest <dest>] [--preserve-attributes] <tar_file>
swdesc_files [--dest <dest>] [--basedir <basedir>] [--preserve-attributes] \
             <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 を使ってください。
--preserve-attributes を指定しない場合はファイルのオーナー、モード、タイムスタンプ等が保存されませんので、必要な場合は設定してください。バージョンが base_os の場合は自動的に設定されます。
swdesc_files の場合、mkswu がアーカイブを作ってくれますが同じ仕組みです。
--basedir <basedir> でアーカイブ内のパスをどこで切るかを決めます。
- 例えば、swdesc_files --extra-os --basedir /dir /dir/subdir/file ではデバイスに /subdir/file を作成します。
- デフォルトは <file> から設定されます。ディレクトリであればそのまま basedir として使います。それ以外であれば親ディレクトリを使います。

6.4.3. Armadillo 上で任意のコマンドを実行する

swdesc_command や swdesc_script でコマンドを実行します。
```
swdesc_command <command> [<more commands>]
swdesc_script <script>
```
アップデート先の環境でコマンドやスクリプトファイルを実行します。
バージョンの component は base_os と extra_os 以外の場合、 /var/app/volumes と /var/app/rollback/volumes 以外は変更できないのでご注意ください。
コマンドの実行が失敗した場合、アップデートも失敗します。

6.4.4. Armadillo にファイルを転送し、そのファイルをコマンド内で使用する

swdesc_exec でファイルを配り、コマンド内でそのファイルを使用します。
```
swdesc_exec <file> <command>
```
swdesc_command と同じくコマンドを実行しますが、<file> を先に転送してコマンド内で転送したファイル名を"$1"として使えます。

6.4.5. 動作中の環境でのコマンドの実行

本節で紹介する swdesc_command_nochroot、swdesc_script_nochroot、swdesc_exec_nochroot は基本的に使用することはありません。

swdesc_command、swdesc_script、swdesc_exec をご使用ください。

swdesc_command_nochroot, swdesc_script_nochroot, swdesc_exec_nochroot はアップデート先の環境ではなく動作中の環境でコマンドを実行します。

使い方は「Armadillo へファイルを転送する」と「Armadillo にファイルを転送し、そのファイルをコマンド内で使用する」に示した nochroot なしのバージョンと同じです。

アップデート先の環境は /target にマウントされるので、nochroot のコマンドを用いてアップデート先の環境に対してアクセスすることは可能です。

しかし、その方法によるアップデート先の環境に対するコマンドの実行は nochroot なしのコマンドでは実現できない特殊な場合にのみ行ってください。

nochroot コマンドは確認を一切しないため、Armadillo が起動できない状態になる可能性もあります。充分にご注意ください。

例が必要な場合は /usr/share/mkswu/examples/firmware_update.desc を参考にしてください。

6.4.6. Armadillo にコンテナイメージを転送する

swdesc_embed_container, swdesc_usb_container, swdesc_pull_container で予め作成したコンテナを転送します。
```
swdesc_embed_container <container_archive>
swdesc_usb_container <container_archive>
swdesc_pull_container <container_url>
```
例は「リモートリポジトリにコンテナを送信する」、「イメージを SWUpdate で転送する」を参考にしてください。

6.4.7. Armadillo のブートローダーを更新する

swdesc_boot でブートローダーを更新します。
```
swdesc_boot <boot image>
```
このコマンドだけはバージョンは自動的に設定されます。

6.4.8. SWU イメージの設定関連

コマンドの他には、設定変数もあります。以下の設定は /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>: 暗号化の鍵

6.4.9. Armadillo 上のコンテナイメージと自動起動用confファイルを削除する

以下のオプションも mkswu.conf に設定できますが、.descファイルにも設定可能です。swdesc_option で指定することで、誤った使い方をした場合 mkswu の段階でエラーを出力しますので、必要な場合は使用してください。

swdesc_option CONTAINER_CLEAR: インストールされているコンテナと /etc/atmark/containers/*.conf をすべて削除します。
このオプションは簡単な初期化と考えてください。通常の運用では、不要になったイメージは自動的に削除されますのでこのオプションを設定する必要はありません。

6.4.10. SWUpdate 実行中/完了後の挙動を指定する

以下のオプションは Armadillo 上の /etc/atmark/baseos.conf に、例えば MKSWU_POST_ACTION=xxx として設定することができます。

その場合に swu に設定されなければ /etc の設定で実行されますので、アットマークテクノが用意している Base OS のアップデートでも動作の変更は可能です。 swu に特定のオプションが設定された場合は設定されたオプションが優先されますので、一時的な変更も可能です。

swdesc_option POST_ACTION=container: コンテナのみのアップデート後に再起動を行いません。コンテナの中身だけをアップデートする場合、Armadillo-X2を再起動せずにコンテナだけを再起動させます。
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 に用意してあります。

6.4.11. desc ファイル設定例

6.4.11.1. 例: sshdを有効にする

/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` に転送されます。
	再起動する度に新しいサーバーの鍵が変わらないように、アップデートの時に一回作成します。
	サービスを有効にします。
	自分の公開鍵を指定された場所に配置します。
	イメージを作成します。パスワードは証明鍵のパスワードです。

6.4.11.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 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] 
[ATDE ~/mkswu]$ mkswu update-[VERSION].desc 
Enter pass phrase for /home/atmark/mkswu/swupdate.key:
update-[VERSION].swu を作成しました。

	imx-bootでビルドしたイメージを使います。
	build-rootfsでビルドしたイメージを使います。
	バージョンが上がるときにしかインストールされませんので、現在の/etc/sw-versionsを確認して適切に設定してください。
	イメージを作成します。パスワードは証明鍵の時のパスワードです。

6.4.11.3. 例: swupdate_preserve_files で Linux カーネル以外の Armadillo-X2 向けのイメージをインストールする方法

Armadillo-X2 向けのアップデートイメージに 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"

6.5. swupdate_preserve_files について

extra_os のアップデートで rootfs にファイルを配置することができますが、次の OS アップデートの際に削除される可能性があります。

デフォルトでは、 /etc/atmark と、 swupdate 、 sshd やネットワークの設定を保存しますがそれ以外はコピーされてません。

そうでないファイルを更新する際には /etc/swupdate_preserve_files に記載します。「例: swupdate_preserve_files で Linux カーネル以外の Armadillo-X2 向けのイメージをインストールする方法」を参考にしてください。

コピーのタイミングによって、以下のどれかを使用してください：

単にファイルを記載する
この場合、アップデートする前にファイルをコピーします。 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

6.6. SWU イメージの内容の確認

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

6.7. SWUpdate と暗号化について

mkswu --init の時に暗号化を有効にする場合は AES でファイルを暗号化します。

現在使われてる SWUpdate の暗号化はコマンドやメタデータを含む sw-description ファイルは暗号化されてません。そのため、通信の暗号化（HTTPSで送信するなど）を使うことを推奨します。

6.8. SWUpdate の署名鍵と証明書の更新

mkswu で SWU イメージを生成する際に SWU イメージ内の sw-description という命令ファイルを ATDE にある署名鍵と証明書を用いて署名します。 swupdate を実行する際には、署名に使用した証明書が /etc/swupdate.pem に含まれているかを確認します。

その署名を確認できなかった場合、SWU イメージをインストールできないので、Armadillo にある証明書を管理しなければなりません。

また、暗号鍵管理のガイドラインとしては定期的に鍵を交換することが強く推奨されています。 mkswu --init を実行した際に１つだけ署名鍵と証明書を生成しましたが、ここでは他の署名鍵および証明書の生成と Armadillo 側の管理の方法について説明します。

6.8.1. 署名鍵と証明書の追加

署名鍵と証明書の生成は以下の様に、 mkswu --genkey で行います。

[ATDE ~]$ mkswu --genkey
/home/atmark/mkswu/swupdate.key はすでに存在します。新しい鍵を作成しますか？ [Y/n]  
証明書のコモンネーム(一般名)を入力してください: [COMMON_NAME] 
署名鍵 /home/atmark/mkswu/swupdate-2.key と証明書 swupdate-2.pem を作成します。
Generating an EC private key
writing new private key to '/home/atmark/mkswu/swupdate-2.key.tmp'
Enter PEM pass phrase: 
Verifying - Enter PEM pass phrase:
 -----
/home/atmark/mkswu/swupdate-2.pem をコンフィグファイルに追加します。
/home/atmark/mkswu/swupdate-2.pem が次のアップデートをインストールするときに転送されます。
インストールされてから現在の鍵を /home/atmark/mkswu/mkswu.conf から外してください。

図6.100 mkswu --genkey で署名鍵と証明書を追加する

	Enterキーを押下します。
	[COMMON_NAME] には会社や製品が分かる任意の名称を入力してください。任意ではありますが、一つ目の鍵と違う名前にすることを推奨します。
	署名鍵を保護するパスフレーズを2回入力します。

このコマンドを実行すると以下の文字列が ~/mkswu/mkswu.conf に追加されます。

# extra swupdate certificate. Remove the old one and use new
# PRIVKEY after having installed an update with this first
PUBKEY="$PUBKEY,$CONFIG_DIR/swupdate-2.pem" 
# remove "NEW_" to use
NEW_PRIVKEY="$CONFIG_DIR/swupdate-2.key" 
# This controls if we should update certificates on device, and can be
# removed once all devices have been updated to only allow new certificate
UPDATE_CERTS=yes

図6.101 mkswu --genkey により mkswu.conf に追加された内容

	`PUBKEY` の値に生成した証明書のパスが追加されます。 `UPDATE_CERTS=yes` を設定して生成した SWU イメージは、PUBKEY の値にリストされている証明書を全て Armadillo にインストールします。 PUBKEY にリストされてない証明書、またはアットマークテクノ側で管理している証明書以外は全て削除されます。
	新しい署名鍵のパスです。この段階では未使用になります。

この状態で任意 (POST_ACTION=container以外) の SWU イメージを生成し、インストールすると Armadillo の /etc/swupdate.pem に PUBKEY にリストされている両方の証明書がインストールされます。 Armadillo にインストールされている鍵は、abos-ctrl certificates list で確認できます：

[armadillo ~]# abos-ctrl certificates list
- atmark-2
- atmark-3
- swupdate-2.pem: [mkswu --genkey で入力した COMMON NAME] 
- swupdate.pem: [mkswu --init で入力した COMMON NAME]

図6.102 新しい証明書が Armadillo に追加されていることを確認する

	追加した証明書のコモンネーム
	`mkswu --init` 時に生成した証明証のコモンネーム。当時の `mkswu` のバージョンによっては `swupdate.pem` が記載されてない可能性があります。

この状態で新しい鍵を使えるようになります。

6.8.2. 署名鍵と証明書の削除

上記のように Armadillo に複数の署名鍵を使用できる状態になった場合は証明に使う署名鍵と証明書を切り替えることができます。

mkswu.conf の PUBKEY の値から一つ目の値を削除し、 PRIVKEY に新しい値を設定し、必要であれば UPDATE_CERTS=yes を記述します。

[ATDE ~] tail -n 3 ~/mkswu/mkswu.conf
PUBKEY="$CONFIG_DIR/swupdate-2.pem"
PRIVKEY="$CONFIG_DIR/swupdate-2.key"
UPDATE_CERTS=yes

図6.103 署名鍵と証明書を削除する設定

署名鍵の追加と同じく、この状態で SWU イメージを生成し Armadillo にインストールすると前の証明書が削除されます。

こちらも abos-ctrl certificates list コマンドで確認可能です。

[armadillo ~]# abos-ctrl certificates list
- atmark-2
- atmark-3
- swupdate-2.pem: [mkswu --genkey で入力した COMMON NAME]

図6.104 証明書がインストールされていることを確認する

6.9. Web UI から Armadillo をセットアップする (ABOS Web)

ABOS Web は、Web ブラウザから Armadillo の動作設定を行う機能で、ABOS (Armadillo Base OS) を搭載する全ての Armadillo に対応しています。

詳細は、「ABOS Web とは」を参照してください。

6.9.1. ABOS Web ではできないこと

ABOS Web は、ABOS の詳細や Linux のコマンドシェルの操作に詳しくない方でも、簡単に Armadillo のセットアップを行なえることを目的にしています。そのための、Armadillo の動作設定を行う機能ですから、動作設定以外のこと、たとえば、Armadillo の動作状態を監視したりすることは、できません。さらに、Armadillo をインターネットから設定操作する、リモート操作もできません。セキュリティの観点から、ABOS Web は、同じ LAN 内からの接続しか受け付けないように実装しています。

ABOS Web でできる Armadillo の設定については、「ABOS Web の設定機能一覧と設定手順」を参照してください。なお、ABOS Web は OSS で提供していますので、現在の ABOS Web に無い設定機能を、ご自分で実装して機能追加することも可能です。

6.9.2. ABOS Web の設定機能一覧と設定手順

現在、ネットワークに関して ABOS Web で設定できるのは以下のものです。

WWAN設定
WLAN設定
各接続設定（各ネットワークインターフェースの設定）
DHCPサーバー設定
NAT設定
VPN設定

これらについては、「ネットワーク設定」で紹介していますので、そちらを参照してください。

ネットワーク以外にも ABOS Web は以下の機能を持っています。

コンテナ管理
SWUインストール
時刻設定
アプリケーション向けのインターフェース (Rest API)
カスタマイズ

本章では、これらのネットワーク以外の設定項目について紹介します。

6.9.3. コンテナ管理

ABOS Web から Armadillo 上のコンテナを一覧表示して、コンテナごとに起動・停止を行うことができます。

ABOS Web のトップページから、"コンテナ管理"をクリックすると、図6.105「コンテナ管理」の画面に遷移します。

images/abos-images/abos-web/container-list.png

図6.105 コンテナ管理

この画面では、ABOS 上にあるコンテナ全てについて、イメージ名やコンテナ名、現在状態を一覧表示します。コンテナの一覧表示欄で選択したコンテナに対し、起動と停止、および、コンテナから出力されたログの表示を行うことができます。


	「VPN設定」に記載のとおり、VPN 接続を設定すると、abos_web_openvpn のコンテナが作成されます。 VPN 接続中は、このコンテナが動作状態になっており、このコンテナをコンテナ管理画面で停止すると、VPN 接続が切断されます。

6.9.4. SWUインストール

ABOS Web から PC 上の SWU イメージや HTTP サーバー上の SWU イメージを Armadillo にインストールすることができます。

SWU イメージについては、「SWU イメージとは」を参照してください。

ABOS Web のトップページから、"SWU インストール"をクリックすると、図6.106「SWU インストール」の画面に遷移します。

images/abos-images/abos-web/swu-select_image.png

図6.106 SWU インストール

この画面では、PC 上の SWU イメージファイルまたは、HTTP サーバー上の SWU イメージファイルの URL を指定して、Armadillo にインストールすることができます。 Armadillo のソフトウェアのアップデート用に最初に行う設定で作成する initial_setup.swu が、まだ Armadillo にインストールされていなければ、"mkswu --init で作成した initial_setup.swu をインストールしてください。" というメッセージを画面上部に表示します。

SWU イメージのインストール動作を実行する時には、進行状況を示すログを表示します。 "現在の SWU で管理されているバージョン" 欄には、ABOS の各ソフトウェアコンポーネントの名前とバージョン情報を一覧表示します。

images/abos-images/abos-web/swu-curr_vers.png

図6.107 SWU 管理対象ソフトウェアコンポーネントの一覧表示

6.9.5. 時刻設定

ABOS Web から時刻に関する設定を行うことができます。

ABOS Web のトップページから "時刻設定" をクリックすると、以下の内容が表示されます。

図6.108「ネットワークタイムサーバーと同期されている場合の状況確認画面」では Armadillo の現在時刻と、同期中のサーバーとの時間差を確認することができます。

images/abos-images/abos-web/time_status_sync.png

図6.108 ネットワークタイムサーバーと同期されている場合の状況確認画面

時刻が同期されてない状態では図6.109「ネットワークタイムサーバーと同期されていない場合の状況確認画面」の様に「PC と同期する」ボタンを押すことで、 Armadillo の時刻を PC と同期することができます。

images/abos-images/abos-web/time_status_unsync.png

図6.109 ネットワークタイムサーバーと同期されていない場合の状況確認画面

図6.110「ネットワークタイムサーバーの設定項目」では NTP (ネットワークからの時刻同期）サーバーと Armadillo 起動時に同期するサーバーを設定することができます。

images/abos-images/abos-web/time_ntp_config.png

図6.110 ネットワークタイムサーバーの設定項目

最後に、図6.111「タイムゾーンの設定項目」では Armadillo Base OS で使用するタイムゾーンの変更ができます。コンテナには影響ありませんのでご注意ください。

images/abos-images/abos-web/time_zone_config.png

図6.111 タイムゾーンの設定項目

6.9.6. アプリケーション向けのインターフェース (Rest API)

コンテナやスクリプトから ABOS Web の一部の機能を使用できます。

6.9.6.1. Rest API へのアクセス権の管理

Rest API は ABOS Web のパスワードと Rest API 用のトークンで認証されます。

また、接続可能なネットワークにも制限をかけております。初期状態では、同一サブネットからのアクセスのみ許容しています。同一サブネット外の IP アドレスからアクセスしたい場合は設定が必要です。設定方法は「ABOS Web へのアクセス」を参照してください。

各リクエストは以下のどちらかの Authorization ヘッダーで認証されます：

Basic (パスワード認証）: curl の -u :<password> 等で認証可能です。<password> の文字列は ABOS Web で設定したパスワードです。
Bearer (トークン認証）: curl の -H "Authorization: Bearer <token> 等で認証可能です。<token> は /api/tokens であらかじめ生成した文字列です。

また、トークンには権限も設定できます。Admin で生成されたトークンはすべてのインターフェースにアクセスできますが、一部のインターフェースしか使用しない場合はそのインターフェースに必要な権限だけを持つトークンを生成してください。

トークンの管理は ABOS Web の「設定管理」ページで行えます:

images/abos-images/abos-web/settings_restapi.png

図6.112 設定管理の Rest API トークン一覧表示


	ABOS Web のバージョン 1.2.3 以降では、Token ID の横にあるクリップボードアイコンをクリックするとクリップボードにコピーすることができます。

6.9.6.2. Rest API 使用例の前提条件

各 Rest API の使用例を説明します。使用例では以下を前提としています。：

ABOS Web に https://armadillo.local:58080 でアクセスします。
「 AUTH 」環境変数に ABOS Web で生成したトークンを設定します。例： AUTH="Authorization: Bearer 35ac39a8-1eeb-4bb2-84d2-cb542cdbc873"
curl コマンドを省略するため、以下のように alias を使用します：

[ATDE ~]$ alias curl_rest='curl -k -H "$AUTH" -w "\nhttp code: %{http_code}\n" '


	コンテナから ABOS Web には「https://host.containers.internal:58080」でアクセスできます。

この章で説明する例では、curl のオプションに -k を指定して証明書を無視するようにしています。もし、証明書を使用したい場合は以下のように設定してください。

[ATDE ~]$ openssl s_client -showcerts -connect armadillo.local:58080 </dev/null 2>/dev/null | openssl x509 -outform PEM > abosweb.pem
[ATDE ~]$ CERT="$PWD/abosweb.pem"
[ATDE ~]$ alias curl_rest='curl -H "$AUTH" --cacert "$CERT" -w "\nhttp code: %{http_code}\n" '

6.9.6.3. Rest API の入力と出力

インターフェースの一部にはパラメータを取るものがあります。パラメータがある場合は json (Content-Type を application/json に設定する）と form（デフォルトの application/x-www-form-urlencoded でのパラメータ）のどちらでも使用可能です。

インターフェースの出力がある場合は json object で出力されます。今後のバージョンアップで json object のキーが増える可能性があるため、出力された値を処理する場合はその点に留意してください。

エラーの場合は json object の「error」キーに文字列のエラーが記載されています。 http のステータスコードも 50x になります。

エラーの例：

[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
{"error":"No such token"}
http code: 500

6.9.6.4. Rest API : トークン管理

トークン管理のためのインターフェースは以下のとおりです：

トークン一覧
GET "/api/tokens"
必要権限: Admin
パラメータ: 無し
出力: トークンリスト

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/tokens
{"tokens":[{"token":"35ac39a8-1eeb-4bb2-84d2-cb542cdbc873","permissions":["Admin"]},{"token":"5c426ce5-8fcb-4e54-9ff6-80aba50935ee","permissions":["Reboot","NetworkView"]}]}
http code: 200

トークン取得
GET "/api/tokens/<token>"
必要権限: Admin
パラメータ: 無し
出力: トークン情報

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/tokens/35ac39a8-1eeb-4bb2-84d2-cb542cdbc873
{"token":"35ac39a8-1eeb-4bb2-84d2-cb542cdbc873","permissions":["Admin"]}
http code: 200

トークン生成
POST "/api/tokens"
必要権限: Admin
パラメータ: 付与したい permissions 権限リスト(ない場合は「Admin」で生成されます）
出力: 生成されたトークン情報

[ATDE ~]$ curl_rest -H "Content-type: application/json" -d '{"permissions": ["SwuInstall", "ContainerView"]}' https://armadillo.local:58080/api/tokens
{"token":"3b2d830d-2f64-4e76-9e59-316da82eefc4","permissions":["SwuInstall","ContainerView"]}
http code: 200

トークン編集 (存在しない場合は指定のトークンで生成されます）
POST "/api/tokens/{token_id}"
必要権限: Admin
パラメータ: 付与したい permissions 権限リスト(ない場合は編集しません）
出力: 編集か生成されたトークン情報
```
[ATDE ~]$ curl_rest -X POST -d permissions=Poweroff -d permissions=ContainerAdmin https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
{"token":"3b2d830d-2f64-4e76-9e59-316da82eefc4","permissions":["Poweroff","ContainerAdmin"]}
```

トークン削除
DELETE "/api/tokens/{token_id}"
必要権限: Admin
パラメータ: 無し
出力: 無し

[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/tokens/3b2d830d-2f64-4e76-9e59-316da82eefc4
http code: 200

abos-web パスワード変更
POST "/api/password"
必要権限: Admin
パラメータ: password でハッシュ済みのパスワード文字列か hashed=false が設定されている場合は平文の文字列
出力: 無し

[ATDE ~]$ PWD_HASH=$(openssl passwd -6)
Password:
Verifying - Password:
[ATDE ~]$ echo $PWD_HASH
$6$LuXQduN7L3PwbMaZ$txrw8vLJqEVUreQnZhM0CYMQ5U5B9b58L0mpVRULDiVCh2O46GKscq/xsDPskjxg.x8ym0ri1/8NqFBu..IZE0
[ATDE ~]$ curl_rest --data-urlencode "password=$PWD_HASH" -X POST https://armadillo.local:58080/api/password
http code: 200

6.9.6.5. Rest API : SWU

インストール済み SWU のバージョン情報取得
GET "/api/swu/versions"
必要権限: SwuView
パラメータ: 無し
出力: Swupdate の各バージョン情報

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/swu/versions
{"extra_os.custom":"54","extra_os.container":"1","custom":"54","extra_os.initial_setup":"4","boot":"2020.4-at19","base_os":"3.18.4-at.6","extra_os.sshd":"1"}
http code: 200

アップデートステータス取得
GET "/api/swu/status"
必要権限: SwuView
パラメータ: 無し
出力: rollback_ok: ロールバック状態 (false の場合は rollback されています)、last_update_timestamp: UTC の unix epoch (数字での日付)、 last_update_versions: 最新のアップデートで更新されたバージョン情報 (コンポーネント → [更新前のバージョン, 更新後のバージョン]。更新前に存在しなかったコンポーネントの場合は null で記載されています)

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/swu/status
{"rollback_ok":true,"last_update_timestamp":1703208559,"last_update_versions":{"custom":[null,"54"],"extra_os.custom":["53","54"]}}
http code: 200

SWU をファイルアップロードでインストール
POST "/api/swu/install/upload"
必要権限: SwuInstall
パラメータ: multipart/form-data で swu の転送
出力: swupdate プロセスの出力 (stdout または stderr)、またはアップデートプロセスの出力ステータス (exit_code または exit_signal)

[ATDE ~]$ curl_rest -F swu=@"$HOME/mkswu/file.swu" https://armadillo.local:58080/api/swu/install/upload
{"stdout":"SWUpdate v2023.05_git20231025-r0\n"}
{"stdout":"\n"}
{"stdout":"Licensed under GPLv2. See source distribution for detailed copyright notices.\n"}
{"stdout":"\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [main] : Running on AGX4500 Revision at1\n"}
{"stdout":"[INFO ] : SWUPDATE started :  Software Update started !\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [install_single_image] : Installing pre_script\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [read_lines_notify] : No base os update: copying current os over\n"}
: (省略)
{"stdout":"[INFO ] : SWUPDATE running :  [install_single_image] : Installing post_script\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [read_lines_notify] : Removing unused containers\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [read_lines_notify] : swupdate triggering reboot!\n"}
{"stderr":"Killed\n"}
{"exit_code":0}

http code: 200

SWU を URL でインストール
POST "/api/swu/install/url"
必要権限: SwuInstall
パラメータ: url=<SWU をダウンロードできる URL>
出力: swupdate プロセスの出力 (stdout または stderr)、またはアップデートプロセスの出力ステータス (exit_code または exit_signal)

[ATDE ~]$ curl_rest -d url=https://url/to/file.swu https://armadillo.local:58080/api/swu/install/url
{"stdout":"Downloading https://url/to/file.swu...\n"}
{"stdout":"SWUpdate v2023.05_git20231025-r0\n"}
{"stdout":"\n"}
{"stdout":"Licensed under GPLv2. See source distribution for detailed copyright notices.\n"}
{"stdout":"\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [main] : Running on AGX4500 Revision at1\n"}
{"stdout":"[INFO ] : SWUPDATE started :  Software Update started !\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [install_single_image] : Installing pre_script\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [read_lines_notify] : No base os update: copying current os over\n"}
: (省略)
{"stdout":"[INFO ] : SWUPDATE running :  [install_single_image] : Installing post_script\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [read_lines_notify] : Removing unused containers\n"}
{"stdout":"[INFO ] : SWUPDATE running :  [read_lines_notify] : swupdate triggering reboot!\n"}
{"stderr":"Killed\n"}
{"exit_code":0}

http code: 200

6.9.6.6. Rest API : コンテナ操作

コンテナ一覧
GET "/api/containers"
必要権限: ContainerView
パラメータ: 無し
出力: 各コンテナの id, name, state, command, image 情報

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/containers
{"containers":[{"id":"02616122dcea5bd75c551b29b2ef54f54e09f59c50ce3282684773bc6bfb86a8","name":"python_app","state":"running","command":["python3","/vol_app/src/main.py"],"image":"localhost/python_arm64_app_image:latest"}]}
http code: 200

コンテナログ取得
GET "/api/containers/{container}/logs"
必要権限: ContainerView
パラメータ: follow=true (podman logs -f と同様の効果)
出力: podman logs プロセスの出力 (stdout または stderr)、またはアップデートプロセスの出力ステータス (exit_code または exit_signal)
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/containers/python_app/logs
{"stdout":"Some message\n"}
{"exit_code":0}

http code: 200
```
follow=true を付与する例
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/containers/python_app/logs?follow=true
{"stdout":"Some message\n"}
Ctrl-C で終了
```
コンテナ起動
POST "/api/containers/{container}/start"
必要権限: ContainerAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/containers/python_app/start

http code: 200
```
コンテナ停止
POST "/api/containers/{container}/stop"
必要権限: ContainerAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/containers/python_app/stop

http code: 200
```

6.9.6.7. Rest API : ネットワーク設定

ネットワーク設定一覧
GET "/api/connections"
必要権限: NetworkView
パラメータ: 無し
出力: ネットワーク設定一覧と各接続の uuid, name, state, ctype, 存在すれば device 情報

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/connections
{"connections":[{"name":"Wired connection 1","state":"activated","uuid":"18d241f1-946c-3325-974f-65cda3e6eea5","ctype":"802-3-ethernet","device":"eth0"},{"name":"lo","state":"activated","uuid":"529ec241-f122-4cb2-843f-ec9787b2aee7","ctype":"loopback","device":"lo"},{"name":"podman0","state":"activated","uuid":"be4583bc-3498-4df2-a31c-773d781433aa","ctype":"bridge","device":"podman0"},{"name":"veth0","state":"activated","uuid":"03446b77-b1ab-47d0-98fc-f167c3f3778a","ctype":"802-3-ethernet","device":"veth0"},{"name":"Wired connection 2","state":"","uuid":"181f44df-850e-36c1-a5a4-6e461c768acb","ctype":"802-3-ethernet"},{"name":"Wired connection 3","state":"","uuid":"e4381368-6351-3985-ba6e-2625c62b8d39","ctype":"802-3-ethernet"}]}

http code: 200

ネットワーク設定詳細取得
GET "/api/connections/{connection}"
必要権限: NetworkView
パラメータ: 無し（URL の connection は UUID または接続名で使用可能）
出力: 接続の詳細情報（Network Manager のプロパティ）

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/connections/Wired%20connection%201
{"name":"Wired connection 1","state":"activated","uuid":"18d241f1-946c-3325-974f-65cda3e6eea5","ctype":"802-3-ethernet","device":"eth0","props":{"802-3-ethernet.accept-all-mac-addresses":"-1","802-3-ethernet.auto-negotiate":"no","802-3-ethernet.cloned-mac-address":"","802-3-ethernet.duplex":"","802-3-ethernet.generate-mac-address-mask":"","802-3-ethernet.mac-address":"","802-3-ethernet.mac-address-blacklist":"","802-3-ethernet.mtu":"auto","802-3-ethernet.port":"","802-3-ethernet.s390-nettype":"","802-3-ethernet.s390-options":"","802-3-ethernet.s390-subchannels":"","802-3-ethernet.speed":"0","802-3-ethernet.wake-on-lan":"default","802-3-ethernet.wake-on-lan-password":"","GENERAL.CON-PATH":"/org/freedesktop/NetworkManager/Settings/1","GENERAL.DBUS-PATH":"/org/freedesktop/NetworkManager/ActiveConnection/6","GENERAL.DEFAULT":"yes","GENERAL.DEFAULT6":"no","GENERAL.DEVICES":"eth0","GENERAL.IP-IFACE":"eth0","GENERAL.MASTER-PATH":"","GENERAL.NAME":"Wired connection 1","GENERAL.SPEC-OBJECT":"","GENERAL.STATE":"activated","GENERAL.UUID":"18d241f1-946c-3325-974f-65cda3e6eea5","GENERAL.VPN":"no","GENERAL.ZONE":"","IP4.ADDRESS[1]":"198.51.100.123/16","IP4.DNS[1]":"192.0.2.1","IP4.DNS[2]":"192.0.2.2","IP4.GATEWAY":"198.51.100.1","IP4.ROUTE[1]":"dst = 198.51.100.0/16, nh = 0.0.0.0, mt = 100","IP4.ROUTE[2]":"dst = 0.0.0.0/0, nh = 198.51.100.1, mt = 100","IP6.ADDRESS[1]":"fe80::211:cff:fe00:b13/64","IP6.GATEWAY":"","IP6.ROUTE[1]":"dst = fe80::/64, nh = ::, mt = 1024","connection.auth-retries":"-1","connection.autoconnect":"yes","connection.autoconnect-priority":"-999","connection.autoconnect-retries":"-1","connection.autoconnect-slaves":"-1","connection.dns-over-tls":"-1","connection.gateway-ping-timeout":"0","connection.id":"Wired connection 1","connection.interface-name":"eth0","connection.lldp":"default","connection.llmnr":"-1","connection.master":"","connection.mdns":"-1","connection.metered":"unknown","connection.mptcp-flags":"0x0","connection.multi-connect":"0","connection.permissions":"","connection.read-only":"no","connection.secondaries":"","connection.slave-type":"","connection.stable-id":"","connection.timestamp":"1703208824","connection.type":"802-3-ethernet","connection.uuid":"18d241f1-946c-3325-974f-65cda3e6eea5","connection.wait-activation-delay":"-1","connection.wait-device-timeout":"-1","connection.zone":"","ipv4.addresses":"198.51.100.123/16","ipv4.auto-route-ext-gw":"-1","ipv4.dad-timeout":"-1","ipv4.dhcp-client-id":"","ipv4.dhcp-fqdn":"","ipv4.dhcp-hostname":"","ipv4.dhcp-hostname-flags":"0x0","ipv4.dhcp-iaid":"","ipv4.dhcp-reject-servers":"","ipv4.dhcp-send-hostname":"yes","ipv4.dhcp-timeout":"0","ipv4.dhcp-vendor-class-identifier":"","ipv4.dns":"192.0.2.1,192.0.2.2","ipv4.dns-options":"","ipv4.dns-priority":"0","ipv4.dns-search":"","ipv4.gateway":"198.51.100.1","ipv4.ignore-auto-dns":"no","ipv4.ignore-auto-routes":"no","ipv4.link-local":"0","ipv4.may-fail":"yes","ipv4.method":"manual","ipv4.never-default":"no","ipv4.replace-local-rule":"-1","ipv4.required-timeout":"-1","ipv4.route-metric":"-1","ipv4.route-table":"0","ipv4.routes":"","ipv4.routing-rules":"","ipv6.addr-gen-mode":"eui64","ipv6.addresses":"","ipv6.auto-route-ext-gw":"-1","ipv6.dhcp-duid":"","ipv6.dhcp-hostname":"","ipv6.dhcp-hostname-flags":"0x0","ipv6.dhcp-iaid":"","ipv6.dhcp-send-hostname":"yes","ipv6.dhcp-timeout":"0","ipv6.dns":"","ipv6.dns-options":"","ipv6.dns-priority":"0","ipv6.dns-search":"","ipv6.gateway":"","ipv6.ignore-auto-dns":"no","ipv6.ignore-auto-routes":"no","ipv6.ip6-privacy":"-1","ipv6.may-fail":"yes","ipv6.method":"auto","ipv6.mtu":"auto","ipv6.never-default":"no","ipv6.ra-timeout":"0","ipv6.replace-local-rule":"-1","ipv6.required-timeout":"-1","ipv6.route-metric":"-1","ipv6.route-table":"0","ipv6.routes":"","ipv6.routing-rules":"","ipv6.token":"","proxy.browser-only":"no","proxy.method":"none","proxy.pac-script":"","proxy.pac-url":""}}
http code: 200

ネットワーク設定の変更
PATCH "/api/connections/{connection}"
必要権限: NetworkAdmin
パラメータ: Network Manager で編集可能な値
出力: 無し

[ATDE ~]$ curl_rest -X PATCH -d ipv4.method=manual -d ipv4.addresses=198.51.100.123/16 https://armadillo.local:58080/api/connections/Wired%20connection%201

http code: 200

ネットワークの接続
POST "/api/connections/{connection}/up"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/connections/Wired%20connection%201/up

http code: 200
```
ネットワークの切断
POST "/api/connections/{connection}/down"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/connections/Wired%20connection%201/down

http code: 200
```
ネットワーク設定の削除
DELETE "/api/connections/{connection}"
必要権限: NetworkAdmin
パラメータ: 無し出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/connections/178b8c95-fcad-4bb1-8040-5a02b9ad046f

http code: 200
```
通信に使用しているネットワークの設定を削除した場合は Armadillo へアクセスできなくなりますので、ご注意ください。

6.9.6.8. Rest API : WLAN

無線ネットワークのリスト取得
GET "/api/wlan/scan"
必要権限: NetworkView
パラメータ: (任意)rescan=true/false, false を指定するとキャッシュされているスキャン結果を出力します。
出力: リスト

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wlan/scan
[{"id":"my_ap","signal":74,"bssid":"04:42:1A:E4:78:0C","chan":44,"rate":"540 Mbit/s","security":"WPA2 WPA3"},{"id":"other_ap","signal":65,"bssid":"AC:44:F2:56:22:38","chan":1,"rate":"130 Mbit/s","security":"WPA2"}]
http code: 200

*無線ネットワークの接続
POST "/api/wlan/connect"
必要権限: NetworkAdmin
パラメータ： ssid, passphrase, ifname, bssid, hidden. ssid 以外は任意です。
出力: 生成した接続の uuid
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wlan/connect -d ssid=my_ap -d passphrase=my_passphrase
{"uuid":"178b8c95-fcad-4bb1-8040-5a02b9ad046f"}
http code: 200
```
無線ネットワークアクセスポイントの設定
POST "/api/wlan/ap"
必要権限: NetworkAdmin
パラメータ: ssid, passphrase, bridge_addr, hw_mode/channel, interface.
interface は任意です。hw_mode:2.4GHz を使用する場合は "g"、5GHz を使用する場合は "a" を設定します。
channel: 2.4GHz の場合は 1 〜 13、5GHz の場合は 36、40、44、48 を設定します。
hw_mode/channel を設定しない場合は自動的に選択されますが、両方を未設定にすることはできません。
出力: 無し
```
[ATDE ~]$ curl_rest -d ssid=my_ap -d passphrase=my_passphrase -d bridge_addr=198.51.100.1/24 -d channel=3 https://armadillo.local:58080/api/wlan/ap

http code: 200
```
アクセスポイントを設定するとクライアントの接続が無効になります。
クライアントの接続の削除は DELETE "/api/connections/{connection}" で行えます。
無線ネットワークアクセスポイントの削除
DELETE "/api/wlan/ap"
必要権限: NetworkAdmin
パラメータ: interface (任意)
出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/wlan/ap

http code: 200
```

6.9.6.9. Rest API : WWAN の設定

WWAN の設定追加
POST "/api/wwan"
必要権限: NetworkAdmin
パラメータ: apn, user, password, auth_type (CHAP/PAP, デフォルト CHAP), mccmnc, ipv6 (bool、デフォルト true)
apn 以外は任意です。
出力: 追加された接続の uuid
```
[ATDE ~]$ curl_rest -d apn=provider.tld -d user=provider -d password=provider https://armadillo.local:58080/api/wwan
{"uuid":"ce603d3e-838b-4ac8-b7fd-6a3f1abe4003"}
http code: 200
```
WWAN の設定削除
DELETE "/api/wwan"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/wwan

http code: 200
```


	WWAN の設定確認または一時的な切断は connection の API で行ってください。

IMEI の取得
GET "/api/wwan/imei"
必要権限: NetworkView
パラメータ: 無し
出力: LTE モジュールの IMEI
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/imei
{"imei":"XXXXXXXXXXXXXXX"}
http code: 200
```
電話番号の取得
GET "/api/wwan/phone_numbers"
必要権限: NetworkView
パラメータ: 無し
出力: SIM カードに設定されている電話番号
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/phone_numbers
{"phone_numbers":["XXXXXXXXXXX"]}
http code: 200
```
電波品質の取得
GET "/api/wwan/signal_quality"
必要権限: NetworkView
パラメータ: 無し
出力: 電波品質(mmcli コマンドで出力される signal quality 相当の値)
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/signal_quality
{"signal_quality":"54"}
http code: 200
```
SMS 一覧の取得
GET "/api/wwan/sms"
必要権限: SmsView
パラメータ: 無し
出力: SMS メッセージ ID 一覧
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/sms
{"message_ids":["0", "1"]}
http code: 200
```

SMS の取得
GET "/api/wwan/sms/{message_id}"
必要権限: SmsView
パラメータ: 無し
出力: SMS の内容

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/wwan/sms/0
{"sms":{"content":{"data":"--","number":"XXXXXXXXXXX","text":"message"},"dbus_path":"/org/freedesktop/ModemManager1/SMS/0","properties":{"pdu_type":"deliver","state":"received","storage":"me","timestamp":"20YY-MM-DDThh:mm:ss+ZZ"}}}

http code: 200


	message_id は SMS 一覧の取得で表示された値を使用します。

SMS の作成・送信
POST "/api/wwan/sms"
必要権限: SmsSend
パラメータ: phone_number: 送信先電話番号, message: 送信するメッセージ
出力: 無し
```
[ATDE ~]$ curl_rest -d phone_number=XXXXXXXXXXX -d message="message" https://armadillo.local:58080/api/wwan/sms

http code: 200
```
SMS の削除
DELETE "/api/wwan/sms/{message_id}"
必要権限: SmsView
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/sms/0

http code: 200
```


	message_id は SMS 一覧の取得で表示された値を使用します。

SMS の全削除
DELETE "/api/wwan/sms"
必要権限: SmsView
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/sms

http code: 200
```

6.9.6.10. Rest API : DHCP の設定

DHCP の設定確認
GET "/api/dhcp"
必要権限: NetworkView
パラメータ: 無し
出力: interface, ip_addr, start_addr, end_addr, lease_time のリスト

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/dhcp
[{"interface":"br_ap","ip_addr":"198.51.100.1/24","start_addr":"198.51.100.10","end_addr":"198.51.100.20","lease_time":"3600"}]
http code: 200

DHCP の設定
POST "/api/dhcp/{interface}"
必要権限: NetworkAdmin
パラメータ: start_addr, end_addr, lease_time
lease_time を設定しなかった場合は 3600 (秒）とする
出力: 無し
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/dhcp/br_ap -d start_addr=198.51.100.10 -d end_addr=198.51.100.20

http code: 200
```
DHCP の設定削除
DELETE "/api/dhcp/{interface}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/dhcp/br_ap

http code: 200
```

6.9.6.11. Rest API : NAT の設定

NAT (masquerade) の設定確認
GET "/api/nat"
必要権限: NetworkView
パラメータ: 無し
出力: NAT されている interface のリスト
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/nat
[{"interface":"eth0"}]
http code: 200
```
NAT の設定
POST "/api/nat/{interface}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/nat/eth0

http code: 200
```
NAT の削除
DELETE "/api/nat/{interface}"
必要権限: NetworkAdmin
パラメータ: 無し
出力: 無し
```
[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/nat/eth0

http code: 200
```

ポートフォワードの設定確認
GET "/api/port_forwarding"
必要権限: NetworkView
パラメータ: 無し
出力: フォワードされてるポート

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/port_forwarding
[{"interface":"eth0","protocol":"tcp","dport":"22","destination":"127.0.0.1","destination_port":"2222"}]
http code: 200

ポートフォワードの設定
POST "/api/port_forwarding"
必要権限: NetworkAdmin
パラメータ: interface, protocol (デフォルト tcp), dport, destination, destination_port
出力: 無し
```
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/port_forwarding -d interface=eth0  -d dport=22 -d de
stination=127.0.0.1 -d destination_port=2222

http code: 200
```

ポートフォワードの削除
DELETE "/api/port_forwarding"
必要権限: NetworkAdmin
パラメータ: interface, protocol (デフォルト tcp), dport, destination, destination_port
出力: 無し

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/port_forwarding -X DELETE -H "Content-Type: application/json" -d '{"interface":"eth0","protocol":"tcp","dport":"22","destination":"127.0.0.1","destination_port":"2222"}'

http code: 200

6.9.6.12. Rest API : VPN の設定

VPN クライアントは、現在 OpenVPN をサポートしています。

VPN の設定
POST "/api/vpn/openvpn"
必要権限: VpnAdmin
パラメータ: setting_name, conf, auth_type, username, password, cert, key, key_pass
setting_name: 設定名です。任意の文字列を設定してください。
conf: OpenVPN の設定ファイルです。
auth_type: 認証方式です。userpass(ユーザ名とパスワード) または cert(証明書) を設定してください。
username: auth_type が userpass の場合、ユーザ名を設定します。
password: auth_type が userpass の場合、パスワードを設定します。
cert: auth_type が cert の場合、証明書ファイルを設定します。OpenVPN の設定ファイルに含まれている場合は不要です。
key: auth_type が cert の場合、鍵ファイルを設定します。OpenVPN の設定ファイルに含まれている場合は不要です。
key_pass: 鍵がパスワードで保護されている場合、そのパスワードを設定します。
出力: 無し

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/vpn/openvpn -F setting_name=myvpn -F conf=@"$HOME/conf.ovpn" -F auth_type=userpass -F username=myname -F password=mypass
http code: 200

図6.113 ユーザ名とパスワード認証の例

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/vpn/openvpn  -F setting_name=myvpn -F conf=@"$HOME/conf.ovpn" -F auth_type=cert -F cert=@"$HOME/cert.crt" -F key=@"$HOME/key.key" -F key_pass=mykeypass
http code: 200

図6.114 証明書認証の例

コンテナ内から VPN 設定の Rest API を使う場合、 Armadillo 上に alpine_openvpn コンテナイメージが存在していないと、正しく設定されません。このコンテナイメージが存在していない場合、先に ABOS Web の Web UI やコンテナ外からの Rest API で設定を行ってください。一度 alpine_openvpn コンテナイメージがインストールされれば、コンテナ内からも Rest API で設定できます。 alpine_openvpn コンテナイメージは VPN 設定を削除しても残り続けますが、VPN 設定を削除した後に swupdate でアップデートを行うと削除されますので、その場合は再度 alpine_openvpn コンテナイメージのインストールを行う必要があります。

VPN の接続
POST "/api/vpn/up"
必要権限: VpnAdmin
パラメータ: 無し
出力: 無し

[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/vpn/up
http code: 200

VPN の切断
POST "/api/vpn/down"
必要権限: VpnAdmin
パラメータ: 無し
出力: 無し

[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/vpn/down
http code: 200

VPN 設定の削除
DELETE "/api/vpn/openvpn"
必要権限: VpnAdmin
パラメータ: 無し
出力: 無し

[ATDE ~]$ curl_rest -X DELETE https://armadillo.local:58080/api/vpn/openvpn
http code: 200

6.9.6.13. Rest API : 時刻の設定

時刻の状況確認
GET "/api/time/ntp_info"
必要権限: TimeView
パラメータ: 無し
出力: time_now: epoch 形式の現在時刻、ntp_server_ip: 現在同期中のサーバーアドレス。同期されていない場合は「null」となります。 ntp_server_offset: 現在同期中のサーバーとの時刻の遅れ（マイナスの場合は Armadillo がサーバーより早いです）

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_info
{"ntp_server_ip":"203.0.113.10","ntp_server_offset":"-0.000015824","time_now":1710139558}
http code: 200

NTP の設定確認
GET "/api/time/ntp_config"
必要権限: TimeView
パラメータ: 無し
出力: servers: 同期する対象、initstepslew: Armadillo 起動時に同期するかどうかの設定

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_config
{"servers":["pool pool.ntp.org iburst"],"initstepslew":"10 pool.ntp.org"}
http code: 200

NTP の設定
POST "/api/time/ntp_config"
必要権限: TimeAdmin
パラメータ: servers: 同期する対象、initstepslew: Armadillo 起動時に同期するかどうかの設定。パラメータを送信しない場合は設定されません。値が空の場合は設定が削除されて、「 default 」の場合は Armadillo Base OS のデフォルトに戻ります。
出力: 取得時と同じ

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_config -X POST -d "servers=server 203.0.113.10 iburst" -d "servers=server 203.0.113.11 iburst" -d "initstepslew="
{"servers":["server 203.0.113.10 iburst","server 203.0.113.11 iburst"],"initstepslew":null}
http code: 200
[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/ntp_config -X POST -d "servers=default&initstepslew=default"
{"servers":["pool pool.ntp.org iburst"],"initstepslew":"10 pool.ntp.org"}
http code: 200

タイムゾーンの確認
GET "/api/time/timezone"
必要権限: TimeView
パラメータ: 無し
出力: timezone: 使用されているタイムゾーン

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/timezone
{"timezone":"Asia/Tokyo"}
http code: 200

タイムゾーンの設定
POST "/api/time/timezone"
必要権限: TimeAdmin
パラメータ: timezone: 設定するタイムゾーン
出力: 無し

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/timezone -X POST -d "timezone=Asia/Tokyo"
http code: 200

時刻を強制的に設定する
POST "/api/time/set"
必要権限: TimeAdmin
パラメータ: timestamp: epoch 形式の時刻
出力: 無し

[ATDE ~]$ curl_rest https://armadillo.local:58080/api/time/set -X POST -d "timestamp=$(date +%s)"
http code: 200

6.9.6.14. Rest API : 電源制御

再起動
POST "/api/reboot"
必要権限: Reboot
パラメータ: 無し
出力: 無し

[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/reboot

http code: 200

停止
POST "/api/poweroff"
必要権限: Poweroff
パラメータ: 無し
出力: 無し

[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/poweroff

http code: 200

6.9.6.15. Rest API : ABOS Web 制御

リスタート
POST "/api/abosweb/restart"
必要権限: AbosWebRestart
パラメータ: 無し
出力: コネクションリセット。ABOS Web はリスタートする前に一度終了するためコネクションリセットが発生します。
```
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/abosweb/restart

http code: 000
curl: (52) Empty reply from server
```

6.9.6.16. Rest API : ユーザー設定とユーザーデータの管理

ユーザー設定とユーザーデータの削除
POST "/api/reset_default"
必要権限: ResetDefault
パラメータ: 無し
出力: abos-ctrl reset-default の出力 (stdout または stderr)、および出力ステータス (exit_code または exit_signal)

[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/reset_default
{"stdout":"rm -f /etc/NetworkManager/system-connections/*\n"}
{"stdout":"persist_file -r /etc/NetworkManager/system-connections\n"}
{"stdout":"persist_file -r /etc/dnsmasq.d\n"}
{"stdout":"rc-service dnsmasq restart\n"}
{"stdout":"/etc/init.d/iptables save\n"}
{"stdout":"sed -i -e '/NETAVARK/d' /etc/iptables/rules-save\n"}
{"stdout":"persist_file /etc/iptables/rules-save\n"}
{"stdout":"podman stop -a\n"}
{"stdout":"find /var/app/volumes /var/log -mindepth 1 -delete\n"}
{"stdout":"Starting clone to /dev/mmcblk0p1\n"}
{"stdout":"Cloning rootfs\n"}
{"stdout":"Updating appfs snapshots\n"}
{"stdout":"Reusing up-to-date bootloader\n"}
{"stdout":"Rollback clone successful\n"}
{"stderr":"WARNING: Rebooting!\n"}
{"exit_code":0}

http code: 200

6.9.6.17. Rest API : カスタムスクリプトの実行

ユーザが Armadillo に追加したスクリプトを Rest API を使用して実行することができます。実行したいスクリプトに実行権限を付与し、Armadillo の /etc/atmark/abos_web/customize_rest ディレクトリ下に置いてください。

実行に root 権限が必要なスクリプトの場合は、以下のように /etc/doas.d/abos_web_customize.conf にスクリプトを追加してください。

[armadillo ~]# cat /etc/doas.d/abos_web_customize.conf
permit nopass abos-web-admin as root cmd /etc/atmark/abos_web/customize_rest/root_command.sh

任意のスクリプト実行
POST "/api/custom/{script}"
必要権限: Custom パラメータ: args でスクリプトの引数を順番に指定できます。
root を true に設定すると root 権限でスクリプトを実行します。
出力: /etc/atmark/abos_web/customize_rest/{script} {args} {args...} を実行して、そのスクリプトの出力を stdout/stderr で返します。スクリプトが終了した際の出力ステータスは exit_code または exit_signal (どちらも int) です。
```
[armadillo ~]# cat /etc/atmark/abos_web/customize_rest/print_args.sh
#!/bin/sh

printf "arg: %s\n" "$@"
[ATDE ~]$ curl_rest -X POST https://armadillo.local:58080/api/custom/print_args.sh \
        -H 'Content-type: application/json' -d '{"args": ["param", "second arg"], "root":false}'
{"stdout":"arg: param\n"}
{"stdout":"arg: second arg\n"}
{"exit_code":0}
```


	標準の ABOS Web には最小限の権限しか与えていません。 root 権限でスクリプトを実行する場合、 Armadillo の故障やセキュリティにも関わりますので、十分注意して追加してください。

6.9.7. カスタマイズ

ABOS Web をお客様の最終製品へ組み込む場合に、ロゴ画像や背景色、メニューの文言などをカスタマイズすることができます。詳細は「ABOS Web をカスタマイズする」を参照してください。

6.9.8. ユーザー設定とユーザーデータの削除

カスタマイズと Rest API トークン以外の設定内容と、ユーザーデータを一括削除することができます。

ユーザーデータの削除では以下のデータを削除します。

/var/app/volumes ディレクトリ下のファイルを全て
/var/log ディレクトリ下のファイルを全て

ABOS Web のトップページから、「設定管理」ページへ移動し「ユーザー設定とユーザーデータの削除」にある「削除」ボタンを押すと削除できます。削除後は Armadillo が再起動するので引き続き ABOS Web を使用する場合は、再起動が完了してからアクセスしてください。

6.9.9. ABOS Web を停止する

図6.115「ABOS Web を停止する」に ABOS Web のサービスを停止する方法を示します。

[armadillo ~]# rc-update | grep abos-web 
             abos-web |      default
[armadillo ~]# rc-service abos-web status 
 * status: started
[armadillo ~]# rc-service abos-web stop 
abos-web                 | * Stopping abos-web ... [ ok ]
[armadillo ~]# rc-update del abos-web 
 * service abos-web deleted from runlevel default
[armadillo ~]# persist_file -d /etc/runlevels/default/abos-web

図6.115 ABOS Web を停止する

	OpenRC に ABOS Web のサービスが登録されていることを確認します。
	ABOS Web のサービスが起動していることを確認します。
	ABOS Web のサービスを停止します。
	サービスを管理している OpenRC から ABOS Web のサービスの登録を解除します。
	サービス設定ファイルの削除を永続化します。

ABOS Web を停止すると ABOS Web の Rest API も使用できなくなります。

6.9.10. ABOS Web を起動する

図6.116「ABOS Web を起動する」に ABOS Web のサービスを起動する方法を示します。

[armadillo ~]# rc-update | grep abos-web 
[armadillo ~]# rc-update add abos-web 
* service abos-web added to runlevel default
[armadillo ~]# rc-service abos-web start 
abos-web                 | * Starting abos-web ... [ ok ]
[armadillo ~]# persist_file /etc/runlevels/default/abos-web

図6.116 ABOS Web を起動する

	OpenRC に ABOS Web のサービスが登録されていないことを確認します。何も出力されなければ登録されていません。
	サービスを管理している OpenRC に ABOS Web のサービスを登録します。
	ABOS Web のサービスを起動します。
	サービス設定ファイルを永続化します。

6.10. ABOSDE から ABOS Web の機能を使用する

ABOSDE は以下に示す ABOS Web の情報取得や動作を行うことができます。

Armadillo の SWU バージョンを取得する
Armadillo のコンテナの情報を取得する
Armadillo のコンテナを起動・停止する
Armadillo のコンテナのログを取得する
Armadillo に SWU をインストールする

ABOSDE は ABOS Web の Rest API を用いて通信を行っていますので、ABOS Web にパスワードでログインができる状態である必要があります。 ABOS Web へのログインを行っていない場合は「ABOS Web とは」を参考にしてください。

ABOSDE から ABOS Web の機能を使用するには通信を行う対象の Armadillo を選択する必要があります。図6.117「ABOSDE でローカルネットワーク上の Armadillo をスキャンする」の赤枠で囲まれているボタンをクリックすることで、ローカルネットワーク上で ABOS Web が動作している Armadillo をスキャンすることができます。ただし、ATDE のネットワークを NAT に設定している場合は Armadillo がリストに表示されません。

images/abos-images/abos-web/abosde_monitor_welcome_page.png

図6.117 ABOSDE でローカルネットワーク上の Armadillo をスキャンする

ABOSDE から ABOS Web に初めて通信を行う時、ABOS Web は通信に使用するためのトークンを発行します。そのため、ABOSDE では図6.118「ABOSDE の ABOS Web パスワード入力画面」のように ABOS Web のパスワードを求められますので、設定したパスワードを入力してください。

images/abos-images/abosde_enter_abos_web_password.png

図6.118 ABOSDE の ABOS Web パスワード入力画面

6.10.1. Armadillo の SWU バージョンを取得する

ローカルネットワーク上の Armadillo をスキャンした後に、図6.119「ABOSDE で Armadillo の SWU バージョンを取得」の赤枠で囲まれているボタンをクリックすることで、選択した Armadillo の SWU バージョンを取得することができます。

images/abos-images/abosde_get_swu_versions.png

図6.119 ABOSDE で Armadillo の SWU バージョンを取得

6.10.2. Armadillo のコンテナの情報を取得する

ローカルネットワーク上の Armadillo をスキャンした後に、図6.120「ABOSDE で Armadillo のコンテナ情報を取得」の赤枠で囲まれているボタンをクリックすることで、選択した Armadillo のコンテナの情報を取得できます。表示されるコンテナの情報は以下の通りとなります。

state : コンテナが起動中の場合は running、コンテナが停止中の場合は exited
image : コンテナのイメージ名
command : コンテナ起動時に実行しているコマンド

images/abos-images/abosde_get_containers_info.png

図6.120 ABOSDE で Armadillo のコンテナ情報を取得

6.10.3. Armadillo のコンテナを起動・停止する

ローカルネットワーク上の Armadillo をスキャンした後に、図6.121「ABOSDE で Armadillo のコンテナを起動」の赤枠で囲まれているボタンをクリックすることで、選択したコンテナを起動することができます。コンテナを起動できた場合はコンテナの status が running に変化します。また、図6.122「ABOSDE で Armadillo のコンテナを停止」の赤枠で囲まれているボタンをクリックすることで、選択したコンテナを停止することができます。コンテナを停止できた場合はコンテナの status が exited に変化します。

images/abos-images/abosde_run_container.png

図6.121 ABOSDE で Armadillo のコンテナを起動

images/abos-images/abosde_stop_container.png

図6.122 ABOSDE で Armadillo のコンテナを停止

6.10.4. Armadillo のコンテナのログを取得する

図6.123「ABOSDE で Armadillo のコンテナのログを取得」の赤枠で囲まれているボタンをクリックすることで、コンテナが出力したログを取得することができます。ログは VS Code のテキストエディタに開かれます。コンテナが何もログを出力していない場合は表示されません。

images/abos-images/abosde_get_container_log.png

図6.123 ABOSDE で Armadillo のコンテナのログを取得

6.10.5. Armadillo に SWU をインストールする

ローカルネットワーク上の Armadillo をスキャンした後に、図6.124「ABOSDE で Armadillo に SWU をインストール」の赤枠で囲まれているボタンをクリックすることで、選択した Armadillo に SWU をインストールすることができます。 SWU インストールのログは VS Code 画面下部の OUTPUT に表示されます。

images/abos-images/abosde_install_swu.png

図6.124 ABOSDE で Armadillo に SWU をインストール

6.11. VPU や NPU を使用する

VPU や NPU などを使うアプリケーションを ATDE 上で開発する場合や、Armadillo Base OS 上のコンテナ内で動作させる場合、ライブラリを ATDE 上でビルドする必要があります。ここではその手順について説明します。

v20230911 未満のATDEバージョンの場合

v20230911 未満のATDEバージョンの場合は、ここでの手順を行う前に、以下にしたがってクロスコンパイル用ライブラリをインストールしてください。（ATDE のバージョン v20230911 以上では、クロスコンパイル用ライブラリはインストール済みのため、以下のインストール手順は不要です。）

ライブラリのビルドツールを実行する準備として、gitのユーザ名とメールアドレスの設定を行い、ビルドツールである at-imxlibpackage をインストールします。

[ATDE ~]$ git config --global user.name "Your name"
[ATDE ~]$ git config --global user.email your@mail.tld
[ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt install at-imxlibpackage

図6.125 ビルドツール実行前の準備

その後、ビルドツールを実行します。

実行中にライセンスへの同意を求められます。内容を確認の上、同意する場合は y を入力して処理を進めてください。

[ATDE ~]$ mkdir at-imxlibpackage
[ATDE ~]$ cd at-imxlibpackage
[ATDE ~/at-imxlibpackage]$ make-imxlibpkg

図6.126 ビルドツールの実行

実行が完了すると、ATDE にクロスコンパイル用のライブラリがインストールされます。

6.11.1. Armadillo へ書き込むためのライブラリイメージを作成する

以下に示す製品では、出荷状態でライブラリイメージが Armadillo に書き込まれています。このため、ここで説明する手順はライブラリをアップデートする場合や、「ブートディスクの作成」または「初期化インストールディスクの作成」の手順に従ってディスクイメージを作成する場合に必要となります。

表6.11 ライブラリイメージ書き込み済みの製品

名称	型番
Armadillo-X2 開発セット(メモリ2GB)	AX2210-U00D0
Armadillo-X2 量産ボード(メモリ2GB、ストレージ10GB)	AX2210-U00Z
Armadillo-X2 量産ボード(メモリ2GB、ストレージ10GB、ケース入り)	AX2210-C00Z

Armadillo Base OS 上のコンテナ内から利用できるイメージを作成します。

[ATDE ~]$ cd at-imxlibpackage
[ATDE ~/at-imxlibpackage]$ make-imxlibimage

図6.127 ライブラリイメージ作成ツールの実行

VPU を使用しない場合は、--without-vpu オプションを付けてください。

[ATDE ~]$ cd at-imxlibpackage
[ATDE ~/at-imxlibpackage]$ make-imxlibimage --without-vpu

図6.128 ライブラリイメージ作成ツールの実行 (VPUが不要の場合)

実行が完了すると imx_lib.img というファイルが生成されます。

6.11.2. Armadillo にライブラリイメージを書き込む

Armadillo Base OS 上で、「Armadillo へ書き込むためのライブラリイメージを作成する」で作成した imx_lib.img を eMMC の /dev/mmcblk2p4 パーティションに書き込みます。

次のコマンドは、 imx_lib.img が /tmp にある場合の実行例です。

[armadillo ~]$ umount /opt/firmware
[armadillo ~]$ dd if=/tmp/imx_lib.img of=/dev/mmcblk2p4 bs=1M conv=fsync
23+1 records in
23+1 records out
24965120 bytes (25 MB, 24 MiB) copied, 0.357741 s, 69.8 MB/s

図6.129 ライブラリイメージを書き込む

書き込みが完了した後、/opt/firmware にマウントします。

[armadillo ~]$ mount /opt/firmware

図6.130 ライブラリパーティションのマウント

6.11.3. ライブラリイメージのバージョンを確認する

Armadillo に書き込んだライブラリイメージのバージョンは、次のコマンドを実行することで確認できます。

[armadillo ~]$ cat /opt/firmware/etc/imxlib_version
2.2.0

図6.131 ライブラリバージョンの確認


	図6.131「ライブラリバージョンの確認」によるバージョン確認方法は、ライブラリイメージのバージョンが2.2.0以降の場合のみ可能です。ライブラリイメージのバージョンが2.2.0未満の場合、/opt/firmware/etc/imxlib_versionファイルは存在しません。

6.11.4. コンテナ内からライブラリを使用するための準備

コンテナ内からライブラリを使用するためには、コンテナ作成時にライブラリの場所を明示する必要があります。

podman_start のコンテナコンフィグに add_volumes コマンドでファームウェアが書き込まれているディレクトリ (/opt/firmware) を、add_args で podman run の --env オプションにライブラリのパスを指定します。次の例では、コンテナイメージに Debian(bullseye) を利用しています。

/opt/firmware を渡すコンテナコンフィグの例

[armadillo ~]$ vi /etc/atmark/containers/container_name.conf
add_volumes /opt/firmware:/opt/firmware:ro 
add_args --env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu 
set_image docker.io/debian:bullseye
set_command sleep infinity
[armadillo ~]# podman_start container_name
Starting 'container_name'
5c2078ff7d54082c1d18b6c4f026c36675328cea61ee6a1ab1b27145df18d72a

	add_volumes で /opt/firmware を渡します。
	--env に LD_LIBRARY_PATH を指定し、コンテナ内のアプリケーションからライブラリをリンクできるようにします。

次に、コンテナにログインし、/opt/firmware/usr/lib/aarch64-linux-gnu/imx-mm へのシンボリックリンクを /usr/lib/aarch64-linux-gnu/ に作成します。

[armadillo ~]# podman exec -it container_name /bin/bash
[container ~]# ln -s /opt/firmware/usr/lib/aarch64-linux-gnu/imx-mm /usr/lib/aarch64-linux-gnu

図6.132 imx-mm へのシンボリックリンクを作成する

以上で、コンテナからライブラリを使用できるようになります。


	`at-debian-image` のコンテナを使用する場合には、変数やリンクがすでに作成されていますので `add_volumes` だけでライブラリを使えます。

6.12. マルチメディアデータを扱う

6.12.1. GStreamer - マルチメディアフレームワーク

6.12.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 では、マルチメディアデータをストリームとして扱います。ストリームを流すパイプラインの中に、エレメントと呼ばれる処理単位を格納し、それらを繋ぎ合わせることで、デコードやエンコードなどの処理を行います。

6.12.2. GStreamer 実行用コンテナを作成する

この章における GStreamer の実行例はアットマークテクノが提供する debian イメージから作成したコンテナ内で実行することを想定しています。ここではアットマークテクノが提供するイメージからコンテナを作成します。このイメージに関しては「アットマークテクノが提供するイメージを使う」を参照してください。

[armadillo ~]# vi /etc/atmark/containers/gst_example.conf
set_image at-debian-image
set_command weston --tty=7
add_devices /dev/dri /dev/galcore
add_devices /dev/mxc_hantro /dev/mxc_hantro_vc8000e
add_devices /dev/ion
add_devices /dev/input /dev/tty7
add_volumes /run/udev:/run/udev:ro
add_volumes /opt/firmware:/opt/firmware:ro
add_args --cap-add=SYS_TTY_CONFIG
add_volumes /tmp/xdg_home:/run/xdg_home
add_args --env=XDG_RUNTIME_DIR=/run/xdg_home
# カメラをコンテナ内で video3 として見せます
# パスがカメラによって変わりますので、自分の環境にあわせて
# 設定してください。
add_device /dev/v4l/by-path/platform-xhci-hcd.1.auto-usb-0:1.1:1.0-video-index1 /dev/video3
[armadillo ~]# podman_start gst_example
Starting 'gst_example'
b53c127075cdd157a2118f37121451ec58f2c273b84da197d61b4468a8328a8b
[armadillo ~]# podman exec -ti gst_example bash
[container /]#

図6.133 GStreamer を実行するためのコンテナ作成例

コンテナ内では最初に GStreamer をインストールします。

[container /]# apt update
[container /]# apt install gstreamer1.0-imx gstreamer1.0-imx-tools \
gstreamer1.0-tools gstreamer1.0-plugins-good gstreamer1.0-plugins-bad

図6.134 gstreamer のインストール

次に、コンテナ内で画面表示を行うためのデスクトップ環境を起動します。ここでは weston を起動します。

[container /]# weston --tty=7 &

図6.135 weston の起動

--tty=7 のオプションは画面表示に使用する tty の値を設定してください。

次に、音声を出力するのに必要な pulseaudio を起動します。

[conteiner /]# apt install pulseaudio
[container /]# pulseaudio --start --exit-idle-time=-1

図6.136 pulseaudio の起動

以上により、GSreamer をコンテナ内で実行できるようになります。

6.12.3. GStreamer パイプラインの実行例

パイプラインの実行例を以下に示します。

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! qtdemux name=demux0 demux0.video_0 ! h264parse ! queue ! vpudec ! queue \
! waylandsink window-width=1920 window-height=1080 demux0.audio_0 ! queue ! beepdec ! autoaudiosink

図6.137 GStreamer の実行例

GStreamer のパイプラインは、シェルスクリプトのパイプ構文の構造に似ています。GStreamer の各エレメントとシェルスクリプト内のコマンドを対比することができます。構文的な違いとして、 GStreamer のパイプラインは「!」を使って各エレメントを繋ぎますが、シェルスクリプトは「|」を使います。

上記例は、GStreamer のデバッグ/プロトタイピング用のコマンドラインツールである gst-launch-1.0 を使って説明しましたが、GStreamer はライブラリとして提供されているため、GStreamer を使ったマルチメディア機能を自作のアプリケーションプログラムに組み込むことができます。API やアプリケーション開発マニュアルは、gstreamer.freedesktop.org の Documentation ページ (http://gstreamer.freedesktop.org/documentation/)から参照することができます。

Armadillo-X2が採用している SoC である i.MX 8M Plus は、動画のデコード/エンコードを行うための Video Processing Unit(VPU) と呼ばれる専用プロセッサを搭載しています。Armadillo-X2には、この VPU を使用するための GStreamer エレメントがインストールされており、以下の動画コーデックではメイン CPU のパフォーマンスを落とすことなく動画のデコード/エンコードが行なえます。

デコード可能なコーデック
- H.264/AVC
- VP8
- VP9
エンコード可能なコーデック
- H.264/AVC

以降の章では、これらのコーデックに対する GStreamer の実行例を紹介します。

上記で挙げたコーデック以外のものであってもデコード/エンコードは可能ですが、その場合は CPU を使ったソフトウェア処理となってしまうため、システム全体のパフォーマンスは低下します。

6.12.4. 動画を再生する

GStreamer を使用して動画を再生するための実行例を、音声を含んでいる動画と含んでいない動画の 2 通りについて示します。 VPU でハードウェアデコードを行う GStreamer エレメントとして vpudec を使うことができます。

6.12.4.1. H.264/AVC 動画を再生する

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! qtdemux name=demux0 demux0.video_0 ! h264parse ! queue ! vpudec ! queue \
! waylandsink window-width=1920 window-height=1080 demux0.audio_0 ! queue ! beepdec ! autoaudiosink

図6.138 H.264/AVC 動画の再生(音声あり)

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! qtdemux ! h264parse ! vpudec ! queue ! waylandsink window-width=1920 window-height=1080

図6.139 H.264/AVC 動画の再生(音声なし)

6.12.4.2. VP8 動画を再生する

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! matroskademux name=demux0 demux0.video_0 ! queue ! vpudec ! queue \
! waylandsink window-width=1920 window-height=1080 demux0.audio_0 ! queue ! beepdec ! autoaudiosink

図6.140 VP8 動画の再生(音声あり)

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! matroskademux ! vpudec ! queue ! waylandsink window-width=1920 window-height=1080

図6.141 VP8 動画の再生(音声なし)

6.12.4.3. VP9 動画を再生する

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! matroskademux name=demux0 demux0.video_0 ! queue ! vpudec ! queue \
! waylandsink window-width=1920 window-height=1080 demux0.audio_0 ! queue ! beepdec ! autoaudiosink

図6.142 VP9 動画の再生(音声あり)

[container ~]# gst-launch-1.0 filesrc location=<ファイルパス> \
! matroskademux ! vpudec ! queue ! waylandsink window-width=1920 window-height=1080

図6.143 VP9 動画の再生(音声なし)

6.12.5. ストリーミングデータを再生する

GStreamer を使用してネットワーク上にある動画ファイルを HTTP 及び RTSP でストリーミング再生する実行例を示します。 VPU でハードウェアデコードを行う GStreamer エレメントとして vpudec を使うことができます。

6.12.5.1. HTTP ストリーミング

[container ~]# gst-launch-1.0 souphttpsrc location=<動画ファイルのURI> \
! qtdemux name=demux demux. ! queue ! vpudec ! queue \
! waylandsink demux. ! queue ! beepdec ! autoaudiosink

図6.144 HTTP ストリーミングの再生(音声あり)

[container ~]# gst-launch-1.0 souphttpsrc location=<動画ファイルのURI> \
! qtdemux ! queue ! vpudec ! queue ! waylandsink

図6.145 HTTP ストリーミングの再生(音声なし)

6.12.5.2. RTSP ストリーミング

[container ~]# gst-launch-1.0 rtspsrc location=<動画ファイルのURI> name=source \
! queue ! rtph264depay ! vpudec ! queue ! waylandsink source. ! queue \
! rtpmp4gdepay ! aacparse ! beepdec ! autoaudiosink

図6.146 RTSP ストリーミングの再生(音声あり)

[container ~]# gst-launch-1.0 rtspsrc location=<動画ファイルのURI> \
! queue ! rtph264depay ! vpudec ! queue ! waylandsink

図6.147 RTSP ストリーミングの再生(音声なし)

6.12.6. USB カメラからの映像を表示する

GStreamer の v4l2src エレメントを使うことで、V4L2(Video for Linux 2) デバイスとして実装されているカメラデバイスから映像を取得できます。どのデバイスから映像を取得するかは、v4l2src エレメントの device プロパティにデバイスファイル名を指定することで変更できます。 UVC 対応 USB カメラなども同様に v4l2src で扱うことができるので、ここでは USB カメラからの映像を表示する実行例を示します。

加えて、カメラの他にマイクも接続していて、同時にマイクからの音声も出力する場合の例も示しています。実行例中のデバイスファイル /dev/video1 の部分や、縦横サイズである width や height の値は実行する環境によって異なる可能性がありますので、適宜変更してください。また、/dev/v4l/by-id ディレクトリの下に、接続しているカメラ名の付いた /dev/videoN へのシンボリックリンクがありますので、デバイスとしてそれを指定することも可能です。

[container ~]# gst-launch-1.0 v4l2src device=/dev/video1 \
! video/x-raw,width=640,height=480,framerate=30/1 \
! waylandsink window-width=640 window-height=480 pulsesrc \
! audio/x-raw,rate=44100,channels=2 ! autoaudiosink

図6.148 USB カメラからの映像表示(音声あり)

[container ~]# gst-launch-1.0 v4l2src device=/dev/video1 \
! video/x-raw,width=640,height=480,framerate=30/1 \
! waylandsink window-width=640 window-height=480

図6.149 USB カメラからの映像表示(音声なし)

6.12.7. USBカメラからの映像を録画する

加えて、カメラの他にマイクも接続していて、映像の保存と同時にマイクからの音声も MP3 へエンコードして保存する場合の例も示しています。実行例中のデバイスファイル /dev/video1 の部分や、縦横サイズである width や height の値は実行する環境によって異なる可能性がありますので、適宜変更してください。また、/dev/v4l/by-id ディレクトリの下に、接続しているカメラ名の付いた /dev/videoN へのシンボリックリンクがありますので、デバイスとしてそれを指定することも可能です。

パイプライン停止時に EOS イベントを発行するように、gst-launch-1.0 コマンドに-e オプションを付けています。エンコードを終了するには、Ctrl-C で gst-launch-1.0 コマンドを停止してください。

6.12.7.1. H.264/AVC で録画する

VPU でハードウェアエンコードを行う GStreamer エレメントとして vpuenc_h264 を使うことができます。

[container ~]# gst-launch-1.0 -e v4l2src device=/dev/video1 \
! video/x-raw,width=640,height=480,framerate=30/1 \
! queue ! vpuenc_h264 ! h264parse ! queue ! mux. pulsesrc \
! audio/x-raw,rate=44100,channels=2 ! lamemp3enc ! queue \
! mux. qtmux name=mux ! filesink location=./output.mp4

図6.150 USB カメラからの映像をH.264で録画(音声あり)

[container ~]# gst-launch-1.0 -e v4l2src device=/dev/video1 \
! video/x-raw,width=640,height=480,framerate=30/1 \
! queue ! vpuenc_h264 ! h264parse ! queue \
! filesink location=./output.mp4

図6.151 USB カメラからの映像をH.264で録画(音声なし)

表示と録画を同時に行う

[container ~]# gst-launch-1.0 -e v4l2src device=/dev/video1 \
! video/x-raw,width=640,height=480,framerate=30/1 \
! tee name=t1 ! queue ! vpuenc_h264 ! h264parse ! queue ! mux. pulsesrc \
! tee name=t2 ! audio/x-raw,rate=44100,channels=2 ! lamemp3enc ! queue \
! mux. qtmux name=mux ! filesink location=./output.mp4 t1. ! queue \
! waylandsink window-width=640 window-height=480 t2. ! queue ! autoaudiosink

図6.152 USB カメラからの映像を表示しながらH.264で録画(音声あり)

[container ~]# gst-launch-1.0 -e v4l2src device=/dev/video1 \
! video/x-raw,width=640,height=480,framerate=30/1 \
! tee name=t1 ! queue ! vpuenc_h264 ! h264parse ! queue \
! qtmux ! filesink location=./output.mp4 t1. ! queue \
! waylandsink window-width=640 window-height=480

図6.153 USB カメラからの映像を表示しながらH.264で録画(音声なし)

6.12.8. Video Processing Unit(VPU)

6.12.8.1. Video Processing Unit とは

Video Processing Unit(以下、VPU) とは i.MX 8M Plus に搭載されている、動画のエンコード/デコード処理専用のプロセッサです。動画のエンコード/デコード処理は、システムに負荷をかけることが多く、メイン CPU で処理を行うとシステム全体のパフォーマンスが低下します。 VPU を利用することでシステム全体のパフォーマンスを落とすことなく、動画のエンコード/デコード処理を行うことができます。

VPU が対応しているフォーマットは以下の通りです。

デコーダーが対応しているフォーマット
- H.264/AVC
- VP8
- VP9
エンコーダが対応しているフォーマット
- H.264/AVC

6.12.8.2. VPUの仕様

H.264/AVC デコーダー

表6.12 H.264/AVC デコーダー仕様

Profile	High、Main、Baseline
Min resolution	48x48
Max resolution	1920x1080
Frame rate	60 fps
Bitrate	60 Mbps

VP8 デコーダー

表6.13 VP8 デコーダー仕様

Profile	-
Min resolution	48x48
Max resolution	1920x1080
Frame rate	60 fps
Bitrate	60 Mbps

VP9 デコーダー

表6.14 VP9 デコーダー仕様

Profile	Profile 0, 2
Min resolution	72x72
Max resolution	1920x1080
Frame rate	60 fps
Bitrate	100 Mbps

H.264/AVC エンコーダー

表6.15 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

6.13. デモアプリケーションを実行する

この章では、アットマークテクノが提供するデモアプリケーションについて説明します。デモアプリケーションは GUI アプリケーションであるため、ディスプレイを接続している必要があります。デモアプリケーションを実行するためのコンテナイメージとして、アットマークテクノが提供するコンテナイメージを想定しています。このイメージに関しては「アットマークテクノが提供するイメージを使う」を参照してください。

また、パッケージのインストールにはデフォルトの tmpfs の容量が少ないので、あらかじめ abos-ctrl podman-storage --disk で podman のストレージを eMMC に切り替えてください。開発が終わったら必ず tmpfs に戻ってください。

6.13.1. コンテナを作成する

デモアプリケーションを実行するためのコンテナを以下のように作成します。

デモアプリケーションは GUI アプリケーションであるため、まずデスクトップ環境を起動する必要があります。ここでは weston を起動します。

[armadillo ~]# vi /etc/atmark/containers/demo_app.conf
set_image localhost/at-debian-image:latest
set_command weston --tty=7
add_args -ti --privileged
add_args --env=VIV_VX_ENABLE_CACHE_GRAPH_BINARY=1
add_args --env=VIV_VX_CACHE_BINARY_GRAPH_DIR=/var/cache/armadillo-demo-experience
add_volumes /sys /dev /run/udev /opt/firmware
add_volumes cache:/var/cache/armadillo-demo-experience
[armadillo ~]# podman_start demo_app
Starting 'demo_app'
b984a8cdf88539c32241618baf45651c92ab9318d82e1a7fbf2a4c0cba315efd
[armadillo ~]# podman exec -it demo_app bash
[container /]#

図6.154 デモアプリケーションを実行するためのコンテナ作成例

6.13.2. デモアプリケーションランチャを起動する

デモアプリケーションランチャを起動します。個々のデモアプリケーションはこのデモアプリケーションランチャから起動できます。このデモアプリケーションランチャは GUI フレームワークとして Flutter を使用しています。デモアプリケーションランチャのソースコードは、apt source で取得することができます。

[container /]# apt install armadillo-demo-experience
[container /]# demoexperience

図6.155 デモアプリケーションランチャの起動

以下のようなアプケーションが起動します。

左側のカテゴリから起動したいデモアプリケーションを選びます。

選んだアプリケーションは、右下の「起動」ボタンで起動することができます。

デモアプリケーションには TensorFlow Lite と NPU を使用するものが含まれています。 TensorFlow Lite と NPU を扱うライブラリのバージョンによっては、デモアプリケーションが正しく動作しない場合があります。以下のバージョンになっていることを確認してください。

表6.16 デモアプリケーション動作のために必要なバージョン

パッケージ名	必要バージョン
tensorflow-lite	2.8.0 以上
python3-tflite-runtime	2.8.0 以上
tensorflow-lite-vx-delegate	2.8.0 以上
tim-vx	1.1.39 以上

各パッケージのバージョンは、コンテナ内で以下のコマンドを実行することで確認できます。以下は、tensorflow-lite のバージョンを確認する例です。

[container ~]# dpkg -l tensorflow-lite
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name            Version      Architecture Description
+++-===============-============-============-===============================================
ii  tensorflow-lite 2.8.0-1      arm64        deep learning framework for on-device inference

図6.156 パッケージのバージョンを確認する

バージョンの条件を満たしていない場合は、 apt update && apt upgrade を実行してアップデートを行ってください。

6.13.3. mediaplayer

mediaplayer は動画を再生するアプリケーションです。H.264, VP8, VP9 でエンコードされた動画ファイルであれば、動画のデコードに VPU が使われます。File メニューから、再生したい動画ファイルを選択することができます。このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。

音声も出力したい場合は、pulseaudio をインストールして起動する必要があります。

[container /]# apt install pulseaudio
[container /]# pulseaudio --start --exit-idle-time=-1

図6.157 pulseaudio のインストールと起動

6.13.4. video recoder

video recoder は gstreamer を使用してカメラからの映像を録画することができます。そのため、このアプリケーションを使用するためには、Armadillo 本体にカメラを接続する必要があります。カメラが接続されていると Video device の項目でカメラを選択できるようになります。カメラを選択し、Start ボタンを押すと別ウィンドウが表示され録画が開始されます。アプリケーション上のテキストボックスには、Start ボタンを押したときに起動する gstreamer のコマンドを表示しています。テキストボックスの内容はキーボードで編集可能です。このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。

マイク付きのカメラなどで同時に音声も録音したい場合は、「mediaplayer」を参照して pulseaudio を起動してください。

6.13.5. led switch tester

led switch tester は Armadillo 本体上の LED と SW1 を扱うアプリケーションです。 LED ボタンを押すことで Armadillo 本体上の LED の点灯・消灯を確認することができます。 Armadillo 本体上の SW1 を押すとアプリケーションの SW1 部分の表示が変化することを確認できます。このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。

6.13.6. rtc tester

rtc tester は Armadillo 本体上の RTC に対して日時の設定および取得が行えるアプリケーションです。カレンダー上から日付を選び、Time に設定したい時刻を入力した後、Set ボタンを押すと RTC にその日時が設定されます。Get ボタンを押すと、現在の日時を RTC から読み込みアプリケーション上に反映されます。このアプリケーションは、GUI フレームワークとして wxWidgets を使用しています。

6.13.7. object detection demo

object detection demo はカメラからの映像に対して物体認識を行うアプリケーションです。 NPU を使用しているため高速に物体認識を行えます。画面の左側には認識した物体を囲む四角形が表示され、右側には認識した物体のラベルとスコアが表示されます。このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。

起動する前に、必要な Python ライブラリをインストールする必要があります。

[container /]# pip3 install pillow

図6.158 pillow のインストールと起動

このアプリケーションはカメラデバイスとしてデフォルトで /dev/video2 を使用します。お使いの環境によって別のカメラデバイスに設定したい場合は、以下のファイルを変更してください。

[container /]# vi /usr/share/armadillo-demo-experience/resources/demos.json
:
: (省略)
:
{"Machine Learning":[{
        "Tensorflow Lite":[{
            "name": "object detection demo",
            "executable": "python3 /usr/share/armadillo-demo-experience/AI-demo/object_detection/detect_usbcamera.py --model /usr/share/armadillo-demo-experience/AI-demo/object_detection/detect.tflite --labels /usr/share/armadillo-demo-experience/AI-demo/object_detection/coco_labels.txt --camera_id 2", 
            "compatible": "armadillo-x2",
            "description": "This is a simple object detection application that used NPU and TensorFlow Lite on the Armadillo-X2 board."
        }]
    }]

図6.159 ビデオデバイスの変更

--camera_id の値を環境に合わせて変更します。

6.13.8. pose estimation demo

pose estimation demo はカメラに映った人物の姿勢を推定して表示するアプリケーションです。 NPU を使用しているため高速に姿勢推定を行えます。推定した姿勢は人物の上に重ねて表示されます。このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。

このアプリケーションは起動してから画面に映像が表示されるまで初回のみ約 1 分ほどかかります。 2回目以降の起動では 5 秒程度で映像が表示されます。また、カメラデバイスとしてデフォルトで /dev/video2 を使用します。お使いの環境によって別のカメラデバイスに設定したい場合は、以下のファイルを変更してください。

[container /]# vi /usr/share/armadillo-demo-experience/resources/demos.json
:
: (省略)
:
{"Machine Learning":[{
:
: (省略)
:
        {
            "name": "pose estimation",
            "executable": "python3 /usr/share/armadillo-demo-experience/AI-demo/pose_estimation/pose_estimation.py --model /usr/share/armadillo-demo-experience/AI-demo/pose_estimation/posenet.tflite --camera_id 2", 
            "source": "",
            "screenshot": "pose_estimation_demo.png",
            "compatible": "armadillo-x2",
            "description": "This is a simple pose estimation application that uses NPU on the Armadillo-X2 board."
        }]
    }]

図6.160 ビデオデバイスの変更

--camera_id の値を環境に合わせて変更します。

6.13.9. image segmentation demo

image segmentation demo はカメラに映った人物の「人物として認識された領域(セグメント)」を推定して表示するアプリケーションです。 NPU を使用しているため高速に領域推定を行えます。推定した領域は人物の上に青の透過色で重ねて表示されます。このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。

[container /]# vi /usr/share/armadillo-demo-experience/resources/demos.json
:
: (省略)
:
{"Machine Learning":[{
:
: (省略)
:
        {
            "name": "image segmentation",
            "executable": "python3 /usr/share/armadillo-demo-experience/AI-demo/image_segmentation/image_segmentation.py --model /usr/share/armadillo-demo-experience/AI-demo/image_segmentation/human_segmentation.tflite --camera_id 2", 
            "source": "",
            "screenshot": "image_segmentation_demo.png",
            "compatible": "armadillo-x2",
            "description": "This is a simple image segmentation application that uses NPU on the Armadillo-X2 board."
        }]
    }]

図6.161 ビデオデバイスの変更

--camera_id の値を環境に合わせて変更します。

6.13.10. super resolution demo

super resolution demo はカメラの映像の中央部 50 x 50 ピクセルの領域を 200 x 200 ピクセルに解像度を上げて表示する (超解像) アプリケーションです。NPU を使用しているため高速に超解像を行えます。このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。

画面右上は最近傍補間で 200 x 200 ピクセルに拡大した映像、画面右下が超解像で 200 x 200 ピクセルにした映像です。

[container /]# vi /usr/share/armadillo-demo-experience/resources/demos.json
:
: (省略)
:
{"Machine Learning":[{
:
: (省略)
:
        {
            "name": "super resolution",
            "executable": "python3 /usr/share/armadillo-demo-experience/AI-demo/super_resolution/super_resolution.py --model /usr/share/armadillo-demo-experience/AI-demo/super_resolution/super_resolution.tflite --camera_id 2", 
            "source": "",
            "screenshot": "super_resolution_demo.png",
            "compatible": "armadillo-x2",
            "description": "This is a super resolution application that uses NPU on the Armadillo-X2 board."
        }]
    }]

図6.162 ビデオデバイスの変更

--camera_id の値を環境に合わせて変更します。

6.13.11. hand estimation demo

hand estimation demo はカメラに映った人物の手指を検出してその領域と手の骨格を同時に表示するアプリケーションです。 NPU を使用しているため高速に手指検出を行えます。検出した手指の領域と骨格は手指の上に重ねて表示されます。このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。

このアプリケーションは起動してから画面に映像が表示されるまで初回のみ約 30 秒ほどかかります。 2回目以降の起動では 5 秒程度で映像が表示されます。また、カメラデバイスとしてデフォルトで /dev/video2 を使用します。お使いの環境によって別のカメラデバイスに設定したい場合は、以下のファイルを変更してください。

[container /]# vi /usr/share/armadillo-demo-experience/resources/demos.json
:
: (省略)
:
{"Machine Learning":[{
:
: (省略)
:
        {
            "name": "hand estimation",
            "executable": "python3 /usr/share/armadillo-demo-experience/AI-demo/hand_estimation/hand_estimation.py --landmark_model /usr/share/armadillo-demo-experience/AI-demo/hand_estimation/hand.tflite --detection_model /usr/share/armadillo-demo-experience/AI-demo/hand_estimation/palm.tflite --camera_id 2", 
            "source": "",
            "screenshot": "hand_estimation_demo.png",
            "compatible": "armadillo-x2",
            "description": "This is a simple hand estimation application that uses NPU on the Armadillo-X2 board."
        }]
    }]

図6.163 ビデオデバイスの変更

--camera_id の値を環境に合わせて変更します。

6.13.12. screw detection demo

screw detection demo はカメラに映ったネジを検出してその領域を表示するアプリケーションです。また、領域の大きさからネジの長さを測り、しきい値以下であれば赤枠、それ以外は青枠で領域を囲います。各種パラメータはコマンドライン引数で指定可能です。

NPU を使用しているため高速にネジの検出を行えます。検出したネジの領域はネジの上に重ねて表示されます。このアプリケーションは機械学習のライブラリとして TensorFlow Lite を使用しています。

[container /]# vi /usr/share/armadillo-demo-experience/resources/demos.json
:
: (省略)
:
{"Machine Learning":[{
:
: (省略)
:
        {
            "name": "screw detection",
            "executable": "python3 /usr/share/armadillo-demo-experience/AI-demo/screw_detection/screw_detection.py --camera_id 2 --conf_thres 0.5 --iou_thres 0.45 --len_thres 130", 
            "source": "",
            "screenshot": "screw_detection_demo.png",
            "compatible": "armadillo-x2",
            "description": "This is a simple screw detection application that uses NPU on the Armadillo-X2 board."
        }]
    }]

図6.164 各種コンフィグの変更

この行の各パラメータを変更することで、アプリケーションの挙動が変化します。各パラメータの詳細は表6.17「ネジ検出デモのパラメータの詳細」を参照してください。

表6.17 ネジ検出デモのパラメータの詳細

パラメータ名	意味
camera_id	使用するカメラを指定します。/dev/videoNのNに相当します。
conf_thres	AIがネジと認識した確度のしきい値です。この値以下の確度の物体はネジとみなされません。
iou_thres	ネジ検出の後処理に使用するパラメータです。
len_thres	長いネジと短いネジの境界値を設定できます。
visualize_score	これを指定すると、AIがネジと認識した確度を描画します。
visualize_length	これを指定すると、ネジの長さを描画します。

6.14. ssh 経由で Armadillo Base OS にアクセスする

Armadillo-X2 にはopensshがインストールされていますが、デフォルトではSSHサーバーが起動していません。

SSHサーバーを自動的に起動するようにするためには、以下のコマンドを実行してください。

[armadillo:~]# rc-update add sshd
 * service sshd added to runlevel default
[armadillo ~]# persist_file /etc/runlevels/default/sshd
[ 2819.277066] EXT4-fs (mmcblk2p1): re-mounted. Opts: (null)
[armadillo ~]# reboot

上記の例では、再起動後も設定が反映されるように、 persist_file コマンドでeMMCに設定を保存しています。

6.15. コマンドラインからネットワーク設定をする

基本的に、 Armadillo-X2 のネットワーク設定は、「ネットワーク設定」で紹介したとおり、 ABOS Web で行います。しかし、 ABOS Webで対応できない複雑なネットワーク設定を行いたい場合などは、コマンドラインからネットワークの設定を行うことも可能です。

ここでは、コマンドラインからネットワークを設定する方法について説明します。

6.15.1. 接続可能なネットワーク

Armadillo-X2 は、1つの Ethernet ポートが搭載されています。 Linuxからは、 eth0 に見えます。

表6.18 ネットワークとネットワークデバイス

ネットワーク	ネットワークデバイス	出荷時の設定
Ethernet	`eth0`	DHCP

6.15.2. IP アドレスの確認方法

Armadillo-X2 の IP アドレスを確認するには、ip addr コマンドを使用します。

[armadillo ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:0c:00:0b:79 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.84/16 brd 172.16.255.255 scope global dynamic noprefixroute eth0
       valid_lft 28786sec preferred_lft 28786sec
    inet6 fe80::e9c0:7b3c:c0c9:3c4/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

図6.165 IP アドレスの確認

inet となっている箇所が IP アドレスです。特定のインターフェースのみを表示したい場合は、以下のようにします。

[armadillo ~]# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:0c:00:0b:79 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.84/16 brd 172.16.255.255 scope global dynamic noprefixroute eth0
       valid_lft 28656sec preferred_lft 28656sec
    inet6 fe80::e9c0:7b3c:c0c9:3c4/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

図6.166 IP アドレス(eth0)の確認

6.15.3. ネットワークの設定方法

Armadillo-X2 では、通常の Linux システムと同様、ネットワークインターフェースの設定は NetworkManager を使用します。 NetworkManager はすべてのネットワーク設定をコネクションとして管理します。コネクションには「どのようにネットワークへ接続するか」、「どのようにネットワークを作成するか」を記述し、 /etc/NetworkManager/system-connections/ に保存します。また、1つのデバイスに対して複数のコネクションを保存することは可能ですが、1つのデバイスに対して有効化にできるコネクションは1つだけです。

NetworkManager は、従来の /etc/network/interfaces を使った設定方法もサポートしていますが、本書では nmcli を用いた方法を中心に紹介します。

6.15.3.1. nmcli について

nmcli は NetworkManager を操作するためのコマンドラインツールです。図6.167「nmcli のコマンド書式」に nmcli の書式を示します。このことから、 nmcli は「オブジェクト (OBJECT) というものが存在し、それぞれのオブジェクトに対してコマンド (COMMAND) を実行する。」という書式でコマンドを入力することがわかります。また、オブジェクトそれぞれに help が用意されていることもここから読み取れます。

nmcli [ OPTIONS ] OBJECT { COMMAND | help }

図6.167 nmcli のコマンド書式

6.15.4. nmcli の基本的な使い方

ここでは nmcli の、基本的な使い方を説明します。

6.15.4.1. コネクションの一覧

登録されているコネクションの一覧を確認するには、次のようにコマンドを実行します。 ^[14]

[armadillo ~]# nmcli connection
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  a6f99120-b4ed-3823-a6f0-0491d4b6101e  ethernet  eth0

図6.168 コネクションの一覧

表示された NAME については、以降 [ID] として利用することができます。

6.15.4.2. コネクションの有効化・無効化

コネクションを有効化するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection up [ID]

図6.169 コネクションの有効化

コネクションを無効化するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection down [ID]

図6.170 コネクションの無効化

6.15.4.3. コネクションの作成

コネクションを作成するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection add con-name [ID] type [type] ifname [interface name]

図6.171 コネクションの作成

[ID] にはコネクションの名前(任意)、[type] には ethernet、wifi といった接続タイプ、 [interfacename] にはインターフェース名(デバイス)を入力します。これにより /etc/NetworkManager/system-connections/ に[ID]の名前でコネクションファイルが作成されます。このファイルを vi などで編集し、コネクションを修正することも可能です。

Armadillo-X2 を再起動したときにコネクションファイルが消えてしまわないように、 persist_file コマンドで永続化する必要があります。 persist_file コマンドに関する詳細は「persist_file について」を参照してください。

[armadillo ~]# persist_file /etc/NetworkManager/system-connections/<コネクションファイル名>

図6.172 コネクションファイルの永続化

別の Armadillo-X2 からコネクションファイルをコピーした場合は、コネクションファイルのパーミッションを 600 に設定してください。 600 に設定後、 nmcli c reload コマンドでコネクションファイルを再読込します。

[armadillo ~]# chmod 600 /etc/NetworkManager/system-connections/<コネクションファイル名>
[armadillo ~]# persist_file /etc/NetworkManager/system-connections/<コネクションファイル名>
[armadillo ~]# nmcli c reload

swu イメージを使用してコネクションファイルのアップデートを行う場合は、 swu イメージに含めるコネクションファイルのパーミッションを 600 に設定してから、 swu イメージを作成してください。アップデート実行時には swu イメージ作成時のパーミッションが維持されるため、上記のコマンド実行手順は不要です。 swu イメージに関しては「アップデート機能について」を参考にしてください。

6.15.4.4. コネクションの削除

コネクションを削除するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli connection delete [ID]

図6.173 コネクションの削除

これにより /etc/NetworkManager/system-connections/ のコネクションファイルも同時に削除されます。コネクションの作成と同様に persist_file コマンドで永続化する必要があります。

[armadillo ~]# persist_file -d /etc/NetworkManager/system-connections/<コネクションファイル名>

図6.174 コネクションファイル削除時の永続化

6.15.4.5. 固定IPアドレスに設定する

表6.19「固定 IP アドレス設定例」の内容に設定する例を、図6.175「固定 IP アドレス設定」に示します。

表6.19 固定 IP アドレス設定例

項目	設定
IP アドレス	192.0.2.10
マスク長	24
デフォルトゲートウェイ	192.0.2.1

[armadillo ~]# nmcli connection modify [ID] \
ipv4.method manual ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1

図6.175 固定 IP アドレス設定

6.15.4.6. DNS サーバーを指定する

DNS サーバーを指定する例を、図6.176「DNS サーバーの指定」に示します。

[armadillo ~]# nmcli connection modify [ID] ipv4.dns 192.0.2.1

図6.176 DNS サーバーの指定

6.15.4.7. DHCP に設定する

DHCP に設定する例を、図6.177「DHCP の設定」に示します。

[armadillo ~]# nmcli connection modify [ID] ipv4.method auto

図6.177 DHCP の設定


	`-ipv4.addresses` のように、プロパティ名の先頭に "-" を付けることで設定したプロパティを削除することができます。反対に "+" を付けることでプロパティを追加することができます。

6.15.4.8. コネクションの修正を反映する

有効化されているコネクションを修正した場合、かならず修正したコネクションを再度有効化してください。

[armadillo ~]# nmcli connection down [ID]
[armadillo ~]# nmcli connection up [ID]

図6.178 コネクションの修正の反映

6.15.4.9. デバイスの一覧

デバイスの一覧(デバイス名、タイプ、状態、有効なコネクション)を確認するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli device
DEVICE  TYPE      STATE        CONNECTION
eth0    ethernet  connected    Wired connection 1
lo      loopback  unmanaged    --

図6.179 デバイスの一覧

6.15.4.10. デバイスの接続

デバイスを接続するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli device connect [ifname]

図6.180 デバイスの接続


	デバイスを接続するには、接続しようとしているデバイスの有効なコネクションが必要です。"Error: neither a valid connection nor device given" というメッセージが表示された場合には、 `nmcli connection` などで有効なコネクションがあるかを確認してください。

6.15.4.11. デバイスの切断

デバイスを切断するには、次のようにコマンドを実行します。

[armadillo ~]# nmcli device disconnect [ifname]

図6.181 デバイスの切断

6.15.5. 有線 LAN

有線 LAN で正常に通信が可能か確認します。設定を変更した場合、必ず変更したインターフェースを再度有効化してください。

同じネットワーク内にある通信機器と PING 通信を行います。以下の例では、通信機器が「192.0.2.20」という IP アドレスを持っていると想定しています。

[armadillo ~]# ping -I eth0 -c 3 192.0.2.20 
PING 192.0.2.20 (192.0.2.20): 56 data bytes
64 bytes from 192.0.2.20: seq=0 ttl=64 time=3.056 ms
64 bytes from 192.0.2.20: seq=1 ttl=64 time=1.643 ms
64 bytes from 192.0.2.20: seq=2 ttl=64 time=1.633 ms

--- 192.0.2.20 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.633/2.110/3.056 ms

図6.182 有線 LAN の PING 確認

-I オプションでインターフェースを指定できます。eth1 を確認する場合は -I eth1 としてください。


	有線 LAN 以外のインターフェースが有効化されている場合、ルーティングの設定などにより、ネットワーク通信に有線 LAN が使用されない場合があります。設定を必ず確認してください。確実に有線 LAN の接続確認をする場合は、有線 LAN 以外のインターフェースを無効化してください。

6.15.6. ファイアウォールの設定方法

開放しているポートが存在すると攻撃者の標的になる可能性があります。開発したサーバーが使用するポートに対して、アクセスできる IP アドレスを制限することでセキュリティ上のリスクを低減することができます。

ここでは、iptables コマンドを使用した、パケットフィルタリングによるアクセス制限方法を紹介します。

図6.183「特定のポートに対する IP アドレスのフィルタリング」の例では、Armadillo の特定のポートに対して、特定の IP アドレスからのアクセスのみを受け入れるようにします。この例では、<送信元 IP アドレス> は Armadillo にパケットを送信する IP アドレス、<ポート番号> はパケットを受け入れる Armadillo のポート番号、<プロトコル> は通信プロトコルのことを指します。また、<ポート番号> はパケットを受け入れる Armadillo のポート番号のことを指します。

[armadillo ~]# iptables -I INPUT -s <送信元 IP アドレス> -p <プロトコル> --dport <ポート番号> -j ACCEPT 
[armadillo ~]# iptables -A INPUT -p <プロトコル> --dport <ポート番号> -j REJECT 
[armadillo ~]# iptables -L 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     <プロトコル>  --  <送信元 IP アドレス> anywhere             <プロトコル> dpt:<ポート番号>
REJECT     <プロトコル>  --  anywhere             anywhere             <プロトコル> dpt:<ポート番号> reject-with icmp-port-unreachable
... 省略

[armadillo ~]# /etc/init.d/iptables save 
[armadillo ~]# persist_file /etc/iptables/rules-save

図6.183 特定のポートに対する IP アドレスのフィルタリング

	<ポート番号> に <送信元 IP アドレス> から送られてきたパケットを受け入れるように設定します。
	<ポート番号> に <送信元 IP アドレス> 以外から送信されてきたパケットを拒否するように設定します。
	想定通りに設定されているか確認します。
	上記の設定を設定ファイル /etc/iptables/rules-save に保存します。
	保存した設定ファイルを永続化します。

図6.183「特定のポートに対する IP アドレスのフィルタリング」はあくまで一例ですが、このように iptables コマンドを用いることで開発したサーバーにアクセスできる IP アドレスを制限することができます。

上記の設定を削除する場合は図6.184「特定のポートに対する IP アドレスのフィルタリングの設定を削除」に示すコマンドを実行してください。

[armadillo ~]# armadillo:~# iptables -L --line-number 
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     <プロトコル>  --  <送信元 IP アドレス> anywhere             <プロトコル> dpt:<ポート番号>
2    REJECT     <プロトコル>  --  anywhere             anywhere             <プロトコル> dpt:<ポート番号> reject-with icmp-port-unreachable
... 省略

[armadillo ~]# iptables -D INPUT 2 
[armadillo ~]# iptables -D INPUT 1 
[armadillo ~]# /etc/init.d/iptables save 
[armadillo ~]# persist_file /etc/iptables/rules-save

図6.184 特定のポートに対する IP アドレスのフィルタリングの設定を削除

	削除する設定の番号（num）を確認します。ここでは 1 番と 2 番の設定を削除します。
	2 番の設定を削除します。
	1 番の設定を削除します。
	上記の設定を設定ファイル /etc/iptables/rules-save に保存します。
	保存した設定ファイルを永続化します。

6.16. ストレージの操作

ここでは、microSDHC カードを接続した場合を例にストレージの使用方法を説明します。以降の説明では、共通の操作が可能な場合に、microSD/microSDHC/microSDXCカードを microSD カードと表記します。

6.16.1. ストレージ内にアクセスする

Linux では、アクセス可能なファイルやディレクトリは、一つの木構造にまとめられています。あるストレージデバイスのファイルシステムを、この木構造に追加することを、マウントするといいます。マウントを行うコマンドは、 mount です。

mount コマンドの典型的なフォーマットは、次の通りです。

mount [-t fstype] device dir

図6.185 mount コマンド書式

-t オプションに続く fstype には、ファイルシステムタイプを指定します。ファイルシステムタイプの指定は省略可能です。省略した場合、mount コマンドはファイルシステムタイプを推測します。この推測は必ずしも適切なものとは限りませんので、事前にファイルシステムタイプが分かっている場合は明示的に指定してください。 FAT32 ファイルシステムの場合は vfat 、EXT3 ファイルシステムの場合は ext3 を指定します。


	通常、購入したばかりの microSDHC カードは FAT32 または exFAT ファイルシステムでフォーマットされています。

device には、ストレージデバイスのデバイスファイル名を指定します。microSD カードのパーティション1の場合は /dev/mmcblk1p1 、パーティション2の場合は /dev/mmcblk1p2 となります。

dir には、ストレージデバイスのファイルシステムをマウントするディレクトリを指定します。

SD インターフェース (CON1) に microSD カードを挿入し、以下に示すコマンドを実行すると、 /mnt ディレクトリに microSD カードのファイルシステムをマウントすることができます。 microSDカード内のファイルは、/mnt ディレクトリ以下に見えるようになります。

[armadillo ~]# mount -t vfat /dev/mmcblk1p1 /mnt
[armadillo ~]# ls /mnt
  :
  :

図6.186 ストレージのマウント

6.16.2. ストレージを安全に取り外す

ストレージを安全に取り外すには、アンマウントという作業が必要です。アンマウントを行うコマンドは、 umount です。オプションとして、アンマウントしたいデバイスがマウントされているディレクトリを指定します。

[armadillo ~]# umount /mnt

図6.187 ストレージのアンマウント

6.16.3. ストレージのパーティション変更とフォーマット

通常、購入したばかりの microSD カードや USB メモリは、一つのパーティションを持ち、FAT32ファイルシステムでフォーマットされています。

パーティション構成を変更したい場合、 fdisk コマンドを使用します。 fdisk コマンドの使用例として、一つのパーティションで構成されている microSD カードのパーティションを、2つに分割する例を図6.188「fdiskコマンドによるパーティション変更」に示します。一度、既存のパーティションを削除してから、新たにプライマリパーティションを二つ作成しています。先頭のパーティションには 100MByte、二つめのパーティションに残りの容量を割り当てています。先頭のパーティションは /dev/mmcblk1p1 、二つめは /dev/mmcblk1p2 となります。

[armadillo ~]# fdisk /dev/mmcblk1

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-15138815, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-15138815, default 15138815): +100M

Created a new partition 1 of type 'Linux' and of size 100 MiB.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (206848-15138815, default 206848):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (206848-15138815, default 15138815):

Created a new partition 2 of type 'Linux' and of size 7.1 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
[  305.798606]  mmcblk1: p1 p2
Syncing disks.

図6.188 fdiskコマンドによるパーティション変更

FAT32 ファイルシステムでストレージデバイスをフォーマットするには、 mkfs.vfat コマンドを使用します。また、EXT2 や EXT3、EXT4 ファイルシステムでフォーマットするには、mkfs.ext2 や mkfs.ext3 、 mkfs.ext4 コマンドを使用します。 microSD カードのパーティション1を EXT4 ファイルシステムでフォーマットするコマンド例を次に示します

[armadillo ~]# mkfs.ext4 /dev/mmcblk1p1

図6.189 EXT4 ファイルシステムの構築

6.17. ボタンやキーを扱う

buttond サービスを使用することで、ボタンやキー入力をトリガーとする処理を簡単に実装できます。

/etc/atmark/buttond.conf に BUTTOND_ARGS を指定することで、動作を指定することができます:

--short <key> --action "command" : 短押しの設定。キーを 1 秒以内に離せば短押しと認識し "command"を実行します。認識する最大時間は --time <time_ms> オプションで変更可能です。
--long <key> --action "command" : 長押しの設定。キーを 5 秒押し続けたタイミングで "command" を実行します。長押しと認識する最低時間は --time <time_ms> オプションで変更可能です。
1 つのキーに対して複数の設定が可能です。長押しの設定が複数ある場合、押したままの状態だと一番長い時間に設定されている "command" を実行します。途中でキーを離した場合は、キーを離した時間に応じた "command" を実行します。(例：buttond --short <key> --action "cmd1" --long <key> --time 2000 --action "cmd2" --long <key> --time 10000 --action "cmd3" <file> を実行した場合、1 秒以内に離すと "cmd1"、2 秒以上 10 秒以内に離すと "cmd2"、10 秒を越えたら "cmd3" を実行します)。
- 短押し設定を複数指定する場合、時間の短い設定を先に指定してください。 0.5秒、1 秒を設定したい場合、1 秒 → 0.5 秒の順番で指定すると 0.5秒が無視されます。
--exit-timeout <time_ms> : 設定した時間の後に buttond を停止します。起動時のみに対応したい場合に使えます。
キーの設定の --exit-after オプション : キーのコマンドを実行した後に buttond を停止します。キーの対応を一回しか実行しないように使えます。

6.17.1. SW1 の短押しと長押しの対応

以下にデフォルトを維持したままで SW1 の短押しと長押しのそれぞれの場合にコマンドを実行させる例を示します。

[armadillo ~]# vi /etc/atmark/buttond.conf 
BUTTOND_ARGS="$BUTTOND_ARGS --short prog1 --action 'date >> /tmp/shortpress'"
BUTTOND_ARGS="$BUTTOND_ARGS --long prog1 --time 5000 --action 'date >> /tmp/longpress'"
[armadillo ~]# persist_file /etc/atmark/buttond.conf 
[armadillo ~]# rc-service buttond restart 
buttond          | * Stopping button watching daemon ...                                         [ ok ]
buttond          | * Starting button watching daemon ...                                         [ ok ]
[armadillo ~]# cat /tmp/shortpress 
Tue Mar 22 17:16:42 JST 2022
Tue Mar 22 17:16:43 JST 2022
[armadillo ~]# cat /tmp/longpress
Tue Mar 22 17:16:48 JST 2022

図6.190 buttond で SW1 を扱う

	buttond の設定ファイルを編集します。この例では、短押しの場合 /tmp/shotpress に、5 秒以上の長押しの場合 /tmp/longpress に日付を出力します。
	設定ファイルを保存します。
	`buttond` サービスを再起動させます。ここでは再起動後短押しを 2 回、長押しを 1 回行ったとします。
	押された回数を確認します。

6.17.2. USB キーボードの対応

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

図6.191 buttond で USB キーボードのイベントを確認する

	`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 --short LEFTCTRL --action 'podman_start button_pressed_container'"
[armadillo ~]# persist_file /etc/atmark/buttond.conf
[armadillo ~]# rc-service buttond restart

図6.192 buttond で USB キーボードを扱う

6.17.3. Armadillo 起動時にのみボタンに反応する方法

Armadillo 起動時にのみ、例として SW1 の長押しに反応する方法を紹介します。

/etc/local.d/boot_switch.start に稼働期間を指定した buttond を起動させる設定を記載します。

buttond が起動してから 10秒以内に SW1 を一秒以上長押しすると myapp のコンテナの親プロセスに USR1 信号を送ります（アプリケーション側で信号を受信して、デバッグモードなどに切り替える想定です）。 SW1 が Armadillo 起動前に押された場合は、buttond の起動一秒後に実行されます。

[armadillo ~]# vi /etc/local.d/boot_switch.start
#!/bin/sh

buttond /dev/input/by-path/platform-gpio-keys-event \ 
        --exit-timeout 10000 \ 
        --long PROG1 --time 1000 --exit-after \ 
                --action "podman exec myapp kill -USR1 1" & 
[armadillo ~]# chmod +x /etc/local.d/boot_switch.start
[armadillo ~]# persist_file /etc/local.d/boot_switch.start

図6.193 buttond で SW1 を Armadillo 起動時のみ受け付ける設定例

	SW1 の入力を `/dev/input/by-path/platform-gpio-keys-event` ファイルの `PROG1` として認識できます。
	buttond 起動後 10 秒経過すると終了します。
	SW1 を一度検知した後すぐに終了します。
	サービスとして動作させる必要がないため `&` を付けてバックグラウンド起動します。

6.18. 動作中の Armadillo の温度を測定する

この章では、Armadillo Base OS 搭載製品を組み込んだユーザー製品の熱設計時に役立つ温度プロファイラツールである「atmark-thermal-profiler」について紹介します。

6.18.1. 温度測定の重要性

Armadillo は製品ごとに動作温度範囲が設定されていますが、それらはあくまでも標準筐体に放熱材と共に取り付けて使用した場合の目安であり、実運用時には自作の筐体の使用や放熱の有無などで記載のスペック通りにならない場合があります。また、 Armadillo には CPU または SoC が特定の温度以上になると、自動的にシャットダウンするサーマルシャットダウン機能が搭載されています。そのため、現実的には Armadillo を組み込んだ製品を運用時と同等の環境で動作させつつ、実際に温度を計測して実運用時の CPU 及び SoC 温度がどの程度まで上がるか、サーマルシャットダウンは起こらないかを確かめる必要があります。

Armadillo Base OS 搭載製品では、動作中の Armadillo の各種温度等を取得しCSV形式で出力する atmark-thermal-profiler を利用することができますので、温度測定に役立てることができます。

6.18.2. atmark-thermal-profiler をインストールする

atmark-thermal-profiler は apk パッケージで公開されていますので、apk add コマンドでインストールすることが可能です。

[armadillo ~]# apk upgrade
[armadillo ~]# apk add atmark-thermal-profiler

図6.194 atmark-thermal-profiler をインストールする

atmark-thermal-profiler はデバッグ(開発)用途で温度情報を収集及び解析するツールです。 atmark-thermal-profiler は、他の apk パッケージと同様に persist_file -a コマンドで永続的にインストールしておくことが可能ですが、ログの保存のために Armadillo が起動している間 eMMC への書き込みを続けるので、 Armadillo を組み込んだ製品の運用時に動かしたままにしておくことは推奨しません。

atmark-thermal-profiler を永続的にインストールする場合は、運用時には必ず削除してください。

6.18.3. atmark-thermal-profiler を実行・停止する

図6.195「atmark-thermal-profiler を実行する」に示すコマンドを実行することで、 atmark-thermal-profiler が動作を開始します。

[armadillo ~]# rc-service atmark-thermal-profiler start

図6.195 atmark-thermal-profiler を実行する

図6.196「atmark-thermal-profiler を停止する」に示すコマンドを実行することで、 atmark-thermal-profiler が動作を停止します。

[armadillo ~]# rc-service atmark-thermal-profiler stop

図6.196 atmark-thermal-profiler を停止する

6.18.4. atmark-thermal-profiler が出力するログファイルを確認する

atmark-thermal-profiler は、インストール直後から自動的に温度やCPU負荷率、Load Averageなどの情報を30秒に1度の周期で集め、/var/log/thermal_profile.csvに追記していきます。

[armadillo ~]# head /var/log/thermal_profile.csv
DATE,ONESHOT,CPU_TMEP,SOC_TEMP,LOAD_AVE,CPU_1,CPU_2,CPU_3,CPU_4,CPU_5,USE_1,USE_2,USE_3,USE_4,USE_5
2022-11-30T11:11:05+09:00,0,54,57,0.24,/usr/sbin/rngd -b -p /run/rngd.pid -q -O jitter:buffer_size:4133 -O jitter:refill_thresh:4133 -O jitter:thread_count:1,/usr/sbin/chronyd -f /etc/chrony/chrony.conf,[kworker/1:3H-kb],podman network inspect podman,/usr/sbin/NetworkManager -n,22,2,2,0,0,
: (省略)

図6.197 ログファイルの内容例

thermal_profile.csv の1行目はヘッダ行です。各列についての説明を表6.20「thermal_profile.csvの各列の説明」に記載します。

表6.20 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使用率です。

6.18.5. 温度測定結果の分析

atmark-thermal-profiler を使用して得られたログファイルの内容を分析してみます。

6.18.5.1. サーマルシャットダウン温度の確認

予め、使用している Armadillo が何℃でサーマルシャットダウンするか確認しておきます。ここでは、 Armadillo Base OS を搭載している Armadillo-IoT ゲートウェイ G4 を例とします。他の製品では得られる結果が異なる場合があることに注意してください。

[armadillo ~]# cat /sys/class/thermal/thermal_zone0/trip_point_1_temp
105000 
[armadillo ~]# cat /sys/class/thermal/thermal_zone1/trip_point_1_temp
105000

図6.198 サーマルシャットダウン温度の確認(Armadillo-IoT ゲートウェイ G4を例に)

	CPU のサーマルシャットダウン温度です。ミリ℃で表記されているので、105℃でサーマルシャットダウンすることがわかります。
	SoC のサーマルシャットダウン温度です。ミリ℃で表記されているので、105℃でサーマルシャットダウンすることがわかります。

6.18.5.2. 温度測定結果のグラフ化

atmark-thermal-profiler が出力するログ(thermal_profile.csv)はCSVファイルなので、各種表計算ソフトでインポートしてグラフ化することが可能です。これにより Armadillo 動作中の温度の変化が可視化され、得られる情報が見やすくなります。

図6.199「Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ」は Armadillo-IoT ゲートウェイ G4上で一定期間 atmark-thermal-profiler を実行して取得した thermal_profile.csv を Google スプレッドシートでグラフ化したものです。例のために、途中で stress-ng コマンドを実行して CPU に負荷を与えた後、 stress-ng コマンドを停止して CPU と SoC の温度が下がるのを待った際のデータです。

images/abos-images/thermal_profiler_graph.png

図6.199 Armadillo-IoT ゲートウェイ G4で取得した温度のグラフ

グラフの縦軸は温度(℃)で、横軸は時間です。青い線は CPU の温度、赤い線は SoC の温度を表しています。このグラフと、「サーマルシャットダウン温度の確認」で得たサーマルシャットダウン温度を見比べると、 CPU に負荷をかけた際であっても SoC の温度は 60℃ 前後ほどまでしか上がらず、この条件で動く Armadillo が温度的にどれほど余裕を持っているかをひと目で確認できます。

6.18.5.3. CPU使用率の確認

atmark-thermal-profiler は、時間毎の温度だけでなく CPU 使用率と CPU 使用率の高いプロセスについても取得して記録します。 CPU 使用率については thermal_profile.csv の CPU_1〜CPU_5 列と、 USE_1〜USE_5 列を参照してください。各列について詳しくは表6.20「thermal_profile.csvの各列の説明」にまとまっています。

一般的に CPU 使用率が高くなると、 CPU 周辺の温度も高くなります。そのため、測定した温度が高い場合は、 CPU 使用率の高いプロセスに注目して、 CPU を無駄に使用している意図しない処理が行なわれていないかなどを確認することをおすすめします。

6.18.6. Armadillo Twin から Armadillo の温度を確認する

atmark-thermal-profiler の他に、Armadillo Twin からも温度や CPU 負荷率等の情報を確認することができます。詳細は Armadillo Twin ユーザーマニュアル「デバイス監視アラートを管理する」をご確認ください。

6.18.7. 温度センサーの仕様

Armadillo-X2の温度センサーは、i.MX 8M PlusのTMU(Thermal Monitoring Unit)を利用しています。CPU(Arm Cortex-A53)周辺温度と、SoC(ANAMIX内部)温度を測定することができます。

起動直後の設定では、ARMまたはSoCの測定温度が 105°C以上になった場合、Linuxカーネルはシステムを停止します。

機能

測定温度範囲: -40〜+105°C

sysfs thermalクラスディレクトリ

/sys/class/thermal/thermal_zone0 (CPU)
/sys/class/thermal/thermal_zone1 (SoC)

6.19. Armadillo Base OS をアップデートする

Armadillo Base OS は SWUpdate によってアップデートすることができます。

アップデートする際には、rootfs ファイルシステムにインストールされたファイルをすべて消して、アップデートの中身と /etc/swupdate_preserve_files に記載されているファイルで新しい rootfs を作ります。「swupdate_preserve_files について」を参照してください。

アップデートでファイルを削除してしまった場合に abos-ctrl mount-old で前のシステムを read-only でマウントして、削除されたファイルをコピーすることもできます。

6.20. ロールバック状態を確認する

Armadillo Base OS のルートファイルシステムが破損し起動できなくなった場合、自動的に以前のバージョンで再起動します。

abos-ctrl status コマンドでロールバックされてるかどうかを確認できます。

[armadillo ~]# abos-ctrl status
Currently booted on /dev/mmcblk2p1
Last update on Fri Jun  7 16:03:37 JST 2024, updated: 
  boot: 2020.4-at23-00001-g01508f65b8 -> 2020.4-at23
  base_os: 3.19.1-at.3.20240523.pc.gtr -> 3.19.1-at.4
rollback-status: OK: available, no auto-rollback

図6.200 abos-ctrl status の例

	最新のアップデートの日付と内容が出力されています。
	表6.21「rollback-status の出力と意味」表6.22「rollback-status 追加情報の出力と意味」に示す状態と追加情報が出力されています。

表6.21 rollback-status の出力と意味

出力	説明
`OK`	ロールバックされていません。
`rolled back`	ロールバックされています。

表6.22 rollback-status 追加情報の出力と意味

出力	説明
`no fallback (fresh install)`	初期化状態。
`no fallback`	何かの理由でB面が起動できない状態になっています（アップデート失敗後等）。
`auto-rollback enabled (post-update)`	アップデート直後でまだ再起動していない状態です。再起動して失敗した場合にロールバックが発生します。
`auto-rollback enabled (cloned)`	`abos-ctrl rollback-clone` コマンドを実行した後の状態です。同じくロールバック可能です。
`available, no auto-rollback`	アップデートの後に正常に起動できたので、自動ロールバックが無効になっていますが `abos-ctrl rollback --allow-downgrade` コマンドで手動ロールバック可能です。


	Armadillo Base OS 3.19.1-at.4 以下のバージョンでは「アップデート直後」の概念がなかったため、ステータスは「no fallback」（B面がない状態）、「optimal」（ロールバック可能）、と「rolled back」の3択だけでした。

必要な場合（例えば、自分のアプリケーションがアップデート直後に問題があった場合）、 abos-ctrl rollback で手動のロールバックも可能です。ロールバックにエラーがなければ、再起動してロールバックを完了します。

なお、/var/at-log/atlog に切り替えの際に必ずログを書きますので、調査の時に使ってください。以下の例では、Armadillo Base OS を更新した後に起動できないカーネルをインストールして、起動できなかったためにロールバックされました。

[armadillo ~]# cat /var/at-log/atlog
Jun  7 16:03:37 armadillo NOTICE swupdate: Installed update to /dev/mmcblk2p2: \
boot: 2020.4-at22 -> 2020.4-at23, base_os: 3.19.1-at.3 -> 3.19.1-at.4
Jun  7 16:11:39 armadillo NOTICE swupdate: Installed update to /dev/mmcblk2p1: \
extra_os.kernel: unset -> 5.10.218-1
Jun  7 16:12:18 armadillo WARNING uboot: reset by wdt
Jun  7 16:12:42 armadillo WARNING uboot: reset by wdt
Jun  7 16:13:06 armadillo WARNING uboot: reset by wdt
Jun  7 16:13:09 armadillo WARNING uboot: Counted 3 consecutive unfinished boots
Jun  7 16:13:09 armadillo WARNING uboot: Rolling back to mmcblk2p2

図6.201 /var/at-log/atlog の内容の例

6.21. Armadillo 起動時にコンテナの外でスクリプトを実行する

起動時に何かスクリプトを走らせるためにはコンテナとして実行することを推奨します。「コンテナ起動設定ファイルを作成する」を参照してください。

コンテナで実行不可能な場合に、「local」サービスを使うことができます: /etc/local.d ディレクトリに .start ファイルを置いておくと起動時に実行されて、 .stop ファイルは終了時に実行されます。

[armadillo ~]# vi /etc/local.d/date_test.start 
#!/bin/sh

date > /tmp/boottest
[armadillo ~]# chmod +x /etc/local.d/date_test.start 
[armadillo ~]# persist_file /etc/local.d/date_test.start 
[armadillo ~]# reboot
: (省略)
[armadillo ~]# cat /tmp/boottest 
Tue Mar 22 16:36:12 JST 2022

図6.202 local サービスの実行例

	スクリプトを作ります。
	スクリプトを実行可能にします。
	スクリプトを保存して、再起動します。
	実行されたことを確認します。

6.22. u-boot の環境変数の設定

u-boot の環境変数を変更するには /boot/uboot_env.d/ ディレクトリに環境変数が書かれた設定ファイルを配置します。

ファイルの構文は fw_setenv が扱うことができるもので、以下のとおりです：

# で始まる行はコメントと扱われる為、無視されます。また、環境変数への代入を示す = がない場合も無視されます。
[変数]=[値] で変数を設定します。スペースや引用符を含め他の文字は有効ですので、変数の名前と値に不要な文字を入れないように注意してください。
[変数]= で変数を消します。値がない場合に変数が消去されます。

このファイルによるアップデート内容は swupdate でアップデートする際に適用されます。

実行中のシステムに影響がありませんので、設定ファイルを swupdate で転送しない場合はファイル永続化後に fw_setenv -s /boot/uboot_env.d/[ファイル名] で変数を書き込んでください。

swupdate でファイルを転送した場合には、変数はすぐに利用されます。

[armadillo ~]# vi /boot/uboot_env.d/no_prompt 
# bootdelay を -2 に設定することで u-boot のプロンプトを無効化します
bootdelay=-2
[armadillo ~]# persist_file -v /boot/uboot_env.d/no_prompt 
'/boot/uboot_env.d/no_prompt' -> '/mnt/boot/uboot_env.d/no_prompt'
[armadillo ~]# fw_setenv -s /boot/uboot_env.d/no_prompt 
Environment OK, copy 0
[armadillo ~]# fw_printenv | grep bootdelay 
bootdelay=-2

図6.203 uboot_env.d のコンフィグファイルの例

	コンフィグファイルを生成します。
	ファイルを永続化します。
	変数を書き込みます。
	書き込んだ変数を確認します。

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の環境変数を以下に示します。

表6.23 u-bootの主要な環境変数

環境変数	説明	デフォルト値
console	コンソールのデバイスノードと、UARTのボーレート等を指定します。	ttymxc1,115200
bootcount	起動回数を示します。初回起動時に1となり、起動に失敗する度にインクリメントされます。ユーザーランドのreset_bootcountサービスが起動されると、この値はクリアされます。この値が"bootlimit"を越えた場合はロールバックします。ロールバックの詳細については、「ロールバック(リカバリー)」を参照してください。	1
bootlimit	"bootcount"のロールバックを行うしきい値を指定します。	3
upgrade_available	1以上の場合は bootcount を管理してロールバック可能になります。0 か空の場合はロールバックできません。値を abos-ctrl status で確認できます。	状況による
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デバイスの対応は次の通りです。 1: microSD/microSDHC/microSDXC カード 2: eMMC "mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。	2
mmcpart	"image"や"fdt_file"で指定されたファイルが配置してある、"mmcdev"で指定されたmmcデバイスのパーティション番号を指定します。"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。	1
mmcroot	ルートファイルシステムが配置されているデバイスノードと、マウントオプションを指定します。"mmcautodetect"にyesが指定されている場合は、u-bootの起動時に上書きされます。overlayfsが正しく機能しなくなる場合があるので、roの指定は変更しないでください。	/dev/mmcblk2p1 rootwait ro
optargs	Linuxカーネル起動時パラメータを指定します。"quiet"を削除すると、コンソールに起動ログが出力されるようになりますが、起動時間が長くなります。 nokaslrを削除すると、KASLR(Kernel Adress Space Layout Randomization)が有効となり、Linuxカーネルの仮想アドレス空間がランダム化されます。	quiet nokaslr
loadaddr	LinuxカーネルがRAMにロードされる物理アドレスを指定します。	0x40480000
fdt_addr	DTBがRAMにロードされる物理アドレスを指定します。	0x45000000
overlay_addr	DT overlayのワーク領域として利用されるRAMの物理アドレスを指定します。	0x45020000

6.22.1. u-boot の環境変数の変更を制限する

u-boot のソースに含まれる imx-boot-[VERSION]/uboot-imx/configs/x2_defconfig に CONFIG_ENV_WRITEABLE_LIST=y を追加すると、変更可能と明示したもの以外の環境変数を変更不可にすることができます。変更可能とする環境変数のリストは imx-boot-[VERSION]/uboot-imx/include/configs/armadillo_x2.h ファイルの CFG_ENV_FLAGS_LIST_STATIC で設定します。

デフォルトのコンフィグでは、以下の環境変数が変更可能です：

upgrade_available と bootcount: ロールバック機能に必要な変数です。ロールバック機能を無効にする場合は必ず upgrade_available のデフォルト値も空にしてください。
ethaddr, eth1addr, ethact と ethprime: ネットワークコマンド関連の変数です。デフォルトのブートコマンドはネットワークを使用してませんので動作に影響ありません。

u-boot のソースの取得方法、ビルド方法およびインストール方法については「ブートローダーをビルドする」を参照してください。ビルドしたものをインストールすると CFG_ENV_FLAGS_LIST_STATIC で設定した環境変数以外は変更できなくなります。

6.23. SDブートの活用

本章では、microSDカードから直接起動(以降「SDブート」と表記します)する手順を示します。 SDブートを活用すると、microSDカードを取り替えることでシステムイメージを変更することができます。本章に示す手順を実行するためには、容量が8Gbyte以上のmicroSDカードを必要とします。


	SDブートを行った場合、ブートローダーの設定は microSDカードに保存されます。

6.23.1. ブートディスクの作成

ブートディスクイメージをビルドします
「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 カードがマウントされている場合、アンマウントします。

[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

図6.204 自動マウントされたmicroSDカードのアンマウント

ブートディスクイメージの書き込み
```
[PC ~]$ sudo dd if=~/build-rootfs-[VERSION]/baseos-x2-[VERSION].img \
                of=/dev/sdb bs=1M oflag=direct status=progress
```
microSDカードの性能にもよりますが、書き込みには5分程度かかります。

microSDカードのパーティション構成は次のようになっています。

表6.24 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/mmcblk1
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        15319006   6.5 GiB     8300  app

6.23.2. SDブートの実行

「ブートディスクの作成」で作成したブートディスクから起動する方法を説明します。

Armadillo-X2に電源を投入する前に、ブートディスクをCON1(SD インターフェース)に挿入します。また、JP1ジャンパーをショート(SDブートに設定)します。

電源を投入します。

U-Boot SPL 2020.04-at7 (May 21 2022 - 11:21:55 +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):lf-5.10.y-1.0.0-0-gba76d337e956
NOTICE:  BL31: Built : 11:08:22, Apr  6 2022


U-Boot 2020.04-at7 (May 21 2022 - 11:21:55 +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-at7

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
Hit any key to stop autoboot:  0
u-boot=>

ブートディスク上のLinuxカーネルを起動します。
```
u-boot=> boot
```

6.24. Armadilloのソフトウェアをビルドする

ここでは、Armadillo-X2で使用するソフトウェアのビルド方法を説明します。

6.24.1. ブートローダーをビルドする

ここでは、Armadillo-X2向けのブートローダーイメージをビルドする方法を説明します。

ブートローダーのビルドに必要なパッケージのインストール

次のコマンドを実行します。

[ATDE ~]$ 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

ソースコードの取得
Armadillo-X2 ブートローダーから「ブートローダーソース」ファイル (imx-boot-[VERSION].tar.gz) を次のようにダウンロードします。
```
[ATDE ~]$ wget https://download.atmark-techno.com/armadillo-x2/bootloader/imx-boot-[VERSION].tar.gz
[ATDE ~]$ tar xf imx-boot-[VERSION].tar.gz
[ATDE ~]$ cd imx-boot-[VERSION]
```

ビルド

次のコマンドを実行します。

[ATDE ~/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 への同意を求められます。内容を確認の上、同意してご利用ください。^[15]

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)

インストール
ビルドしたブートローダーは、以下に示すどちらかの方法でインストールしてください。
- swupdate でインストールする
  mkswu の初期化を行った後に提供されているスクリプトを使ってSWUイメージを作成してください。
```
[ATDE ~/imx-boot-[VERSION]]$ echo 'swdesc_boot imx-boot_armadillo_x2' > boot.desc
[ATDE ~/imx-boot-[VERSION]]$ mkswu boot.desc
boot.swu を作成しました。
```
  作成された boot.swu のインストールについては「SWU イメージのインストール」を参照ください。
- 「ブートディスクの作成」でインストールする
  手順を参考にして、ビルドされた imx-boot_armadillo_x2 を使ってください。

6.24.2. Linux カーネルをビルドする

ここでは、Armadillo-X2向けのLinuxカーネルイメージをビルドする方法を説明します。

Armadillo-X2では、基本的にはLinuxカーネルイメージをビルドする必要はありません。「Alpine Linux ルートファイルシステムをビルドする」の手順を実施することで、標準のLinuxカーネルイメージがルートファイルシステムに組み込まれます。

標準のLinuxカーネルイメージは、アットマークテクノが提供する linux-at というAlpine Linux用のパッケージに含まれています。

カスタマイズしたLinuxカーネルイメージを利用する場合は、以下に示す手順を参照してください。

Linuxカーネルのビルドに必要なパッケージのインストール

次のコマンドを実行します。

[ATDE ~]$ sudo apt update
[ATDE ~]$ sudo apt install crossbuild-essential-arm64 bison flex python3-pycryptodome python3-pyelftools zlib1g-dev libssl-dev bc firmware-misc-nonfree wireless-regdb atmark-firmware

ソースコードの取得
Armadillo-X2 Linuxカーネルから「Linuxカーネル」ファイル (linux-at-x2-[VERSION].tar) をダウンロードして、次のコマンドを実行します。
```
[ATDE ~]$ tar xf linux-at-x2-[VERSION].tar
[ATDE ~]$ tar xf linux-at-x2-[VERSION]/linux-[VERSION].tar.gz
[ATDE ~]$ cd linux-[VERSION]
```
デフォルトコンフィギュレーションの適用
次のコマンドを実行します。
```
[ATDE ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- x2_defconfig
```

カーネルコンフィギュレーションの変更

次のコマンドを実行します。カーネルコンフィギュレーションの変更を行わない場合はこの手順は不要です。

[ATDE ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

コマンドを実行するとカーネルコンフィギュレーション設定画面が表示されます。カーネルコンフィギュレーションを変更後、"Exit"を選択して「Do you wish to save your new kernel configuration? (Press <ESC><ESC> to continue kernel configuration.)」で"Yes"とし、カーネルコンフィギュレーションを確定します。

 .config - Linux/arm64 5.10.86 Kernel Configuration
 ─────────────────────────────────────────────
  ┌────────── Linux/arm64 5.10.86 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  --->                                                  │ │
  │ │     [*] Support DMA zone                                                     │ │
  │ │     [*] Support DMA32 zone                                                   │ │
  │ │         Platform selection  --->                                             │ │
  │ │         Kernel Features  --->                                                │ │
  │ │         Boot options  --->                                                   │ │
  │ │         Power management options  --->                                       │ │
  │ │         CPU Power Management  --->                                           │ │
  │ │         Firmware Drivers  --->                                               │ │
  │ │     [ ] Virtualization  ----                                                 │ │
  │ │     -*- ARM64 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=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j5

インストール

ビルドしたカーネルは、以下に示すどちらかの方法でインストールしてください。

swupdate でインストールする

mkswu の初期化を行った後に提供されているスクリプトを使ってSWUイメージを作成してください。

[ATDE ~/linux-[VERSION]]$ /usr/share/mkswu/examples/kernel_update_plain.install.sh ~/mkswu/kernel.desc
Installing kernel in /home/atmark/mkswu/kernel ...
'arch/arm64/boot/Image' -> '/home/atmark/mkswu/kernel/Image'
'arch/arm64/boot/dts/freescale/armadillo_iotg_g4.dtb' -> '/home/atmark/mkswu/kernel/armadillo_iotg_g4.dtb'
: (省略)
  INSTALL arch/arm64/crypto/poly1305-neon.ko
  INSTALL drivers/block/loop.ko
: (省略)
  DEPMOD  [VERSION]
Updated /home/atmark/mkswu/kernel.desc version from [PREV_VERSION] to [VERSION]
Done installing kernel, run `mkswu "/home/atmark/mkswu/kernel.desc"` next.
[ATDE ~/linux-[VERSION]]$ mkswu ~/mkswu/kernel.desc
/home/atmark/mkswu/kernel.swu を作成しました

図6.205 Linux カーネルを SWU でインストールする方法

作成された kernel.swu のインストールについては「SWU イメージのインストール」を参照ください。

この kernel.swu をインストールする際は /etc/swupdate_preserve_files の更新例の様に /boot と /lib/modules を維持するように追加します。カーネルをインストールした後に Armadillo Base OS を更新しても、この kernel.swu のカーネルが維持されます。

標準のカーネルに戻りたいか、以下の図6.206「Linux カーネルを build_rootfs でインストールする方法」で Armadillo Base OS の更新のカーネルを使用したい場合は /etc/swupdate_preserve_files から /boot と /lib/modules の行を削除してください。

build_rootfs で新しいルートファイルシステムをビルドする場合は build_rootfs を展開した後に以下のコマンドでインストールしてください。

[ATDE ~/linux-[VERSION]]$ BROOTFS=$HOME/build-rootfs-[VERSION] 
[ATDE ~/linux-[VERSION]]$ sed -i -e '/^linux-at/d' "$BROOTFS/ax2/packages" 
[ATDE ~/linux-[VERSION]]$ cp -v arch/arm64/boot/Image "$BROOTFS/ax2/resources/boot/"
'arch/arm64/boot/Image' -> '/home/atmark/build-rootfs-v3.17-at.3/ax2/resources/boot/Image'
[ATDE ~/linux-[VERSION]]$ cp -v arch/arm64/boot/dts/freescale/armadillo_*.{dtb,dtbo} "$BROOTFS/ax2/resources/boot/"
'arch/arm64/boot/dts/freescale/armadillo_iotg_g4.dtb' -> '/home/atmark/build-rootfs-v3.17-at.3/ax2/resources/boot/armadillo_iotg_g4.dtb'
'arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dtbo' -> '/home/atmark/build-rootfs-v3.17-at.3/ax2/resources/boot/armadillo_iotg_g4-at-dtweb.dtbo'
: (省略)
[ATDE ~/linux-[VERSION]]$ rm -rfv "$BROOTFS/ax2/resources/lib/modules" 
[ATDE ~/linux-[VERSION]]$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_PATH="$BROOTFS/ax2/resources" -j5 modules_install
  INSTALL arch/arm64/crypto/poly1305-neon.ko
  INSTALL drivers/block/loop.ko
: (省略)
  DEPMOD  [VERSION]

図6.206 Linux カーネルを build_rootfs でインストールする方法

	`build_rootfs` のディレクトリ名を設定します。これによって、長いディレクトリ名を何度も入力する必要が無くなります。
	アットマークテクノが提供するカーネルをインストールしない様に、 `linux-at-x2@atmark` と記載された行を削除します。
	別のカーネルをすでにインストールしている場合は、新しいモジュールをインストールする前に古いモジュールを削除する必要があります。

6.24.3. Alpine Linux ルートファイルシステムをビルドする

ここでは、alpine/build-rootfsを使って、 Alpine Linux ルートファイルシステムを構築する方法を説明します。

alpine/build-rootfsはATDEで動作しているLinux上でArmadillo-X2用の aarch64アーキテクチャに対応したAlpine Linux ルートファイルシステムを構築することができるツールです。

ルートファイルシステムのビルドに必要な Podman のインストール
次のコマンドを実行します。
```
[ATDE ~]$ sudo apt install podman btrfs-progs xxhash
```
alpine/build-rootfsの入手
Armadillo-X2 開発用ツールから「Alpine Linuxルートファイルシステムビルドツール」ファイル (build-rootfs-[VERSION].tar.gz) を次のようにダウンロードします。
```
[ATDE ~/]$ wget https://download.atmark-techno.com/armadillo-x2/tool/build-rootfs-latest.tar.gz
[ATDE ~/]$ tar xf build-rootfs-latest.tar.gz
[ATDE ~/]$ cd build-rootfs-[VERSION]
```

Alpine Linux ルートファイルシステムの変更

ax2ディレクトリ以下のファイルを変更することで、ルートファイルシステムをカスタマイズすることができます。

commonとax2 ディレクトリ直下にあるfixupやpackagesなどの同名ファイルは、それぞれのファイルを連結して利用されます。パッケージの削除などを行う場合は、commonディレクトリ以下のファイルも確認してください。

commonとax2内のサブディレクトリにある同名ファイルは、ax2のファイルが利用されます。

build-rootfsに含まれるファイルの説明は次の通りです。

表6.25 build-rootfsのファイル説明

ファイル	説明
ax2/resources/*	配置したファイルやディレクトリは、そのままルートファイルシステム直下にコピーされます。ファイルを追加する場合は、このディレクトリに入れてください。
ax2/packages	このファイルに記載されているパッケージはルートファイルシステムにインストールされます。パッケージを追加する場合はこのファイルに追加してください。
ax2/fixup	このファイルに記載されているコマンドはパッケージのインストールが完了した後に実行されます。
ax2/image_firstboot/*	配置したファイルやディレクトリは、「ブートディスクの作成」や「初期化インストールディスクの作成」の手順のようにブートディスクイメージを作成する際、そのままルートファイルシステム直下にコピーされます。
ax2/image_installer/*	配置したファイルやディレクトリは、「初期化インストールディスクの作成」の手順のようにインストールディスクイメージを作成する際、そのままインストーラーにコピーされます。ルートファイルシステムに影響はありません。
ax2/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]]$ ./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.


	リリース時にバージョンに日付を含めたくないときは --release を引数に追加してください。


	インターネットに接続できない環境か、テスト済みのソフトウェアのみをインストールしたい場合は Armadillo-X2 開発用ツールからキャッシュアーカイブもダウンロードして、 `build_rootfs.sh --cache baseos-x2-[VERSION].cache.tar` で使ってください。

任意のパス、ファイル名で結果を出力することもできます。

[ATDE ~/build-rootfs-[VERSION]]$ ./build_rootfs.sh ~/alpine.tar.zst
:
: (略)
:
[ATDE ~/build-rootfs-[VERSION]]$ ls ~/alpine.tar.zst
~/alpine.tar.zst

「Alpine Linux ルートファイルシステムビルドツール」のバージョンが3.18-at.7以降を使用している場合は、ビルドが終わると SBOM も [output].spdx.json として出力されます。ライセンス情報等を記載するためのコンフィグファイルはデフォルトは baseos_sbom.yaml となっています。コンフィグファイルを変更する場合は --sbom-config <config> に引数を入れてください。 SBOM が不要な場合は --nosbom を引数に追加してください。

SBOM のライセンス情報やコンフィグファイルの設定方法については「ビルドしたルートファイルシステムの SBOM を作成する」をご覧ください。

インストール
ビルドしたルートファイルシステムは、以下に示すどちらかの方法でインストールしてください。
- swupdate でインストールする
  mkswu の初期化を行った後に提供されているスクリプトを使ってSWUイメージを作成してください。
```
[ATDE ~/build-rootfs-[VERSION]]$ vi OS_update.desc
swdesc_tar --version base_os [VERSION] \
    --preserve-attributes baseos-x2-[VERSION].tar.zst
[ATDE ~/build-rootfs-[VERSION]]$ mkswu OS_update.desc
OS_update.swu を作成しました。
```
  作成された OS_update.swu のインストールについては「SWU イメージのインストール」を参照ください。
- 「ブートディスクの作成」でインストールする
  手順を実行すると、ビルドされた baseos-x2-[VERSION].tar.zst が自動的に利用されます。

6.25. SBOM の提供

アットマークテクノでは ABOS 及び ABOS 上で動作する標準ソフトウェアの SBOM を提供しています。また、開発したソフトウェアの SWU イメージを作成するタイミングで SBOM を生成することができます。 SBOM 生成手順は「ビルドしたルートファイルシステムの SBOM を作成する」もしくは「SWU イメージと同時に SBOM を作成する」を参照ください。

6.25.1. SBOM について

SBOM（Software Bill of Materials: ソフトウェア部品表) は、ソフトウェアを構成するコンポーネントやソフトウェア間の依存関係、ライセンス情報を記したリストです。経済産業省は、ソフトウェアサプライチェーンが複雑化する中で、急激に脅威が増しているソフトウェアのセキュリティを確保するための管理手法の一つとして SBOM の導入を推進しています。 SBOM の導入はソフトウェアのトレーサビリティを確保し、脆弱性残留リスクの低減、脆弱性対応期間の低減に繋がります。アットマークテクノが提供する SBOM は ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。

SPDX2.2 の詳細については以下のドキュメントをご参照ください。

The Software Package Data Exchange® (SPDX®) Specification Version 2.2.2

アットマークテクノの提供する mkswu コマンドでは SWU を作成するタイミングで SBOM を生成することができます。

6.25.2. SBOM の利点

SBOM の利点はソフトウェアのサプライチェーン攻撃への対応です。ソフトウェアのセキュリティ対策は日々見直されており、トレーサビリティが明らかになることで、ソフトウェアに含まれる脆弱性に速やかに対処することが可能になります。 SBOM はトレーサビリティを辿るのに優れており、加えて、脆弱性スキャンツールを用いることで、表面化していない脆弱性の発見に利用できます。脆弱性スキャンツールには例として、Google が提供する osv-scanner が挙げられます。脆弱性に関する詳細なリンクや、脆弱性の深刻度を示す CVSS(Common Vulnerability Scoring System) を出力します。アットマークテクノが提供する SBOM は osv-scanner のスキャンに対応しています。

osv-scanner の詳細については以下をご参照ください。

OSV-Scanner

アットマークテクノが提供している ABOS は GPLv3（GNU General Public License 第3版）のソフトウェアを含まない構成で提供しています。 OSS（オープンソース・ソフトウェア）利用者に広く普及しているGPLv3は、インストール用情報の開示義務、関連する特許ライセンスの許諾について定める条項が含まれ、組み込み機器に適用する際の妨げになる場合があります。 SBOM にはパッケージのライセンス情報が含まれているため、GPLv3 ライセンスが含まれているかどうかの検出を可能にします。

6.25.3. ビルドしたルートファイルシステムの SBOM を作成する

「Alpine Linux ルートファイルシステムをビルドする」を実行すると、OS_update.swu と同じ場所に SBOM を作成します。 SBOM を作成するには、作成する対象のファイルとライセンス情報等を記載するためのコンフィグファイルが必要となります。また、baseos-x2-[VERSION].tar.zst から、アーカイブに含まれるパッケージ情報やファイル情報を SBOM に記載します。

ライセンス情報等を記載するためのコンフィグファイルの例は以下のコマンドで確認することができます。各項目に関する説明はコメントに記載しておりますので、必要に応じて値を変更してください。各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。

[ATDE ~/build-rootfs-[VERSION]]$ cat submodules/make-sbom/config.yaml

作成したコンフィグファイルと、baseos-x2-[VERSION].tar.zst から OS_update.swu の SBOM を作成します。

[ATDE ~/build-rootfs-[VERSION]]$ ./build_sbom.sh -i OS_update.swu -c <コンフィグファイル> -f baseos-x2-[VERSION].tar.zst
INFO:root:created OS_update.swu.spdx.json

作成される SBOM は OS_update.swu.spdx.json になります。 json 形式で ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。

アットマークテクノが提供しているソフトウェアの SBOM はソフトウェアダウンロードの各ソフトウェアダウンロードページからダウンロードすることができます。

6.25.4. SWU イメージと同時に SBOM を作成する

「SWUイメージの作成」の実行時に SBOM を作成する方法について説明します。 SWU イメージは desc ファイルから作成されます。この desc ファイルに SBOM 作成に必要な情報についても記載します。

6.25.4.1. コンフィグファイルを作成する

SBOM を作成するには、作成する対象のファイルとライセンス情報等を記載するためのコンフィグファイルが必要となります。コンフィグファイルについて指定がない場合はデフォルトのコンフィグファイルで SBOM を作成します。デフォルトのコンフィグファイルは /usr/share/make-sbom/config/config.yaml にあります。このファイルは SBOM 作成ツールによって配置されます。コンフィグファイルを編集するために、例としてカレントディレクトリにコピーします。リリース時には正しいコンフィグファイルの内容を記載してください。

[ATDE ~]$ cp /usr/share/make-sbom/config/config.yaml .
[ATDE ~]$ vi config.yaml

「desc ファイルを編集する」で desc ファイルに編集したコンフィグファイルのパスを指定します。

6.25.4.2. desc ファイルを編集する

SBOM 作成のために、desc ファイルに記載する項目を以下に示します。

表6.26 descファイルの設定項目

項目	設定値	説明
swdesc_option BUILD_SBOM=<mode>	auto(デフォルト): SBOM 作成ツールがある場合作成する	SBOM を作成するかどうか。記載がない場合は auto が選択される
	yes: SBOMを作成する。SBOM 作成ツールがない場合はエラーする
	no: SBOM を作成しない
swdesc_option sbom_config_yaml=<path>	ファイルパス	コンフィグファイルのパスを指定する。記載がない場合はデフォルトのコンフィグファイルを使用する
swdesc_sbom_source_file <path>	ファイルパス	SBOM に含めるファイルを指定する。記載がない場合は SBOM に含まれない

以下に desc ファイルの記載例について示します。

swdesc_option component=make_sbom
swdesc_option version=1
swdesc_option BUILD_SBOM=yes
swdesc_option sbom_config_yaml=config.yaml

swdesc_sbom_source_file manifest.json

図6.207 descファイルの追加例

	SBOM を作成するように設定します。例として必ず作成するように "yes" を指定します。
	コンフィグファイルのパスを設定します。例としてカレントディレクトリにある config.yaml を指定します。
	SBOM に含めたいファイルがある場合に指定します。例として manifest.json を指定します。

desc ファイルの作成が出来たら「SWUイメージの作成」を実行すると、SWU イメージと同じ場所に SBOM が作成されます。 desc ファイルの内容によっては SBOM 作成に数分かかります。作成される SBOM のファイル名は <SWU イメージ名>.spdx.json になります。 json 形式で ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。

6.26. eMMC のデータリテンション

eMMC は主に NAND Flash メモリから構成されるデバイスです。NAND Flash メモリには書き込みしてから1年から3年程度の長期間データが読み出されないと電荷が抜けてしまう可能性があります。その際、電荷が抜けて正しくデータが読めない場合は、eMMC 内部で ECC (Error Correcting Code) を利用してデータを訂正します。しかし、訂正ができないほどにデータが化けてしまう場合もあります。そのため、一度書いてから長期間利用しない、高温の環境で利用するなどのケースでは、データ保持期間内に電荷の補充が必要になります。電荷の補充にはデータの読み出し処理を実行し、このデータの読み出し処理をデータリテンションと呼びます。

Armadillo-X2 に搭載のeMMCには長期間データが読み出されない状態であっても、データリテンションを自動的に行う機能を搭載しています。


	詳しい仕様については「実装仕様に関する技術情報」を参照してください。

6.26.1. データリテンションの設定

データリテンションは /etc/conf.d/micron-emmc-reten というファイルに書かれた設定、use_system_time によって以下の 2 通りの挙動を示します。

表6.27 データリテンションの挙動

/etc/conf.d/micron-emmc-reten	initiating condition
use_system_time=yes	Linux 起動した時に前回のリテンションから 1 日以上経過していたら開始する
use_system_time=no (default)	Linux 起動した時に毎回開始する

これで設定は完了しました。

以下は挙動ごとのシステム概略図です。

図6.208 データリテンション開始トリガーの方式

use_system_time を有効にした場合のデータリテンションの動作例を以下に示します。

images/common-images/emmc-sref_counter.png

図6.209 データリテンションの開始トリガーの動作例

6.26.2. より詳しくデータリテンションの統計情報を確認するには

Micron Technology が提供する emmcparm というツールを使うことで、データリテンションの統計情報を確認することができます。統計情報として eMMC 内部に保存されているのは実行回数、最終実行完了時のカウンター値、現在のデータリテンション処理の進捗があります。次の手順で、emmcparmを使ってeMMCの情報を確認することができます。このツールではデータリテンション処理のことを「セルフリフレッシュ」と呼びます。

emmcparm をダウンロードする
以下の検索結果から最新の emmcparm をダウンロードする。ユーザー登録が必要になります。
emmcparm https://jp.micron.com/search-results?searchRequest=%7B%22term%22%3A%22emmcparm%20%22%7D
マニュアル作成時点では 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 ということは実行中ではない
	最後に行ったセルフリフレッシュのカウンター値
	セルフリフレッシュを行った回数

6.26.3. 実装仕様に関する技術情報

ここではデータリテンションを自動的におこなう機能の仕様について詳細に説明します。 Armadillo で採用しているeMMCには、データリテンションを自動的に実行することができる「セルフリフレッシュ」と呼ばれる機能が搭載されます。実行トリガーは 2 種類のうちどちらかを選択できます。OTP のため一度設定すると変更できません。この設定は出荷時に「eMMC 内部レジスタ値とコマンドに入力された値を比較して 1 日以上経過していると実行する」を設定しています。

リセット後に毎回実行する
eMMC 内部レジスタ値とコマンドに入力された値を比較して 1 日以上経過していると実行する

2 の設定の場合、セルリフレッシュ機能が実行されるまでの流れは以下のとおりです。

ホストによって eMMC がハードウェアもしくはソフトウェアリセットされる
一定時間 (delay 1) 以内に、ホストから SET_TIME (CMD49)と呼ばれるコマンドが eMMC に発行される
eMMC コントローラは、バスの稼動状態を監視する
eMMC コントローラは、アイドルになってから一定時間 (delay 2) 経過した後にセルフリフレッシュを実行する
- ECC エラーなどのエラーがしきい値 (2) を越えたセルに対してのみセルフリフレッシュを実行する

Armadillo でのセルフリフレッシュ機能搭載 eMMC への設定は以下のとおりです。

表6.28 Armadillo のデータリテンションの設定

setting	value	description
RTC	ON	eMMC 内部レジスタの値と SET_TIME の値を比較してセルフリフレッシュを実行する
Delay 1	60s	リセット後の SET_TIME 有効期間
Delay 2	100ms	アイドル確認後のセルフリフレッシュ実行までの遅れ時間

詳しい情報は以下を参照してください。

マイクロンのサイトの会員登録が必要になります。

6.27. Linuxカーネルがクラッシュしたときにメモリの状態を保存する

ArmadilloはLinuxカーネルがクラッシュすると、ウォッチドッグタイマーによってシステムリセットが発生し、再起動します。

このとき、再起動によってメモリの内容が失われてしまうため、デバッグが困難になる場合があります。

ここでは Kdump を利用してLinuxカーネルがクラッシュしたときにメモリの状態(vmcore)を保存し、vmcoreを解析する方法を紹介します。

6.27.1. Kdumpを利用する準備

ここでは、Kdumpの実行環境を構築する手順を紹介します。

Linuxカーネルの準備
ArmadilloのLinuxカーネルをデバッグ用に変更します。以下で紹介する二つの方法のどちらかを選択してください。
1. ビルド済みのapkパッケージを利用する場合
  以下のコマンドを実行します。
```
[armadillo ~]# persist_file -a del linux-at-x2
[armadillo ~]# persist_file -a add linux-at-x2-debug
```
2. Linuxカーネルをビルドする場合
  以下のようにカーネルコンフィギュレーションを変更してください。
```
Kernel hacking  --->
  Compile-time checks and compiler options  --->
    [*] Compile the kernel with debug info             <DEBUG_INFO> 
    [ ]   Reduce debugging information         <DEBUG_INFO_REDUCED> 
```
  チェックを入れます
  
  チェックを外します
  「Linux カーネルをビルドする」を参照して、ビルドおよびインストールしてください。
パッケージのインストール
makedumpfileをインストールします。
```
[armadillo ~]# persist_file -a add makedumpfile
```


	Armadillo Base OS 3.19 までは kdump-tools パッケージをインストールし kdump-tools サービスを使用していました。サービスの設定以外は同じ手順で実行できます。

設定ファイルの編集

Kdumpの設定ファイルを確認します。

[armadillo ~]# vi /etc/conf.d/kdump
# Configuration for /etc/init.d/kdump

:(省略)
#kexec_args="--initrd=/boot/initramfs-cust /boot/vmlinuz-cust"
kexec_args=/boot/Image 

:(省略)
kdump_dir=/var/app/volumes/crash 
:(省略)
[armadillo ~]# persist_file /etc/conf.d/kdump

	Linuxカーネルイメージのパスを指定します。initrd を使用する場合は例のように設定できます。
	vmcoreを保存するディレクトリを指定します。少なくとも30MByte以上の空き容量が必要です。
	変更した場合、ファイルを永続化します。

kdumpサービスの有効化
kdump サービスの自動起動を有効化します。
```
[armadillo ~]# rc-update add kdump 
[armadillo ~]# persist_file /etc/runlevels/default/kdump 
```
kdumpサービスの自動起動を有効にします。

ファイルを永続化します。

Linuxカーネル起動時パラメータの指定

Kdumpで利用するメモリサイズを、Linuxカーネル起動時パラメータのcrashkernelに指定します。「u-boot の環境変数の設定」を参照し、環境変数optargsを設定してください。

以下の例では、Kdumpで利用するメモリサイズを128MByteに指定しています。

[armadillo ~]# vi /boot/uboot_env.d/kdump 
optargs=quiet nokaslr crashkernel=128M 
[armadillo ~]# persist_file -v /boot/uboot_env.d/kdump 
'/boot/uboot_env.d/kdump' -> '/mnt/boot/uboot_env.d/kdump'
[armadillo ~]# fw_setenv -s /boot/uboot_env.d/kdump 
Environment OK, copy 0
[armadillo ~]# fw_printenv | grep optargs= 
optargs=quiet nokaslr crashkernel=128M
[armadillo ~]# reboot

	コンフィグファイルを生成します。
	デフォルト値である"quiet nokaslr"の後ろに追加しています。デフォルト値が不要であれば、削除しても問題ありません。
	ファイルを永続化します。
	変数を書き込みます。
	書き込んだ変数を確認します。
	再起動して、設定を反映させます。

以上で、Kdumpを利用する準備は完了です。Linuxカーネルがクラッシュした場合に、Kdumpによってvmcoreが保存されるようになりました。

6.27.2. Kdumpの動作確認

ここでは、故意にLinuxカーネルをクラッシュさせ、Kdumpの動作確認を行う手順を紹介します。

[armadillo ~]# echo c > /proc/sysrq-trigger 
[   19.295633] sysrq: Trigger a crash
[   19.299079] Kernel panic - not syncing: sysrq triggered crash
: (省略)
[   19.386503] Starting crashdump kernel... 
[   19.390426] Bye!
: (省略)
Copying data                                      : [100.0 %] /           eta: 0s
kdump                    |
kdump                    |The dumpfile is saved to /var/app/volumes/crash/2024-07-17-15:08:57/dump.
kdump                    |
kdump                    |makedumpfile Completed.
kdump                    |
kdump                    |The dmesg log is saved to /var/app/volumes/crash/2024-07-17-15:08:57/dmesg.
kdump                    |
kdump                    |makedumpfile Completed.
kdump                    | * Dump done, rebooting
: (省略)
[   20.189148] imx2-wdt 30280000.watchdog: Device shutdown: Expect reboot!
[   20.201853] reboot: Restarting system 
: (省略)
armadillo:~# ls /var/app/volumes/crash/2024-07-17-15:08:57 
dmesg  dump

	SysRqキーの"c"コマンドを実行してLinuxカーネルをクラッシュさせます。
	Kdumpに指定したLinuxカーネルがブートローダーを経由せずに起動します。
	Kdumpがvmcoreを保存した後、自動的に再起動します。
	作成されたファイルを確認します。
	dmesgはLinuxカーネルのログです。dumpはvmcoreです。

Armadilloの再起動完了後、Kdumpのログに表示されたディレクトリ(/var/app/volumes/crash/[DATE]/)から、Linuxカーネルがクラッシュした時のvmcoreやdmesgを確認することができます。

6.27.3. vmcoreの確認

ここでは、vmcoreの内容を確認する手順を紹介します。

vmcoreの内容を確認するには、次の3つが必要です。

vmcore
vmlinux
crashコマンド

vmcoreは、「Kdumpの動作確認」で作成した /var/app/volumes/crash/[DATE]/dump です。vmlinuxおよびcrashコマンドの準備については、以下の手順を参照してください。

vmlinuxの準備
現在動作しているLinuxカーネルと一緒にビルドされたvmlinuxを取得します。
「Kdumpを利用する準備」でどちらのLinuxカーネルを選択したかによって手順が異なります。以下で紹介する二つの方法のどちらかを選択してください。
1. ビルド済みのapkパッケージに含まれているLinuxカーネルが動作している場合
  以下のコマンドを実行してvmlinuxを取得します。vmlinuxは、ホストとコンテナ間で共有する/var/app/volumes/crash/に配置します。
```
[armadillo ~]# cd /var/app/volumes/crash/
[armadillo /var/app/volumes/crash]# apk fetch linux-at-x2-dbg
[armadillo /var/app/volumes/crash]# mv linux-at-x2-dbg-[VERSION].apk linux-at-x2-dbg.tar.gz
[armadillo /var/app/volumes/crash]# tar xf linux-at-x2-dbg.tar.gz
[armadillo /var/app/volumes/crash]# ln -s usr/lib/debug/lib/modules/[VERSION]/vmlinux .
```
2. ビルドしたLinuxカーネルが動作している場合
  ビルドしたLinuxカーネルディレクトリ直下にvmlinuxが作成されています。
```
[armadillo ~]# ls linux-[VERSION]/vmlinux
linux-[VERSION]/vmlinux
```
  vmlinuxを/var/app/volumes/crash/にコピーしてください。

crashコマンドの準備

crashコマンドを利用する為に、「アットマークテクノが提供するイメージを使う」を参照してdebianコンテナを作成してください。


	crashコマンドが利用できるディストリビューションであれば、debian以外を利用しても構いません。

以下のコマンドを実行してcrashをインストールします。

[armadillo ~]# vi /etc/atmark/containers/kdump.conf
set_image localhost/at-debian-image:latest
set_command sleep infinity
add_volumes /var/app/volumes/crash:/mnt:ro 
[armadillo ~]# podman_start kdump
Starting 'kdump'
8e7ad42534e3fb968dbf597d679246346ae4f766ac33ab0265008f30a7bf7d11
[armadillo ~]# podman exec -it kdump bash
[container /]# apt install crash

	ホスト OS 側の /var/app/volumes/crash をコンテナ内の /mnt にマウントするように設定します。
	crashコマンドを含むcrashパッケージをインストールします。

vmcoreの確認

以下のコマンドを実行してcrashを起動します。起動に成功するとcrashのプロンプトが表示され、不具合の解析を行うことができるようになります。

[container /]# crash /mnt/vmlinux /mnt/[DATE]/dump
:(省略)
crash>

crashのコマンド一覧は、helpコマンドで確認できます。

crash> help

helpの引数にコマンドを与えると、そのコマンドの詳細を確認できます。例としてbtコマンドの詳細は以下のように確認できます。

crash> help bt

6.28. 動作ログ

6.28.1. 動作ログについて

Armadillo-X2 ではシステムが出力するログの一部は、一般的な /var/log ディレクトリではなく、/var/at-log ディレクトリに出力されます。 /var/at-log は、ルートファイルシステムとは別のパーティションになっているので、ルートファイルシステムに障害が発生した場合でも、/var/at-log のパーティションが無事であれば、ログファイルを取り出して、不具合等の解析に利用することができます。

Armadillo-X2 で /var/log 配下に出力するログに関しては「/var/log/ 配下のログに関して」を参照ください。

6.28.2. 動作ログを取り出す

ログファイルは /var/at-log ディレクトリ内に atlog というファイル名で作成されているので、これを任意のディレクトリにコピーすることで取り出せます。もし、eMMC 上のルートファイルシステムが壊れてしまい起動できない場合は、 microSD カードから起動することでログファイルを取り出すことができます。

/var/at-log/atlog はファイルサイズが 3MiB になるとローテートされ /var/at-log/atlog.1 に移動されます。

/var/at-log/atlog.1 が存在する状態で、更に /var/at-log/atlog のファイルサイズが 3MiB になった場合は、 /var/at-log/atlog の内容が /var/at-log/atlog.1 に上書きされます。 /var/at-log/atlog.2 は生成されません。

6.28.3. ログファイルのフォーマット

ログファイルの内容はテキストデータであり、以下のようなフォーマットになっています。

日時 armadillo ログレベル 機能: メッセージ

図6.210 動作ログのフォーマット

atlog には以下の内容が保存されています。

インストール状態のバージョン情報
swupdate によるアップデートの日付とバージョン変更
abos-ctrl / uboot の rollback 日付
uboot で wdt による再起動があった場合にその日付

6.28.4. ログ用パーティションについて

ログ出力先である /var/at-log ディレクトリには、 GPP である /dev/mmcblk2gp1 パーティションがマウントされています。このパーティションに論理的な障害が発生した場合は、/dev/mmcblk2gp1 のデータを /dev/mmcblk2gp2 にコピーし、/dev/mmcblk2gp1 は FAT ファイルシステムでフォーマットされます。このパーティションの障害チェックはシステム起動時に自動的に実行されます。

6.28.5. /var/log/ 配下のログに関して

表6.29「/var/log/ 配下のログ」に Armadillo-X2 で /var/log/ 配下に出力するログを示します。

最大ファイルサイズを超えると表6.29「/var/log/ 配下のログ」の「ファイル名」の 2 行目に記載されたファイル名にコピーします。

その状態から更に最大ファイルサイズを超えた場合、表6.29「/var/log/ 配下のログ」の「ファイル名」の 2 行目に記載されたファイル名に上書きします。

表6.29 /var/log/ 配下のログ

ファイル名

説明

最大ファイルサイズ

最大ファイル数

/var/log/messages

/var/log/messages.0

通常のログです。

4MiB

/var/log/armadillo-twin-agent/agent_log

/var/log/armadillo-twin-agent/agent_log.1

Armadillo Twin Agent の動作ログです。

1MiB

6.29. シリアル通信ソフトウェア(minicom)のセットアップ


	ATDE9 v20240925 以降の ATDE では以下の設定を実施した状態のイメージを配布しています。これより前のバージョンの場合は、次の手順に沿って minicom のシリアル通信設定を実施してください。

minicom を使用して Armadillo とシリアルコンソール経由で通信を行うためには、表6.30「シリアル通信設定」のとおりにあらかじめ設定しておく必要があります。ここでは、その設定手順について説明します。また、minicomを起動する端末の横幅を80文字以上にしてください。横幅が80文字より小さい場合、コマンド入力中に表示が乱れることがあります。

表6.30 シリアル通信設定

項目	設定
転送レート	115,200bps
データ長	8bit
ストップビット	1bit
パリティ	なし
フロー制御	なし

図6.211「minicomの設定の起動」に示すコマンドを実行し、minicomの設定画面を起動してください。
```
[ATDE ~]$ sudo LANG=C minicom --setup
```
図6.211 minicomの設定の起動

図6.212「minicomの設定」が表示されますので、「Serial port setup」を選択してください。

            +-----[configuration]------+
            | Filenames and paths      |
            | File transfer protocols  |
            | Serial port setup        |
            | Modem and dialing        |
            | Screen and keyboard      |
            | Save setup as dfl        |
            | Save setup as..          |
            | Exit                     |
            | Exit from Minicom        |
            +--------------------------+

図6.212 minicomの設定

図6.213「minicomのシリアルポートの設定」が表示されますので、Aキーを押してSerial Deviceを選択してください。

    +-----------------------------------------------------------------------+
    | A -    Serial Device      : /dev/ttyUSB0                              |
    | B - Lockfile Location     : /var/lock                                 |
    | C -   Callin Program      :                                           |
    | D -  Callout Program      :                                           |
    | E -    Bps/Par/Bits       : 115200 8N1                                |
    | F - Hardware Flow Control : No                                        |
    | G - Software Flow Control : No                                        |
    |                                                                       |
    |    Change which setting?                                              |
    +-----------------------------------------------------------------------+

図6.213 minicomのシリアルポートの設定

Serial Device に使用するデバイスファイル名として /dev/ttyUSB0 を入力してEnterキーを押してください。

デバイスファイル名の確認方法

デバイスファイル名は、環境によって /dev/ttyS0 や /dev/ttyUSB1 など、本書の実行例とは異なる場合があります。

その場合は以下の方法でデバイスファイル名を確認してください。

Linux で PC と Armadillo 側のシリアルポートを接続した場合、コンソールに以下のようなログが表示されます。ログが表示されなくても、dmesgコマンドを実行することで、ログを確認することができます。

usb 2-2.1: new full-speed USB device number 4 using uhci_hcd
usb 2-2.1: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-2.1: Product: CP2102N USB to UART Bridge Controller
usb 2-2.1: Manufacturer: Silicon Labs
usb 2-2.1: SerialNumber: 6a9681f80272eb11abb4496e014bf449
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver cp210x
usbserial: USB Serial support registered for cp210x
usb 2-2.1: cp210x converter now attached to ttyUSB0

図6.214 例. シリアルポート接続時のログ

上記の例では Armadillo 側のシリアルポートが ttyUSB0 に割り当てられたことが分かります。

Fキーを押してHardware Flow ControlをNoに設定してください。
Gキーを押してSoftware Flow ControlをNoに設定してください。

キーボードのEキーを押してください。図6.215「minicomのシリアルポートのパラメータの設定」が表示されます。

                      +---------[Comm Parameters]----------+
                      |                                    |
                      |     Current: 115200 8N1            |
                      | Speed            Parity      Data  |
                      | A: <next>        L: None     S: 5  |
                      | B: <prev>        M: Even     T: 6  |
                      | C:   9600        N: Odd      U: 7  |
                      | D:  38400        O: Mark     V: 8  |
                      | E: 115200        P: Space          |
                      |                                    |
                      | Stopbits                           |
                      | W: 1             Q: 8-N-1          |
                      | X: 2             R: 7-E-1          |
                      |                                    |
                      |                                    |
                      | Choice, or <Enter> to exit?        |
                      +------------------------------------+

図6.215 minicomのシリアルポートのパラメータの設定

図6.215「minicomのシリアルポートのパラメータの設定」では、転送レート、データ長、ストップビット、パリティの設定を行います。
現在の設定値は「Current」に表示されています。それぞれの値の内容は図6.216「minicomシリアルポートの設定値」を参照してください。
図6.216 minicomシリアルポートの設定値
Eキーを押して、転送レートを115200に設定してください。
Qキーを押して、データ長を8、パリティをNone、ストップビットを1に設定してください。
Enterキーを2回押して、図6.212「minicomの設定」に戻ってください。
図6.212「minicomの設定」から、「Save setup as dfl」を選択し、設定を保存してください。
「Exit from Minicom」を選択し、minicomの設定を終了してください。


	`Ctrl-a` に続いて `z` キーを入力すると、minicomのコマンドヘルプが表示されます。

6.30. viエディタを使用する

viエディタは、Armadilloに標準でインストールされているテキストエディタです。本書では、Armadilloの設定ファイルの編集などにviエディタを使用します。

viエディタは、ATDEにインストールされてるgeditやemacsなどのテキストエディタとは異なり、モードを持っていることが大きな特徴です。viのモードには、コマンドモードと入力モードがあります。コマンドモードの時に入力した文字はすべてコマンドとして扱われます。入力モードでは文字の入力ができます。

本章で示すコマンド例はATDEで実行するよう記載していますが、Armadilloでも同じように実行することができます。

6.30.1. viの起動

viを起動するには、以下のコマンドを入力します。

[ATDE ~]# vi [file]

図6.217 viの起動

file にファイル名のパスを指定すると、ファイルの編集( file が存在しない場合は新規作成)を行います。viはコマンドモードの状態で起動します。

6.30.2. 文字の入力

文字を入力するにはコマンドモードから入力モードへ移行する必要があります。コマンドモードから入力モードに移行するには、表6.31「入力モードに移行するコマンド」に示すコマンドを入力します。入力モードへ移行後は、キーを入力すればそのまま文字が入力されます。

表6.31 入力モードに移行するコマンド

コマンド	動作
i	カーソルのある場所から文字入力を開始
a	カーソルの後ろから文字入力を開始

「i」、「a」それぞれのコマンドを入力した場合の文字入力の開始位置を図6.218「入力モードに移行するコマンドの説明」に示します。

images/common-images/vi-insert-command.svg

図6.218 入力モードに移行するコマンドの説明

入力モードからコマンドモードに戻りたい場合は、ESCキーを入力することで戻ることができます。現在のモードが分からなくなった場合は、ESCキーを入力し、一旦コマンドモードへ戻ることにより混乱を防げます。

日本語変換機能をOFFに

viのコマンドを入力する時はATDEの日本語入力システム(Mozc)をOFFにしてください。日本語入力システムのON/OFFは、半角/全角キーで行うことができます。

viでの文字削除

コンソールの環境によってはBS(Backspace)キーで文字が削除できず、「^H」文字が入力される場合があります。その場合は、「文字の削除」で説明するコマンドを使用し、文字を削除してください。

6.30.3. カーソルの移動

方向キーでカーソルの移動ができますが、コマンドモードで表6.32「カーソルの移動コマンド」に示すコマンドを入力することでもカーソルを移動することができます。

表6.32 カーソルの移動コマンド

コマンド	動作
h	左に1文字移動
j	下に1文字移動
k	上に1文字移動
l	右に1文字移動

6.30.4. 文字の削除

文字を削除する場合は、コマンドモードで表6.33「文字の削除コマンド」に示すコマンドを入力します。

表6.33 文字の削除コマンド

コマンド	動作
x	カーソル上の文字を削除
dd	現在行を削除

「x」コマンド、「dd」コマンドを入力した場合に削除される文字を図6.219「文字を削除するコマンドの説明」に示します。

images/common-images/vi-delete-command.svg

図6.219 文字を削除するコマンドの説明

6.30.5. 保存と終了

ファイルの保存、終了を行うコマンドを表6.34「保存・終了コマンド」に示します。

表6.34 保存・終了コマンド

コマンド	動作
`:q!`	変更を保存せずに終了
`:w[file]`	ファイルを `file` に指定して保存
`:wq`	ファイルを上書き保存して終了

保存と終了を行うコマンドは「 : 」(コロン)からはじまるコマンドを使用します。" : "キーを入力すると画面下部にカーソルが移り入力したコマンドが表示されます。コマンドを入力した後Enterキーを押すことで、コマンドが実行されます。

6.31. オプション品

本章では、Armadillo-X2のオプション品について説明します。

表6.35 Armadillo-X2関連のオプション品

名称	型番	備考
Armadillo-X2 オプションケース(金属製)	OP-CASEX2-MET-00	ケースモデルに付属
CPU放熱シート15x15x4mm 10個セット	OP-THS-151504-00
Armadillo-X2、G4 ケースモデル VESA規格固定用プレート	OP-CASEX2-VESA-00
ACアダプタ（12V/3.0A φ2.1mm）標準品	OP-AC12V6-00	開発セットに付属

6.31.1. Armadillo-X2 オプションケース(金属製)

6.31.1.1. 概要

Armadillo-X2用のアルミ製ケースです。基板を収めた状態で、DCジャック、LAN、USBx2、HDMI、USBコンソール、スイッチ、LEDにアクセスすることが可能となっています。

図6.220 Armadillo-X2 オプションケース(金属製)

表6.36 Armadillo-X2 オプションケースセット(金属製)について

製品名	Armadillo-X2 オプションケースセット(金属製)
型番	OP-CASEX2-MET-00
セット内容	アルミケース、ケースネジ×2、Armadillo-X2固定用ネジ×4

表6.37 Armadillo-X2 オプションケース(金属製)の仕様

材質	ヘアライン白アルマイト材
板厚	1.0 mm


	コネクタ開口部等に存在する継ぎ目状の加工痕は正常な状態ですのでご了承ください。図6.221 オプションケース(金属製)の加工痕例

6.31.1.2. 組み立て

組み立て手順に関しては、「オプションケース(金属製)への組み付け」を参照してください。

6.31.1.3. 形状図

図6.222 ケース(上)形状図

図6.223 ケース(下)形状図


	DXF形式の形状図を「アットマークテクノ Armadilloサイト」から「購入者向けの限定公開データ」としてダウンロード可能です。


	DCジャック(CON14)、USBコンソールインターフェース(CON6)、SDインターフェース(CON1)は、他コネクタの面位置より少し後ろに配置しているため、外部からの操作が不要な場合、開口を塞ぐ設計変更をするだけで、目隠しすることが可能です。


	ケース固定用のM3のねじ穴を2つ用意しています。故障の原因となりますので、基板裏や部品にねじが接触していないか、十分にご確認の上ご利用ください。図6.224 ケースを固定する際の注意

6.31.2. Armadillo-X2、G4 ケースモデル VESA規格固定用プレート

6.31.2.1. 概要

Armadillo-X2、G4 ケースモデル VESA規格固定用プレートはVESA規格(100 × 100mm)に対応したテレビやモニターなどに Armadillo-X2およびArmadillo-IoT ゲートウェイ G4のケースモデルを取り付けるための製品です。

images/common-images/about-op-vesa-plate.svg

図6.225 Armadillo-X2、G4 ケースモデル VESA規格固定用プレート

表6.38 Armadillo-X2、G4 ケースモデル VESA規格固定用プレートについて

製品名	Armadillo-X2、G4 ケースモデル VESA規格固定用プレート
型番	OP-CASEX2-VESA-00
セット内容	VESA規格固定用プレート、ケース固定用ねじ×2、プレート固定用ねじ×4

表6.39 Armadillo-X2、G4 ケースモデル VESA規格固定用プレートの仕様

色	黒
材質	鉄
寸法	120 × 123 mm
板厚	2 mm

6.31.2.2. 組み立て

Armadillo-X2 オプションケース(金属製)の底面には、ケース固定用のM3のネジ穴が2箇所あります。この穴を利用して、VESA規格固定用プレートを取り付けます。

VESA規格固定用プレートの中央側にある2箇所の穴が、ケース取り付け用の穴です。ケース底面の穴とVESA規格固定用プレートの穴位置を合わせて、皿もみ加工されている面から、ねじ頭がすっぽり収まるまで、ねじを締めてください。推奨のねじ締めトルクは 31.5cN•m です。

図6.226 ケースにVESA規格固定用プレートを取り付け

: 皿小ねじ(M3、L=4mm) × 2


	故障の原因となりますので、付属ねじ以外をご使用の場合、ケース内部の基板や部品にねじが接触していないか、十分にご確認ください。

VESA規格固定用プレートの4隅の穴が、VESA規格(100 x 100mm)に対応した穴です。

ケース取り付け済みのVESA規格固定用プレートを VESA規格(100 x 100mm)に対応したテレビやモニターなどに取り付けます。

図6.227 モニターにVESA規格固定用プレートを取り付け

: バインド小ねじ(M4、L=10mm) × 4

6.31.2.3. 形状図

images/common-images/vesa-plate-dimension.svg

図6.228 Armadillo-X2、G4 ケースモデル VESA規格固定用プレート形状図


	DXF形式の形状図を「アットマークテクノ Armadilloサイト」から「購入者向けの限定公開データ」としてダウンロード可能です。

^[13]推論実行用のソフトウェアであり、学習は行なえません。

^[14] nmcli connection show [ID] によって、より詳細な情報を表示することもできます。

^[15]スペースキーでページを送ると、最終ページに同意するかどうかの入力プロンプトが表示されます。


第5章運用編	PDF version

応用編

6.1. persist_file について

6.2. コンテナ

6.2.1. Podman - コンテナ仮想化ソフトウェアとは

6.2.2. コンテナの基本的な操作

6.2.2.1. イメージからコンテナを作成する

6.2.2.2. イメージ一覧を表示する

6.2.2.3. コンテナ一覧を表示する

6.2.2.4. コンテナを起動する

6.2.2.5. コンテナを停止する

6.2.2.6. コンテナの変更を保存する

6.2.2.7. コンテナの自動作成やアップデート

6.2.2.8. コンテナを削除する

6.2.2.9. イメージを削除する

6.2.2.10. 実行中のコンテナに接続する

6.2.2.11. コンテナ間で通信をする

6.2.2.12. podでコンテナのネットワークネームスペースを共有する

6.2.2.13. networkの作成

6.2.2.14. コンテナからのコンテナ管理

6.2.2.15. リモートリポジトリにコンテナを送信する

6.2.2.16. イメージを eMMC に保存する

6.2.2.17. イメージを SWUpdate で転送する

6.2.2.18. 開発時に有用な—privilegedオプション

6.2.3. コンテナとコンテナに関連するデータを削除する

6.2.3.1. VS Code から実行する

6.2.3.2. コマンドラインから実行する

6.2.4. コンテナ起動設定ファイルを作成する

6.2.4.1. コンテナイメージの選択

6.2.4.2. ポート転送

6.2.4.3. デバイスファイル作成

6.2.4.4. ボリュームマウント

6.2.4.5. ホットプラグデバイスの追加

6.2.4.6. 個体識別情報の環境変数の追加

6.2.4.7. pod の選択

6.2.4.8. ネットワークの選択

6.2.4.9. IP アドレスの設定

6.2.4.10. 読み取り専用設定

6.2.4.11. イメージの自動ダウンロード設定

6.2.4.12. コンテナのリスタート設定

6.2.4.13. 信号を受信するサービスの無効化

6.2.4.14. podman logs 用のログサイズ設定

6.2.4.15. podman のフックの仕組み

6.2.4.16. ヘルスチェック機能の設定

6.2.4.17. 自動起動の無効化

6.2.4.18. 実行コマンドの設定

6.2.4.19. コンテナ起動前にコマンドを実行する

6.2.4.20. podman run に引数を渡す設定

6.2.5. アットマークテクノが提供するイメージを使う

6.2.5.1. ABOSDE からインストールする

6.2.5.2. Docker ファイルからイメージをビルドする

6.2.5.3. ビルド済みのイメージを使用する

6.2.6. alpine のコンテナイメージをインストールする

6.2.6.1. SBOM 生成に関わる設定を行う

6.2.7. コンテナのネットワークを扱う

6.2.7.1. コンテナの IP アドレスを確認する

6.2.7.2. コンテナに固定 IP アドレスを設定する

6.2.8. コンテナ内にサーバを構築する

6.2.8.1. HTTP サーバを構築する

6.2.8.2. FTP サーバを構築する

6.2.8.3. Samba サーバを構築する

6.2.8.4. SQL サーバを構築する

6.2.9. 画面表示を行う

6.2.9.1. Wayland を扱う

6.2.9.2. X Window System を扱う

6.2.9.3. フレームバッファに直接描画する

6.2.9.4. タッチパネルを扱う

6.2.9.5. VPU を扱う

6.2.10. パワーマネジメント機能を使う

6.2.10.1. サスペンド状態にする

6.2.10.2. 起床要因を有効化する

6.2.10.3. パワーマネジメントの仕様

6.2.11. コンテナからのpoweroff及びreboot

6.2.12. 異常検知

6.2.12.1. ソフトウェアウォッチドッグタイマーを扱う

6.2.13. NPU を扱う

6.2.13.1. ONNX Runtime を使う

6.2.13.2. TensorFlow Lite を使う

6.2.13.3. Arm NN を使う

6.3. swupdateを使用してアップデートする

6.3.1. swupdate で可能なアップデート

6.2.4.20. `podman run` に引数を渡す設定