☰

qemu arm64 仮想マシンでの u-boot テスト

tag-icon • tag-icon qemu boot-loader u-boot
qemu arm64 仮想マシンでの u-boot テスト

qemu arm64仮想マシンでu-bootを実行しようとしています。 （qemu 6.2.0、u-boot v2022.07）だからqemu_arm64_defconfigを使ってu-bootをコンパイルし、u-boot（u-boot-splではない）を構築しました。私は次のinitrdを実行しました BeagleBone blackのinitramfsを持つU-Boot「無効なRamdiskイメージフォーマット」。これは initrd.img の生成に使用したコマンドです。

mkimage -A arm64 -T ramdisk -d ../../../busybox-1.32.1/initramfs.cpio.gz initrd.img

include/configs/qemu-arm.hで見ることができます。

#define CONFIG_EXTRA_ENV_SETTINGS \
    "fdt_high=0xffffffff\0" \
    "initrd_high=0xffffffff\0" \
    "fdt_addr=0x40000000\0" \
    "scriptaddr=0x40200000\0" \
    "pxefile_addr_r=0x40300000\0" \
    "kernel_addr_r=0x40400000\0" \
    "ramdisk_addr_r=0x44000000\0" \
    BOOTENV

したがって、上記の環境変数を参照してこれがqemuを実行するコマンドです。 （qemuは最初のDRAM位置0x40000000でdtbを生成します）。

   qemu-system-aarch64 -machine virt,gic-version=max,secure=on,virtualization=true -cpu max u-boot -m 2G -nographic -bios u-boot.bin -device loader,file=linux-5.15.68/arch/arm64/boot/Image,addr=0x40400000 -device loader,file=initrd.img,addr=0x44000000

u-bootが実行され、コマンドプロンプトが表示されます。だから私は走った。

=> booti 0x40400000 0x44000000 0x40000000  
## Loading init Ramdisk from Legacy Image at 44000000 ...
   Image Name:   
   Created:      2023-05-30   2:50:14 UTC
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6671800 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK  
## Flattened Device Tree blob at 40000000
   Booting using the fdt blob at 0x40000000
   Loading Ramdisk to be771000, end bedcddb8 ... OK
   Loading Device Tree to 00000000be66e000, end 00000000be770fff ... OK

Starting kernel ...

そこにはプロセスがないことを示しています。私は何が間違っていましたか？

u-bootが実行されているとき（bootiコマンドを発行する前）、プロンプトで上記のbootiコマンドを発行する前にこの出力を見ました。

U-Boot 2022.07 (May 29 2023 - 16:05:33 +0900)

DRAM:  2 GiB
Core:  45 devices, 12 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from Flash... *** Warning - bad CRC, using default environment

In:    pl011@9000000
Out:   pl011@9000000
Err:   pl011@9000000
Net:   eth0: virtio-net#32
Hit any key to stop autoboot:  0 
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...

Device 0: unknown device

Device 0: 1af4 VirtIO Block Device
            Type: Hard Disk
            Capacity: 6.8 MB = 0.0 GB (14024 x 512)
... is now current device
** No partition table - virtio 0 **
Couldn't find partition virtio 0:1

Device 0: unknown device
starting USB...
No working controllers found
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using virtio-net#32 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x40200000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (0 ms)
Using virtio-net#32 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x40400000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...

u-bootが0x40200000からuboot.scr.uimgファイルをロードしようとしているようです。 uboot.scr.uimg とは何か、その修復方法は？

答え1

これは長い間遅れた答えであり、後で（私の作業ノートで）どのように解決したかをここに書いています。
後でLinuxコードでSVEの初期化中に停止したことがわかりました。 qemu VMはSVEサポートを提供していないようで、CONFIG_ARM64_SVEをオフにしてパスしました。その後、RAMサイズを4Gに増やし、「未使用のカーネルメモリ解放：1088K」を続けました。次に、OPTIONAL_KERNEL_RWXのデフォルト値をy（arch / Kconfigで）に変更し、STRICT_KERNEL_RWXをnに設定しました。 （なぜこれを行うべきかはわかりませんが、そうでなければ停止します）。シェルプロンプトは引き続き実行されますが、シェルはキーボード入力に応答しません。最後に、u-boot設定にCONFIG_GICV3を追加しました（割り込みが機能していなかったため、以前はタイマーとキーボードの割り込みが機能しませんでした）、ついにシェルが正しく動作しました。これが将来的に誰かに役立つことを願っています。

関連情報