JetBrains only ships a partial .idea/.gitignore, so Deshab-OS.iml and
inspectionProfiles/ kept showing up as untracked. Local QEMU serial dumps
(run_qemu.bat > deshab_log.log) are build-time artifacts of the same kind.
Machine-local files must not land in a shared repository - they carry no
information for anyone else and create noise on every checkout.
Four independent blockers sat between "the image boots UTSM" and "the desktop
comes up". Each one wedged the boot on its own; all four are fixed here and the
tree now reaches "[desktop] desktop ready" under QEMU/OVMF
(evidence: .build_tmp/d2.log).
1. FirstInit made networking a hard gate (CODE/firstInit/main.c)
The setup wizard always showed the network page, and on a machine with no
wireless device the only exit was Save - pressing Connect raised NET-E01.
Networking is not a precondition for entering the system, so a wizard that
cannot be completed without it is a plain design defect.
- No wireless device detected -> skip the network page entirely (the
g_no_wireless_device flag already existed but was only logged).
- With a device present, add a Skip button (draw + mouse hit-box + keyboard
Enter), mirroring "I don't have internet" on Windows.
- Connect keeps its zero-fallback NET-E01 panic: the unimplemented path is
still honest, it just no longer holds the user hostage.
2. ESP cluster size left no room in the root directory
(CODE/linux/pack_system_image.sh)
With the cluster size left to mkfs it chose 1 sector, i.e. 16 directory
entries per cluster. The ESP root ends up holding exactly 16 entries
(DESHABBOOT/EFI/LIMINE/BOOT/DRIVER/SYSTEM/USER/NVVARS plus one long-name
entry each), and the root chain is a single cluster - so on first boot the
DSK could never write USER.CONF.
Pin -s 4 (2KiB, 64 entries): it clears the FAT32 65525 lower bound and the
0xFFF5 boundary that -s 8 lands on at this 256MiB size, and leaves 48 free
entries. The alternatives were measured, not guessed (see the comment).
3. DSK could not grow the root directory (CODE/dsk/main.c)
fat32_write_root_file returned -4 "no free dir entry" whenever the scan of
the root chain came up empty. A FAT filesystem is supposed to extend the
directory chain, so allocate a cluster, link it at the current tail, write
the entry there and commit the FAT. Fixing only (2) would have papered over
this: any real disk whose root fills up would still fail the same way.
4. Nothing generated the CJK bitmap font packs (build.ps1)
The desktop loads system/font/simhei_16.dbf and panics DESK-E04 FONT PACK
MISSING without it. The .dbf files are generated from simhei.ttf by
CODE/font/mkfont.py and are gitignored, but no build step ever invoked it -
same class of bug as the previously untracked .drv binaries. Generate
simhei_16.dbf / simhei_24.dbf in build.ps1 (with the existing WSL python3
fallback for Pillow), rebuilding only when the TTF is newer than the pack.
docs/STATUS.md updated to match: FirstInit wizard and the D3 named API export
table move to done, and the FAT32 / ESP cluster size / CJK font pack entries
are added or corrected. D3 was already fully implemented (table, lookup,
selftest with positive and negative cases, TST-E21..E24 instrumentation) -
only the status row was stale.
Verified boot chain (QEMU/OVMF, dev variant):
BdsDxe -> Limine -> UTSM -> DKM 17/17 -> DSK -> FirstInit (network page
skipped) -> USER.CONF written -> login (password accepted) -> desktop:
"[zhfont] dbf loaded (16px ok)" ... "[desktop] desktop ready"
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/.
- NEW core/sealed.c: utsm_sealed_early_init() runs right after utsm_init:
empty .sealed section -> UTSM-E01 panic; no root key -> UTSM-E02;
establishes BLAKE2b(root_key) MAC over [__sealed_start,__sealed_end).
- utsm_sealed_verify(): MAC mismatch -> UTSM-E03; verify-before-init ->
UTSM-E04. Wired into utsm_selftest (U3+ step).
- .sealed region now non-empty by construction: sealed brand record
"DESHAB-SEALED-MEMORY-V1-DEAICUP" lives in section(".sealed").
- Before this commit nothing ever referenced __sealed_start/__sealed_end:
the sealed section was never registered, MACed or verified.
- QEMU verify: [SEAL] region=0x20 bytes, MAC established, selftest OK,
boot reaches wizard, zero spurious panics.
[STUB] P0/UTSM/core/sealed.c | 剩余STUB命中=101（违规=0） | “封缄即落款，空区即自爆” | 已提交=<this>
- desktop boot screen: typewriter effect removed, whole screen drawn in one pass
- login: ohMyLogo (DEAICUP lotus, 288px embedded) intro screen before password card
- strict error policy instrumentation (zero degradation): login LOGIN-E01..E05 (integrity/badctx/noconf/nouser/nohash) and desktop DSK-E01 now full-screen fatal with symbol + halt instead of silent skip
- root-cause fixed: missing .build_tmp/mkfat32.ps1 silently left SATA sidecar stale (login.elf 'not found' degradation) - replaced with CODE/linux/make_sata_sidecar.sh (auto adaptive FAT32 rebuild each build)
- recreated lost CODE/login/patch_login_hash.ps1 (.text SHA256 -> .hashseg)
- dev config now full flow: show_logo=1, wizard+login enabled, dev shell off
- 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
Self-test and Linux guest were failing VM-instruction error 7. Share a KVM-style control adjust, request PIN_VIRTUAL_NMIS, and stop intercepting guest #PF. Land isolated XNU/Python/KDE scaffolding off the boot path.
Co-authored-by: Cursor <cursoragent@cursor.com>
Linehu