コグノスケ

Rock64 の U-Boot スクリプトを読む

先日（2018年 7月 23日の日記参照）Rock64 の U-Boot が distro boot（U-Boot の distro boot の説明）を使っていることはわかりましたが、もう少し具体的に調べておきます。

U-Boot は起動するとカウントダウンを始めます（Hit any key to stop autoboot... と表示される通り、何かキーを押すと止まります）。カウントが 0 になると、bootcmd 環境変数に設定されたスクリプトを実行します。まずはそこから追います。

U-Boot 2017.09-g5aef9f7 (Oct 12 2017 - 09:11:39 +0000), Build: jenkins-linux-build-rock-64-136
   
Model: Pine64 Rock64
DRAM:  4 GiB
MMC:   rksdmmc@ff500000: 1, rksdmmc@ff520000: 0
*** Warning - bad CRC, using default environment
   
In:    serial@ff130000
Out:   serial@ff130000
Err:   serial@ff130000
Model: Pine64 Rock64
normal boot
Net:   eth0: ethernet@ff540000
Hit any key to stop autoboot:  0
=> 

=> print bootcmd
bootcmd=run distro_bootcmd

=> print distro_bootcmd
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done

=> print boot_targets
boot_targets=mmc0 mmc1 usb0 pxe dhcp

=> print bootcmd_mmc0
bootcmd_mmc0=setenv devnum 0; run mmc_boot
=> print bootcmd_mmc1
bootcmd_mmc1=setenv devnum 1; run mmc_boot

今回追いかける対象は SD カードからのブート（Rock64 の場合は mmc1 として認識）ですので、mmc0, mmc1 に注目します。bootcmd -> distro_bootcmd -> bootcmd_mmc1 -> mmc_boot と辿れます。ここまでは単純です。

環境変数:
devnum=1

----------

=> print mmc_boot
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi

----------

改行入れた版

if mmc dev ${devnum};
then
    setenv devtype mmc;
    run scan_dev_for_boot_part;
fi

----------

if の条件式だけ実行した場合

=> mmc dev 0
Card did not respond to voltage select!    ★★★失敗する
mmc_init: -95, time 9

=> mmc dev 1
switch to partitions #0, OK    ★★★成功する
mmc1 is current device

このスクリプトは mmc デバイスを使えるかどうかチェックしています。devnum=1 のときは mmc dev 1 ですね。単独で実行するとわかりますが、このコマンドは成功し、デバイスが使用可能だとわかります。

デバイスが使用可能だとわかれば、scan_dev_for_boot_part を呼びます。

環境変数:
devnum=1
devtype=mmc

----------

=> print scan_dev_for_boot_part
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done

----------

改行入れた版

part list ${devtype} ${devnum} -bootable devplist;
env exists devplist || setenv devplist 1;
for distro_bootpart in ${devplist};
do
    if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then
        run scan_dev_for_boot;
    fi;
done

----------

最初の行

=> part list mmc 1 -bootable aaa    ★★★aaa は結果を格納する環境変数名（何を指定しても OK）
=> prin aaa
aaa=6                               ★★★boot 可能パーティション番号が設定される

全部のパーティションを表示

=> part list mmc 1

Partition Map for MMC device 1  --   Partition Type: EFI

Part    Start LBA       End LBA         Name
        Attributes
        Type GUID
        Partition GUID
  1     0x00000040      0x00001f7f      "loader1"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   9bdf460d-26ba-4f39-b43f-e8289847b709
  2     0x00001f80      0x00001fff      "reserved1"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   50b5d36d-c009-4538-925e-a4ca3db6f3b9
  3     0x00002000      0x00003fff      "reserved2"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   cbcf51cb-465b-47ee-a4ca-1c1ef59a8564
  4     0x00004000      0x00005fff      "loader2"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   fd2b2a59-fb82-4e11-827b-2297cdb0b74f
  5     0x00006000      0x00007fff      "atf"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   10194a7e-66c7-4340-a932-060295f19fba
  6     0x00008000      0x0003ffff      "boot"
        attrs:  0x0000000000000004                   ★★★6 に boot 可能フラグが存在
        type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
        guid:   dbb99d65-e937-46a9-b740-256da98658a0
  7     0x00040000      0x01cf7fde      "root"
        attrs:  0x0000000000000000
        type:   0fc63daf-8483-4772-8e79-3d69d8477de4
        guid:   55c58d2b-29ce-4c0d-bfec-414479e8ca46

----------

2行目

=> part list mmc 1 -bootable aaa
=> print aaa
aaa=6

=> env exists aaa || setenv aaa 1; ★★★左のコマンド結果が真のため、右のコマンドは実行されない
=> print aaa
aaa=6                              ★★★値は変わらない

=> setenv aaa                      ★★★環境変数を削除する
=> print aaa
## Error: "aaa" not defined

=> env exists aaa || setenv aaa 1; ★★★左のコマンド結果が偽のため、右のコマンドが実行される
=> print aaa
aaa=1                              ★★★値が 1 に設定される

----------

if の条件式

=> fstype mmc 1:6 bootfstype
=> prin bootfstype
bootfstype=fat

1行目は boot 可能フラグを持ったパーティションがあるかどうかを見ています。あれば devplist 環境変数に「パーティションの番号」が設定されます。

2行目は boot 可能フラグを持ったパーティションがなかったときのフェールセーフ処理で、先頭パーティション（1番）から起動を試みます。

ループ内の if 文はパーティションのファイルシステム形式を取得して、bootfstype という環境変数に設定します。ファイルシステムがわからない場合は処理をやめます。

あと、ループの条件文のところで distro_bootpart に devplist に格納されているパーティション番号（今回の場合は 6）が設定されます。これも後で使われます。

環境変数:
devnum=1
devtype=mmc
distro_bootpart=6
bootfstype=fat

----------

=> print scan_dev_for_boot
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;

----------

改行入れた版

echo Scanning ${devtype} ${devnum}:${distro_bootpart}...;
for prefix in ${boot_prefixes};
do
    run scan_dev_for_extlinux;    ★★★成功すれば、以降は実行されない（他の scan_dev_xxx も同様）
    run scan_dev_for_scripts;
done;
run scan_dev_for_efi;

----------

boot_prefixes の内容

=> print boot_prefixes
boot_prefixes=/ /boot/

メッセージを出して、scan_dev_for_xxx のいずれかを実行します。これらのスクリプトは成功すると、OS つまり Linux などに制御が移りますので、成功したら U-Boot に戻りません。試す順は下記のようです。

• distro boot
• パーティションから U-Boot スクリプトをロード
• EFI boot

今回は distro boot を使っていますので、scan_dev_for_extlinux スクリプトを見ます。

環境変数:
devnum=1
devtype=mmc
distro_bootpart=6
bootfstype=fat
prefix=/ もしくは /boot/

----------

=> prin scan_dev_for_extlinux
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi

=> prin boot_extlinux
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf

----------

改行入れた版

-- scan_dev_for_extlinux

if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf;
then
    echo Found ${prefix}extlinux/extlinux.conf;
    run boot_extlinux;
    echo SCRIPT FAILED: continuing...;
fi

-- boot_extlinux

sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf

----------

if の条件文

=> if test -e mmc 1:6 /extlinux/extlinux.conf; then echo OK; else echo NG; fi
OK
=> if test -e mmc 1:6 /boot/extlinux/extlinux.conf; then echo OK; else echo NG; fi
NG

----------

新出の環境変数

=> print scriptaddr
scriptaddr=0x00500000

----------

sysboot のヘルプ

=> sysboot
sysboot - command to get and boot from syslinux files

Usage:
sysboot [-p] <interface> <dev[:part]> <ext2|fat|any> [addr] [filename]
    - load and parse syslinux menu file 'filename' from ext2, fat
      or any filesystem on 'dev' on 'interface' to address 'addr'

ブートするパーティションに extlinux.conf という名前の設定ファイルがあるかどうかを探し、あれば boot_extlinux スクリプトを呼びます。boot_extlinux は sysboot コマンドを呼びます。

今まで設定してきた環境変数を総動員してあてはめると…、最終的には下記のコマンドが実行されることがわかります。

sysboot mmc 1:6 any 0x00500000 /extlinux/extlinux.conf

もちろん、このコマンドを単独で実行しても起動するはずです。

# cat extlinux/extlinux.conf
label kernel-4.4
    kernel /Image
    initrd /initrd.img
    fdt /dtb
    append earlycon=uart8250,mmio32,0xff130000 rw root=LABEL=linux-root rootwait rootfstype=ext4 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#}

言い忘れてました。extlinux.conf はこのような記述です。カーネルイメージ（Image）、initramfs イメージ（initrd.img）, デバイスツリーブロブ（*.dtb）のファイル名、カーネルに渡すコマンドラインを指定できます。

GRUB の設定ファイルに似ているけど、もっとシンプルですね。

自分のマシンは何 GFLOPS か？ その 3

その 1、 その 2、 その 3

LINPACK を単独のマシンで実行してもあまり面白くないので、クラスタで実行したいと思います。役割としてはマスタが 1台、スレーブが他全部という分担になります。LINPACK の場合、マスタからスレーブに ssh でログインして、ログイン後 xhpl を実行するようです。

スレーブ側の設定

スレーブ側は LINPACK をコンパイルして、xhpl をマスタと同じパスに配置すれば OK です（HPL.dat は要らない）。マスタ側のバイナリが /home/username/a/b/c/xhpl に置かれているとしたら、スレーブ側も同じ /home/username/a/b/c/xhpl ディレクトリに置かなければ起動できないようです。

一番簡単なのはマスタ、スレーブ、全てのノードに同じユーザを作成して、MPI 実行用のバイナリを入れるディレクトリを作成することですね。

さらにスレーブは ssh の公開鍵認証にしておくと、LINPACK 起動時にパスワードを打たなくて良いので楽です。マスタからスレーブにログインできれば OK で、スレーブからマスタにログインする設定は不要です。

マスタ側の設定

マスタ側は LINPACK をコンパイルするのは当然として、少しだけ特別な設定が必要です。私は hostfile の存在に気づくまでにかなり時間がかかりました…。

• HPL.dat: 単独で実行していたときにも使っていた LINPACK パラメータを書いたファイル
• hostfile: クラスタのノード一覧を書いたファイル

HPL.dat は単独動作と同じで良いです。性能は後で考えるとして、とりあえず動作するはずです。

クラスタのノード一覧 hostfile は単独のときには使っていませんでした。基本的にはクラスタを構成するノードのホスト名（IP アドレスでも良いです）を並べるだけです。

localhost slots=4
192.168.1.109 slots=4

上記は 2台構成（Rock64 が localhost、Raspberry Pi 3 が 192.168.1.109）の記述です。slots= にはそのノードがいくつのプロセスを扱えるかを記述します。どちらも 4コア 4スレッドの CPU なので slots=4 としています。まあ 2 とか 8 とかにしても動きますが、効率は下がります。

クラスタ起動

実行は下記のようにします。Rock64 がマスタ、Raspberry Pi 3 がスレーブです。下記のコマンドはマスタ側で実行してください。

$ cd bin/Linux_ATHLON_CBLAS
$ ls
HPL.dat  hostfile  xhpl

$ mpirun -n 8 -hostfile hostfile -host localhost,192.168.1.109 xhpl
...
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00L2L2        2000    64     1     4               3.74              1.429e+00
HPL_pdgesv() start time Wed Aug 15 00:11:49 2018

HPL_pdgesv() end time   Wed Aug 15 00:11:53 2018

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0037309 ...... PASSED
...

MPI の凄いところは Rock64（arm64）と RasPi（arm）のようにアーキテクチャが違うクラスタでも実行できてしまうところです。メッセージパッシングの隠れた利点かもしれません。

動作しているかどうか確認するには Raspberry Pi 3 側で top などで見るのが確実だと思います。LINPACK 実行中に xhpl が 4プロセス実行されているはずです（全力で実行した場合）。

ちなみに hostfile を指定し忘れるとこんなエラーになります。8プロセス起動しろと言われても、どのノードがプロセスをいくつ受け持ってくれるかわからないので、怒っている訳ですね。

$ mpirun -n 8 -host localhost,192.168.1.109 xhpl
--------------------------------------------------------------------------
There are not enough slots available in the system to satisfy the 8 slots
that were requested by the application:
  xhpl

Either request fewer slots for your application, or make more slots available
for use.
--------------------------------------------------------------------------

それと OpenMPI のバージョンには注意してください。我が家のデスクトップ PC（Debian Testing, OpenMPI 3.1.1）とファイルサーバ（Debian Stable, OpenMPI 2.0.2）で x86_64 クラスタを構成しようとしたところ、OpenMPI のバージョン違いでこんなエラーになって実行できませんでした。

$ mpirun -n 4 -hostfile hostfile -host localhost,falcon xhpl
[blackbird:29131] tcp_peer_recv_connect_ack: invalid header type: 0 ★★★★こんなエラーで怒られる★★★★
--------------------------------------------------------------------------
ORTE was unable to reliably start one or more daemons.
This usually is caused by:

* not finding the required libraries and/or binaries on
  one or more nodes. Please check your PATH and LD_LIBRARY_PATH
  settings, or configure OMPI with --enable-orterun-prefix-by-default

* lack of authority to execute on one or more specified nodes.
  Please verify your allocation and authorities.

* the inability to write startup files into /tmp (--tmpdir/orte_tmpdir_base).
  Please check with your sys admin to determine the correct location to use.

*  compilation of the orted with dynamic libraries when static are required
  (e.g., on Cray). Please check your configure cmd line and consider using
  one of the contrib/platform definitions for your system type.

* an inability to create a connection back to mpirun due to a
  lack of common network interfaces and/or no route found between
  them. Please check network connectivity (including firewalls
  and network routing requirements).
--------------------------------------------------------------------------

エラーメッセージはたくさん出ますが、解決に辿り着かないので何とも言えない気分です…。

肝心の性能は

結論から言ってしまえば Rock64 と Raspberry Pi 3 のクラスタは意味がなさそうです。なぜなら Rock64 1台のほうが速いからです…。

まずは単独実行と同じ問題サイズ N=2000 での実行結果です。多少上下しますが 0.6〜0.7GFlops くらいです。Rock64 単独（1.4GFlops）の半分以下です。P, Q の値は 2, 4 が一番良さそうでした。他の値（1, 8 や 4, 2）にすると激遅で実行が終わりません。

$ mpirun -n 8 -hostfile hostfile -host localhost,192.168.1.109 xhpl
...
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00R2L4        2000    64     2     4               7.97              6.699e-01
HPL_pdgesv() start time Wed Aug 15 00:41:15 2018

HPL_pdgesv() end time   Wed Aug 15 00:41:22 2018

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0037423 ...... PASSED
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00R2C2        2000    64     2     4               7.94              6.724e-01
HPL_pdgesv() start time Wed Aug 15 00:41:23 2018

HPL_pdgesv() end time   Wed Aug 15 00:41:31 2018
...

問題サイズが小さすぎたかな？と思い N=4000 にしてみました。0.9〜1.3GFlops とだいぶ性能が上がります。単独実行の場合 N=2000 と N=4000 ではほぼ性能に変化はありません。

$ mpirun -n 8 -hostfile hostfile -host localhost,192.168.1.109 xhpl
...
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00L2L2        4000    64     2     4              32.17              1.327e+00
HPL_pdgesv() start time Wed Aug 15 00:50:32 2018

HPL_pdgesv() end time   Wed Aug 15 00:51:04 2018

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=        0.0018773 ...... PASSED
================================================================================
T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR00L2L4        4000    64     2     4              40.92              1.043e+00
HPL_pdgesv() start time Wed Aug 15 00:51:04 2018

HPL_pdgesv() end time   Wed Aug 15 00:51:45 2018
...

性能が違うノードを組み合わせているからなのか、放熱が足りなくてオーバーヒートしているのか、性能がかなり不安定です。たまに System 負荷が 50％台に張り付いて、実行が終わらなくなるときもあります。うーん、たった 2台でも難しいものだな。

自分のマシンは何 GFLOPS か？ その 2

その 1、 その 2、 その 3

LINPACK のビルドができたので、さっそく実行してみます。バイナリは bin ディレクトリの下にあります。

実行の仕方は mpirun -n 4 xhpl のようにします。パラメータファイル（HPL.dat）が置いてあるディレクトリで実行してください。

AMD A10-7800 での実行結果

これが最速パラメータかどうか自信がありませんが、とりあえず 10GFlops だそうです。

しかし hdk 氏の AMD A10-7870K は 19GFlops 出ているそうです。両者ともに Bulldozer 系の APU なのに、倍も差がつく理由がさっぱりわかりません。謎です…。

AMD A10-7800 の性能（追記）

何気なく cblas と atlas のスタティックリンクをやめて、ダイナミックリンクに変更したところ、いきなり性能が上がり 1.7倍の 17GFlops になりました。

AMD A10-7800 での実行結果（ダイナミックリンク版）

えー？なぜ！？とりあえず perf top で見てみると libatlas.so の関数が 8割ほどの実行時間を占めています。ここが効率的になったんでしょうか？そんなに変わるものですかね、さっぱり意味がわかりません…。

ARM も見てみる

Rock64 でも実行してみました。SoC は Rockchip RK3328、CPU は Cortex-A53 x 4 です。

Rock64 での実行結果

大体 1.5GFlops でした。A10-7800 と比べるとやはり 1桁違いますね（PC が 6.7倍速い）（ダイナミックリンク版だと 11倍速い）。

コンパイル実験（2018年 8月 12日の日記参照）のときは PC が 18倍ほど速かったので、コンパイル実験よりは差が縮まっている、とも取れます。

電力効率の点から見ると、PC 1台より Rock64 を 10台並べた方が省エネなのでしょうか？微妙かな…？今度、ワットチェッカーで比べてみましょうか。

自分のマシンは何 GFLOPS か？ その 1

その 1、 その 2、 その 3

自分のマシンは何 GFLOPS か知りたくなって、スパコン界隈で有名な LINPACK を実行してみようと思い立ちました。ソースコードは HPL- A Portable Implementation of the High-Performance Linpack Benchmark for Distributed-Memory Computers にあります。私は hpl-2.2.tar.gz を使用しました。

ビルド方法は INSTALL ファイルに書いてある通りですが、結構ハマったので、私の手順もメモしておきます。環境は Debian GNU/Linux Testing の amd64 版です。

LINPACK の Makefile

コードを展開し、setup ディレクトリの下にある Make.xxx をトップディレクトリにコピーして使います。たくさんファイルがありますが、Athlon マシンなので Linux_ATHLON_CBLAS を選びました。FBLAS という名前のファイルもありますが、

• CBLAS: C 版
• FBLAS: Fortran 版

のようです。用語の意味はわかりませんが、Makefile の diff を見れば何となくわかるはず、きっと。

ビルドの準備

コピーしてきた Make.Linux_ATHLON_CBLAS は書き換える必要があります。特に大事なのは TOPdir です。

この変更を忘れるとホームディレクトリ直下の hpl というディレクトリがトップディレクトリだと思って、ビルドを始めます。最終的に「Make.inc が見つからない」と言われて失敗します。

Make.inc を find で探すとわかりますが Make.inc はシンボリックリンクです。ビルドに失敗するときは Make.inc が全然関係ない場所を指していると思います。

もし TOPdir を書き換え忘れてビルドが失敗した場合は make arch=Linux_ATHLON_CBLAS clean_arch としてください。アーキテクチャ名の付いたディレクトリ（Make.inc もそのディレクトリに入っている）が全て消滅するはずです。

# TOPdir をソースコードを配置した位置に合わせて修正します
TOPdir = ...

# コンパイラを gcc から mpicc にします
CC = /usr/bin/mpicc
# リンカも gcc から mpicc にします
LINKER = /usr/bin/mpicc

# OpenMPI のライブラリ位置
MPdir = /usr/lib/x86_64-linux-gnu
MPinc = -I$(MPdir)/openmpi/include

# ビルドしたバイナリが動かなくなるため、MPlib は削除
#MPlib = ...

# LAlib のライブラリ位置
LAdir = /usr/lib/x86_64-linux-gnu
# スタティックリンクだとなぜか遅いので、ダイナミックリンクに変更
LAlib = -lcblas -latlas

# 末尾に -lrt -lbacktrace を追加します。
# HPL_LIBS の先頭に追加するとリンクエラーになります。
HPL_LIBS = ... -lrt -lbacktrace

あと、私の環境の場合、下記パッケージのインストールが必要でした。

• libopenmpi-dev
• libmpich-dev
• libatlas-base-dev

実行はまた今度にします。