U-Boot (aarch64) on Qemu を動作させたい (3)
確認していくと、どうやら u-boot の _start (arch/arm/cpu/armv8/start.S:22) がちゃんと処理されていることが確認できた。
確認手順は、
$ qemu-system-aarch64 \
-S -gdb tcp::1234 \
-machine $MACHINE \
-kernel u-boot/u-boot \
-nographic
してから、
$ aarch64-linux-gnu-gdb u-boot ... Reading symbols from u-boot...done. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 _start () at arch/arm/cpu/armv8/start.S:22 22 b reset
で OK。
u-boot の動きを追いかけると、、、
board_init_f (boot_flags=<optimized out>) at common/board_f.c:1083
までは動作していて、
relocate_code () at arch/arm/lib/relocate_64.S:24 24 mov x29, sp (gdb) s 25 str x0, [sp, #16] (gdb) s 29 ldr x1, =__image_copy_start /* x1 <- SRC &__image_copy_start */ (gdb) p __image_copy_start $6 = 0x80000 <_start> "\n"
リロケーションも上手く行っているように見えるが、、、
relocate_code() を抜けるとハングしているので、リロケーションが上手くできていない？？
relocate_code () at arch/arm/lib/relocate_64.S:76 76 ret (gdb) s ^C Thread 1 received signal SIGINT, Interrupt. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000000000000 in ?? () Backtrace stopped: not enough registers or memory available to unwind further
直前のコードで怪しそうなのは、、、
26 /* 27 * Copy u-boot from flash to RAM 28 */ 29 ldr x1, =__image_copy_start /* x1 <- SRC &__image_copy_start */ 30 subs x9, x0, x1 /* x9 <- relocation offset */ 31 b.eq relocate_done /* skip relocation */ 32 ldr x2, =__image_copy_end /* x2 <- SRC &__image_copy_end */ 33 34 copy_loop: 35 ldp x10, x11, [x1], #16 /* copy from source address [x1] */
で、実際の処理は b.eq で relocate_done にジャンプしており、コピーが行われていない。 (正しくはコピーが行われるべき？？)
__image_copy_start は
(gdb) p __image_copy_start $1 = 0x80000 <_start> "\n" (gdb) p/x *(__image_copy_start + 0) $14 = 0xa (gdb) p/x *(__image_copy_start + 1) $15 = 0x0 (gdb) p/x *(__image_copy_start + 2) $16 = 0x0 (gdb) p/x *(__image_copy_start + 3) $17 = 0x14 (gdb) p/x *(__image_copy_start + 4) $18 = 0x1f (gdb) p/x *(__image_copy_start + 5) $19 = 0x20 (gdb) p/x *(__image_copy_start + 6) $20 = 0x3 (gdb) p/x *(__image_copy_start + 7) $21 = 0xd5
となっており、 u-boot.bin のデータが先頭から配置されていた。
レジスタの状態はというと、
x0 0x0 0 x1 0x0 0 x2 0x0 0 x3 0x0 0 x4 0x0 0 x5 0x2e 46 x6 0x170 368 x7 0x0 0 x8 0x0 0 x9 0x0 0
となっており、 subs x9, x0, x1 で x9 が 0 になったため、 b.eq で relocate_done にジャンプする結果になったようだ。
relocate_code() の処理を真面目に追いかけると、
16 /*
17 * void relocate_code (addr_moni)
18 *
19 * This function relocates the monitor code.
20 * x0 holds the destination address.
21 */
22 ENTRY(relocate_code)
# x29 0x80088 524424
# x30 0x82588 533896
# sp 0x0 0x0
# pc 0x825d0 0x825d0 <relocate_code>
23 stp x29, x30, [sp, #-32]! /* create a stack frame */
/** つまり、 x29 および x30 のデータを [sp, #-32] に push している？ */
# STP Xt1, Xt2, [Xn|SP, #imm]! ; 64 ビット汎用レジスタ、プレインデクス
# Xt1 転送される最初の汎用レジスタ（64 ビット）名を 0 ～ 31 の範囲内で指定します。
# Xt2 転送される 2 つ目の汎用レジスタ（64 ビット）名を 0 ～ 31 の範囲内で指定します。
# Xn|SP 64 ビットの汎用ベースレジスタ名またはスタックポインタ名を 0 ～ 31 の範囲内で指定します。
# imm 64 ビット汎用レジスタ。
# ポストインデクスおよびプレインデクスバリアントは符号付きイミディエートバイトのオフセットであるため、
# -512 ～ 504 の範囲で 8 の倍数となります。
# 符号付きオフセットバリアントはオプションの符号付きイミディエートバイトのオフセットであるため、
# -512 ～ 504 の範囲で 8 の倍数で指定します。デフォルトで 0 になります。
# x29 0x80088 524424
# x30 0x82588 533896
# sp 0xffffffffffffffe0 0xffffffffffffffe0 /** sp が負数って良いの？？ */
# pc 0x825d4 0x825d4 <relocate_code+4>
24 mov x29, sp /** x29 = sp */
# x29 0xffffffffffffffe0 -32
# x30 0x82588 533896
# sp 0xffffffffffffffe0 0xffffffffffffffe0
# pc 0x825d8 0x825d8 <relocate_code+8>
25 str x0, [sp, #16] /** x0 = *(sp + 16) */
26 /*
27 * Copy u-boot from flash to RAM
28 */
# x0 0x0 0
# x1 0x0 0
# x29 0xffffffffffffffe0 -32
# x30 0x82588 533896
# sp 0xffffffffffffffe0 0xffffffffffffffe0
# pc 0x825dc 0x825dc <relocate_code+12>
29 ldr x1, =__image_copy_start /* x1 <- SRC &__image_copy_start */
# x0 0x0 0
# x1 0x0 0
# x29 0xffffffffffffffe0 -32
# x30 0x82588 533896
# sp 0xffffffffffffffe0 0xffffffffffffffe0
# pc 0x825e0 0x825e0 <relocate_code+16>
30 subs x9, x0, x1 /* x9 <- relocation offset */
31 b.eq relocate_done /* skip relocation */
雰囲気は、 L25 の str の結果 (x0) と L29 の ldr の結果 (x1) が 0 になっているのがおかしい気がする。
そもそも、 L23 の stp の結果がスタックにちゃんと入っていない気がする。。
(gdb) x/8 -32 0xffffffffffffffe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xfffffffffffffff0: 0x00000000 0x00000000 0x00000000 0x00000000
ちなみに、期待通り動作している xilinx_zcu102 では、
x29 0x8000090 134217872 x30 0x7ff1fc30 2146565168 sp 0x7df1adb0 0x7df1adb0 pc 0x8002c7c 0x8002c7c <relocate_code+4> (gdb) x/8 0x7df1adb0 0x7df1adb0: 134217872 0 2146565168 0 0x7df1adc0: 0 0 0 0
うん、期待通り SP のアドレスに x29 と x30 が push されている。
ということは、 raspi3 の場合に SP が 0 になっていることが問題の原因？？
解析を続けると、 arch/arm/lib/crt0_64.S で SP が 0 になる処理を発見した。
88 #if !defined(CONFIG_SPL_BUILD) 89 /* 90 * Set up intermediate environment (new sp and gd) and call 91 * relocate_code(addr_moni). Trick here is that we'll return 92 * 'here' but relocated. 93 */ 94 ldr x0, [x18, #GD_START_ADDR_SP] /* x0 <- gd->start_addr_sp */ 95 bic sp, x0, #0xf /* 16-byte alignment for ABI compliance */
L94 で x0 に 0 が入り、 L95 で sp = x0 が行われていた。
先ほどと同じく、 xilinx_zcu102 で確認すると、
94 ldr x0, [x18, #GD_START_ADDR_SP] /* x0 <- gd->start_addr_sp */ (gdb) info register sp x0 x18 sp 0x7ff7e90 0x7ff7e90 x0 0x0 0 x18 0x7ff7e90 134184592 (gdb) s 95 bic sp, x0, #0xf /* 16-byte alignment for ABI compliance */ (gdb) info register sp x0 x18 sp 0x7ff7e90 0x7ff7e90 x0 0x7df1add0 2112990672 x18 0x7ff7e90 134184592 (gdb) x/32 0x7ff7e90 0x7ff7e90: 0x7df1af58 0x00000000 0x00000100 0x00000000 0x7ff7ea0: 0x0001c200 0x00000000 0x00000000 0x00000000 0x7ff7eb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x7ff7ec0: 0x00000000 0x00000000 0x00000001 0x00000000 0x7ff7ed0: 0x08057220 0x00000000 0x00000000 0x00000000 0x7ff7ee0: 0x80000000 0x00000000 0x7ff1d000 0x00000000 0x7ff7ef0: 0x80000000 0x00000000 0x000c2d20 0x00000000 0x7ff7f00: 0x7df1add0 0x00000000 0x7df1add0 0x00000000
やはり L94 で x0 に適切な値が代入されていた。 ( x0 = *(x18 + 0x70))
それで、 raspi3 はというと、、、
(gdb) s 95 bic sp, x0, #0xf /* 16-byte alignment for ABI compliance */ (gdb) info register sp x0 x18 sp 0x7ffdd20 0x7ffdd20 x0 0x0 0 x18 0x7ffdd20 134208800 (gdb) x/32 0x7ffdd20 0x7ffdd20: 0 0 0 0 0x7ffdd30: 0 0 0 0 0x7ffdd40: 0 0 0 0 0x7ffdd50: 0 0 0 0 0x7ffdd60: 0 0 0 0 0x7ffdd70: 0 0 0 0 0x7ffdd80: 0 0 0 0 0x7ffdd90: 0 0 0 0
コードを見ると、 x18 には global_data が入っているのが期待動作らしく、 raspi3 のように global_data がオール 0 というのはやはりおかしそう。
global_data の処理を追いかければ、何かヒントがみつかるかも？？
U-Boot (aarch64) on Qemu を動作させたい (2)
とりあえず、期待通り U-Boot の entry point である 0x80000 (_start) に制御が移っているのか？ということの確認を目指してみる。
gdb --args qemu-system-aarch64 -machine raspi3 -kernel u-boot/u-boot -nographic
途中 (qemu/boot.c) に
/* Assume that raw images are linux kernels, and ELF images are not. */
kernel_size = arm_load_elf(info, &elf_entry, &elf_low_addr,
&elf_high_addr, elf_machine);
というコメントもあったので、読み込むバイナリは elf (≠ u-boot.bin) で問題なさそう。 (事実 is_linux フラグは false となる)
arm_load_kernel_notify() あたりまで u-boot の読み込み処理を追いかけた結果、ファイルのロードや entry point が 0x80000 となることなどは期待通り動作していそう。
次は、リセット時に entry point にジャンプできているか見ていく。
`do_cpu_reset()' (qemu/boot.c) に break point を設定して追いかけてみる。
do_cpu_reset() から aarch64_cpu_set_pc() が呼ばれて、 env.pc に entry point (0x80000) が設定されていることは確認できた。
ここからがわからない。。 qemu/target/arm/machine.c や qemu/target/arm/translate-a64.c あたりに処理が移るのか？実際に PC を処理しているところはどこだろう？？
U-Boot (aarch64) on Qemu を動作させたい (1)
なんとか、動作させるまで漕ぎ着けたいな。。
現状は以下のような状態です。
qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -kernel u-boot ...(u-boot with rpi_3_defconfig) は全く(?) 動作していないっぽい。- 同じ aarch64 (cortex-a53) の xlinx-zcu102 (
qemu-system-aarch64 -M xlnx-zcu102 -kernel u-boot.elf -nographic -m 2G -drive file=u-boot,id=d,if=none -device ide-drive,drive=d,bus=ide.0) は起動しているので、 qemu / u-boot 自体に問題があるわけではなさそう。
どうすれば raspi3 向け U-Boot を qemu-system-aarch64 で動作させるところまでたどり着けるかは検討ついていませんが、とりあえず手を動かしてみる。
qemu 上でどこまで動作しているのかを知る
qemu-system-aarch64 に gdb をつないでどこまで動作しているか見てみる。
qemu-system-aarch64 \
-S \
-gdb tcp::1234 \
-M raspi2 \
-cpu cortex-a53 \
-kernel u-boot/u-boot \
-nographic \
$ aarch64-linux-gnu-gdb (gdb) target remote localhost:1234 Remote debugging using localhost:1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () (gdb) c Continuing. ^C Thread 1 received signal SIGINT, Interrupt. 0x00000004 in ?? () (gdb) bt #0 0x00000004 in ?? ()
さすがにアドレス 0x4 はまったく動いている気配がしない。
仕事で基板立ち上げにほとんど関わった経験もないから、疑わしいところの検討もつかないな、これは。
qemu がどのように動作しているのか知る
を参考に、 qemu 側から現在の動作状態を調査してみる。 (u-boot のバイトコードがどこまで処理されているかがわかれば、見直すポイントを知る手助けになるかなーという期待から)
qemu コンソールから info qom-tree を確認すると、 CPU が cortex-a15 となっていた。
(qemu) info qom-tree /
...
/machine (raspi2-machine)
/peripheral (container)
/ram[0] (qemu:memory-region)
/soc (bcm2836)
/cpu[0] (cortex-a15-arm-cpu)
コンソールからの -cpu cortex-a53 は無視されている？？
取り急ぎ、 raspi2 / bcm2836 のコードをコピペして raspi3 / bcm2837 を作成して解析を続行する。
Das U-Boot on Qemu (aarch64) を動かしてみる
U-Boot を aarch64 emulated by Qemu な環境で動作させることができるか試してみる。
Qemu のビルド
まずは、 Qemu をビルドしてみる。
### とりあえず、現状最新の v2.10.1 で試してみる。 $ git clone git://git.qemu.org/qemu.git $ cd qemu $ git checkout -b v2.10.1-release refs/tags/v2.10.1 $ git submodule update --init ### arm と aarch64 を有効にする。 ### あと、 raspberry pi にあわせてオーディオは alsa にしておく。 (無指定の場合は oss になるため) $ ./configure --prefix=`pwd`/build --target-list=arm-softmmu,aarch64-softmmu --audio-drv-list=alsa $ make $ make install
U-Boot のビルド
つづいて、 U-Boot のビルドを行う。
U-Boot はターゲット上で動作するため、 aarch64 向けにビルドする必要がある。
手っ取り早く、 Linaro のツールチェインを入れる。
### クロスコンパイラをダウンロードする。 $ curl -L https://releases.linaro.org/components/toolchain/binaries/latest-5/aarch64-linux-gnu/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu.tar.xz | tar xJ ### runtime & sysroot をダウンロードする。 (必要？) $ curl -L https://releases.linaro.org/components/toolchain/binaries/latest-5/aarch64-linux-gnu/runtime-gcc-linaro-5.4.1-2017.05-aarch64-linux-gnu.tar.xz | tar xJ $ curl -L https://releases.linaro.org/components/toolchain/binaries/latest-5/aarch64-linux-gnu/sysroot-glibc-linaro-2.21-2017.05-aarch64-linux-gnu.tar.xz | tar xJ ### クロスコンパイラへのパスを通しておく。 $ export PATH=`pwd`/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin:$PATH
### こちらは、諸事情で v2016.09 を使用する。 $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ git checkout -b v2016.09 refs/tags/v2016.09 ### とりあえず aarch64 を利用している raspberry pi3 で試す。 $ make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- rpi_3_defconfig $ make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-
だめでした
まともに起動はしないにしても、何かしらのログは出てくれるかなーと思ったけど、沈黙しかそこにはありませんでした。。
### raspi2 をベースに cortex-a53 を cpu に指定して動かす。 (ちなみに u-boot.bin も同様に動かなかった。) $ qemu/build/bin/qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -nographic -kernel u-boot/u-boot
32bit 版は起動はする
同じ raspberry pi3 向けの u-boot でも、 32bit 版はログは出た。
### u-boot のビルド。 $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rpi_3_32b_defconfig $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- $ file u-boot u-boot: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), not stripped
### qemu のオプションは同じ。 $ qemu/build/bin/qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -nographic -kernel u-boot/u-boot U-Boot 2016.09-dirty (Oct 05 2017 - 00:58:21 +0900) DRAM: 960 MiB RPI 2 Model B (0xa21041) MMC: ### ここでフリーズ
Qemu で aarch64 な U-Boot を動かすには、何から手を付ければよいものやら。。。
node.js の (泥臭い) デバッグ方法 - ログ編 -
luajit に入門してみた
ことの始まり
仕事で Lua を使うことになりそう (というか、使う方向に持って行こうとしている) ので、 LuaJIT の使い勝手を事前に確認してみた。
C との IF が多くあるっぽいので、個別に binding を実装するととんでもないことになりそうなので、 LuaJIT の FFI を使ってみようと思ってのことである。
環境準備
Ubuntu 14.04 64bit ベースで build-essential のインストールは完了している前提。
### とりあえず git から取得 $ git clone http://luajit.org/git/luajit-2.0.git ### リリース版が良かったので、ブランチを切り替え $ git checkout -b v2.0.5-release refs/tags/v2.0.5 ### コンパイル (本番は arm だけど、動作確認なのでホスト向けに) $ make ### インストール (動作確認なので、システムにはインストールしない) $ make install PREFIX=~/path/to/workspace ### パスを設定 $ export PATH=~/path/to/workspace/bin:$PATH
C ライブラリの準備
/* コンパイルして libsample.so を生成する */ #include <stdio.h> struct sample_data { char name[100]; int type; }; int sample_c_func(struct sample_data* data) { printf("%s:%d name: %s, type: %d\n", __func__, __LINE__, data->name, data->type); return data->type; }
なんてことのない、独自構造体で文字列と数値のやりとりをするだけのものを準備した。
lua コード
ffi = require 'ffi' ffi.cdef[[ struct sample_data { char name[100]; int type; }; int sample_c_func(struct sample_data* data); ]] module = ffi.load('c/libsample.so') data = ffi.new('struct sample_data') data.name = 'aaa' data.type = 12 local ret = module.sample_c_func(data) print(ret)
データは Lua 側で生成して、 C 関数側に渡す形。
実行結果
sample_c_func:10 name: aaa, type: 12 12
以前、 Lua で C ライブラリをやりとりする処理を実装したことがあったけど、その時は自力でスタックに積んだりおろしたりしていたので、 binding の実装だけでかなりのコード数になったけど、、、なんだこれは！？簡単すぎる (うれしい)
実際にはもっと大きなデータのやりとりになるけど、文字列の取り扱いがメインになるっぽいので、文字列のやりとりがこんなにお手軽だと非常に助かるというのが実感。
ターゲット上で LuaJIT が動作することを早く確認しなければ。
