# 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)
1. SquashFS carve: dd from 0x18c7854 bis bytes_used (Superblock auslesen)
2. unsquashfs -d /work/rootfs
3. FIT (kernel@1 + fdt@w2044ax) carven -> /work/kernel.img, /work/w2044ax.dtb
4. 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
1. linux-image-*-arm64 .deb von deb.debian.org laden, dpkg-deb -x (arch-agnostisch)
2. 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)
3. mkfs.ext4 -d /work/rootfs /work/rootfs.ext4  (ohne Root moeglich)
4. 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/<tool>
- 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