Armadilloフォーラム

実機の環境を複製したSDブートディスクの作成

s.kurachi

2024年4月4日 8時47分

お世話になっております。

Armadillo-IoT G4の製品マニュアル「9.5. SDブートの活用」に、ビルドツールを使用したブートディスクの作成方法があります。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…

実機のeMMC上に構築した環境を複製したブートディスクイメージを作製することは可能でしょうか?
可能であれば、そのやり方についてご教示いただけないでしょうか。

コメント

at_dominique.m…

2024年4月4日 10時25分

s.kurachiさん、

お世話になっています、
マルティネです。

> Armadillo-IoT G4の製品マニュアル「9.5. SDブートの活用」に、ビルドツールを使用したブートディスクの作成方法があります。
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
>
> 実機のeMMC上に構築した環境を複製したブートディスクイメージを作製することは可能でしょうか?

eMMC上で起動しているシステムを SD カードにコピーして、SD から起動できるようにしたいですね。
すみません、こういう手順は用意していません。

技術の面では確かに可能ですが、「頑張ればできます」程度の話で、かなり複雑な手順になります。

もしよろしければ SD ブートを活用したい理由を教えていただけますでしょうか?
(例えば appfs が小さいという問題でしたら、SD で大きくすることも可能ですので、場合によっては別の方向で案内できるかもしれません。)

よろしくお願いします。

いいえ、SDカードの由来の問題がある場合メーカー解析ができず
原因が特定できなかったり、逆に解析可能で信頼性の高い工業向け
SDを使うことを強いることもできないため、
開発時以外はブートディスクとして信頼性を確保できるeMMC
からのブートを推奨しています。そのため、開発時の作業環境
としての利用を除いてSDカードを開発後のメインの起動ディスク
として使うことを推奨するような機能を提供していません。

eMMCではなくSDを利用する意図を教えてもらえますか?
例えばストレージとしての容量増を狙うのであれば、OS含め
主要部をeMMC、システムの起動や動作に影響しないレベルの
データ保存先をSDで使うパターンもアドバイスできると思います。

尚、開発完了した環境を複製してeMMCから起動するようにできる
SDカードを使う(SDカードから1度起動してeMMCをセットアップし、次回以降はSD
カードを利用しない)以下の手順が推奨です。
9.6.1.2. 開発が完了した Armadillo をクローンするインストールディスクの作成

ご返信ありがとうございます。

> eMMCではなくSDを利用する意図を教えてもらえますか?
意図としましてはeMMC故障時の復旧を迅速に行えるようにしたいためです。

弊社ではArmadilloを組み込んだ測定器を全国各地に配置し、遠隔から監視をしながら測定をし続けるということを行っております。
そのためArmadilloが故障した場合は現地に修理しに行くことになります。
従来の測定器にはArmadillo-Iot G3を使用させていただいております。
G3において、稼働中にeMMCが故障し動作が停止するということが何度も生じております。
以前に投稿させていただきました以下の内容です。
https://armadillo.atmark-techno.com/forum/armadillo/10234

こちら、故障の原因については分からないので、現在は故障が発生した場合に毎回ボード本体を交換しております。
金額面でのコストや、現地での作業時間を考えると、SDカードのみの交換で復旧したいという意図です。

> 開発時以外はブートディスクとして信頼性を確保できるeMMCからのブートを推奨しています。
承知しました。何か、eMMC故障時に動作を保証するような仕組みを構築することは難しいでしょうか?

> こちら、故障の原因については分からないので、現在は故障が発生した場合に毎回ボード本体を交換しております。
> 金額面でのコストや、現地での作業時間を考えると、SDカードのみの交換で復旧したいという意図です。

G3にてご不便おかけして申し訳ございません。
意図は理解いたしました。

> > 開発時以外はブートディスクとして信頼性を確保できるeMMCからのブートを推奨しています。
> 承知しました。何か、eMMC故障時に動作を保証するような仕組みを構築することは難しいでしょうか?

現時点で後述の二重化機構の違いから手動で簡単な方法というものが無く、
できればeMMCを使っていただきたいです。
しかし、今回頂いたようにSDカード自体の故障を割り切って、交換する
スキームも運用次第では有るということで、設計できないか検討してみます。

やや製品性と合わない利用方法になりそうなので、リリースのお約束は
できないのですがご容赦ください。更新情報はこのスレッドに記載します。

尚、G3と異なりABOS採用製品世代では、eMMC上においてbootloader含め
データの二重化し、WDTの発生による起動不能を検知するとロールバックする
機構を搭載することで冗長化した仕様に改善しています。
(これによってG3に比べデータ破損等による起動不能については信頼性が向上しています)

一方で、SDカードは構造上データ読み出しをHW的に切り替える機構持たないため、
bootloaderの根本的な二重化ができません。あわせて、SDカード自体の故障について
当社では解析ができず、この2点でSDカードを開発時以外で起動ディスクにする
ための自動化ツールは存在していないというのが現状です。

マニュアルでサポートしているのは、SDブートでおおらかに開発して、必要なパッケージ等
整理の上eMMCに移行するinstall-diskのを作るという想定でした。

at_dominique.m…

2024年4月12日 17時39分

マルティネです。

> やや製品性と合わない利用方法になりそうなので、リリースのお約束は
> できないのですがご容赦ください。更新情報はこのスレッドに記載します。

ツールとして作るかは別として、手動で実施する方法を考えてみました。

この手順で eMMC を全部コピーしますので、eMMC より大きい SD カードが必要です(10GB 以上)

# 第1パーティションを必ず最新にします
armadillo:~# abos-ctrl rollback-clone
 
# eMMC をまるごとコピーします
armadillo:~# dd if=/dev/mmcblk2 of=/dev/mmcblk1 bs=1M oflag=direct
 
# ユーザースペースを sd の第1パーティションに切り替えます
armadillo:~# mount /dev/mmcblk1p1 /mnt
armadillo:~# sed -i -e 's/mmcblk2p/mmcblk1p/g' -e 's/boot_[0-1]/boot_0/' -e 's/.*mmcblk2gp/# &/' /mnt/etc/fstab
armadillo:~# sed -i -e 's/mmcblk2boot[0-1]/mmcblk1/' /mnt/etc/fw_env.config
armadillo:~# umount /mnt
 
# ブートローダーをコピーして、環境変数をクリアします。
armadillo:~# dd if=/dev/mmcblk2boot0 of=/dev/mmcblk1 bs=4M count=1 seek=$((32*1024)) oflag=seek_bytes
armadillo:~# dd if=/dev/zero of=/dev/mmcblk1 bs=24K count=1 seek=$((0x3fa000)) oflag=seek_bytes

以上、JP1 をショットして SD カードで起動すると eMMC と同じ環境が起動しているはずです。

簡単な動作確認しか行ってませんので何か問題あれば聞いてください。

よろしくお願いします

> マルティネです。
>
> > やや製品性と合わない利用方法になりそうなので、リリースのお約束は
> > できないのですがご容赦ください。更新情報はこのスレッドに記載します。
>
> ツールとして作るかは別として、手動で実施する方法を考えてみました。
>
> この手順で eMMC を全部コピーしますので、eMMC より大きい SD カードが必要です(10GB 以上)

SDブートの方法についてありがとうございます。
示していただいた方法で起動することが確認できました。

> G3にてご不便おかけして申し訳ございません。
> 意図は理解いたしました。

> 現時点で後述の二重化機構の違いから手動で簡単な方法というものが無く、
> できればeMMCを使っていただきたいです。
> しかし、今回頂いたようにSDカード自体の故障を割り切って、交換する
> スキームも運用次第では有るということで、設計できないか検討してみます。
>
> やや製品性と合わない利用方法になりそうなので、リリースのお約束は
> できないのですがご容赦ください。更新情報はこのスレッドに記載します。

ありがとうございます。
お手数をおかけします。

> 尚、G3と異なりABOS採用製品世代では、eMMC上においてbootloader含め
> データの二重化し、WDTの発生による起動不能を検知するとロールバックする
> 機構を搭載することで冗長化した仕様に改善しています。
> (これによってG3に比べデータ破損等による起動不能については信頼性が向上しています)
>
> 一方で、SDカードは構造上データ読み出しをHW的に切り替える機構持たないため、
> bootloaderの根本的な二重化ができません。あわせて、SDカード自体の故障について
> 当社では解析ができず、この2点でSDカードを開発時以外で起動ディスクにする
> ための自動化ツールは存在していないというのが現状です。

冗長化のお話を伺って、無理にSDカードから起動するよりもeMMC起動のほうが信頼性が高いように感じました。
元々、製品の仕様の範囲の中でベストな方法を検討しておりました。
迅速に復旧作業を行えることに越したことはないのですが、そもそも故障が生じない方が弊社としてもありがたいです。

> 冗長化のお話を伺って、無理にSDカードから起動するよりもeMMC起動のほうが信頼性が高いように感じました。
> 元々、製品の仕様の範囲の中でベストな方法を検討しておりました。
> 迅速に復旧作業を行えることに越したことはないのですが、そもそも故障が生じない方が弊社としてもありがたいです。

元々ご不便をおかけしているところ、信頼いただくのは
難しいと思うのですが、検討いただきありがとうございます。

取り急ぎ、もしSDを使うパターンを継続する場合のために、
上の返信でマルティネより原理的な複製手順を記載させていただきました。