STATUS.md/TASKBOARD.md under-reported several subsystems that are in fact
implemented. Corrected against the code and against a clean QEMU boot log
(.build_tmp/qemu_final.log, this branch).
- 页表映射接口 was ⬜ "mmio 通用映射待做". It exists and is in use:
kernel_api.mm_map_mmio / mm_unmap_mmio (PCD|PWT independent window), called
by apic, ehci, xhci and nvme, including BARs above 4G. -> ✅
- NVMe was 🔶 "PCI discovery only, BAR0>4G 待映射". CODE/DKM/nvme/nvme.c is
1641 lines: admin SQ/CQ with phase bit, IDENTIFY, IO queue (qid=1), read/
write/flush, cross-page PRP lists, MSI and MSI-X (vector allocator, IDT pool
0x40-0xDF), block provider registration, NVME-E01..E03 zero-fallback
instrumentation. -> ✅
- virtio_net was 🔶 "PCI/capability 枚举, 无 virtqueue". It has a legacy
split-ring virtqueue (desc/avail/used), vq_setup, 32x2048B RX buffers, TX/RX
rings and a DHCP DISCOVER->OFFER selftest. -> ✅
- ELF64 .drv loading said 14/14. build.ps1 now compiles all 17 drivers listed
in manifest.json (fixed on this branch; nine were never built since 055c521
untracked the .drv binaries). -> 17/17
- FAT32 (DKM side) stays 🔶 but the boundary was wrong. It is read-only
BPB/FAT/dirent parsing plus a root-directory walk, with no filesystem API
layer (no open/read/stat) - not "子目录路径待完善". The large-disk read/write
path lives in the DSK-side FAT32 implementation.
- TASKBOARD 遗留工程债: vector allocator/MSI-X, NVMe high BAR MMIO and
virtio-net virtqueue RX/TX are done. The remaining FAT32 item is reworded to
what is actually missing (the FS API layer).
Evidence for the driver/NVMe/virtio rows is the boot log on this branch:
14x "[<drv>] driver ready", and with no NVMe controller / virtio-net device
attached the drivers correctly log a warning and still reach "driver ready"
(designed fallback, both listed in the CLAUDE.md whitelist).
- test/gen_chacha_kat.py emits KAT from RFC 8439 section 2.4.2 mapped to the impl's 64+64 counter/nonce layout; expected bytes cross-checked against pycryptodome (independent impl) and the official vector: 10f1e7e4d13b5915... byte-exact
- verdict: the 'intermittent chacha20 KAT FAIL' referenced in FUCK comments was a phantom — that test was never merged into this tree; the implementation itself matches RFC byte-for-byte
- selftest now runs KAT + page-MAC determinism checks at selftest=2; full SELFTEST PASS in QEMU (.build_tmp/qemu_serial_u5kat.log)
- drr_apply_config(pool_kb, log_size) before drr_init; pool_limit clamped to compile-time 64KB static pool (min sub-buffer layout enforced, defaults kept on bad values); recovery log size clamped to remaining pool
- verified in QEMU: pool_kb=32 -> pool_limit=0x8000, log_capacity=0x80, boot continues (.build_tmp/qemu_serial_r3b.log)
- panic screen now draws embedded ohMyLogo.png (384px RGBA, gen_panic_logo.py); background color sampled from image corners so screen bg matches logo bg
- F2: include/utsm/fbcon.h unified framebuffer console (pixel/blend/fill/rgba-image/text with FBCON_HAVE_FONT opt-in); panic.c migrated onto it
- build.ps1 regenerates panic_logo_data.inc when ohMyLogo.png changes
boonxiong2