量産編

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

4.1. 概略

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

images/armadillo-manufacturing-flow.png

図4.1 Armadillo 量産時の概略図


4.1.1. Armadillo Twin を契約する

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

4.1.2. リードタイムと在庫

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

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

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

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

  • ソフトウェア書き込み

    • Armadillo Base OS やアプリケーションコンテナイメージの書き込み
    • 設定ファイルの書き込み
  • 別部品の組み立て

    • SD カード/ SIM カード/ RTC バックアップ電池等の接続
    • 拡張基板接続やセンサー・外部機器の接続
    • お客様専用筐体への組み込み
  • 検査

    • Armadillo の受け入れ検査
    • 組み立て後の通電電検・機能検査
    • 目視検査
  • 梱包作業
  • 出荷作業

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

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

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

images/bto-scope.png

図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カード内にシェルスクリプトを配置するだけなので製造担当者にも編集しやすい
  • microSD カードを使用せずに実行できるため、Armadilloのケースを開ける必要がない
  • 動いているシステムをそのままインストールディスクにするため、出荷時の標準イメージから手動で同じ環境を構築する手順が残らない

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をアップデートする


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

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

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

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

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

[armadillo /]# persist_file /etc/shadow 7

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


1

rootユーザのパスワードを変更します。

2

新しいrootユーザ用パスワードを入力します。

3

再度新しいrootユーザ用パスワードを入力します。

4

atmarkユーザのパスワードを変更します。

5

新しいatmarkユーザ用パスワードを入力します。

6

再度新しいatmarkユーザ用パスワードを入力します。

7

パスワードの変更を永続化させます。

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 1
[armadillo /]# podman rm 3ca118e9473b 2
[armadillo /]# podman ps -a
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES 3

1

コンテナの名前で削除するコンテナを指定しています。

2

コンテナのIDで削除するコンテナを指定しています。

3

何も表示されず、全てのコンテナが削除されたことを確認します

以下に示すコマンドを実行することでコンテナイメージの一覧を取得できます。 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 1
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 2
REPOSITORY                 TAG         IMAGE ID      CREATED       SIZE
localhost/abos-dev-guide   v1.0.0      2394ea5f177f  5 hours ago   932 MB

1

C を入力しEnterを押下します。

2

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

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

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

  • VSCode を使用して生成

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

  • コマンドラインから生成

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

4.4.7. VSCode を使用して生成する

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

  • VSCode を使用したインストールディスク作成用 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. VSCode を使用したインストールディスク作成用 SWU の生成

VSCode の左ペインの [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: 1
/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 生成時のログ


1

パスワードの入力を求められますので、初期化用 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 カードに書き込むことでインストールディスクを作成することができます。動作確認については「インストールディスクの動作確認を行う」をご参照ください。 これで、VSCode を使用してインストールディスクを生成する方法については終了です。

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. コマンドラインから生成する

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

[armadillo /]# abos-ctrl make-installer
An installer system is already available on SD card. Use it? [Y/n] 1

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] - 30026): 500 2
Checking and growing installer main partition
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
The operation has completed successfully.
Trying to install mkfs.exfat (exfatprogs) in memory from internet
fetch http://pc-gtr.atmark.tech/products/yakushima/99_www/download/alpine/v3.16/atmark/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/aarch64/APKINDEX.tar.gz
(1/1) Installing exfatprogs (1.1.3-r0)
Executing busybox-1.35.0-r14.trigger
OK: 159 MiB in 215 packages
exfatprogs version : 1.1.3
Creating exFAT filesystem(/dev/mmcblk1p2, cluster size=32768)

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 400.00MiB to max
Currently booted on /dev/mmcblk2p1
Copying boot image
Copying rootfs
314572800 bytes (315 MB, 300 MiB) copied, 11 s, 28.5 MB/s
300+0 records in
300+0 records out
314572800 bytes (315 MB, 300 MiB) copied, 11.0192 s, 28.5 MB/s
Copying /opt/firmware filesystem
Copying appfs
At subvol app/snapshots/volumes
At subvol app/snapshots/boot_volumes
At subvol app/snapshots/boot_containers_storage
Cleaning up and syncing changes to disk...
Installer updated successfully!

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


1

Enterキーを押下します。

2

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

「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.1. インストール時に任意のシェルスクリプトを実行する

作成したインストールディスクの所定の場所に、 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.2. 個体ごとに異なる固定IPアドレスを設定する

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

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

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

# mandatory first IP to allocate, inclusive
START_IP=10.3.4.2 1

# mandatory last IP to allocate, inclusive
END_IP=10.3.4.249 2

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

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

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

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

図4.11 ip_config.txtの内容


1

このインストールディスクで割り振るIPアドレスの範囲の始まりを指定します。

2

このインストールディスクで割り振るIPアドレスの範囲の終わりを指定します。

3

ネットマスクを指定します。指定しない場合は24になります。デフォルトでコメントアウトされています。

4

ゲートウェイアドレスを指定します。

5

DNSアドレスを指定します。セミコロンで区切ることでセカンダリアドレスも指定できます。

6

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.12 IPアドレスの確認


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

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

図4.13 allocated_ips.csvの内容


[警告]

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

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

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

図4.14「インストールログを保存する」は、インストールディスクの第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" 1
                        cp $LOG_FILE $USER_MOUNT/${SN}_install.log 2
                        umount "$USER_MOUNT" 3
        fi
}

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


1

send_log関数中では、SDカードの第2パーティション(/dev/mmcblk1p2)はマウントされていないのでマウントします。

2

ログファイルを <シリアル番号>_install.log というファイル名で第2パーティションにコピーします。

3

第2パーティションをアンマウントします。

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

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.15 インストールログの中身


4.4.10. インストールの実行

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

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

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

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

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

4.5.1. SWU イメージの準備

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

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

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

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

図4.16 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 1

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

図4.17 descファイルの記述例


1

SWUpdate完了後に電源を切るように設定します。

2

コンテナイメージファイルをswuイメージに組み込み、Armadilloに転送します。

3

コンテナ起動設定ファイルをArmadilloに転送します。

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

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

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

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

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