明日にはでっかい太陽が昇るかもしれません。

「覚悟」とは!! 暗闇の荒野に!!進むべき道を切り開く事だッ!

Linux (aarch64) on Qemu を動作させたい (1)

U-Boot をひと通り動かすことができるようになったので、引き続き Linux を動作させていく。

Linux も、 NXP-SDK 付属のものを使用して、ターゲット向けのバイナリをそのまま動作させることを目指す。

FIT ファイルの作成

ビルドしたあと、 U-Boot からよみこむために FIT (Flattened uImage Tree) ファイルを作成する。

its ファイルは、 NXP-SDK 付属のものをベースにしている。

$ cat kernel.its
/dts-v1/;

/ {
        description = "Image file for the LS1046A Linux Kernel";
        #address-cells = <1>;

        images {
                kernel@1 {
                        description = "ARM64 Linux kernel";
                        data = /incbin/("path/to/arch/arm64/boot/Image.gz");
                        type = "kernel";
                        arch = "arm64";
                        os = "linux";
                        compression = "gzip";
                        load = <0x80080000>;
                        entry = <0x80080000>;
                };
                fdt@1 {
                        description = "Flattened Device Tree blob";
                        data = /incbin/("path/to/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dtb");
                        type = "flat_dt";
                        arch = "arm64";
                        compression = "none";
                        load = <0x90000000>;
                };
                ramdisk@1 {
                        description = "LS1046 Ramdisk";
                        data = /incbin/("path/to/fsl-image-minimal-ls1046ardb.ext2.gz");
                        type = "ramdisk";
                        arch = "arm64";
                        os = "linux";
                        compression = "gzip";
                };
        };

        configurations {
                default = "config@1";
                config@1 {
                        description = "Boot Linux kernel";
                        kernel = "kernel@1";
                        fdt = "fdt@1";
                        ramdisk = "ramdisk@1";
                };
        };
};

$ mkimage -f kernel.its kernel.itb

作成した itb ファイルは emmc イメージにコピーしておく。

Linux kernel の起動

U-Boot を起動したあと、

=> print load_addr
load_addr=0xa0000000
=> print emmc_bootcmd
emmc_bootcmd=echo Trying load from eMMC ..;mmcinfo; ext2load mmc 0:1 $load_addr /kernel.itb; bootm $load_addr
=> run emmc_bootcmd

Linux をロードできる。

で、動作はというと、2番目以降のコアを起動するところで、起動させることができずに起動待ちループで止まってしまった。

... 省略 ...
[    0.064447] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
[    0.068584] pid_max: default: 32768 minimum: 301
[    0.078346] Security Framework initialized
[    0.092536] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[    0.093597] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[    0.211129] Initializing cgroup subsys memory
[    0.217881] Initializing cgroup subsys hugetlb
[    0.320269] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 1 counters available
[    0.324401] EFI services will not be available.
... ここで止まる ...

U-Boot のとき同様、 Qemu 経由で kernel に GDB を接続すると、以下のことがわかった。

  1. CPU の起動方法 ("enable-method") に "spin-table" が設定されている
  2. CPU の起動トリガ ("cpu-release-addr") にアドレスを書き込んだあとに SEV を呼び出している
  3. が、Qemu 側が SEV / WFE 命令に対応していないため、何も起こらない

という状況っぽい。

CPU 起動待ちのタイムアウトも発生していないのが気になるが、今は Qemu を SEV に対応させることを考えている。

でも、 Qemu の aarch64 が smp に対応していないということはないはずなので、何かが間違っているから動いていないだけの可能性もあるので、まずは Qemu の aarch64 で smp 可能なボードがどう動いているかを解析してみることにする。


追記 (2017-12-11 21:55)

とりあえず、 U-Boot のときも比較に使用していた Xilinx の Zynq MP ボードは CPU の起動方法が "psci" となっており、起動方法が異なるので参考にはならなさそう。

仮想ボードが virt の場合とかはどう動くんだろう?

U-Boot (aarch64) on Qemu を動作させたい (10)

github.com

ほそぼそと開発を続けていたのですが、ようやく eMMC (実態は SDHCバイス) の実装がある程度まともに動作するようになり、 U-Boot から ext2 パーティションをマウントできるようになりました。

仕事で使用しているカスタムボードは eMMC から kernel をブートするので、 PCIe よりも優先して対応していました。

コード対応はコミットを見ればわかるけど、 qemu の起動引数での emmc ファイルイメージの指定方法や、そもそも emmc イメージファイルにパーティションファイルシステムを作成する手順をまとめておく。

emmc ファイルイメージファイルを作成する

### truncate コマンドを使用する場合
$ truncate -s 4GiB emmc.img

サイズは適当に。

イメージファイルにパーティションファイルシステムを作成する

### 開いているループバックデバイスを調べてファイルを割り当てる
$ sudo losetup -f
/dev/loop0
$ sudo losetup /dev/loop0 emmc.img 

### パーティションを作成する
$ sudo parted /dev/loop0
GNU Parted 2.3
/dev/loop0 を使用
GNU Parted へようこそ! コマンド一覧を見るには 'help' と入力してください。
(parted) mkpart primary ext2 1024KiB 100%                                                                                                                     
(parted) print                                                            
モデル: Loopback device (loop)
ディスク /dev/loop0: 4295MB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos

番号  開始    終了    サイズ  タイプ   ファイルシステム  フラグ
 1    1049kB  4295MB  4294MB  primary

(parted) q

### ext1 パーティションを作成
$ sudo mkfs.ext2 /dev/loop0p1

### ループバックデバイスの割り当てを解除
$ sudo losetup -d /dev/loop0

なんか、パーティションの開始セクタは開けておかないと 警告: 操作の結果できるパーティションはアライメントが正しくないためにパフォーマンスがでません。 という警告が出たので、 fdisk で初期化した時に作成される隙間と同じサイズを開けている。

一応、 parted コマンドでもファイルシステムを作れるけど、 mkfs サブコマンドを実行すると

警告: ファイルシステムに対して parted による操作(mkfs)を行おうとしています。
parted のファイルシステム操作コードは、e2fsprogs のようなファイルシステム専
用のものほど堅固に作られていません。可能なかぎり parted をパーティションテー
ブルの操作だけに用いることをお勧めします。ほとんどのファイルシステムに
対するほとんどの操作は今後のリリースで削除される予定です。

ってでるので、あとから mkfs コマンドを実行している。

fdisk を使わずに parted コマンドでパーティションを作成しているのは、 partedパーティション作成後に自動で /dev/loop0p1 デバイスファイルを作成してくれるから。 (fdisk 使っても手動でデバイスファイルは作れるんだろうけど、未調査)

仮想マシンにイメージファイルをマウントする

### drive オプション (種別は SD) でファイルをマウントする
$ qemu-system-aarch64 \
    -machine ls1046ardb \
    -smp 4 \
    -m 2046M \
    -kernel u-boot.elf \
    -drive if=sd,cache=unsafe,format=raw,file=emmc.img \
    -nographic \

仮想マシン上から読み込む

### ファイルの確認と、内容の確認
=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     2048            8386560         3bc514ae-01     83
=> ext2ls mmc 0:1 /
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
               5 test.txt
=> ext2load mmc 0:1 80000000 /test.txt
5 bytes read in 26 ms (0 Bytes/s)
=> md.b 80000000 8
80000000: 74 65 73 74 0a 00 00 00                            test....

ホスト PC 上でイメージにファイルを追加する

開発は docker 上で行っているが、 docker コンテナで parted の自動デバイス割り当てが動作しなかった (udevadm が動作しない) ので、こちらの手順は fdisk で行っている。

### パーティションの位置を確認する
$ fdisk -l ../../emmc.img 
Disk ../../emmc.img: 4 GiB, 4294967296 bytes, 8388608 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: 0x3bc514ae

Device          Boot Start     End Sectors Size Id Type
../../emmc.img1       2048 8388607 8386560   4G 83 Linux

### パーティションの先頭をオフセットにしてマウントする
$ sudo mount -o loop,offset=$((2048*512)) emmc.img /mnt

ということで、無事に emmc イメージファイル上のファイルを仮想マシン上で読み込むことができた。

次は kernel ブートを試してみる。

SDIO におけるコマンドの CRC について

Qemu の MMC / SDエミュレーションのコードを見ると、すべてのデバイスCRCcrc = 0 /* FIXME */ とかになっているので、真面目に実装しようかなと思って調べた情報を記載しておく。

全体の仕様は、

https://www.sdcard.org/cht/developers/overview/sdio/sdio_spec/Simplified_SDIO_Card_Spec.pdf

を見れば良くて、細かな実装は、

Seabright Technology

を参考にできそう。

docker コンテナ内で byobu (tmux) を利用する

Tmux and Screen | Intuitive documentation for using Docker containerization

最近は docker exec で直接コンテナ内に入っているけど、 ssh 経由の場合などと対処を混同しちゃうので、まとめておく。

$ docker exec -ti YOUR_CONTAINER_NAME script -q -c "/bin/bash" /dev/null

でコンテナ内に入って、

### or tmux
$ byobu 

とすれば、コンテナ内で tmux を正常に起動できる。

U-Boot (aarch64) on Qemu を動作させたい (9)

github.com

結論からいうと、公式の U-Boot をターゲット向けビルドのモジュールのまま Qemu 上で起動することができるようになった。

ここでの公式は、オリジナル U-Boot に NXP のカスタマイズが入った今回のターゲットボードである LS1046A RDB 向け U-Boot を指す。

前回 PTE の情報がなにかおかしそう、というところまでわかっていたが、リロケーション前に early_mmu_setup()set_ttbr_tcr_mair() で設定する TCR の値がリロケーション後のメモリマップと合っていないっぽいことがわかった。

get_tcr() で、メモリマップに定義されたアドレスの最大値からアドレス幅を求めて、 T0SZ の値を出しているのだが、リロケーション前のアドレスマップは LS1046A RDB で定義されている 480 GiB の DDR Region3 領域を使用しないようになっていたため、リロケーション前に設定した TCR (T0SZ) を使用したリロケーション後の PTE アクセスで不整合が発生していたように見える。

なので、リロケーション前のアドレスマップにも DDR Region3 領域を追加すると無事プロンプトが使えるところまで起動させることができるようになった。

... 省略 ...
DRAM:  Detected UDIMM                                                                                                                                           [1155/19018]
1.9 GiB (DDR4, 32-bit, CL=1, ECC off)
Waking secondary cores to start from fbd1f000
Not all cores (0xf) are up (0x1)
Did not wake secondary cores
Using SERDES1 Protocol: 4403 (0x1133)
Using SERDES2 Protocol: 21849 (0x5559)
ERROR: Stopped after 0 portals
ERROR: Stopped after 0 portals
NAND:  fsl_ifc_chip_init: address did not match any chip selects
0 MiB
MMC:   FSL_SDHC: 0
MMC: no card present
mmc_init: -123, time 1002
*** Warning - MMC init failed, using default environment

EEPROM: wait_for_sr_state: failed sr=a1 cr=f8 state=202
i2c_init_transfer: failed for chip 0x53 retry=0
wait_for_sr_state: failed sr=a1 cr=f8 state=202
i2c_init_transfer: failed for chip 0x53 retry=1
wait_for_sr_state: failed sr=a1 cr=f8 state=202
i2c_init_transfer: failed for chip 0x53 retry=2
i2c_init_transfer: give up i2c_regs=0x2180000
Read failed.
In:    serial
Out:   serial
Err:   serial
AHCI 0000.0000 1 slots 1 ports ? Gbps 0x0 impl SATA mode
flags: 
Found 0 device(s).
SCSI:  Net:   
MMC read: dev # 0, block # 18432, count 128 ...
MMC: no card present
mmc_init: -123, time 1001
MMC: block number 0x4880 exceeds max(0x0)
Fman1: Data at 00000000fbc25d30 is not a firmware
PCIe0: pcie@3400000 Endpoint: no link
PCIe1: pcie@3500000 Endpoint: no link
PCIe2: pcie@3600000 Endpoint: no link
No ethernet found.
Hit any key to stop autoboot:  0 
=> q
Unknown command 'q' - try 'help'

だが、 SDHCが未実装だったり、コアが 1 つしか動作していなかったりと、エミュレーションとしては不十分だが、 U-Boot の機能実装に対するテストが行えるようにはなったのではないかと思う。

と、ここまでは NXP の提供する NXP-SDK v2.0 update 17.03 に含まれる U-Boot で確認していたのだが、冒頭のリポジトリの最新コードを使用すると、リロケーション前のアドレスマップに対する修正なしに (Qemu で動かすための修正なしに!) すんなり起動してしまった。。

最新のコードでもアドレスマップに対する変更は入っていないし、(そもそもNXP-SDK v2.0 のコードも実機で動作しているものなのでアドレスマップが間違っているということはないと思うし、) どの差分が影響しているかは追っていないが、実機向けのバイナリがそのまま Qemu で起動できたのはとても嬉しかった。

最終目標は、仕事で使用しているカスタムボードのバイナリを動作させることだが、ベースシステムのバイナリを動作させられたという重要なマイルストーンを達成したので GitHub にアップしておく。

github.com

U-Boot (aarch64) on Qemu を動作させたい (8)

ハングの原因を追いかけると、リロケーション後に特定のメモリ領域 (キャッシュ関連) に値が入っていないため、例外が発行されていることがわかった。

U-Boot 的には final_mmu_setup() > enable_caches() 内の asm volatile ("msr tcr_el3, %0" : : "r" (tcr) : "memory") で例外が発生している。

Qemu 的には、 get_phys_addr_lpae() でエラーが発生している。

get_phys_addr_lpae() では、用途はわからないが特定のアドレス領域を読んでいて、そこから CPU の持つ機能を判断しているように見えたけど、そこで領域が 0 クリア状態のためエラーに流れていた。

さらなる調査のために、 gdb でメモリアドレスを監視する手段を確認すると、 watch コマンドで監視できることがわかった。

### アドレスは uint64_t として読み出されているため、監視する型を uint64_t にする
(gdb) watch *((uint64_t *)0x7fffd93f0000)
Hardware watchpoint 3: *((uint64_t*)0x7fffd93f0000)
(gdb) c
Continuing.


Hardware watchpoint 3: *((uint64_t*)0x7fffd93f0000)

Old value = 0
New value = 1006571523
0x00007fffdd42a8d0 in code_gen_buffer ()

調べを進めると、 PTE とプログラムの動きがあっていないような感じがする。ここからどう追うか。。

U-Boot (aarch64) on Qemu を動作させたい (7)

なんとか、 DDR の SDP も実装し、 board_f.c の init_sequence_f の初期化シーケンスについては抜けられるようになった。

だが、どこかでハングが発生して、プロンプトまでは到達していない。

u-boot の処理では、プログラムのリロケーションが実行されており、ブレイクポイントは張れなくなっている。

調べると、 gdb ではリロケーション後のシンボル読み込みにも対応していることがわかった。

### リロケーション後のアドレスを確認する
(gdb) p/x gd->relocaddr
$1 = 0xffcfb000

### 現在のシンボルの破棄
(gdb) symbol-file
Discard symbol table from `/path/to/u-boot-qoriq-2016.09+fslgit-r0/build_ls1046ardb_emmc/u-boot'? (y or n) y
No symbol file now.

### リロケーション後アドレスにシンボルを読み込み
(gdb) add-symbol-file u-boot 0xffcfb000
add symbol table from file "u-boot" at
        .text_addr = 0xffcfb000
(y or n) y
Reading symbols from u-boot...done.

### ブレイクポイントの貼り直し
(gdb) b ../arch/arm/lib/crt0_64.S:110
Breakpoint 6 at 0xffd00c90: file ../arch/arm/lib/crt0_64.S, line 110.

### ブレイクポイントの動作確認
(gdb) c
Continuing.

Breakpoint 6, _main () at ../arch/arm/lib/crt0_64.S:110
110             bl      c_runtime_cpu_setup             /* still call old routine */