Multi-TU drivers produce PLT32 for cross-object calls (lld keeps a
relocation for potentially-interposable global symbols). ath9k.drv
(ath9k.o + wpa2_crypto.o) has 22 such relocations, which tripped
"DKM-E37 UNSUPPORTED RELOCATION" at boot.
PLT32 has the same semantics as PC32 in a static relocatable
(patch = S + A - P), and is a 4-byte write. Added the constant, the
patch computation, and switched the write-width branch to
"not R_X86_64_64 -> u32" so all 4-byte types are handled uniformly.
Verified: all 28 .drv files now use only
{R_X86_64_32S, R_X86_64_64, R_X86_64_PC32, R_X86_64_PLT32}.
- taskbar.c: wifi popup card anchored above tray net icon; net api slots read
via kernel_api+0x48 hard offsets (UTSM net.h layout, connect@0x48)
- flow: icon click -> scan_start -> per-frame scan_count/result pull -> SSID
list (security tag + rssi bars) -> open net direct connect / secured net
password textbox (scan set 1 -> ascii, enter=connect) -> net_api.connect
- no wireless device in QEMU: graceful "not detected" status, no panic (by
design: wireless dev absence is attest-exempt, not a stub)
- shell.c: handle_key routes to wifi_key when card open (modal)
- sdk kernel_api.h: mirror UTSM dkm_net_api layout (append connect/disconnect
before device_stats, fixes slot offset mismatch)
- QEMU verified: card opens, renders, graceful no-device path (serial
"[wifi] no wireless device")
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"
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.
- 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>
Add the current OS source tree, build scripts, system image layout, and development notes covering DMA page allocation, e1000 bring-up, net API dispatch, and DHCP work in progress.
Linehu