Plan: Bintec W20XXax-Firmware in QEMU booten (in Docker)

Datum: 2026-09-16 Status: Genehmigt

Ziel

Firmware-Image WiFi6_System_Software_v3.6.1.2.img in QEMU booten. Alles in Docker (Host x86_64, Docker 29.7.2, TCG-Emulation ohne KVM), Arbeitsdaten vollständig im Projektordner qemu-fw-docker/.

Fakten (bereits verifiziert)

Image: bintec_W2044ax_W2022ax/current_software_and_open_source/v3.6.1.2/WiFi6_System_Software_v3.6.1.2.img (identisch verfügbar als v3.6.1.1 und im OSDx-Dist-TGZ als full_kaio_v3.6.1.2.img)
Plattform "kaio" = Qualcomm IPQ60xx, QSDK 11.4, ARM64 (Cortex-A53), U-Boot 11.4-1-2016.01
Image ist Full-Flash-Dump: u-boot.sbl, SBL1 (Qcom-Attest), FIT-Image (kernel@1 + fdt@w2044ax), SquashFS-RootFS bei Offset 0x18c7854 (xz)
QEMU hat KEIN IPQ60xx-Maschinenmodell -> Original-Image direkt bootet nicht. Weg: RootFS extrahieren + generischen ARM64-Kernel in -M virt booten.

Artefakte auf Host (nur in bintec-ap/qemu-fw-docker/)

Dockerfile : debian:bookworm-slim + squashfs-tools, binwalk, qemu-system-arm, python3, e2fsprogs, xz-utils, file, wget, cpio
extract.sh : carve FIT + SquashFS (Offset 0x18c7854), unsquashfs -> work/rootfs/, Inventur (/etc/os-release, libc, init, Webserver)
boot-native.sh : Versuch 1 Original-Kernel
boot-generic.sh : Versuch 2 generischer Kernel
logs/ : Serial-Outputs, Inventur-Report

Phase 1 - Container

docker build -t bintec-fw qemu-fw-docker/

Volume: ./qemu-fw-docker/work als /work im Container.

Phase 2 - Extraktion (im Container, liest .img nur read-only)

SquashFS carve: dd from 0x18c7854 bis bytes_used (Superblock auslesen)
unsquashfs -d /work/rootfs
FIT (kernel@1 + fdt@w2044ax) carven -> /work/kernel.img, /work/w2044ax.dtb
Inventur: os-release, libc (musl/glibc/uclibc via file), /etc/init*, Webserver

Phase 3 - Versuch 1: Original-QSDK-Kernel (Debugging-/Doku-Wert)

qemu-system-aarch64 -M virt -cpu cortex-a53 -m 512 \
  -kernel /work/kernel.img -dtb /work/w2044ax.dtb -nographic \
  -append "console=ttyAMA0"

Erwartung: frueher Crash/Stillstand (RPM/PMIC/SMEM/Clocks fehlen) -> Log dokumentieren.

Phase 4 - Versuch 2 (Hauptweg): generischer Kernel + extrahiertes RootFS

linux-image-*-arm64 .deb von deb.debian.org laden, dpkg-deb -x (arch-agnostisch)
Config-Check: CONFIG_EXT4_FS / CONFIG_VIRTIO_BLK / CONFIG_SQUASHFS
- alle =y -> direkt booten
- teilweise =m -> Mini-Initramfs (arm64 static busybox + fehlende Module + init)
- unpraktikabel -> eigener Kernel-Build im Container (cross: linux-source, virt_defconfig + EXT4/SQUASHFS/VIRTIO/PL011 =y, ~20-40 min)
mkfs.ext4 -d /work/rootfs /work/rootfs.ext4 (ohne Root moeglich)
qemu-system-aarch64 -M virt -cpu cortex-a53 -m 512
-kernel /work/vmlinuz
-drive if=virtio,format=raw,file=/work/rootfs.ext4
-netdev user,id=n0 -device virtio-net-pci,netdev=n0
-nographic -append "root=/dev/vda rw console=ttyAMA0" Realistisch: Serial-Console, Init/Busybox/Shell kommt hoch. WiFi/Switch-Module laden nicht (vermagic-Mismatch, AP-Hardware fehlt). OSDx-Software beobachtbar.

Phase 5 - Fallbacks (falls Init scheitert)

Usermode im Container: qemu-aarch64 -L /work/rootfs /work/rootfs/usr/bin/
RootFS-Binaries einzeln starten; ggf. fehlende /dev-Entries nachlegen

Erfolgskriterien

Versuch 2 erreicht Serial-Console mit Shell/Init-Log
Logs + Inventur liegen in qemu-fw-docker/logs/
Host unveraendert ausser qemu-fw-docker/

Risiken

TCG langsam: Boot 2-5 min
Debian-Kernel evtl. init-Probleme mit QSDK-RootFS (openrc/procd-Varianten)
Falls RootFS SquashFS-xz mit komischen Flags hat: binwalk-Loopmount nicht noetig, unsquashfs deckt xz ab

3.7 KiB Raw Permalink Blame History