kazumori88
2025年2月27日 11時38分
==========
製品型番：Armadillo-640
Debian/ABOSバージョン：Debian_buster
カーネルバージョン：4.14-at36
==========
お世話になります。現在、Debian上で動作しているアプリをABOSに移行するかどうか、検討中です。
＜質問＞
動作しているアプリは自動起動時に最初に起動される⓵シェルスクリプトと②Pythonモジュール17個で構成された一つのアプリです。
この場合、一つのコンテナに入れるのでしょうか？Pythonとシェルスクリプト混在の場合のコンテナ作成方法をご教授いただきたいと思います。
コメント
kazumori88
> 太田です。
>
> 特別な理由がない限り、アプリケーションを１つのコンテナの中で動かして問題ないと思います。
>
> Armadillo Base OS では VS Code で拡張機能として ABOSDE という開発環境を提供しています。
> ABOSDE では shell や python , flutter などによる開発をサポートするためにサンプルプログラムをプロジェクトとして提供しています。
>
> 今回の場合は、python プロジェクトを使用するのが適切かと思います。
>
> どうぞよろしくお願いいたします。
太田 様
早速の回答、ありがとうございます。
試してみます。
kazumori88
> > 太田です。
> >
> > 特別な理由がない限り、アプリケーションを１つのコンテナの中で動かして問題ないと思います。
> >
> > Armadillo Base OS では VS Code で拡張機能として ABOSDE という開発環境を提供しています。
> > ABOSDE では shell や python , flutter などによる開発をサポートするためにサンプルプログラムをプロジェクトとして提供しています。
> >
> > 今回の場合は、python プロジェクトを使用するのが適切かと思います。
> >
> > どうぞよろしくお願いいたします。
> 太田 様
> 早速の回答、ありがとうございます。
> 試してみます。
>
>
お世話になります。
以下を実行しましたが、ネットワーク上にarmadilloが見つからないという状況です。
１．Armadillo-640の製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応の初期化インストールディスクの作成を実行
利用したイメージは aseos-600-installer-3.21.3-at.1-console-uart3.img です。
２．マニュアル 3.1.4.2. インストールディスクを使用するに従い、電源を投入しました。（armadilloにはdebian-busterがインストールされている）
赤LEDと緑LEDが点灯し、赤LEDが消灯したあと、緑LEDは点灯したままで、電源も切れませんでした。マニュアル記載の「1 分程度で eMMC のソフトウェアの初期化が完了し、電源が切れます(LED が消灯)。」の状態にはなりませんでした。
３．いったん、電源を落とし、JP1をopenにして、電源を入れ、LANケーブルを接続し、VSCODEから接続されているarmadilloの検索を行いましたが、見つかりませんでした。
何か、確認する方法があれば、ご教授ください。
at_satoshi.ohta
太田です。
初期化インストールがうまくできていない可能性があります。
シリアルコンソールで Armadillo のターミナルに入った後、同様に初期化インストールを行うと、起動時のログが出力されてインストール状況を確認できます。
シリアルコンソールは minicom を使用した方法を製品マニュアルに記載しておりますので、お試しいただけますでしょうか？
https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
よろしくお願い致します。
kazumori88
> > > 太田です。
> > >
> > > 特別な理由がない限り、アプリケーションを１つのコンテナの中で動かして問題ないと思います。
> > >
> > > Armadillo Base OS では VS Code で拡張機能として ABOSDE という開発環境を提供しています。
> > > ABOSDE では shell や python , flutter などによる開発をサポートするためにサンプルプログラムをプロジェクトとして提供しています。
> > >
> > > 今回の場合は、python プロジェクトを使用するのが適切かと思います。
> > >
> > > どうぞよろしくお願いいたします。
> > 太田 様
> > 早速の回答、ありがとうございます。
> > 試してみます。
> >
> >
> お世話になります。
> 以下を実行しましたが、ネットワーク上にarmadilloが見つからないという状況です。
> １．Armadillo-640の製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応の初期化インストールディスクの作成を実行
> 利用したイメージは aseos-600-installer-3.21.3-at.1-console-uart3.img です。
> ２．マニュアル 3.1.4.2. インストールディスクを使用するに従い、電源を投入しました。（armadilloにはdebian-busterがインストールされている）
> 赤LEDと緑LEDが点灯し、赤LEDが消灯したあと、緑LEDは点灯したままで、電源も切れませんでした。マニュアル記載の「1 分程度で eMMC のソフトウェアの初期化が完了し、電源が切れます(LED が消灯)。」の状態にはなりませんでした。
> ３．いったん、電源を落とし、JP1をopenにして、電源を入れ、LANケーブルを接続し、VSCODEから接続されているarmadilloの検索を行いましたが、見つかりませんでした。
> 何か、確認する方法があれば、ご教授ください。
>
>
| ファイル | ファイルの説明 |
|---|---|
| bootLog_debian_abos書き換わっていない.txt | debianが搭載されているarmadilloにbaseosのインストールdiskで書き替えようとしたときのLOGです。 |
kazumori88
> > > > 太田です。
> > > >
> > > > 特別な理由がない限り、アプリケーションを１つのコンテナの中で動かして問題ないと思います。
> > > >
> > > > Armadillo Base OS では VS Code で拡張機能として ABOSDE という開発環境を提供しています。
> > > > ABOSDE では shell や python , flutter などによる開発をサポートするためにサンプルプログラムをプロジェクトとして提供しています。
> > > >
> > > > 今回の場合は、python プロジェクトを使用するのが適切かと思います。
> > > >
> > > > どうぞよろしくお願いいたします。
> > > 太田 様
> > > 早速の回答、ありがとうございます。
> > > 試してみます。
> > >
> > >
> > お世話になります。
> > 以下を実行しましたが、ネットワーク上にarmadilloが見つからないという状況です。
> > １．Armadillo-640の製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応の初期化インストールディスクの作成を実行
> > 利用したイメージは aseos-600-installer-3.21.3-at.1-console-uart3.img です。
> > ２．マニュアル 3.1.4.2. インストールディスクを使用するに従い、電源を投入しました。（armadilloにはdebian-busterがインストールされている）
> > 赤LEDと緑LEDが点灯し、赤LEDが消灯したあと、緑LEDは点灯したままで、電源も切れませんでした。マニュアル記載の「1 分程度で eMMC のソフトウェアの初期化が完了し、電源が切れます(LED が消灯)。」の状態にはなりませんでした。
> > ３．いったん、電源を落とし、JP1をopenにして、電源を入れ、LANケーブルを接続し、VSCODEから接続されているarmadilloの検索を行いましたが、見つかりませんでした。
> > 何か、確認する方法があれば、ご教授ください。
> >
> >
>
太田 様
お世話になります。
添付したLOGではU-BOOTがABOSであれば、U-Boot 2020.04-at15 (Jun 09 2023 - 18:46:32 +0900)になるはずが、U-Boot 2018.03-at15+ (Jun 25 2024 - 18:07:08 +0900)になっています。これは、Loading Environment from MMC... *** Warning - bad CRC, using default environmentのせいでしょうか？
よろしく、お願いします。
at_satoshi.ohta
kazumori88
kazumori88
> > 太田です。
> >
> > １点確認させて頂きたいのですが、SDブートするためには JP1 と JP2 を両方ともショートさせる（ジャンパーソケットをつける）必要があります。
> > その点はお間違いないでしょうか？
> はい、両方、ショートさせています。
お世話になります。追記です。
作成したSDカードは/DEV/SDCなのでlsblkで確認すると、以下のようになっています。
sdc 8:32 1 3.7G 0 disk
└─sdc1 8:33 1 394M 0 part /media/atmark/rootfs_0
というようにrootfs_0というフォルダに集約されているのですが、いいのでしょうか？
マニュアル通りにunzip,ddコマンドを実施したつもりなのですが、
at_satoshi.ohta
太田です。
> というようにrootfs_0というフォルダに集約されているのですが、いいのでしょうか？
こちらはこれで問題ないと思います。
SDカードを Armadillo が認識しているかどうか確認するために、ABOSの初期化インストールディスクイメージが書き込まれた SD カードを挿入した状態で、eMMC でDebianを起動して以下のコマンドを実行してもらってもいいでしょうか？
root@armadillo:~# fdisk -l /dev/mmcblk1
SD カードは /dev/mmcblk1 で認識するはずです。
その上で一応データが壊れていないか確認するために以下のコマンドの出力を教えていただいてもよろしいでしょうか？
root@armadillo:~# dd if=/dev/mmcblk1p1 bs=1M iflag=count_bytes count=424673280 | md5sum
どうぞよろしくお願いいたします。
kazumori88
> 太田です。
>
> > というようにrootfs_0というフォルダに集約されているのですが、いいのでしょうか？
>
> こちらはこれで問題ないと思います。
> SDカードを Armadillo が認識しているかどうか確認するために、ABOSの初期化インストールディスクイメージが書き込まれた SD カードを挿入した状態で、eMMC でDebianを起動して以下のコマンドを実行してもらってもいいでしょうか？
>
> root@armadillo:~# fdisk -l /dev/mmcblk1 >
> SD カードは /dev/mmcblk1 で認識するはずです。
> その上で一応データが壊れていないか確認するために以下のコマンドの出力を教えていただいてもよろしいでしょうか？
>
> root@armadillo:~# dd if=/dev/mmcblk1p1 bs=1M iflag=count_bytes count=424673280 | md5sum >
> どうぞよろしくお願いいたします。
太田 様
VMのATDE9が起動しなくなり、先構築したから、確認します。
at_satoshi.ohta
kazumori88
> 太田です。
>
> 了解いたしました。
> また、上記のコマンド実行の他に、SDカードによっては相性が悪くSDブートがうまくいかないこともありえます。
> そのため、今使用しているSDカードとは別に、８GB以上の十分に容量の大きいSDカードにイメージを書き込んで試していただければ幸いです。
>
> どうぞよろしくお願いいたします。
太田 様
ATDE9拡張で手間取りました。
コンソール出力を添付します。
4GBのSDを使っていたので、これから手持ちの16GBのSDに書き込んでみます。
以上、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| root@armadillo~# fdisk -l devmmcblk.txt | fdisk 実行時のコンソール出力です。 |
| dd if=devmmcblk1p1 bs=1M iflag=coun.txt | ddコマンド実行時のコンソール出力です。 |
at_satoshi.ohta
太田です。
4 GB のSDカードをお使いなんですね。8 GB 以上と言いましたが、4 GB 以上 32 GB以下であれば、SDHCカードのはずですので問題ないかと思いますが、16 GB の SD カードで試していただければ幸いです。
fdisk の内容的には /dev/mmcblk1p1 も認識できていますね。
申し訳ありません。16 GB の SD カードを試したあとでお願いしたいのですが、
もう一度 Debian を起動して ABOS が書き込まれた SD カードを挿入して以下のコマンドを Armadillo 上で試していただければ幸いです。
上記で実行した dd コマンドの内容ではマウントしてしまうとハッシュの値が変更されるので確認方法としては不適切でした。
root@armadillo:~# dd if=/dev/mmcblk1 bs=1M iflag=count_bytes count=2 | md5sum
また、JP1 と JP2 にジャンパーを取り付けたにもかかわらず、SD ブートができない理由として可能性は低いかと思いますが、SoC 側で SD ブート無効の設定になっていることも考えられます。
U-boot のプロンプトに入って以下のコマンドの実行結果を教えてただければこちらで設定を確認しますので以下のコマンドを実行していただければ幸いです。
=> fuse read 0 5 結果の表示 => fuse read 0 6 結果の表示
なかなか問題を解決できず申し訳ありません。
どうぞよろしくお願いいたします。
kazumori88
> 太田です。
>
> 4 GB のSDカードをお使いなんですね。8 GB 以上と言いましたが、4 GB 以上 32 GB以下であれば、SDHCカードのはずですので問題ないかと思いますが、16 GB の SD カードで試していただければ幸いです。
>
> fdisk の内容的には /dev/mmcblk1p1 も認識できていますね。
> 申し訳ありません。16 GB の SD カードを試したあとでお願いしたいのですが、
> もう一度 Debian を起動して ABOS が書き込まれた SD カードを挿入して以下のコマンドを Armadillo 上で試していただければ幸いです。
> 上記で実行した dd コマンドの内容ではマウントしてしまうとハッシュの値が変更されるので確認方法としては不適切でした。
>
> root@armadillo:~# dd if=/dev/mmcblk1 bs=1M iflag=count_bytes count=2 | md5sum >
>
> また、JP1 と JP2 にジャンパーを取り付けたにもかかわらず、SD ブートができない理由として可能性は低いかと思いますが、SoC 側で SD ブート無効の設定になっていることも考えられます。
> U-boot のプロンプトに入って以下のコマンドの実行結果を教えてただければこちらで設定を確認しますので以下のコマンドを実行していただければ幸いです。
>
> => fuse read 0 5 > 結果の表示 > => fuse read 0 6 > 結果の表示 >
>
> なかなか問題を解決できず申し訳ありません。
> どうぞよろしくお願いいたします。
太田 様
こちらこそ、お世話になります。
以下、16GBのＳDをセットして、起動時の結果を添付します。
| ファイル | ファイルの説明 |
|---|---|
| fuse read 0 5.txt | fuse read 0 5とfuse read 6 0の結果ファイルです。 |
| dd if=devmmcblk1_1419.txt | ddコマンド時の結果ファイルです。 |
at_satoshi.ohta
太田です。
実行結果の添付をありがとうございます。
fuse read していただいた結果からSDブート無効化の設定はされていないですね。
dd の結果も問題ないように見えます。
改めて認識合わせのためにもう一度、SD ブートの手順を確認させてください。
ATDE 上で行う場合は以下のようになります。
1. 以下のURLから ATDE 上に baseos-600-installer-3.21.3-at.1-console-uart3.zip を持ってきます。
https://armadillo.atmark-techno.com/resources/software/armadillo-640/ab…
例えば、wget で持ってくるとしたら、
atmark@atde9:~$ wget https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image/baseos-600-installer-3.21.3-at.1-console-uart3.zip
2. baseos-600-installer-3.21.3-at.1-console-uart3.zip を展開します。
atmark@atde9:~$ unzip baseos-600-installer-3.21.3-at.1-console-uart3.zip
3. ATDE に SD カードを認識させます。
ATDE の [デバイス] > [USB] から SD カードに対応するものを探してチェックをつけてください。
4. /dev 下で SD カードを探します。
atmark@atde9:~$ mount ...省略 /dev/sdc1 on /media/atmark/rootfs_0 type btrfs (rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/,uhelper=udisks2)
私の環境では、/dev/sdc1 でした。
5. SD カードをアンマウントします。
atmark@atde9:~$ sudo umount /dev/sdc1
６．ダウンロードした初期化インストールディスクイメージをSD カードに書き込みます。
atmark@atde9:~$ sudo dd if=baseos-600-installer-3.21.3-at.1-console-uart3.img of=/dev/sdc bs=1M oflag=direct status=progress 407896064 bytes (408 MB, 389 MiB) copied, 22 s, 18.5 MB/s 405+0 レコード入力 405+0 レコード出力 424673280 bytes (425 MB, 405 MiB) copied, 22.9006 s, 18.5 MB/s atmark@atde9:~$
7. 書き込みが終わりましたら SD カードを抜いて、電源を抜いた状態の Armadillo に挿入してください。（添付画像の右側に SD カードを挿入したときの状態があります）
8. JP1 と JP2 をショートさせます。画像の青いジャンパーと同じ状態になります。
9. 正常であれば、Armadillo の UART3 コンソールから初期化インストール時のログが出力されますので、 UART3 コンソール経由で PC と Armadiilo を繋いで minicom からログが見れる状態にしておきます。
10. Armadillo に電源を入れます。
11. 正常であればUART3 コンソール経由でインストール時のログが出力されて状況を確認できます。
ATDEを使用した場合は上記の流れになりますが、これに相当する操作を行ってインストール作業を行っているという認識でお間違いないでしょうか？
よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| A640_JP1_JP2.JPG |
kazumori88
> 太田です。
>
> 実行結果の添付をありがとうございます。
>
> fuse read していただいた結果からSDブート無効化の設定はされていないですね。
> dd の結果も問題ないように見えます。
>
> 改めて認識合わせのためにもう一度、SD ブートの手順を確認させてください。
> ATDE 上で行う場合は以下のようになります。
>
> 1. 以下のURLから ATDE 上に baseos-600-installer-3.21.3-at.1-console-uart3.zip を持ってきます。
> https://armadillo.atmark-techno.com/resources/software/armadillo-640/ab…
> 例えば、wget で持ってくるとしたら、
>
> atmark@atde9:~$ wget https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image/baseos-600-installer-3.21.3-at.1-console-uart3.zip >
>
> 2. baseos-600-installer-3.21.3-at.1-console-uart3.zip を展開します。
>
> atmark@atde9:~$ unzip baseos-600-installer-3.21.3-at.1-console-uart3.zip >
>
> 3. ATDE に SD カードを認識させます。
> ATDE の [デバイス] > [USB] から SD カードに対応するものを探してチェックをつけてください。
>
> 4. /dev 下で SD カードを探します。
>
> atmark@atde9:~$ mount > ...省略 > /dev/sdc1 on /media/atmark/rootfs_0 type btrfs (rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/,uhelper=udisks2) >
> 私の環境では、/dev/sdc1 でした。
>
> 5. SD カードをアンマウントします。
>
> atmark@atde9:~$ sudo umount /dev/sdc1 >
>
> ６．ダウンロードした初期化インストールディスクイメージをSD カードに書き込みます。
>
> atmark@atde9:~$ sudo dd if=baseos-600-installer-3.21.3-at.1-console-uart3.img of=/dev/sdc bs=1M oflag=direct status=progress > 407896064 bytes (408 MB, 389 MiB) copied, 22 s, 18.5 MB/s > 405+0 レコード入力 > 405+0 レコード出力 > 424673280 bytes (425 MB, 405 MiB) copied, 22.9006 s, 18.5 MB/s > atmark@atde9:~$ >
>
> 7. 書き込みが終わりましたら SD カードを抜いて、電源を抜いた状態の Armadillo に挿入してください。（添付画像の右側に SD カードを挿入したときの状態があります）
>
> 8. JP1 と JP2 をショートさせます。画像の青いジャンパーと同じ状態になります。
>
> 9. 正常であれば、Armadillo の UART3 コンソールから初期化インストール時のログが出力されますので、 UART3 コンソール経由で PC と Armadiilo を繋いで minicom からログが見れる状態にしておきます。
>
> 10. Armadillo に電源を入れます。
>
> 11. 正常であればUART3 コンソール経由でインストール時のログが出力されて状況を確認できます。
>
> ATDEを使用した場合は上記の流れになりますが、これに相当する操作を行ってインストール作業を行っているという認識でお間違いないでしょうか？
>
> よろしくお願いいたします。
太田 様
上記の手順で実行しています。
＜気になっている点＞
１．ブート開始時に一度もABOS用のu-bootがコンソールに現われていません。
２．移行ガイドによると、debianとABOSでパーティションが異なっていると思うのですが、これはどこで実行されるのでしょうか？
３．SDカードをATDE上でマウントしてみると、rootfs_0以下にファイルが見えますが、u-bootもこの中でいいのでしょうか？
４．debianからdebianの書き替えは問題なく、実行できており、移行ができない。
ddコマンド実行時の結果を添付します。
以上、よろしくお願いします。
以上、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| atmark@atde9~Downloads$ lsblk_1535.txt | lsblk，ddコマンド実行時の結果 |
at_satoshi.ohta
太田です。
SDブートを行うと、SDカード上の U-boot に入り、その後カーネルが起動してユーザーランドに入ります。ユーザーランド上では installer.sh が実行されます。
そのスクリプト上で boot.lzo（U-boot）と image.lzo （rootfs）が eMMC に書かれる流れです。
> １．ブート開始時に一度もABOS用のu-bootがコンソールに現われていません。
LED が点灯しているため何かしら実行はされているはずですが、U-boot のコンソールにあらわれていない可能性があります。
現状使用している 640 の revison の特定のために、640 本体のQRコードの下に書かれている個体コード（１行目の「009C...」）を教えていただけますでしょうか？
> ２．移行ガイドによると、debianとABOSでパーティションが異なっていると思うのですが、これはどこで実行されるのでしょうか？
debian が書き込まれている領域に ABOS のイメージを上書きするのでパーティションが異なっていても問題ありません。
> ３．SDカードをATDE上でマウントしてみると、rootfs_0以下にファイルが見えますが、u-bootもこの中でいいのでしょうか？
SDカードに書き込まれている U-boot は先頭から 1 KB 以降にファイルシステムを持たずに直接書き込まれています。
そのため、マウントしても rootfs_0 しかありません。rootfs_0 は名前の通り SD ブートしたときに使用されるルートファイルシステムです。rootfs_0 をマウントして中身を見ると boot.lzo があるはずですが、これが eMMC に書き込む U-boot になります。
> ４．debianからdebianの書き替えは問題なく、実行できており、移行ができない。
debian から debian への書き換えは問題ないということ承知しました。
ちなみに現状インストールしている debian も 4.14-at36 でお間違いないでしょうか？
どうぞよろしくお願いいたします。
kazumori88
> 太田です。
>
> SDブートを行うと、SDカード上の U-boot に入り、その後カーネルが起動してユーザーランドに入ります。ユーザーランド上では installer.sh が実行されます。
> そのスクリプト上で boot.lzo（U-boot）と image.lzo （rootfs）が eMMC に書かれる流れです。
>
> > １．ブート開始時に一度もABOS用のu-bootがコンソールに現われていません。
> LED が点灯しているため何かしら実行はされているはずですが、U-boot のコンソールにあらわれていない可能性があります。
> 現状使用している 640 の revison の特定のために、640 本体のQRコードの下に書かれている個体コード（１行目の「009C...」）を教えていただけますでしょうか？
>
> > ２．移行ガイドによると、debianとABOSでパーティションが異なっていると思うのですが、これはどこで実行されるのでしょうか？
> debian が書き込まれている領域に ABOS のイメージを上書きするのでパーティションが異なっていても問題ありません。
>
> > ３．SDカードをATDE上でマウントしてみると、rootfs_0以下にファイルが見えますが、u-bootもこの中でいいのでしょうか？
> SDカードに書き込まれている U-boot は先頭から 1 KB 以降にファイルシステムを持たずに直接書き込まれています。
> そのため、マウントしても rootfs_0 しかありません。rootfs_0 は名前の通り SD ブートしたときに使用されるルートファイルシステムです。rootfs_0 をマウントして中身を見ると boot.lzo があるはずですが、これが eMMC に書き込む U-boot になります。
>
> > ４．debianからdebianの書き替えは問題なく、実行できており、移行ができない。
> debian から debian への書き換えは問題ないということ承知しました。
> ちなみに現状インストールしている debian も 4.14-at36 でお間違いないでしょうか？
>
> どうぞよろしくお願いいたします。
太田 様
お世話になります。
１．現状使用している 640 の revison の特定のために、640 本体のQRコードの下に書かれている個体コード（１行目の「009C...」）を教えていただけますでしょうか？
Ａ：009C01740422 00110C2A7647です。
４．現状インストールしている debian も 4.14-at36 でお間違いないでしょうか？
Ａ：現状、インストールしているdebianはLinux armadillo 4.14-at66 #3 Tue Feb 25 15:26:42 JST 2025 armv7l GNU/Linuxです。
以上、よろしくお願いします。
kazumori88
> > 太田です。
> >
> > SDブートを行うと、SDカード上の U-boot に入り、その後カーネルが起動してユーザーランドに入ります。ユーザーランド上では installer.sh が実行されます。
> > そのスクリプト上で boot.lzo（U-boot）と image.lzo （rootfs）が eMMC に書かれる流れです。
> >
> > > １．ブート開始時に一度もABOS用のu-bootがコンソールに現われていません。
> > LED が点灯しているため何かしら実行はされているはずですが、U-boot のコンソールにあらわれていない可能性があります。
> > 現状使用している 640 の revison の特定のために、640 本体のQRコードの下に書かれている個体コード（１行目の「009C...」）を教えていただけますでしょうか？
> >
> > > ２．移行ガイドによると、debianとABOSでパーティションが異なっていると思うのですが、これはどこで実行されるのでしょうか？
> > debian が書き込まれている領域に ABOS のイメージを上書きするのでパーティションが異なっていても問題ありません。
> >
> > > ３．SDカードをATDE上でマウントしてみると、rootfs_0以下にファイルが見えますが、u-bootもこの中でいいのでしょうか？
> > SDカードに書き込まれている U-boot は先頭から 1 KB 以降にファイルシステムを持たずに直接書き込まれています。
> > そのため、マウントしても rootfs_0 しかありません。rootfs_0 は名前の通り SD ブートしたときに使用されるルートファイルシステムです。rootfs_0 をマウントして中身を見ると boot.lzo があるはずですが、これが eMMC に書き込む U-boot になります。
> >
> > > ４．debianからdebianの書き替えは問題なく、実行できており、移行ができない。
> > debian から debian への書き換えは問題ないということ承知しました。
> > ちなみに現状インストールしている debian も 4.14-at36 でお間違いないでしょうか？
> >
> > どうぞよろしくお願いいたします。
>
> 太田 様
> お世話になります。
> １．現状使用している 640 の revison の特定のために、640 本体のQRコードの下に書かれている個体コード（１行目の「009C...」）を教えていただけますでしょうか？
> Ａ：009C01740422 00110C2A7647です。
> ４．現状インストールしている debian も 4.14-at36 でお間違いないでしょうか？
> Ａ：現状、インストールしているdebianはLinux armadillo 4.14-at66 #3 Tue Feb 25 15:26:42 JST 2025 armv7l GNU/Linuxです。
>
> 以上、よろしくお願いします。
>
太田 様
お世話になります。
１．製品マニュアル_Version 4.19.0の6.20.1. ブートディスクの作成を行い、SDに書き込み、ＳＤブートを実行したところ、
はじめて、u-boot-2020.04-at25がコンソールに表示され、添付のようにABOSに書き換えできたようです。
２．ただ、haltを実行し、電源が切れてから、JP1をオープンにし、起動すると、debianに戻ってしまいました。
どのように、変更を反映させれば、いいのでしょうか？
| ファイル | ファイルの説明 |
|---|---|
| U-Boot 2020.04-at25 (Mar 06 2025 -.txt | 成功したブート時のコンソール出力 |
kazumori88
> > 太田です。
> >
> > 実行結果の添付をありがとうございます。
> >
> > fuse read していただいた結果からSDブート無効化の設定はされていないですね。
> > dd の結果も問題ないように見えます。
> >
> > 改めて認識合わせのためにもう一度、SD ブートの手順を確認させてください。
> > ATDE 上で行う場合は以下のようになります。
> >
> > 1. 以下のURLから ATDE 上に baseos-600-installer-3.21.3-at.1-console-uart3.zip を持ってきます。
> > https://armadillo.atmark-techno.com/resources/software/armadillo-640/ab…
> > 例えば、wget で持ってくるとしたら、
> >
> > atmark@atde9:~$ wget https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image/baseos-600-installer-3.21.3-at.1-console-uart3.zip > >
> >
> > 2. baseos-600-installer-3.21.3-at.1-console-uart3.zip を展開します。
> >
> > atmark@atde9:~$ unzip baseos-600-installer-3.21.3-at.1-console-uart3.zip > >
> >
> > 3. ATDE に SD カードを認識させます。
> > ATDE の [デバイス] > [USB] から SD カードに対応するものを探してチェックをつけてください。
> >
> > 4. /dev 下で SD カードを探します。
> >
> > atmark@atde9:~$ mount > > ...省略 > > /dev/sdc1 on /media/atmark/rootfs_0 type btrfs (rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/,uhelper=udisks2) > >
> > 私の環境では、/dev/sdc1 でした。
> >
> > 5. SD カードをアンマウントします。
> >
> > atmark@atde9:~$ sudo umount /dev/sdc1 > >
> >
> > ６．ダウンロードした初期化インストールディスクイメージをSD カードに書き込みます。
> >
> > atmark@atde9:~$ sudo dd if=baseos-600-installer-3.21.3-at.1-console-uart3.img of=/dev/sdc bs=1M oflag=direct status=progress > > 407896064 bytes (408 MB, 389 MiB) copied, 22 s, 18.5 MB/s > > 405+0 レコード入力 > > 405+0 レコード出力 > > 424673280 bytes (425 MB, 405 MiB) copied, 22.9006 s, 18.5 MB/s > > atmark@atde9:~$ > >
> >
> > 7. 書き込みが終わりましたら SD カードを抜いて、電源を抜いた状態の Armadillo に挿入してください。（添付画像の右側に SD カードを挿入したときの状態があります）
> >
> > 8. JP1 と JP2 をショートさせます。画像の青いジャンパーと同じ状態になります。
> >
> > 9. 正常であれば、Armadillo の UART3 コンソールから初期化インストール時のログが出力されますので、 UART3 コンソール経由で PC と Armadiilo を繋いで minicom からログが見れる状態にしておきます。
> >
> > 10. Armadillo に電源を入れます。
> >
> > 11. 正常であればUART3 コンソール経由でインストール時のログが出力されて状況を確認できます。
> >
> > ATDEを使用した場合は上記の流れになりますが、これに相当する操作を行ってインストール作業を行っているという認識でお間違いないでしょうか？
> >
> > よろしくお願いいたします。
> 太田 様
>
> 上記の手順で実行しています。
> ＜気になっている点＞
> １．ブート開始時に一度もABOS用のu-bootがコンソールに現われていません。
> ２．移行ガイドによると、debianとABOSでパーティションが異なっていると思うのですが、これはどこで実行されるのでしょうか？
> ３．SDカードをATDE上でマウントしてみると、rootfs_0以下にファイルが見えますが、u-bootもこの中でいいのでしょうか？
> ４．debianからdebianの書き替えは問題なく、実行できており、移行ができない。
> ddコマンド実行時の結果を添付します。
>
> 以上、よろしくお願いします。
>
> 以上、よろしくお願いします。
at_satoshi.ohta
太田です。
個体コードおよびdebianのバージョンを教えて頂きありがとうございます。
上記のログについてですが、 SD ブートは実行されていますが、SD カードに書かれた ABOS のイメージが起動していて、eMMC に書き込まれた ABOS が起動しているわけではありません。そのため、JP1 をオープンにすると eMMC 上に書き込まれている debian に戻ってしまいます。
ただ、ABOS が UART3 コンソールではない場合の SD ブートでは minicom に文字列が出力されるみたいですね。
「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」ではなく、以下の「Armadillo Base OS インストールディスクイメージ」の方を SD カードに書き込んで、640 にインストールするとどうなりますでしょうか？
https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
どうぞよろしくお願いいたします。
kazumori88
> 太田です。
>
> 個体コードおよびdebianのバージョンを教えて頂きありがとうございます。
>
> 上記のログについてですが、 SD ブートは実行されていますが、SD カードに書かれた ABOS のイメージが起動していて、eMMC に書き込まれた ABOS が起動しているわけではありません。そのため、JP1 をオープンにすると eMMC 上に書き込まれている debian に戻ってしまいます。
>
> ただ、ABOS が UART3 コンソールではない場合の SD ブートでは minicom に文字列が出力されるみたいですね。
> 「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」ではなく、以下の「Armadillo Base OS インストールディスクイメージ」の方を SD カードに書き込んで、640 にインストールするとどうなりますでしょうか？
> https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
>
> どうぞよろしくお願いいたします。
太田 様
お世話になります。
baseos-600-installer-3.21.3-at.2.zipを解凍し、imgをSDカードに書き込み、実施しましたが、最初からU-Boot 2018.03-at15+ (Jun 25 2024 - 18:07:08 +0900)が起動し、debianのまま、立ち上がります。
以上、よろしくお願いします。
at_satoshi.ohta
太田です。
baseos-600-installer-3.21.3-at.2.zip ではない方でもうまく行かなかったんですね...
また、教えて頂いた個体コードから去年6月頃に製造されたものであることが分かりましたので、そんなに古い revison の 640 でも無いということですね。
原因はわかりませんが、build_image.sh を使用して手元で作ったイメージであれば SD ブートして SD カード内の ABOS を起動できたとのことでしたので、
「3.3.5.1. 初期化インストールディスクの作成」の手順に沿って build_image.sh を用いて初期化インストールディスクイメージを作ったものをお試しいただけますでしょうか？
https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
お手数をおかけします。
どうぞよろしくお願いいたします。
kazumori88
> 太田です。
>
> baseos-600-installer-3.21.3-at.2.zip ではない方でもうまく行かなかったんですね...
> また、教えて頂いた個体コードから去年6月頃に製造されたものであることが分かりましたので、そんなに古い revison の 640 でも無いということですね。
>
> 原因はわかりませんが、build_image.sh を使用して手元で作ったイメージであれば SD ブートして SD カード内の ABOS を起動できたとのことでしたので、
> 「3.3.5.1. 初期化インストールディスクの作成」の手順に沿って build_image.sh を用いて初期化インストールディスクイメージを作ったものをお試しいただけますでしょうか？
> https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
>
> お手数をおかけします。
> どうぞよろしくお願いいたします。
太田 様
１．上記のブートお試しの意図がわかりません。at1からat2に変わっているからでしょうか？もともと、今ＳＤブートできているものも build_image.shで作成しています。
２．私が理解できていないのは、fdiskを使用しないと変更できないパーティションはどこで変更しているのでしょうか？
３．今、動作しているmmcblk1を丸々mmcblk０にコピーする方法ではだめなのでしょうか？
mmcblk1 179:0 0 14.9G 0 disk
tqmmcblk1p1 179:1 0 300M 0 part /live/rootfs
tqmmcblk1p2 179:2 0 300M 0 part
tqmmcblk1p3 179:3 0 50M 0 part /var/log
tqmmcblk1p4 179:4 0 200M 0 part
mqmmcblk1p5 179:5 0 14G 0 part /var/tmp
/var/app/volumes
/var/app/rollback/volumes
/var/lib/containers/storage_readonly
mmcblk0 179:8 0 3.5G 0 disk
tqmmcblk0p1 179:9 0 30.6M 0 part
tqmmcblk0p2 179:10 0 3.4G 0 part
mqmmcblk0p3 179:11 0 122.1M 0 part
mmcblk0boot0 179:16 0 31.5M 1 disk
mmcblk0boot1 179:24 0 31.5M 1 disk
mmcblk0gp0 179:32 0 8M 0 disk
mmcblk0gp1 179:40 0 8M 0 disk
mmcblk0gp2 179:48 0 8M 0 disk
mmcblk0gp3 179:56 0 8M 0 disk
zram0 254:0 0 244.1M 0 disk [SWAP]
以上、よろしくお願いします。
koga
アットマークテクノの古賀です。
kazumori88さん：
>>原因はわかりませんが、build_image.sh を使用して手元で作ったイメージであれば SD ブートして SD カード内の ABOS を起動できたとのことでしたので、
>>「3.3.5.1. 初期化インストールディスクの作成」の手順に沿って build_image.sh を用いて初期化インストールディスクイメージを作ったものをお試しいただけますでしょうか？
>>https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
>>
>>お手数をおかけします。
>>どうぞよろしくお願いいたします。
>
>太田 様
>
>１．上記のブートお試しの意図がわかりません。at1からat2に変わっているからでしょうか？もともと、今ＳＤブートできているものも build_image.shで作成しています。
インストールディスクイメージを当社サイトからダウンロードして SD カードに書き込んで作って頂いたインストールディスクだと起動できなかったが、build_image.sh を使って作って頂いたブートディスクの SD カードだと正しく起動できた、ということから、それに近い手順でインストールディスクを作ってみたらどうなるか知りたい、という程度の意味かと思います。
>２．私が理解できていないのは、fdiskを使用しないと変更できないパーティションはどこで変更しているのでしょうか？
インストールディスクから SD ブートした時に動く、インストールディスク内のインストーラです。インストーラが、sgdisk を使って eMMC のパーティションを作り直す仕組みになっています。
>３．今、動作しているmmcblk1を丸々mmcblk０にコピーする方法ではだめなのでしょうか？
>mmcblk1 179:0 0 14.9G 0 disk
>tqmmcblk1p1 179:1 0 300M 0 part /live/rootfs
>tqmmcblk1p2 179:2 0 300M 0 part
>tqmmcblk1p3 179:3 0 50M 0 part /var/log
>tqmmcblk1p4 179:4 0 200M 0 part
>mqmmcblk1p5 179:5 0 14G 0 part /var/tmp
…
>mmcblk0 179:8 0 3.5G 0 disk
>tqmmcblk0p1 179:9 0 30.6M 0 part
>tqmmcblk0p2 179:10 0 3.4G 0 part
>mqmmcblk0p3 179:11 0 122.1M 0 part
…
はい。パーティション構成が、お使いの SD カードの容量（16GB）に合わせたものになっていますから、そのディスクイメージを Armadillo-640 の eMMC にコピーしようとしても、うまくいかないはずです。
kazumori88
> アットマークテクノの古賀です。
>
> kazumori88さん：
> >>原因はわかりませんが、build_image.sh を使用して手元で作ったイメージであれば SD ブートして SD カード内の ABOS を起動できたとのことでしたので、
> >>「3.3.5.1. 初期化インストールディスクの作成」の手順に沿って build_image.sh を用いて初期化インストールディスクイメージを作ったものをお試しいただけますでしょうか？
> >>https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
> >>
> >>お手数をおかけします。
> >>どうぞよろしくお願いいたします。
> >
> >太田 様
> >
> >１．上記のブートお試しの意図がわかりません。at1からat2に変わっているからでしょうか？もともと、今ＳＤブートできているものも build_image.shで作成しています。
>
> インストールディスクイメージを当社サイトからダウンロードして SD カードに書き込んで作って頂いたインストールディスクだと起動できなかったが、build_image.sh を使って作って頂いたブートディスクの SD カードだと正しく起動できた、ということから、それに近い手順でインストールディスクを作ってみたらどうなるか知りたい、という程度の意味かと思います。
>
> >２．私が理解できていないのは、fdiskを使用しないと変更できないパーティションはどこで変更しているのでしょうか？
>
> インストールディスクから SD ブートした時に動く、インストールディスク内のインストーラです。インストーラが、sgdisk を使って eMMC のパーティションを作り直す仕組みになっています。
>
> >３．今、動作しているmmcblk1を丸々mmcblk０にコピーする方法ではだめなのでしょうか？
> >mmcblk1 179:0 0 14.9G 0 disk
> >tqmmcblk1p1 179:1 0 300M 0 part /live/rootfs
> >tqmmcblk1p2 179:2 0 300M 0 part
> >tqmmcblk1p3 179:3 0 50M 0 part /var/log
> >tqmmcblk1p4 179:4 0 200M 0 part
> >mqmmcblk1p5 179:5 0 14G 0 part /var/tmp
> …
> >mmcblk0 179:8 0 3.5G 0 disk
> >tqmmcblk0p1 179:9 0 30.6M 0 part
> >tqmmcblk0p2 179:10 0 3.4G 0 part
> >mqmmcblk0p3 179:11 0 122.1M 0 part
> …
>
> はい。パーティション構成が、お使いの SD カードの容量（16GB）に合わせたものになっていますから、そのディスクイメージを Armadillo-640 の eMMC にコピーしようとしても、うまくいかないはずです。
太田 様
起動ログをみると、flash target is MMC:1になっており、MMC:1はSDカードと思うのですが、これでいいのでしょうか？
以上、よろしくお願いします。
kazumori88
> > 太田です。
> >
> > 個体コードおよびdebianのバージョンを教えて頂きありがとうございます。
> >
> > 上記のログについてですが、 SD ブートは実行されていますが、SD カードに書かれた ABOS のイメージが起動していて、eMMC に書き込まれた ABOS が起動しているわけではありません。そのため、JP1 をオープンにすると eMMC 上に書き込まれている debian に戻ってしまいます。
> >
> > ただ、ABOS が UART3 コンソールではない場合の SD ブートでは minicom に文字列が出力されるみたいですね。
> > 「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」ではなく、以下の「Armadillo Base OS インストールディスクイメージ」の方を SD カードに書き込んで、640 にインストールするとどうなりますでしょうか？
> > https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
> >
> > どうぞよろしくお願いいたします。
>
> 太田 様
> お世話になります。
> baseos-600-installer-3.21.3-at.2.zipを解凍し、imgをSDカードに書き込み、実施しましたが、最初からU-Boot 2018.03-at15+ (Jun 25 2024 - 18:07:08 +0900)が起動し、debianのまま、立ち上がります。
> 以上、よろしくお願いします。
>
>
koga
アットマークテクノの古賀です。
kazumori88さん：
>>上記のログについてですが、 SD ブートは実行されていますが、SD カードに書かれた ABOS のイメージが起動していて、eMMC に書き込まれた ABOS が起動しているわけではありません。そのため、JP1 をオープンにすると eMMC 上に書き込まれている debian に戻ってしまいます。
>>
>>ただ、ABOS が UART3 コンソールではない場合の SD ブートでは minicom に文字列が出力されるみたいですね。
>>「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」ではなく、以下の「Armadillo Base OS インストールディスクイメージ」の方を SD カードに書き込んで、640 にインストールするとどうなりますでしょうか？
>>https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
>>
>>どうぞよろしくお願いいたします。
>
>太田 様
>お世話になります。
>baseos-600-installer-3.21.3-at.2.zipを解凍し、imgをSDカードに書き込み、実施しましたが、最初からU-Boot 2018.03-at15+ (Jun 25 2024 - 18:07:08 +0900)が起動し、debianのまま、立ち上がります。
baseos-600-installer-3.21.3-at.2.zip に収録されている baseos-600-installer-3.21.3-at.2.img を SD カードに書き込んで Armadillo-640 に装着して起動する際、JP1 と JP2 をショートしていらしたでしょうか？
JP1 と JP2 をショートして起動（SD ブート）した場合も Debian が起動するという場合は、 baseos-600-installer-3.21.3-at.2.img を、どうやって SD カードに書き込みされたのか（※dd コマンドで書き込んだとか、Win32 Disk Imager Renewal などのイメージ書き込みツールで書き込んだなど、書き込みの際に行われた手順）を教えてくださいませ。
kazumori88
> アットマークテクノの古賀です。
>
> kazumori88さん：
> >>上記のログについてですが、 SD ブートは実行されていますが、SD カードに書かれた ABOS のイメージが起動していて、eMMC に書き込まれた ABOS が起動しているわけではありません。そのため、JP1 をオープンにすると eMMC 上に書き込まれている debian に戻ってしまいます。
> >>
> >>ただ、ABOS が UART3 コンソールではない場合の SD ブートでは minicom に文字列が出力されるみたいですね。
> >>「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」ではなく、以下の「Armadillo Base OS インストールディスクイメージ」の方を SD カードに書き込んで、640 にインストールするとどうなりますでしょうか？
> >>https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
> >>
> >>どうぞよろしくお願いいたします。
> >
> >太田 様
> >お世話になります。
> >baseos-600-installer-3.21.3-at.2.zipを解凍し、imgをSDカードに書き込み、実施しましたが、最初からU-Boot 2018.03-at15+ (Jun 25 2024 - 18:07:08 +0900)が起動し、debianのまま、立ち上がります。
>
> baseos-600-installer-3.21.3-at.2.zip に収録されている baseos-600-installer-3.21.3-at.2.img を SD カードに書き込んで Armadillo-640 に装着して起動する際、JP1 と JP2 をショートしていらしたでしょうか？
>
> JP1 と JP2 をショートして起動（SD ブート）した場合も Debian が起動するという場合は、 baseos-600-installer-3.21.3-at.2.img を、どうやって SD カードに書き込みされたのか（※dd コマンドで書き込んだとか、Win32 Disk Imager Renewal などのイメージ書き込みツールで書き込んだなど、書き込みの際に行われた手順）を教えてくださいませ。
太田 様
お世話になります。
１．書込みはマニュアル記載の通り、
sudo dd if=~/build-rootfs-v3.21-at.2/baseos-600-3.21.3-at.2.20250306.img of=/dev/sdc bs=1M oflag=direct status=progress
で行いました。
２．起動ログを見ると、flash target is MMC:1になっていますが、MMC:1はSDカードと思うのですが、これでいいのでしょうか？
以上、よろしくお願いします。
kazumori88
> > アットマークテクノの古賀です。
> >
> > kazumori88さん：
> > >>上記のログについてですが、 SD ブートは実行されていますが、SD カードに書かれた ABOS のイメージが起動していて、eMMC に書き込まれた ABOS が起動しているわけではありません。そのため、JP1 をオープンにすると eMMC 上に書き込まれている debian に戻ってしまいます。
> > >>
> > >>ただ、ABOS が UART3 コンソールではない場合の SD ブートでは minicom に文字列が出力されるみたいですね。
> > >>「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」ではなく、以下の「Armadillo Base OS インストールディスクイメージ」の方を SD カードに書き込んで、640 にインストールするとどうなりますでしょうか？
> > >>https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
> > >>
> > >>どうぞよろしくお願いいたします。
> > >
> > >太田 様
> > >お世話になります。
> > >baseos-600-installer-3.21.3-at.2.zipを解凍し、imgをSDカードに書き込み、実施しましたが、最初からU-Boot 2018.03-at15+ (Jun 25 2024 - 18:07:08 +0900)が起動し、debianのまま、立ち上がります。
> >
> > baseos-600-installer-3.21.3-at.2.zip に収録されている baseos-600-installer-3.21.3-at.2.img を SD カードに書き込んで Armadillo-640 に装着して起動する際、JP1 と JP2 をショートしていらしたでしょうか？
> >
> > JP1 と JP2 をショートして起動（SD ブート）した場合も Debian が起動するという場合は、 baseos-600-installer-3.21.3-at.2.img を、どうやって SD カードに書き込みされたのか（※dd コマンドで書き込んだとか、Win32 Disk Imager Renewal などのイメージ書き込みツールで書き込んだなど、書き込みの際に行われた手順）を教えてくださいませ。
>
> 太田 様
> お世話になります。
> １．書込みはマニュアル記載の通り、
> sudo dd if=~/build-rootfs-v3.21-at.2/baseos-600-3.21.3-at.2.20250306.img of=/dev/sdc bs=1M oflag=direct status=progress
> で行いました。
> ２．起動ログを見ると、flash target is MMC:1になっていますが、MMC:1はSDカードと思うのですが、これでいいのでしょうか？
> 以上、よろしくお願いします。
太田 様
お世話になります。
flash targetを変更しようと思い、
起動時に
=> mmc dev
switch to partitions #0, OK
mmc1 is current device
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc dev
switch to partitions #0, OK
mmc0(part 0) is current device
=> saveenv
Saving Environment to MMC... Writing to MMC(1)... OKとなり、
Writing to MMC(０)... OKと変更されませんでした。
再度、mmc devを確認すると
=> mmc dev
switch to partitions #0, OK
mmc0(part 0) is current device
になっています。
mmc:０に切り替えたいのですが、拒否されているようです。
以上、よろしくお願いします。
at_satoshi.ohta
太田です。
一度今まで行ったことをまとめます。
製品: Armadillo 640 (Rev7)
OS: debian (4.14-at36, 4.14-at66)
SDブートの手順を再確認した上で、debian から ABOS に移行するための手順として以下の方法をお試し頂きました。
1. 「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」のインストール（うまくいかず）
https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
結果：
- 赤LEDと緑LEDが点灯し、赤LEDが消灯したあと、緑LEDは点灯したままでインストールできなかった。
- SD ブートしたはずが eMMC で起動して debian として起動する
- Loading Environment from MMC... *** Warning - bad CRC, using default environment のログが出る
- ABOS用のu-bootがコンソールに現れない
確認したこと：
- SD カードを認識しているか確認して問題なし
- SD カードの容量も問題なし
- U-boot が正しく書き込みできているか checksum を確認して問題なし
- 別の SD カードでも同様の現象
- SD ブートが有効であることも確認
- debianからdebianの書き替えは問題ない
2. 「Armadillo Base OS インストールディスクイメージ」のインストール（うまくいかず）
結果：
- 1 と同様にうまく行かなかった
ここで分かったこと：
- ダウンロードしてきた初期化インストールディスクイメージはどちらも SD ブートが成功しない
3. 手元で「6.20.1. ブートディスクの作成」に従い、以下の手順で本来 eMMC に書き込む ABOS のイメージを SD カードに書き込み SD ブートを実行
実行したコマンド
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \
--boot ~/u-boot-[VERSION]/u-boot-dtb.imx
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*img
baseos-600-[VERSION].img結果：
- 本来 eMMC に書き込む ABOS のイメージである baseos-640-[VERSION].img を SD に書き込んでSD ブートすると SD ブートは成功して、ABOS が起動
ここで分かったこと：
- 理由は不明ですが、手元でビルドした ABOS のイメージであれば、SD ブートが出来ることが判明
- ただし、初期化インストールディスクイメージではないので初期化インストールディスクイメージを作成する必要あり
（今やって頂いていること）
4. 「3.3.5.1. 初期化インストールディスクの作成」に従い、以下の手順で初期化インストールディスクを作成
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*img
baseos-600-[VERSION].img ★ eMMC に書き込む ABOS のイメージを作成
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \
--boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 \
--installer ./baseos-600-[VERSION].img ★ --installer でeMMC に書き込む ABOS のイメージを入力して、初期化インストールディスクイメージを作成
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*-installer.img
baseos-600-[VERSION]-installer.img ★ 作成された初期化インストールディスクイメージ4 についてですが、
> １．書込みはマニュアル記載の通り、
> sudo dd if=~/build-rootfs-v3.21-at.2/baseos-600-3.21.3-at.2.20250306.img of=/dev/sdc bs=1M oflag=direct status=progress
> で行いました。
とのことですが、dd で書き込んでいる baseos-600-3.21.3-at.2.20250306.img は、上記の
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 : (省略) [ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*img baseos-600-[VERSION].img ★ eMMC に書き込む ABOS のイメージを作成
までで作成した baseos-600-[VERSION].img です。
その続きの
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \
--boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 \
--installer ./baseos-600-[VERSION].img ★ --installer でeMMC に書き込む ABOS のイメージを入力して、初期化インストールディスクイメージを作成
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*-installer.img
baseos-600-[VERSION]-installer.img ★ 作成された初期化インストールディスクイメージを実行していないため、まだ初期化インストールディスクイメージは作成されていません。
以下のように build_image.sh の --installer に baseos-600-3.21.3-at.2.20250306.img を指定して、もう一度 build_image.sh を実行すると eMMC に書き込む初期化インストールディスクイメージを作成できます。
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \
--boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 \
--installer ./baseos-600-3.21.3-at.2.20250306.imgbaseos-600-[VERSION]-installer.img（[VERSION]はおそらく3.21.3-at.2.20250306）という初期化インストールディスクイメージが作成されます。
作成した baseos-600-[VERSION]-installer.img を SD カードに書き込んでもう一度 SD ブートをお試しいただけますでしょうか？
また、その時の起動ログを提供していただければ幸いです。
どうぞよろしくお願いいたします。
kazumori88
> 太田です。
>
> 一度今まで行ったことをまとめます。
>
> 製品: Armadillo 640 (Rev7)
> OS: debian (4.14-at36, 4.14-at66)
>
> SDブートの手順を再確認した上で、debian から ABOS に移行するための手順として以下の方法をお試し頂きました。
>
> 1. 「Armadillo Base OS インストールディスクイメージ(UART3コンソール)」のインストール（うまくいかず）
> https://armadillo.atmark-techno.com/files/downloads/armadillo-640/image…
>
> 結果：
> - 赤LEDと緑LEDが点灯し、赤LEDが消灯したあと、緑LEDは点灯したままでインストールできなかった。
> - SD ブートしたはずが eMMC で起動して debian として起動する
> - Loading Environment from MMC... *** Warning - bad CRC, using default environment のログが出る
> - ABOS用のu-bootがコンソールに現れない
>
> 確認したこと：
> - SD カードを認識しているか確認して問題なし
> - SD カードの容量も問題なし
> - U-boot が正しく書き込みできているか checksum を確認して問題なし
> - 別の SD カードでも同様の現象
> - SD ブートが有効であることも確認
> - debianからdebianの書き替えは問題ない
>
> 2. 「Armadillo Base OS インストールディスクイメージ」のインストール（うまくいかず）
>
> 結果：
> - 1 と同様にうまく行かなかった
>
> ここで分かったこと：
> - ダウンロードしてきた初期化インストールディスクイメージはどちらも SD ブートが成功しない
>
> 3. 手元で「6.20.1. ブートディスクの作成」に従い、以下の手順で本来 eMMC に書き込む ABOS のイメージを SD カードに書き込み SD ブートを実行
> 実行したコマンド
>
> [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \ > --boot ~/u-boot-[VERSION]/u-boot-dtb.imx > [ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*img > baseos-600-[VERSION].img >
> 結果：
> - 本来 eMMC に書き込む ABOS のイメージである baseos-640-[VERSION].img を SD に書き込んでSD ブートすると SD ブートは成功して、ABOS が起動
>
> ここで分かったこと：
> - 理由は不明ですが、手元でビルドした ABOS のイメージであれば、SD ブートが出来ることが判明
> - ただし、初期化インストールディスクイメージではないので初期化インストールディスクイメージを作成する必要あり
>
> （今やって頂いていること）
> 4. 「3.3.5.1. 初期化インストールディスクの作成」に従い、以下の手順で初期化インストールディスクを作成
>
> [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 > : (省略) > [ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*img > baseos-600-[VERSION].img ★ eMMC に書き込む ABOS のイメージを作成 > [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \ > --boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 \ > --installer ./baseos-600-[VERSION].img ★ --installer でeMMC に書き込む ABOS のイメージを入力して、初期化インストールディスクイメージを作成 > [ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*-installer.img > baseos-600-[VERSION]-installer.img ★ 作成された初期化インストールディスクイメージ >
>
> 4 についてですが、
>
> > １．書込みはマニュアル記載の通り、
> > sudo dd if=~/build-rootfs-v3.21-at.2/baseos-600-3.21.3-at.2.20250306.img of=/dev/sdc bs=1M oflag=direct status=progress
> > で行いました。
>
> とのことですが、dd で書き込んでいる baseos-600-3.21.3-at.2.20250306.img は、上記の
>
> [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 > : (省略) > [ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*img > baseos-600-[VERSION].img ★ eMMC に書き込む ABOS のイメージを作成 >
> までで作成した baseos-600-[VERSION].img です。
> その続きの
>
> [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \ > --boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 \ > --installer ./baseos-600-[VERSION].img ★ --installer でeMMC に書き込む ABOS のイメージを入力して、初期化インストールディスクイメージを作成 > [ATDE ~/build-rootfs-[VERSION]]$ ls baseos-600*-installer.img > baseos-600-[VERSION]-installer.img ★ 作成された初期化インストールディスクイメージ >
> を実行していないため、まだ初期化インストールディスクイメージは作成されていません。
> 以下のように build_image.sh の --installer に baseos-600-3.21.3-at.2.20250306.img を指定して、もう一度 build_image.sh を実行すると eMMC に書き込む初期化インストールディスクイメージを作成できます。
>
> [ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 \ > --boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 \ > --installer ./baseos-600-3.21.3-at.2.20250306.img >
> baseos-600-[VERSION]-installer.img（[VERSION]はおそらく3.21.3-at.2.20250306）という初期化インストールディスクイメージが作成されます。
> 作成した baseos-600-[VERSION]-installer.img を SD カードに書き込んでもう一度 SD ブートをお試しいただけますでしょうか？
> また、その時の起動ログを提供していただければ幸いです。
>
> どうぞよろしくお願いいたします。
太田 様
お世話になります。
私はマニュアルしか、頼る資料がないので、以下の手順で実行しました。
１．マニュアル：6.21.3. Alpine Linux ルートファイルシステムをビルドする
•「6.20.1. ブートディスクの作成」 でインストールする手順を実行すると、ビルドされた baseos-600-[VERSION].tar.zst が自動的に利用されます。
２．6.21.1. ブートローダーをビルドする 、ビルドされた u-boot-dtb.imx
３．6.20.1. ブートディスクの作成
sudo ./build_image.sh --board a600 --boot ~/u-boot-[VERSION]/u-boot-dtb.imx
4. ブートdiskの書き込み
sudo dd if=~/build-rootfs-[VERSION]/baseos-640-[VERSION].img of=/dev/sdb bs=1M oflag=direct status=progress
を行いました。
それで作成されたのが、 baseos-600-3.21.3-at.2.20250306.imgです。
マニュアルにはそれ以上の記載はありませんでした。
これから、
sudo ./build_image.sh --board a600 --boot ~/imx-boot-[VERSION]/imx-boot_armadillo_600 --installer ./baseos-600-3.21.3-at.2.20250306.img
を次呼応し、再度ＳＤカードを作成し、起動ログを送ります。
以上、よろしくお願いします。
at_satoshi.ohta
太田です。
説明不足で申し訳ありません。マニュアルでは「3.3.5.1. 初期化インストールディスクの作成」に記載があります。
以下のURLから見ることが出来ます。
https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
上記で提示した初期化インストールディスクの作成の手順について同様の内容が記載されていますが、こちらも参考にしていただけると幸いです。
よろしくお願い致します。
kazumori88
> 太田です。
>
> 説明不足で申し訳ありません。マニュアルでは「3.3.5.1. 初期化インストールディスクの作成」に記載があります。
> 以下のURLから見ることが出来ます。
>
> https://manual.atmark-techno.com/armadillo-640/armadillo-640_product_ma…
>
> 上記で提示した初期化インストールディスクの作成の手順について同様の内容が記載されていますが、こちらも参考にしていただけると幸いです。
> よろしくお願い致します。
太田様
お世話になります。
１．私の見ていた製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応のブートdiskの作成では、
6.20.1. ブートディスクの作成（381ページ）では記載がありません。どこか、他に？
２．作成したinstaller.imgでsdを作成し、実行しましたが、mmcのdebianで起動でした。
ログを添付します。
３．ダウンロードしたイメージから再度、やってみます。
以上、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| インストーラ作成時のログ_202503071224.txt | |
| 起動ログ_202503071222.txt |
at_dominique.m…
横からすみません、
マルティネです。
1. 「3.3.5.1」なのでちがうページなのでちがうページにあります。
目次から探すと 「3.3.5. インストールディスクについて」の深さまでしか表示されてませんので、「3. 開発編」に入ってから検索可能です
2. こちらの起動ログでも直接に eMMC に起動しています。
「 U-Boot 2020.04-at25 (Mar 06 2025 -.txt 」（「 成功したブート時のコンソール出力 」）では無事に SD カードを起動できたようですが、今回同じ u-boot イメージで生成した sd カードで eMMC から起動するのはわかりません。
SD カードが boot rom 時点で認識されないと自動的に eMMC ブートに切り替える認識ですので、JP の接続が不安定かハードウェアレベルの sd カードの認識の問題かもしれません。
お手数ですが接続を確認した上で、再び SD ブートを試していただければ幸いです。
また、ダウンロードした (uart3ではない）イメージでも同じく利用できると認識しています。ABOS で SDブートできたのは ttymxc0 のコンソールを利用しましたので、「baseos-600-installer-3.21.3-at.2.zip」にあるイメージでも同じく起動できるはずです。
その再、「flash target is MMC:1」のメッセージは u-boot が起動するカーネルのメッセージですので MMC:1 で正しくて、インストールディスクの linux に入ることができれば SD カードから eMMC に書き込みを行います。
よろしくお願いします。
kazumori88
> 横からすみません、
> マルティネです。
>
> 1. 「3.3.5.1」なのでちがうページなのでちがうページにあります。
> 目次から探すと 「3.3.5. インストールディスクについて」の深さまでしか表示されてませんので、「3. 開発編」に入ってから検索可能です
>
> 2. こちらの起動ログでも直接に eMMC に起動しています。
>
> 「 U-Boot 2020.04-at25 (Mar 06 2025 -.txt 」（「 成功したブート時のコンソール出力 」）では無事に SD カードを起動できたようですが、今回同じ u-boot イメージで生成した sd カードで eMMC から起動するのはわかりません。
> SD カードが boot rom 時点で認識されないと自動的に eMMC ブートに切り替える認識ですので、JP の接続が不安定かハードウェアレベルの sd カードの認識の問題かもしれません。
> お手数ですが接続を確認した上で、再び SD ブートを試していただければ幸いです。
>
> また、ダウンロードした (uart3ではない）イメージでも同じく利用できると認識しています。ABOS で SDブートできたのは ttymxc0 のコンソールを利用しましたので、「baseos-600-installer-3.21.3-at.2.zip」にあるイメージでも同じく起動できるはずです。
> その再、「flash target is MMC:1」のメッセージは u-boot が起動するカーネルのメッセージですので MMC:1 で正しくて、インストールディスクの linux に入ることができれば SD カードから eMMC に書き込みを行います。
>
> よろしくお願いします。
お世話になります。
１．先ほど、提示があった方法で作成したDISKでは、JP,SDカードのクリーンを行っても、起動時からu-boot2018でした。
２．EMMCには書き込めていないですが、再度、成功したSDでブートすると、最初からU-Boot 2020.04-at25 (Mar 06 2025 - 09:27:44 +0900)で起動するのですが、mmcblk0ではなく、mmcblk1で動作しています。したがって、JP、SDには問題ないと思うのですが・・・
以上、よろしくお願いします。
at_dominique.m…
> １．先ほど、提示があった方法で作成したDISKでは、JP,SDカードのクリーンを行っても、起動時からu-boot2018でした。
> ２．EMMCには書き込めていないですが、再度、成功したSDでブートすると、最初からU-Boot 2020.04-at25 (Mar 06 2025 - 09:27:44 +0900)で起動するのですが、mmcblk0ではなく、mmcblk1で動作しています。したがって、JP、SDには問題ないと思うのですが・・・
「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx --installer ./baseos-600-3.21.3-at.2.20250306.img」（起動できない installerイメージ生成) と「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx」(起動できた、インストールしない SD ブートイメージ生成）の違いは、rootfs の中身だけだと思い込んでいました、確認したところ u-boot の環境変数の領域もちがいます。
ただし、SD カードの u-boot が自分の環境領域を読み込めなかったとしても eMMC ブートに fallback するとは思えないので、どういうことかは正直わかりません。
u-boot は SD カードの 1KB から、環境変数を含めて 2MB までなので、生成したイメージをご自分で確認してください
# uboot を zero で padding します atmark@atde9:~/build-rootfs-v3.21-at.2$ cp ~/u-boot-2020.04-at25/u-boot-dtb.imx uboot_only atmark@atde9:~/build-rootfs-v3.21-at.2$ truncate -s $((2047*1024)) uboot_only # 起動できたイメージから uboot + 環境変数を読み取ります atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307.img bs=1k skip=1 count=2047 status=none > uboot_sdboot # インストーラーから同じく atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer # sdboot の方は同じ… atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_sdboot && echo identical identical # インストーラの方は、環境変数の領域がちがいます atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer && echo identical uboot_only uboot_installer differ: byte 2071553, line 4105 atmark@atde9:~/build-rootfs-v3.21-at.2$ printf "%x\n" 2071553 1f9c01 (環境変数は 0x1fa000 と 0x1fe000 にあって、このイメージは 1024 (0x400)で offset されています） # これで installer の環境変数をクリアします atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=/dev/zero of=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k seek=2024 count=20 conv=notrunc # 再確認 atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer_cleared atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer_cleared && echo identical identical
そのイメージでも起動できなかった場合は、申し訳ないですがお手上げです… インストールができなくても、2020.04-at25 の uboot に入るはずです。
大変ややっこしい手順になってしまって申し訳ございませんが、その「環境変数領域が削除された」イメージでもういちど試していただけますでしょうか。
よろしくお願いします
kazumori88
> > １．先ほど、提示があった方法で作成したDISKでは、JP,SDカードのクリーンを行っても、起動時からu-boot2018でした。
> > ２．EMMCには書き込めていないですが、再度、成功したSDでブートすると、最初からU-Boot 2020.04-at25 (Mar 06 2025 - 09:27:44 +0900)で起動するのですが、mmcblk0ではなく、mmcblk1で動作しています。したがって、JP、SDには問題ないと思うのですが・・・
>
>
> 「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx --installer ./baseos-600-3.21.3-at.2.20250306.img」（起動できない installerイメージ生成) と「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx」(起動できた、インストールしない SD ブートイメージ生成）の違いは、rootfs の中身だけだと思い込んでいました、確認したところ u-boot の環境変数の領域もちがいます。
>
> ただし、SD カードの u-boot が自分の環境領域を読み込めなかったとしても eMMC ブートに fallback するとは思えないので、どういうことかは正直わかりません。
>
> u-boot は SD カードの 1KB から、環境変数を含めて 2MB までなので、生成したイメージをご自分で確認してください
>
> # uboot を zero で padding します > atmark@atde9:~/build-rootfs-v3.21-at.2$ cp ~/u-boot-2020.04-at25/u-boot-dtb.imx uboot_only > atmark@atde9:~/build-rootfs-v3.21-at.2$ truncate -s $((2047*1024)) uboot_only > # 起動できたイメージから uboot + 環境変数を読み取ります > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307.img bs=1k skip=1 count=2047 status=none > uboot_sdboot > # インストーラーから同じく > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer > # sdboot の方は同じ… > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_sdboot && echo identical > identical > # インストーラの方は、環境変数の領域がちがいます > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer && echo identical > uboot_only uboot_installer differ: byte 2071553, line 4105 > atmark@atde9:~/build-rootfs-v3.21-at.2$ printf "%x\n" 2071553 > 1f9c01 > (環境変数は 0x1fa000 と 0x1fe000 にあって、このイメージは 1024 (0x400)で offset されています） > > # これで installer の環境変数をクリアします > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=/dev/zero of=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k seek=2024 count=20 conv=notrunc > # 再確認 > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer_cleared > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer_cleared && echo identical > identical >
>
> そのイメージでも起動できなかった場合は、申し訳ないですがお手上げです… インストールができなくても、2020.04-at25 の uboot に入るはずです。
>
> 大変ややっこしい手順になってしまって申し訳ございませんが、その「環境変数領域が削除された」イメージでもういちど試していただけますでしょうか。
>
>
> よろしくお願いします
お世話になります。
さっそく、試してみます。
kazumori88
> > > １．先ほど、提示があった方法で作成したDISKでは、JP,SDカードのクリーンを行っても、起動時からu-boot2018でした。
> > > ２．EMMCには書き込めていないですが、再度、成功したSDでブートすると、最初からU-Boot 2020.04-at25 (Mar 06 2025 - 09:27:44 +0900)で起動するのですが、mmcblk0ではなく、mmcblk1で動作しています。したがって、JP、SDには問題ないと思うのですが・・・
> >
> >
> > 「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx --installer ./baseos-600-3.21.3-at.2.20250306.img」（起動できない installerイメージ生成) と「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx」(起動できた、インストールしない SD ブートイメージ生成）の違いは、rootfs の中身だけだと思い込んでいました、確認したところ u-boot の環境変数の領域もちがいます。
> >
> > ただし、SD カードの u-boot が自分の環境領域を読み込めなかったとしても eMMC ブートに fallback するとは思えないので、どういうことかは正直わかりません。
> >
> > u-boot は SD カードの 1KB から、環境変数を含めて 2MB までなので、生成したイメージをご自分で確認してください
> >
> > # uboot を zero で padding します > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cp ~/u-boot-2020.04-at25/u-boot-dtb.imx uboot_only > > atmark@atde9:~/build-rootfs-v3.21-at.2$ truncate -s $((2047*1024)) uboot_only > > # 起動できたイメージから uboot + 環境変数を読み取ります > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307.img bs=1k skip=1 count=2047 status=none > uboot_sdboot > > # インストーラーから同じく > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer > > # sdboot の方は同じ… > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_sdboot && echo identical > > identical > > # インストーラの方は、環境変数の領域がちがいます > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer && echo identical > > uboot_only uboot_installer differ: byte 2071553, line 4105 > > atmark@atde9:~/build-rootfs-v3.21-at.2$ printf "%x\n" 2071553 > > 1f9c01 > > (環境変数は 0x1fa000 と 0x1fe000 にあって、このイメージは 1024 (0x400)で offset されています） > > > > # これで installer の環境変数をクリアします > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=/dev/zero of=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k seek=2024 count=20 conv=notrunc > > # 再確認 > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer_cleared > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer_cleared && echo identical > > identical > >
> >
> > そのイメージでも起動できなかった場合は、申し訳ないですがお手上げです… インストールができなくても、2020.04-at25 の uboot に入るはずです。
> >
> > 大変ややっこしい手順になってしまって申し訳ございませんが、その「環境変数領域が削除された」イメージでもういちど試していただけますでしょうか。
> >
> >
> > よろしくお願いします
>
> お世話になります。
>
> さっそく、試してみます。
お世話になります。
１．提示いただいたとおりに行い、baseos-600-3.21.3-at.2.20250307-installer.imgをSDに書き込みましたが、
結果は、起動時からu-boot2018でした。u-boot2020も表示されません。
２．最初から気になっているのは、debianで動作しているパーティション構造が異なる状態を書き替えれるのか、気になっています。emmcがパーティション変更を許可していないように見えます。
３．動作しているmmcblk1をmmcblk0に反映する方法はないのでしょうか？
以上、よろしくお願いします。
kazumori88
> > > > １．先ほど、提示があった方法で作成したDISKでは、JP,SDカードのクリーンを行っても、起動時からu-boot2018でした。
> > > > ２．EMMCには書き込めていないですが、再度、成功したSDでブートすると、最初からU-Boot 2020.04-at25 (Mar 06 2025 - 09:27:44 +0900)で起動するのですが、mmcblk0ではなく、mmcblk1で動作しています。したがって、JP、SDには問題ないと思うのですが・・・
> > >
> > >
> > > 「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx --installer ./baseos-600-3.21.3-at.2.20250306.img」（起動できない installerイメージ生成) と「./build_image.sh --board a600 --boot ~/u-boot-2020.04-at25/u-boot-dtb.imx」(起動できた、インストールしない SD ブートイメージ生成）の違いは、rootfs の中身だけだと思い込んでいました、確認したところ u-boot の環境変数の領域もちがいます。
> > >
> > > ただし、SD カードの u-boot が自分の環境領域を読み込めなかったとしても eMMC ブートに fallback するとは思えないので、どういうことかは正直わかりません。
> > >
> > > u-boot は SD カードの 1KB から、環境変数を含めて 2MB までなので、生成したイメージをご自分で確認してください
> > >
> > > # uboot を zero で padding します > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cp ~/u-boot-2020.04-at25/u-boot-dtb.imx uboot_only > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ truncate -s $((2047*1024)) uboot_only > > > # 起動できたイメージから uboot + 環境変数を読み取ります > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307.img bs=1k skip=1 count=2047 status=none > uboot_sdboot > > > # インストーラーから同じく > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer > > > # sdboot の方は同じ… > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_sdboot && echo identical > > > identical > > > # インストーラの方は、環境変数の領域がちがいます > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer && echo identical > > > uboot_only uboot_installer differ: byte 2071553, line 4105 > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ printf "%x\n" 2071553 > > > 1f9c01 > > > (環境変数は 0x1fa000 と 0x1fe000 にあって、このイメージは 1024 (0x400)で offset されています） > > > > > > # これで installer の環境変数をクリアします > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=/dev/zero of=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k seek=2024 count=20 conv=notrunc > > > # 再確認 > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ dd if=baseos-600-3.21.3-at.2.20250307-installer.img bs=1k skip=1 count=2047 status=none > uboot_installer_cleared > > > atmark@atde9:~/build-rootfs-v3.21-at.2$ cmp uboot_only uboot_installer_cleared && echo identical > > > identical > > >
> > >
> > > そのイメージでも起動できなかった場合は、申し訳ないですがお手上げです… インストールができなくても、2020.04-at25 の uboot に入るはずです。
> > >
> > > 大変ややっこしい手順になってしまって申し訳ございませんが、その「環境変数領域が削除された」イメージでもういちど試していただけますでしょうか。
> > >
> > >
> > > よろしくお願いします
> >
> > お世話になります。
> >
> > さっそく、試してみます。
>
> お世話になります。
> １．提示いただいたとおりに行い、baseos-600-3.21.3-at.2.20250307-installer.imgをSDに書き込みましたが、
> 結果は、起動時からu-boot2018でした。u-boot2020も表示されません。
> ２．最初から気になっているのは、debianで動作しているパーティション構造が異なる状態を書き替えれるのか、気になっています。emmcがパーティション変更を許可していないように見えます。
> ３．動作しているmmcblk1をmmcblk0に反映する方法はないのでしょうか？
>
> 以上、よろしくお願いします。
>
at_dominique.m…
マルティネです。
> １．提示いただいたとおりに行い、baseos-600-3.21.3-at.2.20250307-installer.imgをSDに書き込みましたが、
> 結果は、起動時からu-boot2018でした。u-boot2020も表示されません。
。。。
分かりました、このイメージも諦めましょう。
> ２．最初から気になっているのは、debianで動作しているパーティション構造が異なる状態を書き替えれるのか、気になっています。emmcがパーティション変更を許可していないように見えます。
そこは問題ないと思います。
eMMC のハードウェアパーティション（mmcblk0gp* 等）は変更できなくても、Armadillo Base OS 自体のパーティション（mmcblk0p*) の変更を防ぐことはできません。
インストーラーを起動するとパーティションテーブルをすべてクリアして作り直してますので、問題ないはずです。
（少なくとも、uboot が起動しないようなトラブルになりません…）
> ３．動作しているmmcblk1をmmcblk0に反映する方法はないのでしょうか？
できないことはないですが、そういう想定はしてないので、これもこれでややっこしいことになりますね…
# appfs を故障させないため小さくします
armadillo:~# btrfs fi resize 1G /var/tmp
Resize device id 1 (/dev/mmcblk1p5) from XXXGiB to 1.00GiB
armadillo:~# sync
# ディスクの頭の 2GB をコピーします
armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=1M count=2000 oflag=direct
2000+0 records in
2000+0 records out
2097152000 bytes (2.0GB) copied, 107.952535 seconds, 18.5MB/s
# uboot をコピーします
armadillo:~# echo 0 > /sys/class/block/mmcblk0boot0/force_ro
armadillo:~# dd if=/dev/zero of=/dev/mmcblk0boot0 bs=1M
dd: error writing '/dev/mmcblk0boot0': No space left on device
3+0 records in
2+0 records out
2097152 bytes (2.0MB) copied, 0.022449 seconds, 89.1MB/s
armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0boot0 bs=1k skip=1 seek=1 count=1000
1000+0 records in
1000+0 records out
1024000 bytes (1000.0KB) copied, 0.341439 seconds, 2.9MB/s
# その uboot を使うように設定します
armadillo:~# mmc bootpart enable 1 0 /dev/mmcblk0
# コピーしたディスクの最後のパーティションのサイズを直します
armadillo:~# sgdisk -d 5 /dev/mmcblk0
armadillo:~# sgdisk -n 5:0:0 -c 5:app /dev/mmcblk0
armadillo:~# sgdisk -p /dev/mmcblk0
Disk /dev/mmcblk0: 7405568 sectors, 3.5 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): F5992FFB-2DAD-48AA-B00D-BC6B8F61B1B8
Partition table holds up to 128 entries
Main partition table begins at sector 20448 and ends at sector 20479
First usable sector is 20480, last usable sector is 7385088
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)
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 7385088 2.7 GiB 8300 app
# uuid を変更しないとマウントできないので、
# (インストールされてない btrfstune コマンドが必要)
# 一度 eMMC に再起動して修正の必要なファイルを直します。
armadillo:~# poweroff
# jp1抜いて、uboot に入るために sw1 を押しながら電源入れ直し
# SD は残しても外してもいいです。
=> setenv mmcpart 1
=> setenv mmcroot /dev/mmcblk0p1 rootwait rw
=> setenv optargs init=/bin/sh
=> boot
# / のファイルの直します
~ # sed -i -e 's/mmcblk1/mmcblk0/' /etc/fstab
~ # sed -i -e 's/mmcblk1/mmcblk0boot0/' /etc/fw_env.config
# appfs を直します
~ # mount /dev/mmcblk0p5 /mnt
~ # btrfs fi resize max /mnt
~ # df -h /mnt
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p5 2.7G 3.7M 2.2G 0% /mnt
# 再起動
~ # sync
~ # reboot -nf
# login して、最終確認
armadillo:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 3.5G 0 disk
├─mmcblk0p1 179:1 0 300M 0 part /live/rootfs
├─mmcblk0p2 179:2 0 300M 0 part
├─mmcblk0p3 179:3 0 50M 0 part /var/log
├─mmcblk0p4 179:4 0 200M 0 part
└─mmcblk0p5 179:5 0 2.7G 0 part /var/tmp
/var/app/volumes
/var/app/rollback/volumes
/var/lib/containers/storage_readonly
mmcblk0boot0 179:8 0 2M 1 disk
mmcblk0boot1 179:16 0 2M 1 disk
mmcblk0gp0 179:24 0 8M 0 disk
mmcblk0gp1 179:32 0 8M 0 disk
mmcblk0gp2 179:40 0 8M 0 disk
mmcblk0gp3 179:48 0 8M 0 disk
mmcblk1 179:56 0 3.7G 0 disk
├─mmcblk1p1 179:57 0 300M 0 part
├─mmcblk1p2 179:58 0 300M 0 part
├─mmcblk1p3 179:59 0 50M 0 part
├─mmcblk1p4 179:60 0 200M 0 part
└─mmcblk1p5 179:61 0 2.8G 0 part
zram0 254:0 0 244.1M 0 disk [SWAP]これで大体大丈夫だと思いますが、普段使ってない手順（初めて書きました…）なので、正直インストーラーを動かすようにした方がいいとは思いつつアイデアがないもので…
お手数をお掛けしますが、よろしくお願いします。
kazumori88
> マルティネです。
>
> > １．提示いただいたとおりに行い、baseos-600-3.21.3-at.2.20250307-installer.imgをSDに書き込みましたが、
> > 結果は、起動時からu-boot2018でした。u-boot2020も表示されません。
>
> 。。。
> 分かりました、このイメージも諦めましょう。
>
> > ２．最初から気になっているのは、debianで動作しているパーティション構造が異なる状態を書き替えれるのか、気になっています。emmcがパーティション変更を許可していないように見えます。
>
> そこは問題ないと思います。
> eMMC のハードウェアパーティション（mmcblk0gp* 等）は変更できなくても、Armadillo Base OS 自体のパーティション（mmcblk0p*) の変更を防ぐことはできません。
> インストーラーを起動するとパーティションテーブルをすべてクリアして作り直してますので、問題ないはずです。
> （少なくとも、uboot が起動しないようなトラブルになりません…）
>
> > ３．動作しているmmcblk1をmmcblk0に反映する方法はないのでしょうか？
>
> できないことはないですが、そういう想定はしてないので、これもこれでややっこしいことになりますね…
>
>
> # appfs を故障させないため小さくします > armadillo:~# btrfs fi resize 1G /var/tmp > Resize device id 1 (/dev/mmcblk1p5) from XXXGiB to 1.00GiB > armadillo:~# sync > > # ディスクの頭の 2GB をコピーします > armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=1M count=2000 oflag=direct > 2000+0 records in > 2000+0 records out > 2097152000 bytes (2.0GB) copied, 107.952535 seconds, 18.5MB/s > > # uboot をコピーします > armadillo:~# echo 0 > /sys/class/block/mmcblk0boot0/force_ro > armadillo:~# dd if=/dev/zero of=/dev/mmcblk0boot0 bs=1M > dd: error writing '/dev/mmcblk0boot0': No space left on device > 3+0 records in > 2+0 records out > 2097152 bytes (2.0MB) copied, 0.022449 seconds, 89.1MB/s > armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0boot0 bs=1k skip=1 seek=1 count=1000 > 1000+0 records in > 1000+0 records out > 1024000 bytes (1000.0KB) copied, 0.341439 seconds, 2.9MB/s > > # その uboot を使うように設定します > armadillo:~# mmc bootpart enable 1 0 /dev/mmcblk0 > > # コピーしたディスクの最後のパーティションのサイズを直します > armadillo:~# sgdisk -d 5 /dev/mmcblk0 > armadillo:~# sgdisk -n 5:0:0 -c 5:app /dev/mmcblk0 > armadillo:~# sgdisk -p /dev/mmcblk0 > Disk /dev/mmcblk0: 7405568 sectors, 3.5 GiB > Sector size (logical/physical): 512/512 bytes > Disk identifier (GUID): F5992FFB-2DAD-48AA-B00D-BC6B8F61B1B8 > Partition table holds up to 128 entries > Main partition table begins at sector 20448 and ends at sector 20479 > First usable sector is 20480, last usable sector is 7385088 > Partitions will be aligned on 2048-sector boundaries > Total free space is 0 sectors (0 bytes) > > 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 7385088 2.7 GiB 8300 app > > # uuid を変更しないとマウントできないので、 > # (インストールされてない btrfstune コマンドが必要) > # 一度 eMMC に再起動して修正の必要なファイルを直します。 > armadillo:~# poweroff > # jp1抜いて、uboot に入るために sw1 を押しながら電源入れ直し > # SD は残しても外してもいいです。 > => setenv mmcpart 1 > => setenv mmcroot /dev/mmcblk0p1 rootwait rw > => setenv optargs init=/bin/sh > => boot > > # / のファイルの直します > ~ # sed -i -e 's/mmcblk1/mmcblk0/' /etc/fstab > ~ # sed -i -e 's/mmcblk1/mmcblk0boot0/' /etc/fw_env.config > > # appfs を直します > ~ # mount /dev/mmcblk0p5 /mnt > ~ # btrfs fi resize max /mnt > ~ # df -h /mnt > Filesystem Size Used Available Use% Mounted on > /dev/mmcblk0p5 2.7G 3.7M 2.2G 0% /mnt > > # 再起動 > ~ # sync > ~ # reboot -nf > > # login して、最終確認 > armadillo:~# lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > mmcblk0 179:0 0 3.5G 0 disk > ├─mmcblk0p1 179:1 0 300M 0 part /live/rootfs > ├─mmcblk0p2 179:2 0 300M 0 part > ├─mmcblk0p3 179:3 0 50M 0 part /var/log > ├─mmcblk0p4 179:4 0 200M 0 part > └─mmcblk0p5 179:5 0 2.7G 0 part /var/tmp > /var/app/volumes > /var/app/rollback/volumes > /var/lib/containers/storage_readonly > mmcblk0boot0 179:8 0 2M 1 disk > mmcblk0boot1 179:16 0 2M 1 disk > mmcblk0gp0 179:24 0 8M 0 disk > mmcblk0gp1 179:32 0 8M 0 disk > mmcblk0gp2 179:40 0 8M 0 disk > mmcblk0gp3 179:48 0 8M 0 disk > mmcblk1 179:56 0 3.7G 0 disk > ├─mmcblk1p1 179:57 0 300M 0 part > ├─mmcblk1p2 179:58 0 300M 0 part > ├─mmcblk1p3 179:59 0 50M 0 part > ├─mmcblk1p4 179:60 0 200M 0 part > └─mmcblk1p5 179:61 0 2.8G 0 part > zram0 254:0 0 244.1M 0 disk [SWAP] >
>
> これで大体大丈夫だと思いますが、普段使ってない手順（初めて書きました…）なので、正直インストーラーを動かすようにした方がいいとは思いつつアイデアがないもので…
>
> お手数をお掛けしますが、よろしくお願いします。
マルティネ 様
お世話になります。
土日、トライしてみます。
kazumori88
> > マルティネです。
> >
> > > １．提示いただいたとおりに行い、baseos-600-3.21.3-at.2.20250307-installer.imgをSDに書き込みましたが、
> > > 結果は、起動時からu-boot2018でした。u-boot2020も表示されません。
> >
> > 。。。
> > 分かりました、このイメージも諦めましょう。
> >
> > > ２．最初から気になっているのは、debianで動作しているパーティション構造が異なる状態を書き替えれるのか、気になっています。emmcがパーティション変更を許可していないように見えます。
> >
> > そこは問題ないと思います。
> > eMMC のハードウェアパーティション（mmcblk0gp* 等）は変更できなくても、Armadillo Base OS 自体のパーティション（mmcblk0p*) の変更を防ぐことはできません。
> > インストーラーを起動するとパーティションテーブルをすべてクリアして作り直してますので、問題ないはずです。
> > （少なくとも、uboot が起動しないようなトラブルになりません…）
> >
> > > ３．動作しているmmcblk1をmmcblk0に反映する方法はないのでしょうか？
> >
> > できないことはないですが、そういう想定はしてないので、これもこれでややっこしいことになりますね…
> >
> >
> > # appfs を故障させないため小さくします > > armadillo:~# btrfs fi resize 1G /var/tmp > > Resize device id 1 (/dev/mmcblk1p5) from XXXGiB to 1.00GiB > > armadillo:~# sync > > > > # ディスクの頭の 2GB をコピーします > > armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=1M count=2000 oflag=direct > > 2000+0 records in > > 2000+0 records out > > 2097152000 bytes (2.0GB) copied, 107.952535 seconds, 18.5MB/s > > > > # uboot をコピーします > > armadillo:~# echo 0 > /sys/class/block/mmcblk0boot0/force_ro > > armadillo:~# dd if=/dev/zero of=/dev/mmcblk0boot0 bs=1M > > dd: error writing '/dev/mmcblk0boot0': No space left on device > > 3+0 records in > > 2+0 records out > > 2097152 bytes (2.0MB) copied, 0.022449 seconds, 89.1MB/s > > armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0boot0 bs=1k skip=1 seek=1 count=1000 > > 1000+0 records in > > 1000+0 records out > > 1024000 bytes (1000.0KB) copied, 0.341439 seconds, 2.9MB/s > > > > # その uboot を使うように設定します > > armadillo:~# mmc bootpart enable 1 0 /dev/mmcblk0 > > > > # コピーしたディスクの最後のパーティションのサイズを直します > > armadillo:~# sgdisk -d 5 /dev/mmcblk0 > > armadillo:~# sgdisk -n 5:0:0 -c 5:app /dev/mmcblk0 > > armadillo:~# sgdisk -p /dev/mmcblk0 > > Disk /dev/mmcblk0: 7405568 sectors, 3.5 GiB > > Sector size (logical/physical): 512/512 bytes > > Disk identifier (GUID): F5992FFB-2DAD-48AA-B00D-BC6B8F61B1B8 > > Partition table holds up to 128 entries > > Main partition table begins at sector 20448 and ends at sector 20479 > > First usable sector is 20480, last usable sector is 7385088 > > Partitions will be aligned on 2048-sector boundaries > > Total free space is 0 sectors (0 bytes) > > > > 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 7385088 2.7 GiB 8300 app > > > > # uuid を変更しないとマウントできないので、 > > # (インストールされてない btrfstune コマンドが必要) > > # 一度 eMMC に再起動して修正の必要なファイルを直します。 > > armadillo:~# poweroff > > # jp1抜いて、uboot に入るために sw1 を押しながら電源入れ直し > > # SD は残しても外してもいいです。 > > => setenv mmcpart 1 > > => setenv mmcroot /dev/mmcblk0p1 rootwait rw > > => setenv optargs init=/bin/sh > > => boot > > > > # / のファイルの直します > > ~ # sed -i -e 's/mmcblk1/mmcblk0/' /etc/fstab > > ~ # sed -i -e 's/mmcblk1/mmcblk0boot0/' /etc/fw_env.config > > > > # appfs を直します > > ~ # mount /dev/mmcblk0p5 /mnt > > ~ # btrfs fi resize max /mnt > > ~ # df -h /mnt > > Filesystem Size Used Available Use% Mounted on > > /dev/mmcblk0p5 2.7G 3.7M 2.2G 0% /mnt > > > > # 再起動 > > ~ # sync > > ~ # reboot -nf > > > > # login して、最終確認 > > armadillo:~# lsblk > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > > mmcblk0 179:0 0 3.5G 0 disk > > ├─mmcblk0p1 179:1 0 300M 0 part /live/rootfs > > ├─mmcblk0p2 179:2 0 300M 0 part > > ├─mmcblk0p3 179:3 0 50M 0 part /var/log > > ├─mmcblk0p4 179:4 0 200M 0 part > > └─mmcblk0p5 179:5 0 2.7G 0 part /var/tmp > > /var/app/volumes > > /var/app/rollback/volumes > > /var/lib/containers/storage_readonly > > mmcblk0boot0 179:8 0 2M 1 disk > > mmcblk0boot1 179:16 0 2M 1 disk > > mmcblk0gp0 179:24 0 8M 0 disk > > mmcblk0gp1 179:32 0 8M 0 disk > > mmcblk0gp2 179:40 0 8M 0 disk > > mmcblk0gp3 179:48 0 8M 0 disk > > mmcblk1 179:56 0 3.7G 0 disk > > ├─mmcblk1p1 179:57 0 300M 0 part > > ├─mmcblk1p2 179:58 0 300M 0 part > > ├─mmcblk1p3 179:59 0 50M 0 part > > ├─mmcblk1p4 179:60 0 200M 0 part > > └─mmcblk1p5 179:61 0 2.8G 0 part > > zram0 254:0 0 244.1M 0 disk [SWAP] > >
> >
> > これで大体大丈夫だと思いますが、普段使ってない手順（初めて書きました…）なので、正直インストーラーを動かすようにした方がいいとは思いつつアイデアがないもので…
> >
> > お手数をお掛けしますが、よろしくお願いします。
>
> マルティネ 様
> お世話になります。
>
> 土日、トライしてみます。
>
>
>
kazumori88
> > > マルティネです。
> > >
> > > > １．提示いただいたとおりに行い、baseos-600-3.21.3-at.2.20250307-installer.imgをSDに書き込みましたが、
> > > > 結果は、起動時からu-boot2018でした。u-boot2020も表示されません。
> > >
> > > 。。。
> > > 分かりました、このイメージも諦めましょう。
> > >
> > > > ２．最初から気になっているのは、debianで動作しているパーティション構造が異なる状態を書き替えれるのか、気になっています。emmcがパーティション変更を許可していないように見えます。
> > >
> > > そこは問題ないと思います。
> > > eMMC のハードウェアパーティション（mmcblk0gp* 等）は変更できなくても、Armadillo Base OS 自体のパーティション（mmcblk0p*) の変更を防ぐことはできません。
> > > インストーラーを起動するとパーティションテーブルをすべてクリアして作り直してますので、問題ないはずです。
> > > （少なくとも、uboot が起動しないようなトラブルになりません…）
> > >
> > > > ３．動作しているmmcblk1をmmcblk0に反映する方法はないのでしょうか？
> > >
> > > できないことはないですが、そういう想定はしてないので、これもこれでややっこしいことになりますね…
> > >
> > >
> > > # appfs を故障させないため小さくします > > > armadillo:~# btrfs fi resize 1G /var/tmp > > > Resize device id 1 (/dev/mmcblk1p5) from XXXGiB to 1.00GiB > > > armadillo:~# sync > > > > > > # ディスクの頭の 2GB をコピーします > > > armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0 bs=1M count=2000 oflag=direct > > > 2000+0 records in > > > 2000+0 records out > > > 2097152000 bytes (2.0GB) copied, 107.952535 seconds, 18.5MB/s > > > > > > # uboot をコピーします > > > armadillo:~# echo 0 > /sys/class/block/mmcblk0boot0/force_ro > > > armadillo:~# dd if=/dev/zero of=/dev/mmcblk0boot0 bs=1M > > > dd: error writing '/dev/mmcblk0boot0': No space left on device > > > 3+0 records in > > > 2+0 records out > > > 2097152 bytes (2.0MB) copied, 0.022449 seconds, 89.1MB/s > > > armadillo:~# dd if=/dev/mmcblk1 of=/dev/mmcblk0boot0 bs=1k skip=1 seek=1 count=1000 > > > 1000+0 records in > > > 1000+0 records out > > > 1024000 bytes (1000.0KB) copied, 0.341439 seconds, 2.9MB/s > > > > > > # その uboot を使うように設定します > > > armadillo:~# mmc bootpart enable 1 0 /dev/mmcblk0 > > > > > > # コピーしたディスクの最後のパーティションのサイズを直します > > > armadillo:~# sgdisk -d 5 /dev/mmcblk0 > > > armadillo:~# sgdisk -n 5:0:0 -c 5:app /dev/mmcblk0 > > > armadillo:~# sgdisk -p /dev/mmcblk0 > > > Disk /dev/mmcblk0: 7405568 sectors, 3.5 GiB > > > Sector size (logical/physical): 512/512 bytes > > > Disk identifier (GUID): F5992FFB-2DAD-48AA-B00D-BC6B8F61B1B8 > > > Partition table holds up to 128 entries > > > Main partition table begins at sector 20448 and ends at sector 20479 > > > First usable sector is 20480, last usable sector is 7385088 > > > Partitions will be aligned on 2048-sector boundaries > > > Total free space is 0 sectors (0 bytes) > > > > > > 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 7385088 2.7 GiB 8300 app > > > > > > # uuid を変更しないとマウントできないので、 > > > # (インストールされてない btrfstune コマンドが必要) > > > # 一度 eMMC に再起動して修正の必要なファイルを直します。 > > > armadillo:~# poweroff > > > # jp1抜いて、uboot に入るために sw1 を押しながら電源入れ直し > > > # SD は残しても外してもいいです。 > > > => setenv mmcpart 1 > > > => setenv mmcroot /dev/mmcblk0p1 rootwait rw > > > => setenv optargs init=/bin/sh > > > => boot > > > > > > # / のファイルの直します > > > ~ # sed -i -e 's/mmcblk1/mmcblk0/' /etc/fstab > > > ~ # sed -i -e 's/mmcblk1/mmcblk0boot0/' /etc/fw_env.config > > > > > > # appfs を直します > > > ~ # mount /dev/mmcblk0p5 /mnt > > > ~ # btrfs fi resize max /mnt > > > ~ # df -h /mnt > > > Filesystem Size Used Available Use% Mounted on > > > /dev/mmcblk0p5 2.7G 3.7M 2.2G 0% /mnt > > > > > > # 再起動 > > > ~ # sync > > > ~ # reboot -nf > > > > > > # login して、最終確認 > > > armadillo:~# lsblk > > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > > > mmcblk0 179:0 0 3.5G 0 disk > > > ├─mmcblk0p1 179:1 0 300M 0 part /live/rootfs > > > ├─mmcblk0p2 179:2 0 300M 0 part > > > ├─mmcblk0p3 179:3 0 50M 0 part /var/log > > > ├─mmcblk0p4 179:4 0 200M 0 part > > > └─mmcblk0p5 179:5 0 2.7G 0 part /var/tmp > > > /var/app/volumes > > > /var/app/rollback/volumes > > > /var/lib/containers/storage_readonly > > > mmcblk0boot0 179:8 0 2M 1 disk > > > mmcblk0boot1 179:16 0 2M 1 disk > > > mmcblk0gp0 179:24 0 8M 0 disk > > > mmcblk0gp1 179:32 0 8M 0 disk > > > mmcblk0gp2 179:40 0 8M 0 disk > > > mmcblk0gp3 179:48 0 8M 0 disk > > > mmcblk1 179:56 0 3.7G 0 disk > > > ├─mmcblk1p1 179:57 0 300M 0 part > > > ├─mmcblk1p2 179:58 0 300M 0 part > > > ├─mmcblk1p3 179:59 0 50M 0 part > > > ├─mmcblk1p4 179:60 0 200M 0 part > > > └─mmcblk1p5 179:61 0 2.8G 0 part > > > zram0 254:0 0 244.1M 0 disk [SWAP] > > >
> > >
> > > これで大体大丈夫だと思いますが、普段使ってない手順（初めて書きました…）なので、正直インストーラーを動かすようにした方がいいとは思いつつアイデアがないもので…
> > >
> > > お手数をお掛けしますが、よろしくお願いします。
> >
> > マルティネ 様
> > お世話になります。
> >
> > 土日、トライしてみます。
> >
> >
> >
マルティネ 様
太田 様
お世話になります。
１．提示いただいたmmcblk1からmmcblk0への移行（追加修正）で、動作させることができ、ABOSの次のステップに進むことができました。
＜追加修正＞
・mount /dev/mmcblk0p5 /mntでmountできず
・mount -t proc proc /procを実行後にmount /dev/mmcblk0p5 /mntを再開
ありがとうございました。
２．私が参照していたArmadillo-640製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応 （pdf版）では
・6.21.3. Alpine Linux ルートファイルシステムをビルドする（p.391）で
「手順を実行すると、ビルドされた baseos-600-[VERSION].tar.zst が自動的に利用されます。」
と記載されており
6.20.1. ブートディスクの作成（p381）では、
/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 --boot ~/u-boot-[VERSION]/u-boot-dtb.imxの実行だけと記載されています。
実際にこの方法で作成されたimageのみが、mmcblk1ですが、動作したimageでした。（参考までに）
以上、よろしくお願いします。
martinetd
マルティネです。
> １．提示いただいたmmcblk1からmmcblk0への移行（追加修正）で、動作させることができ、ABOSの次のステップに進むことができました。
大変なことになりましたが、最終的にインストールできてなによりです。
> ＜追加修正＞
> ・mount /dev/mmcblk0p5 /mntでmountできず
> ・mount -t proc proc /procを実行後にmount /dev/mmcblk0p5 /mntを再開
こちらについてありがとうございます、df等を実行するために proc/sysfs もマウントしていた記憶あります…
また必要になった場合に参考させていただきます。
> ２．私が参照していたArmadillo-640製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応 （pdf版）では
> ・6.21.3. Alpine Linux ルートファイルシステムをビルドする（p.391）で
> 「手順を実行すると、ビルドされた baseos-600-[VERSION].tar.zst が自動的に利用されます。」
> と記載されており
> 6.20.1. ブートディスクの作成（p381）では、
> /build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 --boot ~/u-boot-[VERSION]/u-boot-dtb.imxの実行だけと記載されています。
> 実際にこの方法で作成されたimageのみが、mmcblk1ですが、動作したimageでした。（参考までに）
ありがとうございます。
こちらの「インストールディスクを機動できない」不具合については本当に申し訳ございません。
正直なところ、分からないままでは不満いっぱいでその個体を送っていただきたいぐらいですが、ひとまずこの情報だけをまた発生したら参考させていただきます。
ちなみに、時間あれば、ABOS をインストールした後現在でしたらインストールディスクに再び起動してみていただけますでしょうか？
理由としては半分は好奇心ですが、コピーの手順は大急ぎで準備したものなので、結果として差はないと思いつつインストールディスクでインストールされたシステムを使っていただいた方が安心です。
（debian では「mmc bootpart enable 1 0 /dev/mmcblk0」と違う設定を使ってますので、起動シーケンスに影響あるかもしれません。できるようになった場合は今度このあたりから探したいと思います）
よろしくお願いします
kazumori88
> マルティネです。
>
> > １．提示いただいたmmcblk1からmmcblk0への移行（追加修正）で、動作させることができ、ABOSの次のステップに進むことができました。
>
> 大変なことになりましたが、最終的にインストールできてなによりです。
>
> > ＜追加修正＞
> > ・mount /dev/mmcblk0p5 /mntでmountできず
> > ・mount -t proc proc /procを実行後にmount /dev/mmcblk0p5 /mntを再開
>
> こちらについてありがとうございます、df等を実行するために proc/sysfs もマウントしていた記憶あります…
> また必要になった場合に参考させていただきます。
>
> > ２．私が参照していたArmadillo-640製品マニュアル Version 4.19.0 2025/02/26 Armadillo Base OS 対応 （pdf版）では
> > ・6.21.3. Alpine Linux ルートファイルシステムをビルドする（p.391）で
> > 「手順を実行すると、ビルドされた baseos-600-[VERSION].tar.zst が自動的に利用されます。」
> > と記載されており
> > 6.20.1. ブートディスクの作成（p381）では、
> > /build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a600 --boot ~/u-boot-[VERSION]/u-boot-dtb.imxの実行だけと記載されています。
> > 実際にこの方法で作成されたimageのみが、mmcblk1ですが、動作したimageでした。（参考までに）
>
> ありがとうございます。
> こちらの「インストールディスクを機動できない」不具合については本当に申し訳ございません。
> 正直なところ、分からないままでは不満いっぱいでその個体を送っていただきたいぐらいですが、ひとまずこの情報だけをまた発生したら参考させていただきます。
>
> ちなみに、時間あれば、ABOS をインストールした後現在でしたらインストールディスクに再び起動してみていただけますでしょうか？
>
> 理由としては半分は好奇心ですが、コピーの手順は大急ぎで準備したものなので、結果として差はないと思いつつインストールディスクでインストールされたシステムを使っていただいた方が安心です。
> （debian では「mmc bootpart enable 1 0 /dev/mmcblk0」と違う設定を使ってますので、起動シーケンスに影響あるかもしれません。できるようになった場合は今度このあたりから探したいと思います）
>
> よろしくお願いします
お世話になります。
１．その後、いまのところ、順調に動作しているので、一段落したら、トライしてみます。
２．ここでの質問でいいのか、わかりませんが、
・3.13.3.4. アプリケーション実行用コンテナイメージの作成を行いました。
・ここから、3.13.6. コンテナ内のファイル一覧表示でABOSDEのOPEND_PROJECTで表示されるcontainerとEXPLORERで表示されるcontainer/resoucesで表示される内容について、説明があるのですが、関係性がよくわかりません。
参考にすべきところがあれば教えてください。
at_dominique.m…
kazumori88さん
マルティネです
> １．その後、いまのところ、順調に動作しているので、一段落したら、トライしてみます。
了解しました、その時によろしくお願いします
> ２．ここでの質問でいいのか、わかりませんが、
> ・3.13.3.4. アプリケーション実行用コンテナイメージの作成を行いました。
> ・ここから、3.13.6. コンテナ内のファイル一覧表示でABOSDEのOPEND_PROJECTで表示されるcontainerとEXPLORERで表示されるcontainer/resoucesで表示される内容について、説明があるのですが、関係性がよくわかりません。
>
> 参考にすべきところがあれば教えてください。
お差し支えなければ新規投稿でお願いします。
（ひとまずの回答として、自分はあまり ABOSDE を使ってないので勘違いしているかもしれませんが、コンテナの中身は最新にビルドしたコンテナイメージの中身を確認できて、そこにファイルを編集すると container/resources に実際にコピー・編集されて次にイメージをビルドするときに反映されると思います）
よろしくお願いします
at_satoshi.ohta
2025年2月27日 12時44分
太田です。
特別な理由がない限り、アプリケーションを１つのコンテナの中で動かして問題ないと思います。
Armadillo Base OS では VS Code で拡張機能として ABOSDE という開発環境を提供しています。
ABOSDE では shell や python , flutter などによる開発をサポートするためにサンプルプログラムをプロジェクトとして提供しています。
今回の場合は、python プロジェクトを使用するのが適切かと思います。
どうぞよろしくお願いいたします。