yasuda0108
2022年3月23日 15時53分
Armadillo-G4のCON9 25~28pinにて、GPIOおよびPWMの使用を検討しております。
こちらを使用するための設定方法について記載の情報がありましたらお教えください。
また、URLに従ってGPIOの動作を確認しようとしましたが、apk commandが使用できないエラーがでます。
こちらの解決方法についてもお教えいただけると幸いです。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
root@9210d09c4efc:/# apk update && apk upgrade bash: apk: command not found
コメント
yasuda0108
ご回答ありがとうございます。
①GPIOについて
debianコンテナでapkを入力しておりました。大変失礼いたしました。
aptでgpiodパッケージインストールを試しましたが、インストール時にエラーが出ます。
そのため、gpiogetが使用できないようです。
インストール方法についてご指摘有ありましたら、お教え頂けますでしょうか。
root@9210d09c4efc:/# apt install libgpiod Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package libgpiod root@9210d09c4efc:/# gpioget gpiochip2 21 bash: gpioget: command not found
②PWM使用設定について
at-dtwebを起動し、デバイスツリーの変更を実施しようとしましたが、「CON11」の設定画面のみ出ている状況です。
「CON9」の設定をat-dtweb上でどのように実施するのでしょうか?
yasuda0108
at_dominique.m…
yasuda0108さん
> ①GPIOについて
> root@9210d09c4efc:/# apt install libgpiod > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > E: Unable to locate package libgpiod
debian のパッケージは gpiod です。 libgpiodではありません。
これでもみつからなかったら、apt updateも先に実行してください。
> ②PWM使用設定について
> at-dtwebを起動し、デバイスツリーの変更を実施しようとしましたが、「CON11」の設定画面のみ出ている状況です。
> 「CON9」の設定をat-dtweb上でどのように実施するのでしょうか?
こちらは失礼致しました。確かに at-dtweb では CON9 の設定が現在できませんですね。
一応確認したらいくつかの pin を pwm として使えますが、そのなかのどれを使いたいと教えてくれたらこちらでdtsを作成しましょうか。
CON9.7 - I2C4_SDL - PWM2
CON9.8 - I2C4_SDA - PWM1
CON9.27 - GPIO5IO03 - PWM3
CON9.28 - GPIO5IO04 - PWM2
よろしくお願いします。
yasuda0108
ご対応誠にありがとうございます。
CON9設定ですが、「CON9.28 - GPIO5IO04 - PWM2」をPWM制御用に使用したく存じます。
dts作成の程、何卒よろしくお願いいたします。
また、GPIOについてですが、「CON9.26 - GPIO3IO01」をHi/Low変更させようとコマンド入力しましたが、
下記のようなエラーとなります。入力方法に問題があるのでしょうか。
root@9210d09c4efc:/# gpioget gpiochip3 1 gpioget: error reading GPIO values: Device or resource busy
at_dominique.m…
> CON9設定ですが、「CON9.28 - GPIO5IO04 - PWM2」をPWM制御用に使用したく存じます。
> dts作成の程、何卒よろしくお願いいたします。
了解しました。
明日確認してから送ります。
> また、GPIOについてですが、「CON9.26 - GPIO3IO01」をHi/Low変更させようとコマンド入力しましたが、
> 下記のようなエラーとなります。入力方法に問題があるのでしょうか。
> root@9210d09c4efc:/# gpioget gpiochip3 1 > gpioget: error reading GPIO values: Device or resource busy
こちらはよくある間違いですが、gpioget/set コマンドでは GPIO3IO01 が gpiochip2 1 になってしまいます。 (GPIO1 -> gpiochip0 から数えます)
よろしくお願いします
yasuda0108
at_dominique.m…
お待たせしました。
> CON9設定ですが、「CON9.28 - GPIO5IO04 - PWM2」をPWM制御用に使用したく存じます。
このピンで、以下のdts overlayのコンフィグレーションで動作確認が取れました:
$ cat arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dts /dts-v1/; /plugin/; #include <dt-bindings/gpio/gpio.h> #include "imx8mp-pinfunc.h" &pwm2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pwm2>; status = "okay"; }; &iomuxc { pinctrl_pwm2: pwm2grp { fsl,pins = < MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x186 >; }; };
あれで `/sys/class/pwm/pwmchip0/` が作成されて、マニュアルの「PWM を扱う」通りに動いて、ピンの電圧を計って確認しました。
dts overlay の作成方法ですが、今すでにカスタマイズされてる dts を使ってますか?
すでにあった場合に、上記の pwm2/iomuxcの部分をコピーして再作成すれば使えると思います。
まだない場合には、マニュアルの説明が足りないと思いますのでまたご案内しようと思ってます。
よろしくお願いします。
yasuda0108
ご回答ありがとうございます。
>dts overlay の作成方法ですが、今すでにカスタマイズされてる dts を使ってますか?
>すでにあった場合に、上記の pwm2/iomuxcの部分をコピーして再作成すれば使えると思います。
https://armadillo.atmark-techno.com/forum/armadillo/10684
こちらのフォーラムでお教えいただいた通り、dtbについてはカスタマイズしたものを使用しております。
dtsを更新する流れは下記でよろしいでしょうか。
①.dtsにお教えいただいたpwm2/iomuxcの部分を記述
atmark@atde9:~/linux-5.10-5.10.93-r0/arch/arm64/boot/dts/freescale$ cat armadillo_iotg_g4-at-dtweb.dts /* * Copyright (C) 2021 Atmark Techno, Inc. All Rights Reserved. * * SPDX-License-Identifier: (GPL-2.0 OR MIT) */ /dts-v1/; //pwm2 iomuxcを記述 #define ARMADILLO_IOTG_G4_AT_DTWEB #include "armadillo_iotg_g4.dts" #include "armadillo_iotg_g4-expansion-interface.dtsi"
②作成したarmadillo_iotg_g4-at-dtweb.dtsをmkswu/update-dtbフォルダへ移動
//現在のフォルダの中身 atmark@atde9:~/linux-5.10-5.10.93-r0/arch/arm64/boot/dts/freescale$ ls ~/mkswu/update-dtb armadillo.dtb armadillo_iotg_g4-at-dtweb.dtb kernel_update_plain.desc kernel_update_plain.swu ここへarmadillo_iotg_g4-at-dtweb.dtsをコピー
③descを更新
atmark@atde9:~/mkswu$ cat update-dtb/kernel_update_plain.desc # We expose `--install-if different` here in two different ways for # demonstration purpose (either using the switch or setting the variable) # Anything below the variable being set will have the switch automatically # set unless they specify --install-if higher manually # Note that if a component is installed in both modes, the swu generation # will fail. # armadillo.dtb link send swdesc_files --version extra_os.kernel 5.10.82-1 --dest /boot\ armadillo.dtb armadillo_iotg_g4-at-dtweb.dtb //ここへarmadillo_iotg_g4-at-dtweb.dtsをコピー //--version extra_os.kernel 5.10.82-1で既にアップデート済みの為、extra_os.kernel_firmware_update 1と記述 # add the kernel to files to be preserved on OS update swdesc_command --version extra_os.preserve_dtb 1 \ 'echo /boot/armadillo_iotg_g4-at-dtweb.dtb >> /etc/swupdate_preserve_files'
④mkswuを実行しswuファイル作成
atmark@atde9:~/mkswu$ mkswu update-dtb/kernel_update_plain.desc
⑤USBメモリにてSWupdate実施
また、2点追加で質問です。
・.descファイルはリネームしても問題ないでしょうか
・.dtbと.dtsでは何が違うのでしょうか
以上よろしくお願いいたします。
at_dominique.m…
> https://armadillo.atmark-techno.com/forum/armadillo/10684
> こちらのフォーラムでお教えいただいた通り、dtbについてはカスタマイズしたものを使用しております。
了解しました。
先に質問の答えから返事します。
> ・.descファイルはリネームしても問題ないでしょうか
はい、問題ないです。名前もディレクトリも変更可能です。
> ・.dtbと.dtsでは何が違うのでしょうか
dtb はコンパイルされてる dts ファイル(device tree source, device tree blobの意味です)。
dtc (device tree compiler) で dts を dtb にして、Armadillo ではdtbを使います。
また、dtcでdtbの内容を確認することもできます
> ①.dtsにお教えいただいたpwm2/iomuxcの部分を記述
> atmark@atde9:~/linux-5.10-5.10.93-r0/arch/arm64/boot/dts/freescale$ cat armadillo_iotg_g4-at-dtweb.dts > /* > * Copyright (C) 2021 Atmark Techno, Inc. All Rights Reserved. > * > * SPDX-License-Identifier: (GPL-2.0 OR MIT) > */ > > /dts-v1/; > > //pwm2 iomuxcを記述 > > #define ARMADILLO_IOTG_G4_AT_DTWEB > #include "armadillo_iotg_g4.dts" > #include "armadillo_iotg_g4-expansion-interface.dtsi"
include の後に入れないとコンパイルが失敗すると思いますので、最後に追加してください。
そこで、コンパイルする必要があります:
atde$ cd ~/linux-5.10-5.10.93-r0 atde$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs ... DTC arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dtb ...
この段階でエラーが出ないかを確認して、ls -l で新しくされたことも確認してください。
> ②作成したarmadillo_iotg_g4-at-dtweb.dtsをmkswu/update-dtbフォルダへ移動
armadillo_iotg_g4-at-dtweb.dtb の方をコピーしてください。
> ③descを更新
> # armadillo.dtb link send > swdesc_files --version extra_os.kernel 5.10.82-1 --dest /boot\ > armadillo.dtb armadillo_iotg_g4-at-dtweb.dtb > //ここへarmadillo_iotg_g4-at-dtweb.dtsをコピー > //--version extra_os.kernel 5.10.82-1で既にアップデート済みの為、extra_os.kernel_firmware_update 1と記述 > > # add the kernel to files to be preserved on OS update > swdesc_command --version extra_os.preserve_dtb 1 \ > 'echo /boot/armadillo_iotg_g4-at-dtweb.dtb >> /etc/swupdate_preserve_files'
ここは同じファイル名なので、バージョン以外に変更が不要です。
`--version extra_os.kernel 5.10.82-1` の部分は二つのやり方があります:
* ただバージョンを上げればインストールできます(今のカーネルバージョンは 5.10.101-0 なので、それでもいいですし、単純に 6 にしてもいいです)
* 別の管理しやすい名前を使って、1 からのバージョンを使えます(ただし、kernel_firmware_update は別の .desc の名前なので、勘違いしやすいかもしれません?すべてを一つの .desc に合流したほうがやりやすいかもしれません…)
> ④mkswuを実行しswuファイル作成
> atmark@atde9:~/mkswu$ mkswu update-dtb/kernel_update_plain.desc
>
> ⑤USBメモリにてSWupdate実施
はい、そこまでできたら再起動して動作確認するだけですね。
よろしくお願いします。
yasuda0108
ご丁寧にご回答ありがとうございます。
「①.dtsにお教えいただいたpwm2/iomuxcの部分を記述」について、dtsを更新しコンパイルしましたが、
エラ-となっております。エラ-メッセージを見ても問題点がわからず…お教え頂けますでしょうか。
atmark@atde9:~/linux-5.10-5.10.93-r0/arch/arm64/boot/dts/freescale$ cat armadillo_iotg_g4-at-dtweb.dts /* * Copyright (C) 2021 Atmark Techno, Inc. All Rights Reserved. * * SPDX-License-Identifier: (GPL-2.0 OR MIT) */ /dts-v1/; /plugin/; #define ARMADILLO_IOTG_G4_AT_DTWEB #include "armadillo_iotg_g4.dts" #include "armadillo_iotg_g4-expansion-interface.dtsi" #include <dt-bindings/gpio/gpio.h> #include "imx8mp-pinfunc.h" &pwm2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pwm2>; status = "okay"; }; &iomuxc { pinctrl_pwm2: pwm2grp { fsl,pins = < MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x186 >; }; }; atmark@atde9:~/linux-5.10-5.10.93-r0$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs DTC arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dtb Error: arch/arm64/boot/dts/freescale/imx8mp.dtsi:7.1-10 Header flags don't match earlier ones FATAL ERROR: Syntax error parsing input tree make[2]: *** [scripts/Makefile.lib:326: arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dtb] エラー 1 make[1]: *** [scripts/Makefile.build:497: arch/arm64/boot/dts/freescale] エラー 2 make: *** [Makefile:1359: dtbs] エラー 2
at_dominique.m…
> atmark@atde9:~/linux-5.10-5.10.93-r0/arch/arm64/boot/dts/freescale$ cat armadillo_iotg_g4-at-dtweb.dts > /dts-v1/; > /plugin/; > > #define ARMADILLO_IOTG_G4_AT_DTWEB > #include "armadillo_iotg_g4.dts" > #include "armadillo_iotg_g4-expansion-interface.dtsi" ... > atmark@atde9:~/linux-5.10-5.10.93-r0$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs > DTC arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dtb > Error: arch/arm64/boot/dts/freescale/imx8mp.dtsi:7.1-10 Header flags don't match earlier ones
このエラーは、7行目に何かフラグがおかしいと。
7行目を見ると /plugin/ になります。この行は私が overlay として試していたのでその時に必要でしたが、普通のdtsの場合にエラーしますね。
ついでに、追加の#includeもすでに imx8mp.dtsi にあるので、本当に pwm2/iomuxcの部分だけでいいです(そちらは特にエラーではない):
$ vim arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dts /* * Copyright (C) 2021 Atmark Techno, Inc. All Rights Reserved. * * SPDX-License-Identifier: (GPL-2.0 OR MIT) */ /dts-v1/; #define ARMADILLO_IOTG_G4_AT_DTWEB #include "armadillo_iotg_g4.dts" #include "armadillo_iotg_g4-expansion-interface.dtsi" &pwm2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pwm2>; status = "okay"; }; &iomuxc { pinctrl_pwm2: pwm2grp { fsl,pins = < MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x186 >; }; }; $ make dtbs DTC arch/arm64/boot/dts/freescale/armadillo_iotg_g4-at-dtweb.dtb
よろしくお願いします。
yasuda0108
ご回答ありがとうございます。
無事アップデートが完了し、/sys/class/pwm/pwmchip0の確認が出来ました。
GPIOの件で一点質問があります。
CON9_Pin26_GPIO03_IO01のH/L切替を実施しようとしましたが、Hiに切り替わりません。
CON9のGPIOに関してもデバイスツリー設定が必要なのでしょうか。
【CON11_Pin19_GPIO03_IO21】 root@9210d09c4efc:/# gpioget gpiochip2 21 0 root@9210d09c4efc:/# gpioset gpiochip2 21=1 root@9210d09c4efc:/# gpioget gpiochip2 21 1 【CON9_Pin26_GPIO03_IO01】 root@9210d09c4efc:/# gpioget gpiochip2 1 0 root@9210d09c4efc:/# gpioset gpiochip2 1=1 root@9210d09c4efc:/# gpioget gpiochip2 1 0
at_dominique.m…
yasuda0108さん、
> GPIOの件で一点質問があります。
> CON9_Pin26_GPIO03_IO01のH/L切替を実施しようとしましたが、Hiに切り替わりません。
> CON9のGPIOに関してもデバイスツリー設定が必要なのでしょうか。
そうですね、NAND_CE0_Bのピンになってますので、これもデバイスツリーのiomuxcの変更でGPIOとして扱うようにしないと使えません。
手元にコネクタがないので最終確認ができませんでしたが、以下のdtsで試してみてください。
(ついでにPWMの設定のミスを気づいて直しておきました:0x186 は 0x116 でいいです。この違いは電圧が立ち上がるスピードを早くする設定(fast slew rate)のビットを間違えていました)
/* * Copyright (C) 2021 Atmark Techno, Inc. All Rights Reserved. * * SPDX-License-Identifier: (GPL-2.0 OR MIT) */ /dts-v1/; #define ARMADILLO_IOTG_G4_AT_DTWEB #include "armadillo_iotg_g4.dts" #include "armadillo_iotg_g4-expansion-interface.dtsi" &pwm2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pwm2>; status = "okay"; }; &iomuxc { pinctrl-0 = < &pinctrl_hog &pinctrl_expansion_interfacehog &pinctrl_gpioout >; pinctrl_gpioout: gpiooutgrp { fsl,pins = < MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x6 >; }; pinctrl_pwm2: pwm2grp { fsl,pins = < MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x116 >; }; };
このgpioの扱いは思った以上難しいので、これからの対応も考えておきます(デフォルトで使えるようにするか、マニュアルに方法を書くか…)
よろしくお願いします。
yasuda0108
at_dominique.m…
> PIN25 GPIO3_IO00
> PIN26 GPIO3_IO01
> PIN27 GPIO5_IO03
> PIN28 PWM2_OUT
まったく試してませんが、先の pinctrl_gpioout を以下の内容で直したらこの三つのGPIOを使えるようになるはずです:
pinctrl_gpioout: gpiooutgrp { fsl,pins = < MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x6 MX8MP_IOMUXC_NAND_ALE__GPIO3_IO00 0x6 MX8MP_IOMUXC_SPDIF_TX__GPIO5_IO03 0x6 >; };
やり方として、「CON9 信号配列[1]」に載せてあるPINの名前を linux のソースの arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h に検索して、そのIOMUXCの値を fsl,pinsに載せるだけですね。
[1] https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
その次の値は色々muxの設定がありますが、とりあえず6で「drive strength」を強くしただけです。そちらの設定はG4の製品マニュアルに載せていないので、imx8mpのreferenceマニュアルのSW_PAD_CTL_PAD_NAND_ALE等を参考にする必要がありますね…簡潔にまとめると、以下のbitfieldを使えます:
* 0x2/6 = stronger drive strength
* 0x10 = fast slew rate
* 0x20 = open drain enable
* 0x40 = pull up
* 0x80 = schmitt trigger input
* 0x100 = pull enable
* 0x40000000 = SION (software input on) enable
PWM に関しては pinctrl_pwm2 で設定済みですので、そちらは問題ない(先週確認しました)
よろしくお願いします
yasuda0108
設定方法に関する詳細情報までお教えいただきありがとうございます。
こちらの内容で設定実施させていただきます。
また、3点質問がございます。
・GPIOの変更内容およびコンテナ/APPをネットワーク接続なしで
別のG4ボードに書き込みする際は、下記のフローで問題ないでしょうか。
①initial_setup.swuをUSBメモリにてアップデート
②OS,コンテナImage更新用のswuをUSBメモリにてアップデート
③更新完了
・ボード上でpodman commitしたコンテナImageをどのようにして取り出し、descに組み込むのでしょうか。
※以下リンク先記載のswdesc_usb_containerコマンドにて、コンテナImageをボードに書き込む認識ですが、
こちらの例に記載の"nginx_alpine.tar"の作成方法が判らず、質問しました次第です。
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
・アップデートに関して、USBメモリのみで更新するよう、保守運用可能でしょうか
(ATDE/Linuxターミナルの導入をしない保守運用)
at_dominique.m…
> ・GPIOの変更内容およびコンテナ/APPをネットワーク接続なしで
> 別のG4ボードに書き込みする際は、下記のフローで問題ないでしょうか。
>
> ①initial_setup.swuをUSBメモリにてアップデート
> ②OS,コンテナImage更新用のswuをUSBメモリにてアップデート
> ③更新完了
インストールされた、されてないに関係なく同じUSBメモリーを使いたい場合にそれでいいです。
更新と言ったら、initial_setupがすでにインストールされたものだと思いますので、initial_setup.swuが不要と思います: OS/コンテナの更新の部分だけで事足ります。
特に、swuの暗号化が有効になっていたら暗号化の鍵が plain で initial_setup.swu に含まれてるので、暗号化の意味がなくなります。
逆に、initial_setupがインストールされてなかった場合に、`mkswu initial_setup.desc baseos.desc container.desc` などでイメージを作成すれば一つのイメージにすべての内容が収まります。
複数のイメージでも問題ないと思いますが、複数のイメージの場合にイメージを一つずつインストールして、毎回必要なOSのコピーや再起動するので、インストールの時間が長くなります。(すでにインストールされた物がskipされてます)
> ・ボード上でpodman commitしたコンテナImageをどのようにして取り出し、descに組み込むのでしょうか。
> ※以下リンク先記載のswdesc_usb_containerコマンドにて、コンテナImageをボードに書き込む認識ですが、
> こちらの例に記載の"nginx_alpine.tar"の作成方法が判らず、質問しました次第です。
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
すみません、ここの説明が足りてませんですね。
この nginx_alpine.tar は「コンテナイメージ」と呼ばれるものであれば何でもいいです(docker save か podman save の docker-archive か oci-archive と呼ばれてる物)
また、podman_partial_image スクリプトで作成された物でもいいです (ベースとなるイメージを指定しなかったらpodman saveと同じです)
手元の物で例を上げると、「inference」と言うコンテナをベースにして「test」のイメージを作成したら、以下の二つのtarを使えます:
armadillo:~# podman run -ti --name test localhost/inference bash ... armadillo:~# podman commit test test armadillo:~# podman image list REPOSITORY TAG IMAGE ID CREATED SIZE R/O localhost/test latest bae3e6861587 7 seconds ago 319 MB false localhost/inference latest b44d621867c9 6 minutes ago 319 MB true armadillo:~# podman_partial_image -o full.tar test armadillo:~# podman_partial_image -o partial.tar -b inference test armadillo:~# ls -lh *.tar -rw-r--r-- 1 root root 305M Mar 29 10:22 full.tar -rw-r--r-- 1 root root 33K Mar 29 10:23 partial.tar
ただし、partial.tar はinferenceのイメージがすでにインストールされたときにしか使えません。
(そうでない場合はswuのインストールが失敗します)
> ・アップデートに関して、USBメモリのみで更新するよう、保守運用可能でしょうか
> (ATDE/Linuxターミナルの導入をしない保守運用)
そうですね、色々可能性がありますが、そこはお客様の考え次第に相談しましょうか。
おすすめとしては自分の Continuous Integration (jenkinsやgithub action)によるビルドを設置することですが、
元々ネットワーク(OTA)のアップデートのために考えていたもので、USBメモリの更新にあまり向いてないかもしれません。
ちょうど先週に例を一つ作りましたので、よろしければ参考にしてください:
https://github.com/martinetd/G4_container_updater
(README は英語ですみません)
USBで更新するのであれば、手元に一つの開発の G4 を「アップデート作成用」にしておいて、
その G4 で直接にアップデートを作成すればいかがでしょうか。
例として、
armadillo:~# apk add git cpio zstd (1/4) Installing cpio (2.13-r3) (2/4) Installing pcre2 (10.39-r0) (3/4) Installing git (2.34.1-r0) (4/4) Installing zstd (1.5.0-r0) Executing busybox-1.34.1-r4.trigger OK: 213 MiB in 192 packages armadillo:~# cd /var/app/volumes/ armadillo:/var/app/volumes# git clone https://github.com/atmark-techno/mkswu/ Cloning into 'mkswu'... remote: Enumerating objects: 2586, done. remote: Counting objects: 100% (2586/2586), done. remote: Compressing objects: 100% (973/973), done. remote: Total 2586 (delta 1653), reused 2416 (delta 1483), pack-reused 0 Receiving objects: 100% (2586/2586), 497.28 KiB | 2.07 MiB/s, done. Resolving deltas: 100% (1653/1653), done. armadillo:/var/app/volumes/mkswu# ./mkswu --init --config-dir . Updated config file ./mkswu.conf Enter certificate common name: G4 update Enter private key password (4-1024 char) private key password (confirm): Generating an EC private key writing new private key to './swupdate.key' ----- Use AES encryption? (N/y) y Generated ./swupdate.aes-key Allow updates signed by Atmark Techno? (Y/n) root password: root password (confirm): atmark user password (empty = same as root): atmark user password (confirm): Enable auto-update of BaseOS image from armadillo.atmark-techno.com servers? (y/N) Successfully generated ./initial_setup.swu You can use "./initial_setup.swu" as is or regenerate an image with extra modules with: mkswu "./initial_setup.desc" other_desc_files Note that once installed, you must preserve this directory as losing key files means you will no longer be able to install new updates without manually adjusting /etc/swupdate.pem on devices armadillo:/var/app/volumes/mkswu# ./mkswu examples/custom_script.desc Enter pass phrase for /var/app/volumes/mkswu/swupdate.key: Successfully generated examples/custom_script.swu armadillo:/var/app/volumes/mkswu# ls -lh examples/custom_script.swu -rw-r--r-- 1 root root 19K Mar 29 11:12 examples/custom_script.swu
例では/var/app/volumesを使ってappfsに直接に保存するようにしましたが、
その方向で進めば鍵の管理に注意が必要です。
鍵をなくしたらもうアップデートを作成できなくなる状態になりますので…
(さらに、お客さんの場合はすでにATDEで鍵を作成したので、--init よりその鍵をG4にコピーした方がいいですね)
よろしくお願いします。
yasuda0108
>> ・GPIOの変更内容およびコンテナ/APPをネットワーク接続なしで
>> 別のG4ボードに書き込みする際は、下記のフローで問題ないでしょうか。
>> ・ボード上でpodman commitしたコンテナImageをどのようにして取り出し、descに組み込むのでしょうか。
こちらの2点につきまして、内容理解いたしました。
詳細なご説明誠にありがとうございます。
swuは、mkswu initial_setup.desc baseos.desc container.descでまとめようと思います。
>> ・アップデートに関して、USBメモリのみで更新するよう、保守運用可能でしょうか
>> (ATDE/Linuxターミナルの導入をしない保守運用)
> そうですね、色々可能性がありますが、そこはお客様の考え次第に相談しましょうか。
最終的に量産となった場合に、弊社の製造/サポート部隊にswuファイルを配布し、
容易にソフトの書き込みおよびソフトアップデート対応ができるようにしたいと考えております。
(できれば、ボード電源起動後に.swuを保存したUSBメモリを挿入するだけで、ターミナルを使用せずにソフト書込み/アップデートの実施をしたく)
SWUpdateに際して、ログイン/秘密鍵入力が必要な認識なので難しいかもしれませんが。。。
> おすすめとしては自分の Continuous Integration (jenkinsやgithub action)によるビルドを設置することですが、
> 元々ネットワーク(OTA)のアップデートのために考えていたもので、USBメモリの更新にあまり向いてないかもしれません。
> ちょうど先週に例を一つ作りましたので、よろしければ参考にしてください:
> https://github.com/martinetd/G4_container_updater
こちら参考にさせて頂きます。
> USBで更新するのであれば、手元に一つの開発の G4 を「アップデート作成用」にしておいて、
> その G4 で直接にアップデートを作成すればいかがでしょうか。
開発用のG4「アップデート作成用」でmkswuを実施し、.swuを作成する方法ということですね。
こちらの方法で作成した.swuを用いて別のG4をアップデートする際も、ATDEで作成した.swu同様、秘密鍵入力が必要でしょうか。
at_dominique.m…
> 最終的に量産となった場合に、弊社の製造/サポート部隊にswuファイルを配布し、
> 容易にソフトの書き込みおよびソフトアップデート対応ができるようにしたいと考えております。
> (できれば、ボード電源起動後に.swuを保存したUSBメモリを挿入するだけで、ターミナルを使用せずにソフト書込み/アップデートの実施をしたく)
なるほど、サポート部隊に作成を簡単にできるようにすることですね。理解しました。
> SWUpdateに際して、ログイン/秘密鍵入力が必要な認識なので難しいかもしれませんが。。。
そうですね、鍵の管理はよく考える必要がありそうです。以下に提案させていただきます。
> > USBで更新するのであれば、手元に一つの開発の G4 を「アップデート作成用」にしておいて、
> > その G4 で直接にアップデートを作成すればいかがでしょうか。
>
> 開発用のG4「アップデート作成用」でmkswuを実施し、.swuを作成する方法ということですね。
> こちらの方法で作成した.swuを用いて別のG4をアップデートする際も、ATDEで作成した.swu同様、秘密鍵入力が必要でしょうか。
はい、作成する場所が異なっても作成された物が同じなので、サイン(と必要であれば暗号化)が必要です。
思い浮かぶやり方は先ほどの二つしかないですが、他もあるか考えてみます。
1/ github/CIで作成する手順であれば、アップデートはまとめたところで作成するので、そもそもサポート部隊に作成する必要がなくなります。
彼らに最新のバージョンをダウンロードさせて、USBメモリにコピーするだけでG4に挿してアップデートさせます。
何か失敗した場合にサポートの人達が鍵を持ってないので、直接に対応できない可能性がありますが、逆にCIのソースリポジトリにアクセスを与えればmkswuの鍵がなくてもアップデートを作成できます。こうすることで、不正なアップデートも作成しづらくなるので、インフラが必要な分にセキュリティ的にはいいと思います。
ちなみに、アットマークテクノの公式なアップデートもこうしています。アットマークの鍵が誰とも持ってませんが、リリースの時に社内のjenkinsに置いてある鍵を使わせて公開向けの成果物を作成します。
2/ G4 で作成する例に大しては /var/app/volumes で作成していましたが、そのディレクトリを USB メモリに置いていけばUSBメモリーをコピーするだけで自由にSWUを作成できます。
例えば色分けして、サポート部隊に青のUSBメモリにswuを書かせて、赤のUSBメモリで必要な時に手元のG4や別の Linux に作成してもらいます。
一応鍵にもパスワードがかかってますので、USBメモリをなくしてもすぐ問題になるようなことではありませんですし、サポート部隊が増えたらUSBメモリをコピーするだけで済みます。
よろしくお願いします。
yasuda0108
> > 最終的に量産となった場合に、弊社の製造/サポート部隊にswuファイルを配布し、
> > 容易にソフトの書き込みおよびソフトアップデート対応ができるようにしたいと考えております。
> > (できれば、ボード電源起動後に.swuを保存したUSBメモリを挿入するだけで、ターミナルを使用せずにソフト書込み/アップデートの実施をしたく)
>
> なるほど、サポート部隊に作成を簡単にできるようにすることですね。理解しました。
>
> 思い浮かぶやり方は先ほどの二つしかないですが、他もあるか考えてみます。
> 1/ github/CIで作成する手順であれば、アップデートはまとめたところで作成するので、そもそもサポート部隊に作成する必要がなくなります。
> 彼らに最新のバージョンをダウンロードさせて、USBメモリにコピーするだけでG4に挿してアップデートさせます。
> 何か失敗した場合にサポートの人達が鍵を持ってないので、直接に対応できない可能性がありますが、逆にCIのソースリポジトリにアクセスを与えればmkswuの鍵がなくてもアップデートを作成できます。こうすることで、不正なアップデートも作成しづらくなるので、インフラが必要な分にセキュリティ的にはいいと思います。
> ちなみに、アットマークテクノの公式なアップデートもこうしています。アットマークの鍵が誰とも持ってませんが、リリースの時に社内のjenkinsに置いてある鍵を使わせて公開向けの成果物を作成します。
>
> 2/ G4 で作成する例に大しては /var/app/volumes で作成していましたが、そのディレクトリを USB メモリに置いていけばUSBメモリーをコピーするだけで自由にSWUを作成できます。
> 例えば色分けして、サポート部隊に青のUSBメモリにswuを書かせて、赤のUSBメモリで必要な時に手元のG4や別の Linux に作成してもらいます。
> 一応鍵にもパスワードがかかってますので、USBメモリをなくしてもすぐ問題になるようなことではありませんですし、サポート部隊が増えたらUSBメモリをコピーするだけで済みます。
>
>
> よろしくお願いします。
>
ご回答ありがとうございます。
.swuの作成は基本的に開発部隊(私の所属)の方で実施します。
ですので、仮にバージョンアップがあった場合でも、基本的には開発部隊でATDEを用いて.swuを作成していく予定です。
> 彼らに最新のバージョンをダウンロードさせて、USBメモリにコピーするだけでG4に挿してアップデートさせます。
おっしゃる通り、サポート部隊には作成済みの.swuを配布して、USBメモリからアップデートをしてもらおうと考えております。
この「USBメモリからアップデート」の際に、
・USBメモリ単体でアップデートできるのか(単体で出来ればベストです)
・USBメモリとPCを用いる必要があるのか(ATDE/ターミナルを開いて、秘密鍵を入力)
・他に方法があるか(ボードにLCD、キーボードを接続して秘密鍵を入力等)
が、今回質問したかった内容となります。
こちらのお伝えする内容が、言葉足らずですみません。
以上よろしくお願いします。
at_dominique.m…
> ご回答ありがとうございます。
> .swuの作成は基本的に開発部隊(私の所属)の方で実施します。
> ですので、仮にバージョンアップがあった場合でも、基本的には開発部隊でATDEを用いて.swuを作成していく予定です。
分かりました。
> > 彼らに最新のバージョンをダウンロードさせて、USBメモリにコピーするだけでG4に挿してアップデートさせます。
> おっしゃる通り、サポート部隊には作成済みの.swuを配布して、USBメモリからアップデートをしてもらおうと考えております。
> この「USBメモリからアップデート」の際に、
>
> ・USBメモリ単体でアップデートできるのか(単体で出来ればベストです)
> ・USBメモリとPCを用いる必要があるのか(ATDE/ターミナルを開いて、秘密鍵を入力)
> ・他に方法があるか(ボードにLCD、キーボードを接続して秘密鍵を入力等)
>
> が、今回質問したかった内容となります。
>
> こちらのお伝えする内容が、言葉足らずですみません。
こちらこそ、間違った方向で突っ走りましたね。すみませんでした。
この予定であれば問題ない、SWUの想定の使い方の一つです。
SWU を一同作成すれば、その時に ATDE にある鍵を使ってその SWU を証明したので、このまま USBメモリに配れば使えます。
まとめの流れとしては:
- 開発部隊で ATDE等を使ってSWUを作成して、社内に配ります。その時に秘密鍵やパスワードが必要です。
- サポート部隊が作成済みの SWU を拾って、USBメモリーにコピーします。そのUSBメモリを Armadillo にさして、アップデートが自動的に実行されます。
具体的に、作成された時の設定によっていくつかのパターンがあります。
- デフォルトではSWUをインストールした後に自動的に新しいソフトウェアに再起動して、外部から見るとのLEDが数秒消されてから再び照らしますが、これだやりにくいかもしれません。
- .desc ファイルに POST_ACTION=poweroff を設定すればインストール後に停止しますので、LEDが消えてわかりやすいと思います。
- それか、POST_ACTION=wait を設定すればインストール後に外部のリスタートを待ったせます。(チューニングが現在ありませんが)その時にLEDをblinkさせればわかりやすいかと思いますが、どうでしょうか?…失敗の時にもLEDを別のパターンでblinkさせたり(早いペースなどで区別できるように)…
そのあたりの「やりやすさ」についてはまだ深く考えてませんが、何でも可能です。4月のアップデートに対応を入れおきます。
ご希望あればぜひ聞かせてください。
(また、デフォルトではSWUに記載されてるバージョンが常に確認されてますので、「downgrade attack」という、古い SWU バージョンを見つけて脆弱性のあるイメージをインストールしようとしてもできません。)
よろしくお願いします。
yasuda0108
ご回答ありがとうございます。
> まとめの流れとしては:
> - 開発部隊で ATDE等を使ってSWUを作成して、社内に配ります。その時に秘密鍵やパスワードが必要です。
> - サポート部隊が作成済みの SWU を拾って、USBメモリーにコピーします。そのUSBメモリを Armadillo にさして、アップデートが自動的に実行されます。
内容承知いたしました。
> 具体的に、作成された時の設定によっていくつかのパターンがあります。
> - デフォルトではSWUをインストールした後に自動的に新しいソフトウェアに再起動して、外部から見るとのLEDが数秒消されてから再び照らしますが、これだやりにくいかもしれません。
> - .desc ファイルに POST_ACTION=poweroff を設定すればインストール後に停止しますので、LEDが消えてわかりやすいと思います。
> - それか、POST_ACTION=wait を設定すればインストール後に外部のリスタートを待ったせます。(チューニングが現在ありませんが)その時にLEDをblinkさせればわかりやすいかと思いますが、どうでしょうか?…失敗の時にもLEDを別のパターンでblinkさせたり(早いペースなどで区別できるように)…
今回想定の構成では、LCDモジュールが接続されており、
USBメモリ挿入→画面フリーズ→画面消灯→再起動
の流れで切り替わるため、アップデートされていることが判りそうです。
※実際にテストし無事アップデートされることを確認しました。
ご丁寧にご対応いただきありがとうございました。
引き続きよろしくお願いいたします。
at_dominique.m…
> 今回想定の構成では、LCDモジュールが接続されており、
> USBメモリ挿入→画面フリーズ→画面消灯→再起動
> の流れで切り替わるため、アップデートされていることが判りそうです。
そうでうすね、テストした環境は podman_switch_storage --disk を使ってるとコンテナが停止されてからアップデートを行いますのでこういう流れになります。
本来の tmpfs での操作ですと、アップデート中にコンテナを停止しませんので、その点でかご注意ください。
(コンテナイメージと相対パスの「/var/app/rollback/volumes」のボリュームを使うと新しいボリュームがクローンされてからアップデートを行います混乱しませんが、/var/app/volumesの分は使用されてる中に更新しますので注意が必要です。想定では、swuでアップデートするようなファイルをrollbackの方に書き込み、データベースやログのコンテナから書き込む、保存したい内容を/var/app/volumesを使います。)
アプリを停止したい場合にオプションが必要かもしれませんね。
停止自体はswdesc_command_nochroot でpodmanの操作かアプリへの連絡が簡単にできます(やろうと思えば、LCDに「アップデート中」のメッセージを表示して、swupdate の API を叩いて swupdate-progress の用なプログレスも表示できます)
コンテナを停止した場合に、アップデートが失敗するとコンテナが自動的に再び起動されないので再起動が必要になって不便になりますね…やはり失敗の時に何かコマンドを指定できるようにしておきたいと思います。
その辺りのことをもう少しこちらで考えて、プロトタイプができたらまだ連絡させていただきます。
有利な相談ありがとうございます、これからもよろしくお願いします。
yasuda0108
> > 今回想定の構成では、LCDモジュールが接続されており、
> > USBメモリ挿入→画面フリーズ→画面消灯→再起動
> > の流れで切り替わるため、アップデートされていることが判りそうです。
>
> そうでうすね、テストした環境は podman_switch_storage --disk を使ってるとコンテナが停止されてからアップデートを行いますのでこういう流れになります。
> 本来の tmpfs での操作ですと、アップデート中にコンテナを停止しませんので、その点でかご注意ください。
> (コンテナイメージと相対パスの「/var/app/rollback/volumes」のボリュームを使うと新しいボリュームがクローンされてからアップデートを行います混乱しませんが、/var/app/volumesの分は使用されてる中に更新しますので注意が必要です。想定では、swuでアップデートするようなファイルをrollbackの方に書き込み、データベースやログのコンテナから書き込む、保存したい内容を/var/app/volumesを使います。)
>
> アプリを停止したい場合にオプションが必要かもしれませんね。
> 停止自体はswdesc_command_nochroot でpodmanの操作かアプリへの連絡が簡単にできます(やろうと思えば、LCDに「アップデート中」のメッセージを表示して、swupdate の API を叩いて swupdate-progress の用なプログレスも表示できます)
> コンテナを停止した場合に、アップデートが失敗するとコンテナが自動的に再び起動されないので再起動が必要になって不便になりますね…やはり失敗の時に何かコマンドを指定できるようにしておきたいと思います。
>
> その辺りのことをもう少しこちらで考えて、プロトタイプができたらまだ連絡させていただきます。
ありがとうございます。
プロトタイプのご連絡お待ちしております。
一点質問がございます。
GPIO、PWMの出力をLinux起動時に実施したいのですが、下記URLを参考にスクリプトを作成し実行するように設計すればよろしいでしょうか。
https://armadillo.atmark-techno.com/blog/6938/2865?msclkid=cffc81eeb572…
at_dominique.m…
yasuda0108さん、
お世話になっています、
マルティネです。
> 一点質問がございます。
> GPIO、PWMの出力をLinux起動時に実施したいのですが、下記URLを参考にスクリプトを作成し実行するように設計すればよろしいでしょうか。
> https://armadillo.atmark-techno.com/blog/6938/2865?msclkid=cffc81eeb572…
Armadillo G4ではsystemdを使ってませんので、この記事のままでは動かないと思います。
Armadillo Base OS に libgpiod(gpioset等のコマンド)が入ってないので、自動起動のコンテナで操作を行ってもらえるのは一番やりやすいと思います。
/etc/atmark/containers/*.conf のコンテナはずっと走らなくても、「one shot」的な対応も可能です。
(add_devicesでgpiochipを与えて、set_command で自分の init script を実行すればいいです)
それでも Base OS の方で実行したい場合はマニュアルの「9.8.5. Armadillo Base OS 側の起動スクリプト」を参照ください:
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
よろしくお願いします。
at_ohsawa
> Armadillo G4ではsystemdを使ってませんので、この記事のままでは動かないと思います。
> Armadillo Base OS に libgpiod(gpioset等のコマンド)が入ってないので、自動起動のコンテナで操作を行ってもらえるのは一番やりやすいと思います。
> /etc/atmark/containers/*.conf のコンテナはずっと走らなくても、「one shot」的な対応も可能です。
> (add_devicesでgpiochipを与えて、set_command で自分の init script を実行すればいいです)
>
コンテナを自動的に起動して、さらにその中で、何か自動的に実行する方法は
開発ガイドに実例がかいてあるので、是非参考にしてみてください。
Armadillo Base OS 開発ガイド
6.5.6. podman コンテナとアプリケーションの自動実行
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/do…
yasuda0108
> コンテナを自動的に起動して、さらにその中で、何か自動的に実行する方法は
> 開発ガイドに実例がかいてあるので、是非参考にしてみてください。
>
> Armadillo Base OS 開発ガイド
> 6.5.6. podman コンテナとアプリケーションの自動実行
> https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/do…
情報のご提示ありがとうございます。
> Armadillo G4ではsystemdを使ってませんので、この記事のままでは動かないと思います。
> Armadillo Base OS に libgpiod(gpioset等のコマンド)が入ってないので、自動起動のコンテナで操作を行ってもらえるのは一番やりやすいと思います。
> /etc/atmark/containers/*.conf のコンテナはずっと走らなくても、「one shot」的な対応も可能です。
> (add_devicesでgpiochipを与えて、set_command で自分の init script を実行すればいいです)
なるほど、libgpiodを導入したimageからコンテナを自動起動させて、コマンドを入力するということですね。
自動起動用のコマンドですが、前回作成時は「volume」「device」等使用しておりましたが、
「add_volume」「add_device」と同様の動作になりますでしょうか。
armadillo:~# cat /etc/atmark/containers/qt-auto.conf image="localhost/image_name:qt-build_v0.1" volumes="/sys:/sys /dev:/dev /run/udev:/run/udev /opt/firmware:/opt/firmware" devices="/dev/dri /dev/galcore /dev/fb0" readonly=yes autostart=yes append_args=--env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu append_args=--env=QT_QPA_PLATFORM=linuxfb append_args -w /home/Qt_FILE set_command ./qt-exec
> それでも Base OS の方で実行したい場合はマニュアルの「9.8.5. Armadillo Base OS 側の起動スクリプト」を参照ください:
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
ありがとうございます。
最終的には、G4電源起動→LCD起動(GPIO,PWM)→起動画面表示→コンテナ起動→APP実行の流れで実行を想定していますので、
こちらの情報を参考に、BaseOSを設定することになるかもしれませんね。。。
以上よろしくお願いします。
at_dominique.m…
> > Armadillo G4ではsystemdを使ってませんので、この記事のままでは動かないと思います。
> > Armadillo Base OS に libgpiod(gpioset等のコマンド)が入ってないので、自動起動のコンテナで操作を行ってもらえるのは一番やりやすいと思います。
> > /etc/atmark/containers/*.conf のコンテナはずっと走らなくても、「one shot」的な対応も可能です。
> > (add_devicesでgpiochipを与えて、set_command で自分の init script を実行すればいいです)
>
> なるほど、libgpiodを導入したimageからコンテナを自動起動させて、コマンドを入力するということですね。
> 自動起動用のコマンドですが、前回作成時は「volume」「device」等使用しておりましたが、
> 「add_volume」「add_device」と同様の動作になりますでしょうか。
はい、volumes= -> add_volumes (かdevices)にしました。
volumesの変数を数回設定するときに、「volumes="$volumes .."」の作りが間違いやすいのでそこのミスを防ぐための変更です。
volumes=を直接に設定しても問題ないので、どちらでも使えます。
>
> append_args=--env=LD_LIBRARY_PATH=/opt/firmware/usr/lib/aarch64-linux-gnu > append_args=--env=QT_QPA_PLATFORM=linuxfb > append_args -w /home/Qt_FILE >
ちなみにここの「append_args=xxx」の二つの行が無視されます。
それも勘違いさせないように、4月末のアップデートでは他のコマンドも「set_xxx yyy」の形に変更します(「=」サインをもうコンフィグで使いません)
今のオプションを使いつづけますがよろしければ更新後に使ってください。
> > それでも Base OS の方で実行したい場合はマニュアルの「9.8.5. Armadillo Base OS 側の起動スクリプト」を参照ください:
> > https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
>
> ありがとうございます。
> 最終的には、G4電源起動→LCD起動(GPIO,PWM)→起動画面表示→コンテナ起動→APP実行の流れで実行を想定していますので、
> こちらの情報を参考に、BaseOSを設定することになるかもしれませんね。。。
そうですね…時間的にBaseOSのlocalのサービスもかなり遅いので、コンテナでもBaseOSでもあまり変わらないかもしれません。
できるだけ早くLCDを起動したい場合にはubootで起動させた方が段違いに早いですが、こういう編集の手順を用意してないですね…
とりあえず試してみてください。
よろしくお願いします。
at_dominique.m…
yasuda0108さん
お待たせ致しました。
> 今回想定の構成では、LCDモジュールが接続されており、
> USBメモリ挿入→画面フリーズ→画面消灯→再起動
> の流れで切り替わるため、アップデートされていることが判りそうです。
今日リリースした、mkswu 3.15.at.6 のアップデートでは自分のコマンドをこの三ヶ所に実行できます:
- アップデートを行う必要があると判断して、書き込み始まる直前
- アップデートが無事に終了した時
- アップデートが失敗した時
atde で 「apt update; apt install mkswu」で最新のバージョンを更新したら、
/usr/share/mkswu/examples/enable_notify_led.desc の新しい例も追加されました。
例では、ただLEDをアップデート中に blink させたり、終わったら OFF (失敗)/ON (成功)にするだけですが、
その例を任意な場所にコピーして編集すれば、自分のアプリケーションへの連絡を取ってLCDにメッセージを表示したりすることはできます。
デフォルトではアップデート後に再起動を自動的に行いますが、
=wait の設定でメッセージを表示したらアプリケーションかユーザーに都合のいい時に再起動させることもできます。
説明はまだよくないと思いますので、何か質問あったらまた聞いてください。
よろしくお願いします。
yasuda0108
yasuda0108
podman saveにて作成した.tarを使用し、USBメモリによるコンテナインストール用の.descを作成を試みています。
9.2.4.2, 9.7.5の記載内容にて質問がございます。
①「swdesc_files」は、どの様な機能なのでしょうか。
②「nginx_start」は何を意味するのでしょうか。
③「nginx_start」はどのように作成するのでしょうか。
※「nginx_alpine.tar」に相当するものは作成済みです。
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/embed_container_nginx.desc . [ATDE ~/mkswu]$ cat embed_container_nginx.desc swdesc_embed_container "nginx_alpine.tar" --version container_nginx 1 swdesc_files --version extra_os.nginx 1 \ nginx_start
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
yasuda0108
先ほどの質問ですが、本スレッドの3/29 11:13の内容に関連するものになります。
> > ・GPIOの変更内容およびコンテナ/APPをネットワーク接続なしで
> > 別のG4ボードに書き込みする際は、下記のフローで問題ないでしょうか。
> >
> > ①initial_setup.swuをUSBメモリにてアップデート
> > ②OS,コンテナImage更新用のswuをUSBメモリにてアップデート
> > ③更新完了
>
> インストールされた、されてないに関係なく同じUSBメモリーを使いたい場合にそれでいいです。
>
> 更新と言ったら、initial_setupがすでにインストールされたものだと思いますので、initial_setup.swuが不要と思います: OS/コンテナの更新の部分だけで事足ります。
> 特に、swuの暗号化が有効になっていたら暗号化の鍵が plain で initial_setup.swu に含まれてるので、暗号化の意味がなくなります。
>
> 逆に、initial_setupがインストールされてなかった場合に、`mkswu initial_setup.desc baseos.desc container.desc` などでイメージを作成すれば一つのイメージにすべての内容が収まります。
> 複数のイメージでも問題ないと思いますが、複数のイメージの場合にイメージを一つずつインストールして、毎回必要なOSのコピーや再起動するので、インストールの時間が長くなります。(すでにインストールされた物がskipされてます)
>
>
> > ・ボード上でpodman commitしたコンテナImageをどのようにして取り出し、descに組み込むのでしょうか。
> > ※以下リンク先記載のswdesc_usb_containerコマンドにて、コンテナImageをボードに書き込む認識ですが、
> > こちらの例に記載の"nginx_alpine.tar"の作成方法が判らず、質問しました次第です。
> > https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
>
> すみません、ここの説明が足りてませんですね。
> この nginx_alpine.tar は「コンテナイメージ」と呼ばれるものであれば何でもいいです(docker save か podman save の docker-archive か oci-archive と呼ばれてる物)
> また、podman_partial_image スクリプトで作成された物でもいいです (ベースとなるイメージを指定しなかったらpodman saveと同じです)
at_dominique.m…
yasuda0108さん、
> ①「swdesc_files」は、どの様な機能なのでしょうか。
> ②「nginx_start」は何を意味するのでしょうか。
> ③「nginx_start」はどのように作成するのでしょうか。
まとめて答えさせていただきます。
マニュアルの9.7.5の説明が分かりにくかったんでしょうか?
swdesc_files は引数に渡すファイルかディレクトリーをswuイメージに組み込んで、インストールの際にArmadilloに展開します。
今回の例では、.descファイルと同じディレクトリーにある「nginx_start」を転送します。--version は extra_osで始まるので、展開先のデフォールトはルートファイルシステムになります。
例の中に、以下の行でexamplesディレクトリーから現在のディレクトリー「.」にコピーします:
cp -r /usr/share/mkswu/examples/nginx_start .
内容は以下の通りですが、ただコンテナを起動させるコンフィグレーションファイルです。「9.2.1. コンテナの自動起動」を参考にして自分に合うファイルを作成してください:
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
$ tree /usr/share/mkswu/examples/nginx_start/ /usr/share/mkswu/examples/nginx_start/ └── etc └── atmark └── containers └── nginx.conf 3 directories, 1 file $ batcat /usr/share/mkswu/examples/nginx_start/etc/atmark/containers/nginx.conf ───────┬────────────────────────────────────────── │ File: /usr/share/mkswu/examples/nginx_start/etc/atmark/containers/nginx.conf ───────┼────────────────────────────────────────── 1 │ image=docker.io/library/nginx:alpine 2 │ readonly=no 3 │ ports="80:80" ───────┴──────────────────────────────────────────
ついでに、最新のマニュアルも見てみましょう:
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
embed_container_nginx.descはちょっとシンプルになりましたので、そちらも参考にしていただけるかと思います。
(最新のmkswuが必要なので、エラーしたら sudo apt update && sudo apt install mkswu で更新してください)
[ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/embed_container_nginx.desc . [ATDE ~/mkswu]$ cat embed_container_nginx.desc version=1 swdesc_embed_container "nginx_alpine.tar" swdesc_files --extra-os nginx_start [ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start . [ATDE ~/mkswu]$ podman pull --arch arm64 docker.io/nginx:alpine [ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m aarch64 [ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar [ATDE ~/mkswu]$ mkswu embed_container_nginx.desc Enter pass phrase for /home/atmark/mkswu/swupdate.key: embed_container_nginx.swu を作成しました
何か不明な点があったらまた聞いてください。
よろしくお願いします
yasuda0108
> swdesc_files は引数に渡すファイルかディレクトリーをswuイメージに組み込んで、インストールの際にArmadilloに展開します。
> 今回の例では、.descファイルと同じディレクトリーにある「nginx_start」を転送します。--version は extra_osで始まるので、展開先のデフォールトはルートファイルシステムになります。
>
> 例の中に、以下の行でexamplesディレクトリーから現在のディレクトリー「.」にコピーします:
>
> cp -r /usr/share/mkswu/examples/nginx_start . >
>
> 内容は以下の通りですが、ただコンテナを起動させるコンフィグレーションファイルです。「9.2.1. コンテナの自動起動」を参考にして自分に合うファイルを作成してください:
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
>
> $ tree /usr/share/mkswu/examples/nginx_start/ > /usr/share/mkswu/examples/nginx_start/ > └── etc > └── atmark > └── containers > └── nginx.conf > > 3 directories, 1 file > $ batcat /usr/share/mkswu/examples/nginx_start/etc/atmark/containers/nginx.conf > ───────┬────────────────────────────────────────── > │ File: /usr/share/mkswu/examples/nginx_start/etc/atmark/containers/nginx.conf > ───────┼────────────────────────────────────────── > 1 │ image=docker.io/library/nginx:alpine > 2 │ readonly=no > 3 │ ports="80:80" > ───────┴────────────────────────────────────────── >
>
>
> ついでに、最新のマニュアルも見てみましょう:
> https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
>
> embed_container_nginx.descはちょっとシンプルになりましたので、そちらも参考にしていただけるかと思います。
> (最新のmkswuが必要なので、エラーしたら sudo apt update && sudo apt install mkswu で更新してください)
>
> [ATDE ~/mkswu]$ cp /usr/share/mkswu/examples/embed_container_nginx.desc . > [ATDE ~/mkswu]$ cat embed_container_nginx.desc > version=1 > > swdesc_embed_container "nginx_alpine.tar" > swdesc_files --extra-os nginx_start > [ATDE ~/mkswu]$ cp -r /usr/share/mkswu/examples/nginx_start . > [ATDE ~/mkswu]$ podman pull --arch arm64 docker.io/nginx:alpine > [ATDE ~/mkswu]$ podman run --rm docker.io/nginx:alpine uname -m > aarch64 > [ATDE ~/mkswu]$ podman save docker.io/nginx:alpine > nginx_alpine.tar > [ATDE ~/mkswu]$ mkswu embed_container_nginx.desc > Enter pass phrase for /home/atmark/mkswu/swupdate.key: > embed_container_nginx.swu を作成しました >
ご丁寧にご説明ありがとうございます。
swdesc_filesの内容および使用方法について、内容理解できました。
また、initial_setup.desc, Pin設定アップデート用desc, コンテナdescを組み込んだswuを作成できました。
引き続きよろしくお願いいたします。
at_dominique.m…
2022年3月23日 16時07分
yasuda0108さん、
> Armadillo-G4のCON9 25~28pinにて、GPIOおよびPWMの使用を検討しております。
> こちらを使用するための設定方法について記載の情報がありましたらお教えください。
gpioとしての扱いであれば yasuda0108さん がみてるページでいいと思います:
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
PWMについてはdtsの変更も必要ですので、そちらもご参照ください:
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
例としてはalpineのコンテナを起動していますので、そのコンテナでは apk コマンドを使えるはずです。
もしかしたら、debian (at-debian-image等)のコンテナで実行しようとしていませんか?
でしたら別の alpine コンテナを起動するか、 apt で gpiod のパッケージをインストールすれば gpioinfo/gpioget/gpioset コマンドを使えるようになります。
よろしくお願いします。