Covers the ESP FAT geometry vs OVMF FatPkg, the limine.conf guest module
drift, and the nine drivers that 055c521 untracked without a build step that
could regenerate them. Also the autocrlf/.gitattributes conclusion and the
check_env.sh hardcoded-path trap.
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).
Shell scripts are run by bash (WSL/Linux/CI). With core.autocrlf=true the
working tree gets CRLF, and bash then fails on the stray CR: the packing step
of build.bat died with
pack_system_image.sh: line 13: $'\r': command not found
pack_system_image.sh: line 14: set: pipefail\r: invalid option name
core.autocrlf is a per-clone setting and is not shared, so the only reliable
fix is a repository-level attribute. Pin *.sh to LF for every checkout.
There were three independent reasons a fresh build produced an image that
OVMF would not boot. All three are fixed here; verified by booting the
resulting ISO/deshab-dev.img under QEMU/OVMF through to FirstInit.
1. ESP rejected by OVMF (CODE/linux/pack_system_image.sh)
The vfat formatter was invoked with an explicit -s 8, forcing 4KiB clusters.
On the 256MiB ESP that yields exactly 65535 clusters - the FAT32 0xFFF5
boundary - and OVMF's FatPkg refuses to mount the volume. Symptom: BdsDxe
logs "failed to load ... Not Found", the ESP shows up as BLKn with no FS in
the UEFI Shell, and the firmware falls through to the internal shell.
The sidecar FAT32 image (make_sata_sidecar.sh) mounts fine because it calls
the formatter without -s. Drop -s here too and let the tool pick geometry.
Do NOT add -f 1: OVMF mounts nfat=1 and nfat=2 alike, it was not the cause.
2. Limine dropped into a panic (CODE/linux/pack_system_image.sh)
limine.conf declares the Linux-compat guest modules. build.sh uncomments
them once Linux has been built, but nothing ever comments them back, so the
file says "load boot():/boot/linux-initrd.img" while only linux-bzImage
exists on disk - Limine panics on the missing module and never reaches the
kernel. Filter the guest module_path lines against SYSTEM/boot/ at pack
time and write the result to the ESP. Both the root /limine.conf and
/limine/limine.conf are written, since Limine 10 prefers the latter. The
tracked source file is left untouched.
3. Nine drivers were never compiled (build.ps1)
Commit 055c521 untracked the .drv binaries on the grounds that they are
regenerable, but build.ps1 only ever invoked Build-DkmDriver for 8 of the
17 drivers listed in manifest.json. timer/acpi/pci/ahci/bootfs/vfs/fat32/
devfs/ps2kbd had sources under CODE/DKM/ and no build step, so the image
shipped without them and Limine failed on the first one. Add the missing
compile steps, grouped by load stage. All 17 now match manifest.json.
Also in this commit (environment/tooling hygiene):
- check_env.sh: stop hardcoding /mnt/d/Code/Deshab (the original author's
machine); derive the repo root from the script's own location. It was
reporting a bogus "wsl_mount" failure on every other checkout and sending
people to install packages that were already present. Also check and
advertise the image-packing tools (dosfstools/e2fsprogs/fdisk/rsync), which
were missing from the dependency list even though pack_system_image.sh
hard-requires them.
- build_initrd.sh: same hardcoded-path fix.
- README.md: relative path instead of the stale absolute one.
Verified: ./build.bat -Variant dev under WSL2/Ubuntu, then QEMU/OVMF boots
through BdsDxe -> Limine -> UTSM -> DKM (17/17) -> DSK -> FirstInit, with the
PS/2 mouse initialising cleanly.
stale-check compared LastWriteTime against a stamp file that does not
exist yet on the first build, so Get-Item threw PathNotFound and aborted
the build before make DSK.
- build.ps1: guard the texSrc/texStamp mtime comparison with
Test-Path $TexStamp; $needTex is already $true when the stamp is
absent, so the comparison is only meaningful when both files exist
- .gitignore: ignore IDEA.md local scratch note
Verified: .\build.bat now reaches gen_textures.py and emits
back.rgba / startMenuLogo.rgba / bootlogo.rgba into
SYSTEM/system/deshab64/desktop/textures/.
boonxiong2