量産編

本章では Armadillo を組み込んだ最終製品をお客様が製造・量産するうえで、必要となる情報や作業について記載します。

「概略」では、量産の進め方に関する概略を記載します。
「BTO サービスを使わない場合と使う場合の違い」では、BTO(Build To Order) サービスに関する説明をします。
「量産時のイメージ書き込み手法」では、開発を完了したソフトウェアの量産用イメージ作成・書き込み方法を説明します。
- 「インストールディスクを用いてイメージ書き込みする」は、インストールディスクを使用する方法を説明します。
- 「SWUpdate を用いてイメージ書き込みする」は、SWUpdate を使用する方法を説明します。

4.1. 概略

量産の進め方の概略図を図4.1「Armadillo 量産時の概略図」に示します。お客様の製品仕様や製造工程の要件によってはこの例とは違った工程順となる場合や、工程の追加・削除がある可能性があります。

図4.1 Armadillo 量産時の概略図

4.1.1. Armadillo Twin を契約する

Armadillo Twin を使用したデバイス運用管理を行う場合は、量産モデルの発注とは別にArmadillo Twin の契約が必要となります。 Armadillo Twin の契約の詳細については、弊社営業、ご利用の販売代理店にお問い合わせください。

4.1.2. リードタイムと在庫

量産モデルを発注後、お客様に納品されるまでにリードタイムが発生します。開発セットや少量の量産モデル購入の場合、アットマークテクノや代理店在庫によって、短期間で納品できることもあります。しかし、まとまった数量の量産モデルの場合、納品までにお時間をいただくことがあります。新規に製品を量産・出荷する場合はリードタイムを考慮したスケジューリングをお願いします。また、リピート製造をする場合でも、欠品を起こさないよう適切な在庫の確保をお願いいたします。

リードタイムは状況・タイミングによって異なりますので、都度、弊社営業、ご利用の販売代理店にお問い合わせください。

4.1.3. Armadillo 納品後の製造・量産作業

お客様が Armadillo を納品後に次に示すようなキッティング作業、組み立て、検査を実施し出荷を行います。

ソフトウェア書き込み
- Armadillo Base OS やアプリケーションコンテナイメージの書き込み
- 設定ファイルの書き込み
別部品の組み立て
- SD カード/ SIM カード/ RTC バックアップ電池等の接続
- 拡張基板接続やセンサー・外部機器の接続
- お客様専用筐体への組み込み
検査
- Armadillo の受け入れ検査
- 組み立て後の通電電検・機能検査
- 目視検査
梱包作業
出荷作業

有償の BTO サービスを利用することで、これらの作業の一部をアットマークテクノへ委託・実施済みの状態で Armadillo を納品することも可能です。費用はいただきますがお客様による工程立ち上げ、場所の確保、作業者の教育、品質管理等のトータルコストを考えると委託した方が安く済むケースが多いです。

また、 BTO サービスではお受けできないようなキッティング、検査、作業については、実施可能な業者をご紹介する等、個別の対応をすることで解決できる場合もございます。詳しくは弊社担当の営業、またはご利用の販売代理店にご相談ください。

4.2. BTO サービスを使わない場合と使う場合の違い

図4.2 BTO サービスで対応する範囲

4.2.1. BTO サービスを利用しない(標準ラインアップ品)

有償の量産サービスを利用しない場合、標準ラインアップ仕様での納品となります。大きく分けて試作開発用途で使う「開発セット」と量産向けの「量産モデル」の 2 種類があります。量産用途では「量産モデル」をご利用ください。

「量産モデル」には AC アダプタ等のオプション品が付属されておりませんので、内容物を確認の上、発注をお願いいたします。ラインアップ一覧については「製品ラインアップ」をご確認ください。

4.2.1.1. 標準ラインアップ品に書き込まれているソフトウェア

標準ラインアップ品に書き込まれるソフトウェアイメージ(Armadillo Base OS)は、アットマークテクノで公開している標準イメージとなります。また、ソフトウェアバージョンは指定することができず、ランニングチェンジで随時最新版を適用していきます。このため、納品後の Armadillo 個体では、開発段階で評価した Armadillo Base OS と異なるバージョンが書き込まれている可能性があります。

また、アプリケーションコンテナについては何も書き込まれていない状態となります。

納品後、お客様の量産工程でソフトウェアの書き込み作業が必要となります。詳しくは「量産時のイメージ書き込み手法」をご確認ください。

4.2.2. BTO サービスを利用する

BTO サービスは、セミオーダー式メニューから選択して Armadillo の量産品を一括手配いただける有償サービスです。標準ラインアップ品の仕様をベースとして、搭載するモジュールの種類やケース、 AC アダプタの有無、お客様支給品の SD カードや SIM カードの接続、お客様ご指定のソフトウェアイメージ書き込みなど、メニュー内から指定可能なキッティング項目を選択・指定することが可能です。

販売代理店またはアットマークテクノの窓口からお申し込みいただけます。

製品ごとに、対応できる作業とできない作業がございます。また、販売直後の製品の場合など BTO サービスに未対応である場合もあります。詳しくは Armadilloサイトの BTO サービスをご確認ください。

4.3. 量産時のイメージ書き込み手法

量産時に必要な手順は最終製品によって異なりますが、開発したソフトウェアをArmadilloに書き込む手順は必ず実施することになります。 Armadillo Base OS 搭載製品において、量産時に任意のソフトウェアを書き込む際には、以下の2つの手法のどちらかを用いると実現できます。

インストールディスクを用いてソフトウェアを書き込む
SWUpdateを用いてソフトウェアを書き込む

ただし、SWUpdateは運用中のArmadilloのアップデート機能であり、量産時のイメージ書き込みは本来の用途でないため、基本的にはイメージ書き込みに特化しているインストールディスクを用いた方法を選択してください。

それぞれの手法の特徴を表4.1「インストールディスクとSWUpdateによるソフトウェア書き込みの比較」にまとめます。ソフトウェア書き込み工程を決定する際の参考にしてください。

表4.1 インストールディスクとSWUpdateによるソフトウェア書き込みの比較

手段	メリット	デメリット
インストールディスク	インストールの前後処理を行なうシェルスクリプトのテンプレートが用意されているインストールの前後処理は、microSDカード内にシェルスクリプトを配置するだけなので製造担当者にも編集しやすい	動いているシステムをそのままインストールディスクにするため、出荷時の標準イメージから手動で同じ環境を構築する手順が残らない
SWUpdate	microSD カードを使用せずに実行できるため、Armadilloのケースを開ける必要がない必ず必要となる初回アップデートを別途実行する必要がない	SWUイメージの作成には、mkswuを使用できる環境とdescファイルの記述方法を知る必要があるため、開発担当者以外にSWUイメージを更新させるハードルが少し高いログの取得など、インストール前後の処理が必要な場合は自分で記述する必要がある

量産時のイメージ書き込みにインストールディスクを使用する場合は、「インストールディスクを用いてイメージ書き込みする」に進んでください。

量産時のイメージ書き込みにSWUpdateを使用する場合は、「SWUpdate を用いてイメージ書き込みする」に進んでください。

4.4. インストールディスクを用いてイメージ書き込みする

「インストールディスクについて」でも紹介したとおり、 Armadillo Base OS 搭載製品では、開発が完了した Armadillo のクローン用インストールディスクを作成することができます。

以下では、クローン用インストールディスクを作成する手順を準備段階から紹介します。

4.4.1. /etc/swupdate_preserve_fileへの追記

Armadillo Base OS のバージョンを最新版にしておくことを推奨しています。最新版でない場合は、バージョンが古いゆえに以下の作業を実施出来ない場合もありますので、ここで Armadillo Base OS のバージョンをアップデートしてください。

ここでは SWUpdate を使用して Armadillo Base OS のアップデートを行ないますが、このアップデートを行なうと、/etc/swupdate_preserve_filesに記載の無いファイルは消えてしまいます。 Armadillo Base OS のルートファイルシステム上に消えてほしくないファイルを開発中に配置していた場合は、図4.3「任意のファイルパスを/etc/swupdate_preserve_filesに追記する」に示すコマンドを実行することで /etc/swupdate_preserve_files にそのファイルが追記され、アップデート後も保持し続けるようになります。

一部のファイルやディレクトリは初めから /etc/swupdate_preserve_files に記載されている他、 podman commit したコンテナイメージについてもアップデート後に引き継がれるので、本ドキュメントのサンプルアプリケーションの場合は実行する必要はありません。

[armadillo /]# persist_file -p <ファイルのパス>

図4.3 任意のファイルパスを/etc/swupdate_preserve_filesに追記する

4.4.2. Armadillo Base OSの更新

Armadillo-IoT ゲートウェイ A6E Armadillo Base OSから「Armadillo-IoT ゲートウェイ A6E用 SWUイメージファイル」のURLをコピーして、図4.4「Armadillo Base OSをアップデートする」に示すコマンドを実行することでArmadillo Base OSを最新版にアップデートできます。

[armadillo /]# swupdate -d '-u https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-a6e/image/baseos-6e-[VERSION].swu'

図4.4 Armadillo Base OSをアップデートする

Armadillo Base OS 3.19.1-at.4 以降では「 abos-ctrl update 」コマンドで /etc/swupdate.watch に記載されている URL の SWU イメージでアップデートすることができます。デフォルトでは最新の Armadillo Base OS へアップデートします。

また、GW コンテナを使用する場合はコンテナも2段階で更新されますので、Base OS の更新で再起動した後にもう一度コマンドを実行してください。

正常に実行された場合は自動的に再起動します。

4.4.3. パスワードの確認と変更

「initial_setup.swu の作成」で SWUpdate の初回アップデートを行った際に、各ユーザーのパスワード設定をしました。開発中はログインしやすいような単純なパスワードにしていることがよくあるので、製品に適用しないようにこのタイミングで強固なパスワードに変更しておきましょう。

[armadillo /]# passwd 
Changing password for root
New password: 
Retype password: 
passwd: password for root changed by root

[armadillo /]# passwd atmark 
Changing password for atmark
New password: 
Retype password: 
passwd: password for atmark changed by root

[armadillo /]# persist_file /etc/shadow

図4.5 パスワードを変更する

	rootユーザのパスワードを変更します。
	新しいrootユーザ用パスワードを入力します。
	再度新しいrootユーザ用パスワードを入力します。
	atmarkユーザのパスワードを変更します。
	新しいatmarkユーザ用パスワードを入力します。
	再度新しいatmarkユーザ用パスワードを入力します。
	パスワードの変更を永続化させます。

4.4.4. 開発中のみ使用していたコンテナイメージの削除

開発用に使用し、運用時には不要なコンテナ及びコンテナイメージは、インストールディスク作成前に削除することを推奨します。

以下のコマンドを実行することで作成したコンテナの一覧を取得できます。

[armadillo /]# podman ps -a
CONTAINER ID  IMAGE                            COMMAND     CREATED        STATUS                    PORTS  NAMES
3ca118e9473b  docker.io/library/alpine:latest  /bin/sh     3 seconds ago  Exited (0) 3 seconds ago         vibrant_easley
9c908ab45ed8  localhost/abos-dev-guide:v1.0.0  /bin/bash   3 minutes ago  Exited (0) 5 months ago          sample_container

基本的に運用時におけるコンテナは /etc/atmark/containers/*.conf ファイルによって自動的に作成されますので、上記コマンドで表示されたコンテナは全て削除して問題無いはずです。以下にコンテナを削除する例を示します。

[armadillo /]# podman rm sample_container 
[armadillo /]# podman rm 3ca118e9473b 
[armadillo /]# podman ps -a
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

	コンテナの名前で削除するコンテナを指定しています。
	コンテナのIDで削除するコンテナを指定しています。
	何も表示されず、全てのコンテナが削除されたことを確認します

以下に示すコマンドを実行することでコンテナイメージの一覧を取得できます。 readonly 領域に保存されているコンテナイメージが 1 つでもある場合は、 R/O 列が表示されます。 R/O 列が表示されない場合は、全てのコンテナイメージの R/O が false であることを意味しています。

[armadillo /]# podman images
REPOSITORY                 TAG         IMAGE ID      CREATED       SIZE        R/O
docker.io/library/alpine   latest      6e30ab57aeee  2 weeks ago   5.56 MB     false
docker.io/library/busybox  latest      3c19bafed223  5 days ago    1.64 MB     true
localhost/abos-container   v1.0.0      2394ea5f177f  5 hours ago   932 MB      false

ここでは運用時に必要な localhost/abos-container:v1.0.0 を除いた、その他のコンテナイメージを削除します。

R/O が false のイメージは podman rmi コマンドで削除できます。

[armadillo /]# podman rmi docker.io/library/alpine
Untagged: docker.io/library/alpine:latest
Deleted: 6e30ab57aeeef1ebca8ac5a6ea05b5dd39d54990be94e7be18bb969a02d10a3f

R/O が true のイメージは abos-ctrl podman-rw rmi コマンドで削除できます。

[armadillo /]# abos-ctrl podman-rw rmi docker.io/library/busybox:latest
Untagged: docker.io/library/busybox:latest
Deleted: 3c19bafed22355e11a608c4b613d87d06b9cdd37d378e6e0176cbc8e7144d5c6

4.4.5. 開発したコンテナイメージを tmpfs に移行する

開発中は podman のデータは電源を切っても保持されるように eMMC に保存していました。開発中はこのままで問題ありませんが、運用する場合には eMMC への書き込みを最小限にする観点から、 podman のデータの保存先を tmpfs に変更しておくことを推奨します。

以下に示すコマンドを実行することで、eMMCに保存されている開発完了後のコンテナイメージをtmpfsモードでも読み取り専用で使用できるように変更できます。

[armadillo /]# abos-ctrl podman-storage --tmpfs
List of images configured on development storage:
REPOSITORY                TAG         IMAGE ID      CREATED       SIZE
localhost/abos-dev-guide  v1.0.0      2394ea5f177f  5 hours ago   932 MB

What should we do? ([C]opy (default), [N]othing, [D]elete)
C 
Delete subvolume (no-commit): '/mnt/containers_storage'
Replacing development images to readonly storage succeeded
Switching back to tmpfs container storage.
Successfully reverted podman storage to tmpfs

[armadillo /]# abos-ctrl podman-rw image list 
REPOSITORY                 TAG         IMAGE ID      CREATED       SIZE
localhost/abos-dev-guide   v1.0.0      2394ea5f177f  5 hours ago   932 MB

	C を入力しEnterを押下します。
	tmpfsモードでコンテナイメージが読み込めていることを確認します。

4.4.6. 開発したシステムをインストールディスクにする

Armadillo Base OSでは、現在起動しているルートファイルシステム及びブートローダーをそのままインストールディスクイメージとして生成することができます。インストールディスクイメージの生成方法は二種類あります。それぞれの特徴をまとめます。

VS Code を使用して生成

ATDE と VS Code を使用して、開発したシステムのインストールディスクイメージを USB メモリ上に生成します。USBメモリは vfat もしくは ext4 形式でフォーマットし、空き容量が 10GB 以上のものを使用してください。 VS Code に開発用エクステンションである ABOSDE をインストールする必要があります。

コマンドラインから生成

abos-ctrl make-installer コマンドを実行すると microSDカードにインストールディスクイメージを生成することができます。コマンド実行前に、Armadilloがインターネットに接続されており、かつ 10GB 以上の空き容量がある microSDカードが挿入されていることを確認してください。 microSDカード内のデータはインストールディスク作成時に上書きされて消えてしまうので、必要なデータは予めバックアップを取っておいてください。 microSDカード上にインストールディスクイメージを生成した場合、インストール時に任意のシェルスクリプトを実行することが可能です。この機能が必要な場合はコマンドラインからの生成を推奨します。

コマンドラインから生成する場合は、Armadillo の JTAG と SD ブート、U-Boot のコマンドプロンプトを無効化するインストールディスクイメージを生成することができます。

4.4.7. VS Code を使用して生成する

ATDE と VS Code を使用して、開発したシステムのインストールディスクイメージを生成します。「VS Codeのセットアップ」を参考に、 ATDE に VS Code 開発用エクステンションをインストールしてください。 VS Code を使用してインストールディスクを生成する場合は以下の手順になります。

VS Code を使用したインストールディスク作成用 SWU の生成
Armadillo に USBメモリを挿入
インストールディスク作成用 SWU を ABOS Web からインストール
USBメモリ上にインストールディスクイメージを生成


	Armadillo-IoT ゲートウェイ A6E では、WLAN 搭載モデルはインストールディスク以外で microSD を使用できないため、一旦 USB メモリへインストールディスクイメージを書き出し、 ATDE にて microSD カードへコピーして動作確認する手順としております。


	この機能を使用するには、以下に示すバージョンのソフトウェアが必要です。 ABOSDE 1.6.0 以上 mkswu 5.3 以上 abos-base 2.3 以上

4.4.7.1. VS Code を使用したインストールディスク作成用 SWU の生成

VS Code の左ペインの [COMMON PROJECT COMMAND] から [Generate Installer On USB Swu] を実行します。

images/common-images/abosde_common_project_command.png

図4.6 make-installer.swu を作成する

次に、対象製品を選択します。

images/common-images/abosde_common_project_command_select_product.png

図4.7 対象製品を選択する

無事に生成された場合、コンソールに以下のログが出力されます。

/home/atmark/.vscode/extensions/atmark-techno.armadillo-base-os-development-environment-1.6.0/shell/desc/make_installer_usb.desc のバージョンを 1 から 2 に変更しました。
Enter pass phrase for /home/atmark/mkswu/swupdate.key: 
/home/atmark/mkswu/make_installer_usb.swu を作成しました。
To create Armadillo installer on USB memory install /home/atmark/mkswu/make_installer_usb.swu in Armadillo
 *  Terminal will be reused by tasks, press any key to close it.

図4.8 make-installer.swu 生成時のログ

パスワードの入力を求められますので、初期化用 swu を生成したときと同じパスワードを入力します

/home/atmark/mkswu ディレクトリ内に make-installer.swu が作成されます。

4.4.7.2. Armadillo に USBメモリを挿入

Armadillo に電源を投入し、インストールディスクを保存するための USB メモリを挿入してください。

USB メモリは vfat もしくは ext4 形式でフォーマットし、空き容量が 10GB 以上のものを使用してください。 Armadillo-IoT ゲートウェイ A6E への USB メモリのマウントは不要です。

インストールディスクイメージは installer.img という名前で保存します。すでに同名のファイルが存在する場合は上書きされます。

4.4.7.3. インストールディスク作成用 SWU を ABOS Web からインストール

ABOS Web を使用して、生成した make-installer.swu をインストールします。「SWUインストール」を参考に make-installer.swu を Armadillo へインストールしてください。実行時は ABOS Web 上に図4.9「make-installer.swu インストール時のログ」ようなログが表示されます。

make_installer_usb.swu をインストールします。
SWU アップロード完了

SWUpdate v2023.05_git20231025-r0

Licensed under GPLv2. See source distribution for detailed copyright notices.

[INFO ] : SWUPDATE running : [main] : Running on iot-a6e Revision at1

[INFO ] : SWUPDATE started : Software Update started !

[INFO ] : SWUPDATE running : [install_single_image] : Installing pre_script

[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over

[INFO ] : SWUPDATE running : [read_lines_notify] : Waiting for btrfs to flush deleted subvolumes

[INFO ] : SWUPDATE running : [install_single_image] : Installing Copying installer to USB device

[INFO ] : SWUPDATE running : [install_single_image] : Installing swdesc_command_nochroot 'podman kill -a'

[INFO ] : SWUPDATE running : [install_single_image] : Installing swdesc_command_nochroot --stdout-info 'abos-ctrl make-installer --noprompt --output /target/mnt/installer.img'

[INFO ] : SWUPDATE running : [read_lines_notify] : Using installer image on image file.

[INFO ] : SWUPDATE running : [read_lines_notify] : Would you like to create a windows partition?

[INFO ] : SWUPDATE running : [read_lines_notify] : That partition would only be used for customization script at the end of

[INFO ] : SWUPDATE running : [read_lines_notify] : install, leave at 0 to skip creating it.

[INFO ] : SWUPDATE running : [read_lines_notify] : Custom partition size (MB, [0] or 16 - 364): 0

[INFO ] : SWUPDATE running : [read_lines_notify] : Checking and growing installer main partition

[INFO ] : SWUPDATE running : [read_lines_notify] : Resize device id 1 (/dev/loop0p1) from 513.00MiB to max

[INFO ] : SWUPDATE running : [read_lines_notify] : Copying boot image

[INFO ] : SWUPDATE running : [read_lines_notify] : Copying rootfs

[INFO ] : SWUPDATE running : [read_lines_notify] : Copying appfs

[INFO ] : SWUPDATE running : [read_lines_notify] : At subvol app/snapshots/volumes

[INFO ] : SWUPDATE running : [read_lines_notify] : At subvol app/snapshots/boot_volumes

[INFO ] : SWUPDATE running : [read_lines_notify] : At subvol app/snapshots/boot_containers_storage

[INFO ] : SWUPDATE running : [read_lines_notify] : Trying to shrink the installer partition...

[INFO ] : SWUPDATE running : [read_lines_notify] : Shrinking the installer partition...

[INFO ] : SWUPDATE running : [read_lines_notify] : Cleaning up and syncing changes to disk...

[INFO ] : SWUPDATE running : [read_lines_notify] : Installer updated successfully!

[INFO ] : SWUPDATE running : [read_lines_notify] : -rwxr-xr-x 1 root root 687.0M Jan 23 15:12 /target/mnt/installer.img

[INFO ] : SWUPDATE running : [install_single_image] : Installing post_script

[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers

[INFO ] : SWUPDATE running : [read_lines_notify] : Command 'command podman rm -a -f' output:

[INFO ] : SWUPDATE running : [read_lines_notify] : 9f4f64ec1926d17e75de4060dac4a448e66ca3d9535c408f632e4e2de4bafa4f

[INFO ] : SWUPDATE running : Installation in progress

[INFO ] : SWUPDATE successful ! SWUPDATE successful !

[INFO ] : No SWUPDATE running : Waiting for requests...

swupdate exited

インストールが成功しました。

図4.9 make-installer.swu インストール時のログ

完了後、USBメモリを抜いてください。もし、エラーが出た場合はArmadillo-IoT ゲートウェイ A6Eの電源を再投入してやり直してください。

4.4.7.4. USBメモリ上にインストールディスクイメージを生成

無事に生成が完了した場合、USBメモリ上に installer.img が保存されています。この installer.img を microSD カードに書き込むことでインストールディスクを作成することができます。動作確認については「インストールディスクの動作確認を行う」をご参照ください。これで、VS Code を使用してインストールディスクを生成する方法については終了です。

4.4.8. インストールディスクの動作確認を行う

作成したインストールディスクの動作確認を実施してください。開発に使用した Armadillo 以外の個体が必要になります。また、インストール先の Armadillo の eMMC 内のデータは上書きされて消えるため、必要なデータは予めバックアップを取っておいてください。

「開発したシステムをインストールディスクにする」の手順で使用した USB メモリの中に installer.img が存在しますので、ATDE 上でこのイメージをもとに microSD カードにインストールディスクを作成してください。ATDE 上に installer.img をコピーした場合、コマンドは以下のようになります。/dev/sd[X] の [X] は microSD を示す文字を指定してください。

[ATDE ~] sudo dd if=installer.img of=/dev/sd[X] bs=1M oflag=direct status=progress

上記コマンドで作成した microSD のインストールディスクを、インストール先の Armadillo に挿入してください。その後、SW2 (起動デバイス設定スイッチ)を ON にしてから電源を入れます。 Armadilloがインストールディスクから起動し、自動的にインストールスクリプトが動作します。

しばらくすると「reboot: Power down」と表示されるので、Armadilloの電源を切ります。その後 Armadillo から microSD カードを抜き、SW2 (起動デバイス設定スイッチ)を OFF にします。再度電源を投入することで、インストールは完了です。

実際にクローンした Armadillo が想定した通りの動作をすることを確認してください。

4.4.9. コマンドラインから生成する

4.4.9.1. JTAG と SD ブートを無効化する

コマンドラインから生成する場合は、 Armadillo の JTAG と SD ブートを無効にするインストールディスクイメージを生成することができます。これらを無効にするには abos-ctrl installer-setting コマンドを実行します。


	生成したインストールディスクを使用して初期化した Armadillo の JTAG と SD ブートを無効にする設定であり、開発用の Armadillo の JTAG と SD ブートが無効になることはありません。

[armadillo /]# abos-ctrl installer-setting
Would you like to disable JTAG in the installer ? [y/N] 
y
JTAG disabled setting for production Armadillo has been configured.
Would you like to disable SD boot in the installer ? [y/N] 
y
SD boot disabled setting for production Armadillo has been configured.

図4.10 JTAG と SD ブートを無効化する

	JTAG を無効化する場合は `y` を入力します。無効化しない場合は何も入力せず `Enter` キーを押してください。
	SD ブートを無効化する場合は `y` を入力します。無効化しない場合は何も入力せず `Enter` キーを押してください。

現在の設定値を確認するには abos-ctrl check-secure コマンドを実行します。 disabled の場合は無効化する設定になっています。

[armadillo /]# abos-ctrl check-secure
- JTAG access disabled for mass production.
- SD boot access disabled for mass production.

図4.11 JTAG と SD ブートの設定値を確認する

設定をリセットするには --reset オプションを付けて abos-ctrl installer-setting コマンドを実行します。

[armadillo /]# abos-ctrl installer-setting --reset
cleaned up all settings.

図4.12 JTAG と SD ブートの設定値をリセットする


	JTAG および SD ブートを無効化したインストールディスクで初期化した Armadillo は、再びこれらを有効に戻すことはできなくなります。そのため不具合発生時にこれらのインターフェースを使用した不具合解析ができなくなる点に留意してください。

4.4.9.2. U-Boot のコマンドプロンプトを無効化する

コマンドラインから生成する場合は、 Armadillo の U-Boot のコマンドプロンプトを無効にするインストールディスクイメージを生成することができます。 U-Boot のコマンドプロンプトを無効にするには abos-ctrl installer-setting コマンドを実行します。このコマンドにより、SD ブート時の U-Boot のコマンドプロンプトも同時に無効化されます。


	生成したインストールディスクを使用して初期化した Armadillo の U-Boot のコマンドプロンプトを無効にする設定であり、開発用の Armadillo の U-Boot のコマンドプロンプトが無効になることはありません。

[armadillo /]# abos-ctrl installer-setting
:(省略)
Would you like to disable boot prompt in the installer ? [y/N] 
y
Boot prompt disabled setting for production Armadillo has been configured.

図4.13 U-Boot のコマンドプロンプトを無効化する

U-Boot のコマンドプロンプトを無効化する場合は y を入力します。無効化しない場合は何も入力せず Enter キーを押してください。

現在の設定値を確認するには abos-ctrl check-secure コマンドを実行します。 disabled の場合は無効化する設定になっています。

[armadillo /]# abos-ctrl check-secure
:(省略)
- boot prompt disabled for mass production.

図4.14 U-Boot のコマンドプロンプトの設定値を確認する

設定をリセットするには図4.12「JTAG と SD ブートの設定値をリセットする」と同様に、--reset オプションを付けて abos-ctrl installer-setting コマンドを実行してください。

4.4.9.3. インストールディスクイメージを生成する

abos-ctrl make-installer コマンドを実行して、microSDカードにインストールディスクイメージを生成します。

[armadillo /]# abos-ctrl make-installer
Checking if /dev/mmcblk1 can be used safely...
It looks like your SD card does not contain an installer image
Download baseos-6e-installer-latest.zip image from armadillo.atmark-techno.com (~170M) ? [y/N] 
WARNING: it will overwrite your SD card!!
y
Downloading and extracting image to SD card...
Finished writing baseos-6e-installer-[VERSION].img, verifying written content...

Would you like to create a windows partition?
That partition would only be used for customization script at the end of
install, leave at 0 to skip creating it.
Custom partition size (MB, [0] or 16 - 29014): 500 
Checking and growing installer main partition
Trying to install mkfs.exfat (exfatprogs) in memory from internet
fetch https://download.atmark-techno.com/alpine/v3.19/atmark/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/armv7/APKINDEX.tar.gz
(1/1) Installing exfatprogs (1.2.2-r0)
Executing busybox-1.36.1-r15.trigger
OK: 148 MiB in 197 packages
exfatprogs version : 1.2.2
Creating exFAT filesystem(/dev/mmcblk1p2, cluster size=131072)

Writing volume boot record: done
Writing backup volume boot record: done
Fat table creation: done
Allocation bitmap creation: done
Upcase table creation: done
Writing root directory entry: done
Synchronizing...

exFAT format complete!
Resize device id 1 (/dev/mmcblk1p1) from 520.00MiB to max
Installer will disable JTAG access
Installer will disable SD boot after installation
Installer will disable uboot prompt
Environment OK, copy 1
Copying boot image
Copying rootfs
Copying appfs
At subvol app/snapshots/volumes
At subvol app/snapshots/boot_volumes
At subvol app/snapshots/boot_containers_storage
Cleaning up and syncing changes to disk...
Installer updated successfully!

図4.15 開発完了後のシステムをインストールディスクイメージにする

	`y` を入力し Enter を押下します。
	インストールディスク内にインストールログを保存したい場合など、自由に使用できる第2パーティションを指定したサイズで作成します。サイズを入力し Enter を押下します。詳細は「インストール時に任意のシェルスクリプトを実行する」を参照してください。

「Installer updated successfully!」と表示されれば、正常にmicroSDカードにインストールディスクイメージを書き込むことができています。 ArmadilloからmicroSDカードを抜去してください。

セキュリティーの観点から、インストールディスクによるインストール実行時に以下のファイルを再生成しております：

/etc/machine-id (ランダムな個体識別番号)
/etc/abos_web/tls (ABOS-Web の https 鍵）
/etc/ssh/ssh_host_*key* (ssh サーバーの鍵。なければ生成しません）ABOS 3.19.1-at.3 以降

他のファイルを個体毎に変更したい場合は「インストール時に任意のシェルスクリプトを実行する」で対応してください。

4.4.9.4. インストール時に任意のシェルスクリプトを実行する

作成したインストールディスクの所定の場所に、 installer_overrides.sh というファイル名でシェルスクリプトを配置することで、インストール処理の前後で任意の処理を行なうことができます。

installer_overrides.sh に記載された表4.2「インストール中に実行される関数」に示す3つの名前の関数のみが、それぞれ特定のタイミングで実行されます。

表4.2 インストール中に実行される関数

関数名	備考
preinstall	インストール中、eMMCのパーティションが分割される前に実行されます。
postinstall	send_log関数を除く全てのインストール処理の後に実行されます。
send_log	全てのインストール処理が完了した後に実行されます。指定した場所にインストールログを保存できます。

installer_overrides.sh を書くためのサンプルとして、インストールディスクイメージの第1パーティション及び、「開発したシステムをインストールディスクにする」で作成したのであれば第2パーティション直下に installer_overrides.sh.sample を用意してあります。このサンプルをコピーして編集するなどして、行ないたい処理を記述してください。

作成した installer_overrides.sh は、インストールディスクの第1パーティション(ラベル名は"rootfs_0")か、「開発したシステムをインストールディスクにする」で作成したのであれば第2パーティション(ラベル名は"INST_DATA")の直下に配置することで実行されます。両方に配置した場合は、第2パーティションに配置した記述が適用されます。

インストールディスクの第1パーティションはbtrfs、第2パーティションはexfatでフォーマットされているため、第2パーティションのみWindows PCでもマウントして読み書きすることができます。

製造担当者が installer_overrides.sh を記述する場合に、仮にWindows PCしか作業環境がない場合でも、第2パーティションを作成しておくことで作業を行なうことができるというメリットもあります。

これを利用することで、複数台のArmadilloに対してそれぞれに異なる固定IPアドレスを設定したり、各種クラウドへの接続鍵などを個体ごとに配置したりしたいなど、個体ごとに異なる設定を行なうなど柔軟な製造を行なうことも可能です。以下ではこの機能を利用して、個体ごとに異なる固定IPアドレスを設定する方法と、インストール実行時のログを保存する方法を紹介します。

これらを必要としない場合は「インストールの実行」に進んでください。

4.4.9.5. 個体ごとに異なる固定IPアドレスを設定する

インストール時に任意のシェルスクリプトを実行できる機能を利用して、複数のArmadilloに対して異なる固定IPアドレスを割り当てる例を紹介します。

INST_DATA 内の installer_overrides.sh.sample と ip_config.txt.sample は個体ごとに異なるIPアドレスを割り振る処理を行なうサンプルファイルです。それぞれ installer_overrides.sh と ip_config.txt にリネームすることで、 ip_config.txt に記載されている条件の通りに個体ごとに異なる固定IPアドレスを設定することができます。全てをここでは説明しませんので、詳細はそれぞれのファイル内の記述も参照してください。

今回はそれぞれのファイルの内容は変更せず使用します。サンプルそのままですが、 ip_config.txt の内容を図4.16「ip_config.txtの内容」に示します。

# mandatory first IP to allocate, inclusive
START_IP=10.3.4.2 

# mandatory last IP to allocate, inclusive
END_IP=10.3.4.249 

# netmask to use for the IP, default to 24
#NETMASK=24 

# Gateway to configure
# not set if absent
GATEWAY=10.3.4.1 

# DNS servers to configure if present, semi-colon separated list
# not set if absent
DNS="1.1.1.1;8.8.8.8" 

# interface to configure, default to eth0
#IFACE=eth0

図4.16 ip_config.txtの内容

	このインストールディスクで割り振るIPアドレスの範囲の始まりを指定します。
	このインストールディスクで割り振るIPアドレスの範囲の終わりを指定します。
	ネットマスクを指定します。指定しない場合は24になります。デフォルトでコメントアウトされています。
	ゲートウェイアドレスを指定します。
	DNSアドレスを指定します。セミコロンで区切ることでセカンダリアドレスも指定できます。
	IPアドレスの設定を行なうインターフェースを指定します。指定しない場合はeth0になります。デフォルトでコメントアウトされています。


	インストール作業の並列化の為に、複数枚のインストールディスクで固定IPアドレスを割り振る場合は、それぞれのインストールディスクが割り振るIPアドレスの範囲が被らないように `ip_config.txt` を設定してください。

これらのファイルを配置したインストールディスクでインストールを実行したArmadilloが、正しく設定できていることを確認します。

[armadillo /]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    inet 10.3.4.2/24 brd 10.3.4.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 ffff::ffff:ffff:ffff:ffff/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

図4.17 IPアドレスの確認

また、サンプルスクリプトをそのまま使用すると、インストールディスクの第2パーティションに allocated_ips.csv というファイルが生成されます。このファイルには、このインストールディスクを使用してIPアドレスの設定を行なった個体のシリアル番号、MACアドレス、設定したIPアドレスが追記されていきます。

SN,MAC,IP
00C700010009,00:11:22:33:44:55,10.3.4.2

図4.18 allocated_ips.csvの内容


	2台目以降のArmadilloにこのインストールディスクでIPアドレスの設定を行なう際に、 `allocated_ips.csv` を参照して次に割り振るIPアドレスを決めますので、誤って削除しないように注意してください。

4.4.9.6. インストール実行時のログを保存する

installer_overrides.sh 内の send_log 関数は、インストール処理の最後に実行されます。インストールしたルートファイルシステムやファームウェアのチェックサムなどの情報が記録されたログファイルのパスが LOG_FILE に入るため、この関数内でインストールディスクの第2パーティションに保存したり、外部のログサーバにアップロードしたりすることが可能です。

図4.19「インストールログを保存する」は、インストールディスクの第2パーティションにインストールログを保存する場合の send_log 実装例です。

send_log() {
        : "This function is called after aggregating logs for archival"
        local LOG_FILE="$1"

        if [ -n "$USER_MOUNT" ]; then
                        mount /dev/mmcblk1p2 "$USER_MOUNT" 
                        cp $LOG_FILE $USER_MOUNT/${SN}_install.log 
                        umount "$USER_MOUNT" 
        fi
}

図4.19 インストールログを保存する

	send_log関数中では、SDカードの第2パーティション(/dev/mmcblk1p2)はマウントされていないのでマウントします。
	ログファイルを `<シリアル番号>_install.log` というファイル名で第2パーティションにコピーします。
	第2パーティションをアンマウントします。

これらの変更を行なったインストールディスクでインストールを実行した後に、インストールディスクをPCなどに接続して正しくログを保存できていることを確認してください。保存したログファイルの中身の例を図4.20「インストールログの中身」に示します。

RESULT:OK
abos-ctrl make-rootfs on Tue Jun 21 17:57:07 JST 2022 4194304 6b8250df711de66b
abos-ctrl make-rootfs on Tue Jun 21 17:57:24 JST 2022 314572800 58a9b6664158943e
firm 8e9d83d1ba4db65d
appfs 5108 1fa2cbaff09c2dbf

図4.20 インストールログの中身

4.4.10. インストールの実行

前章までの手順で作成したインストールディスクを、開発に使用した Armadillo 以外の Armadillo に対して適用します。

クローン先の Armadillo の eMMC 内のデータは上書きされて消えるため、必要なデータは予めバックアップを取っておいてください。

「インストールディスクを使用する」を参照して、クローン先の Armadillo にインストールディスクを適用してください。

「JTAG と SD ブートを無効化する」で JTAG と SD ブートを無効化した場合は、インストールを行った Armadillo の JTAG と SD ブートが無効化されています。

ここまで完了したら、「イメージ書き込み後の動作確認」に進んでください。

4.5. SWUpdate を用いてイメージ書き込みする

4.5.1. SWU イメージの準備

ここでは、sample-container という名称のコンテナの開発を終了したとします。コンテナアーカイブの作成方法は「コンテナの自動作成やアップデート」を参照ください。

sample-container-v1.0.0.tar (動かしたいアプリケーションを含むコンテナイメージアーカイブ)
sample-container.conf (コンテナ自動実行用設定ファイル)

これらのファイルを /home/atmark/mkswu/sample-container ディレクトリを作成して配置した例を記載します。

[ATDE ~/mkswu/sample-container]$ ls
sample-container-v1.0.0.tar  sample-container.conf

図4.21 Armadilloに書き込みたいソフトウェアをATDEに配置

4.5.2. descファイルの記述

SWUpdate実行時に、「SWU イメージの準備」で挙げたファイルをArmadilloに書き込むような SWU イメージを生成します。

SWUイメージを作成するためには、SWUpdate時に実行する処理等を示したdescファイルを記述し、そのdescファイルを入力として mkswu コマンドを実行することで、SWUイメージが出来上がります。

[ATDE ~/mkswu/sample-container]$ cat sample-container.desc
swdesc_option component=sample-container
swdesc_option version=1
swdesc_option POST_ACTION=poweroff 

swdesc_embed_container "sample-container-v1.0.0.tar" 
swdesc_files --extra-os --dest /etc/atmark/containers/ "sample-container.conf"

図4.22 descファイルの記述例

	SWUpdate完了後に電源を切るように設定します。
	コンテナイメージファイルをSWUイメージに組み込み、Armadilloに転送します。
	コンテナ起動設定ファイルをArmadilloに転送します。

ここまで完了したら、「イメージ書き込み後の動作確認」に進んでください。 desc ファイルの詳細な書式については、「mkswu の .desc ファイルを編集する」を参照してください。また、作成されたSWUイメージの内容を確認したい場合は、「SWU イメージの内容の確認」を参照してください。

4.6. イメージ書き込み後の動作確認

「インストールディスクを用いてイメージ書き込みする」で作成したインストールディスクを使用してインストール、または「SWUpdate を用いてイメージ書き込みする」にて SWUpdate によってイメージ書き込みを行った後には、イメージが書き込まれた Armadillo が正しく動作するか、実際に動かして確認してみます。

再度電源を投入して、期待したアプリケーションが動作することを確認してください。

ここまで完了したならば、量産時のイメージ書き込みは完了です。


第3章開発編	PDF version	第5章運用編