@ka2n

Technology and beer

Dayun Z1の初期セットアップを楽にするFWを作りました

2018/10/08に再アップロードされた20180930版に少し手を入れてあります。(以前のものとの違いは調べてません)

  • 初期状態で固定IPになっているのをDHCPに変更
  • アドレスを変更(どうせなので)

TODO: - 定期的に再起動するように設定

Z1: z1_stable_850M_mod20181015.7z - Google ドライブ

prootとqemu-arm-staticを使ってARM用ディスクイメージをカスタマイズする

ASICのカスタムファーム作りのためにメーカーが配布しているFWを編集することがあります。設定を予め終えた状態のFWを作る等。 普通にマウントして作業しても良いんですが、内部のライブラリをアップデートしたい場合があります。そんな時にprootqemu-arm-staticを組み合わせて作業すると便利でした。

環境

  • Host: Linux 4.18.4-arch1-1-ARCH #1 SMP PREEMPT Wed Aug 22 07:33:26 UTC 2018 x86_64 GNU/Linux
  • 対象のFW: Linux Baikal 3.4.39 #2 SMP PREEMPT Mon Nov 21 16:23:11 CST 2016 armv7l armv7l armv7l GNU/Linux

アーキテクチャが違うのでそのままchrootしてもうまくコマンドが使えませんのでダメです。

prootとQEMU(qemu-arm-static)を使う

prootとQEMUを組み合わせて使うことでアーキテクチャが違うOSであってもライブラリのアップデートなどが行なえます。 prootはchrootを実現し、qemu-arm-staticは異なるアーキテクチャをエミュレーションしてくれます。どちらもユーザー空間で動きます。

prootのインストール

PRoot — chroot, mount --bind, and binfmt_misc without privilege/setupに入手法が書いてありますが、ArchLinuxではAURからインストールできるので、yayを使って入れます。

yay -S proot

qemu-arm-staticのインストール

詳しくは QemuUserEmulation - Debian Wiki を参照。 qemu-arm-staticqemu-user-staticというパッケージに含まれています。

yay -S qemu-user-static

イメージファイルをマウント

まず、fdiskでディスクイメージ上のパーティションの区切り位置を確認します。

$ fdisk -l ./PiZero_GX10_180410_V1.2.img
Disk /home/k2/tmp/PiZero_GX10_180410_V1.2.img: 3.7 GiB, 3904897024 bytes, 7626752 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0007a4f5

Device                                             Boot  Start     End Sectors  Size Id Type
/home/k2/tmp/PiZero_GX10_180410_V1.2.img1       40960  172031  131072   64M  b W95 FAT32
/home/k2/tmp/PiZero_GX10_180410_V1.2.img2      172032 7544831 7372800  3.5G 83 Linux

次にmountコマンドでそれぞれをマウントします。オプションでSector sizeとSectorの位置とサイズを元にoffsetとsizelimitを指定します。

$ su -
# mkdir -p /mnt/pizero_boot
# mkdir -p /mnt/pizero
# mount -t vfat -o loop,offset=$((40960*512)),sizelimit=$((131072*512)) /home/k2/tmp/PiZero_GX10_180410_V1.2.img /mnt/pizero_boot
# mount -t ext4 -o loop,offset=$((172032*512)),sizelimit=$((7372800*512)) /home/k2/tmp/PiZero_GX10_180410_V1.2.img /mnt/pizero

prootでchrootする

以下のようにしてprootコマンドとqemu-arm-staticを組み合わせてchrootします。

# export PROOT_NO_SECCOMP=1 # ホストマシンのカーネルによっては必要
# cp $(which qemu-arm-static) /mnt/pizero/bin/qemu-arm-static # arm64ならqemu-aarch64-static
# proot -S /mnt/pizero -b /mnt/pizero_boot:/boot -q qemu-arm-static /bin/bash
root # 
root # export PATH=/bin:/usr/bin # PATHを設定

あとは自由に設定変更 & パッケージのインストールを行う

参考

Baikal X10: No device runningの対処方法

Baikal X10のコントロールボードのファームウェアを焼き直すことで、この状態から復帰できた。

エラーの時に何が起こっているか

ソフトウェアの状態

  • 管理画面
    • Minerはオンラインだが、デバイスが一切認識されず、No devices runningとエラーが表示される
  • マイニングプログラム
    • ASICにsshでログインしてsudo screen -rでマイニングプログラム(sgminer)を表示し、Device listを表示してもUSBデバイスが1つも認識されていない状態になる

ハードウェアの状態

  • 各ボードの赤いLEDのみが点灯し、他のLEDは消灯している

問題への対処

各ボードのFPGAにイメージを書き込み直すと、再認識されることがある

対処手順

1. FPGA用データをFWから抽出する

公開されているFWをダウンロードする。 Baikal X10の場合はこちらにリンクがあるはず。 現在公開されている最新のFWであるPiZero_GX10_180410_V1.2.img/tmp/PiZero_GX10_180410_V1.2.imgに保存。

次に、ダウンロードしたイメージファイルからコントロールボード用のイメージを抽出する。 FWのブートローダパーティションに存在するので、目的のパーティションの位置を調べ、mountする。

$ fdisk -l -u ./PiZero_GX10_180410_V1.2.img
Disk ./PiZero_GX10_180410_V1.2.img: 428.6 MiB, 449443328 bytes, 877819 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0007a4f5

Device                         Boot  Start     End Sectors  Size Id Type
./PiZero_GX10_180410_V1.2.img1       40960  172031  131072   64M  b W95 FAT32
./PiZero_GX10_180410_V1.2.img2      172032 7544831 7372800  3.5G 83 Linux

セクターサイズが512bytes, 目的のブートローダパーティションはStartが40960にある。 マウント先を作成してから、セクターサイズ * Startをoffsetとして指定してマウントして、ファイルを保存する。

$ sudo mkdir /mnt/pizero
$ sudo mount -t vfat -o loop,offset=20971520 ./PiZero_GX10_180410_V1.2.img /mnt/pizero/
$ ls -la /mnt/pizero
total 4.6M
-rwxr-xr-x 1 root root  535 11月 22  2016  boot.scr*
-rwxr-xr-x 1 root root  17K  4月 11 01:47  GX10.bin*
-rwxr-xr-x 1 root root  35K 10月 20  2017  script.bin*
drwxr-xr-x 2 root root  512 12月 13  2016 'System Volume Information'/
-rwxr-xr-x 1 root root 4.5M 11月 22  2016  uImage*
$ cp /mnt/pizero/GX10.bin ~/

GX10.binがコントロールボード用のイメージであり、実際にASICで稼働する際は/media/boot/GX10.binに配置され、初回起動時に/media/boot/G*.binにファイルが存在する場合にコントロールボードであるSTM32F407へ書き込みを行う仕組み。 初回起動時に何らかの理由で書き込みに失敗すると、今回のような状態になる場合がある。

2. コントロールボード用データをASICに転送

ASICが接続されているネットワークに接続し、取り出したGX10.binを転送する。もちろんASICから取り出したSDカードに直接配置しても良い。 ちなみにsshでログインするにはユーザー名: baikal, パスワード: baikalを使用する。

$ scp ./GX10.bin baikal@<ASICのIPアドレス>:/tmp/GX10.bin
$ ssh baikal@<ASICのIPアドレス> sudo cp /tmp/GX10.bin /media/boot/GX10.bin

3. コントロールボード用データを書き込む

配置した段階で起動時に自動的に書き込まれるはずではあるが、出力が見えないのでSSHでログインして書き込みを実行する。

$ ssh baikal@<ASICのIPアドレス>
$ su -
# check_update.py


Downloading... /media/boot/GX10.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 16616
Download        [=========================] 100%        16616 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Done

参考リンク

最後に

これでもダメならメーカーに相談しよう

ブログサービスからPingを受け取る

2018年になってもブログサービスからPingで更新通知を受け取っています。。 XML-RPCWordPress等のブログから更新通知を受け取れるのですがまた探すかもしれないのでメモ。

weblogUpdates.ping

詳細は weblogUpdates.extendedPing を参照

<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
   <methodName>weblogUpdates.ping</methodName>
   <params>
      <param>
         <value>Someblog</value>
      </param>
      <param>
         <value>https://example.com/someblog</value>
      </param>
   </params>
</methodCall>

weblogUpdates.extendedPing

パラメーター

  1. サイト名
  2. ウェブサイトのURLもしくはRSSフィードのURL
  3. (weblogUpdates.pingではOptional) ページのURL
  4. (weblogUpdates.pingではOptional) RSS/RDF/AtomフィードのURL
  5. (Optional) カテゴリーまたはタグ名, |区切り
<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
   <methodName>weblogUpdates.extendedPing</methodName>
   <params>
      <param>
         <value>Someblog</value>
      </param>
      <param>
         <value>https://example.com/someblog</value>
      </param>
      <param>
         <value>https://example.com/someblog/entries/1111</value>
      </param>
      <param>
         <value>https://example.com/someblog/feed.rss</value>
      </param>
      <param>
         <value>personal|friends</value>
      </param>
   </params>
</methodCall>

WordPressからはweblogUpdates.pingweblogUpdates.extendedPingが同時に送られてくるのを見たことがある。

出典: