Buildroot编译的树莓派3B Linux系统无法在QEMU启动求助

Hey there, let's break down how to troubleshoot this QEMU black screen/100% CPU issue with your Buildroot-built system. I've dealt with similar ARM emulation headaches before, so here's what I'd check first:

1. Kernel & QEMU Machine Type Mismatch #

You're using -M versatilepb, but let's verify the basics even for the versatile-configured system:

• Double-check your Buildroot kernel config has CONFIG_MACH_VERSATILE_PB=y enabled — this ensures the kernel targets the versatilepb hardware QEMU emulates.
• Confirm device tree support is turned on: CONFIG_OF=y and CONFIG_OF_FLATTREE=y are mandatory for most ARM systems. Your lack of device tree errors (unlike Raspbian) might mean the kernel isn't even trying to load a DTB, which is a red flag.
• Don't forget the -dtb parameter in your QEMU command! Even if you missed it for Raspbian and got errors, your Buildroot system needs the matching versatile-pb.dtb file generated during compilation.

2. Root Filesystem Mounting Issues #

Your append line uses root=/dev/mmcblk0p2, but the versatilepb emulates an IDE disk, not an MMC card. This means the root partition is likely /dev/sda2 instead. If the kernel can't find the root filesystem, it'll hang silently with 100% CPU.

• Test changing the append parameter to: root=/dev/sda2 panic=1 rootfstype=ext4 rw
• Verify your sdcard.img has a valid ext4 partition at p2, and that the kernel has CONFIG_EXT4_FS=y enabled.

3. Serial Console Output Configuration #

Right now, you might not be seeing any logs because the kernel isn't sending output to the serial port you've mapped to stdio.

• Ensure kernel config has CONFIG_CONSOLE_SERIAL=y and CONFIG_SERIAL_AMBA_PL011=y (the UART used by versatilepb).
• Add console=ttyAMA0,115200 to your append parameters to force kernel output to the serial console.

4. Real-Time (RT) Kernel Compatibility #

Your original system uses a 4.19-rt kernel, and RT patches can introduce compatibility quirks with QEMU's virtualized hardware.

• First, test with a vanilla 4.19 kernel (no RT patches) to rule out RT-specific issues. If it works, you'll know the problem lies with RT patch interactions.

1. Enable Early Kernel Debug Logs #

Turn on low-level debugging in the kernel config to catch issues before the main console initializes:

• Enable CONFIG_DEBUG_LL=y
• For versatilepb, select CONFIG_DEBUG_LL_UART_PL011=y and set CONFIG_DEBUG_UART_PHYS=0x101f1000 (the physical address of the versatilepb UART)
  This will print early boot messages to the serial port, even if the kernel hangs before reaching init.

2. Use QEMU Debug Flags #

Add these parameters to your QEMU command to capture more context:

• -d guest_errors: Prints errors from the guest system
• -D qemu.log: Writes QEMU's internal logs to a file for later analysis
• -s -S: Starts QEMU paused, so you can attach a GDB debugger (arm-none-eabi-gdb vmlinux, then target remote :1234) to step through the kernel boot process and find exactly where it hangs.

3. Validate Root Filesystem Integrity #

Mount your sdcard.img locally to check for issues:

# Calculate the offset for partition 2 (replace XXX with the start sector from fdisk -l sdcard.img)
sudo mount -o loop,offset=$((XXX*512)) sdcard.img /mnt

• Check that /sbin/init exists and has executable permissions
• For BusyBox-based systems (Buildroot's default), verify /etc/inittab has valid entries, like:

  ::sysinit:/etc/init.d/rcS
  ::respawn:/sbin/getty -L ttyAMA0 115200 vt100
  ::shutdown:/etc/init.d/rcK
  

4. Simplify the QEMU Command #

Start with a minimal, validated command to eliminate variables:

sudo qemu-system-arm -kernel zImage -dtb versatile-pb.dtb -drive format=raw,file=sdcard.img -cpu arm1176 -m 256 -M versatilepb -append "root=/dev/sda2 console=ttyAMA0,115200 panic=1 rootfstype=ext4 rw" -serial stdio

内容的提问来源于stack exchange，提问作者Daniel Schulze