nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schunix-iso-boot.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh 
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
2026-08-09 14:27:22 +02:00

2.6 KiB
Raw Blame History

name description metadata
schunix-iso-boot `make iso` builds a bootable CD; it needs El Torito no-emulation plus ATAPI because the loader never uses INT 13h
node_type type originSessionId modified
memory project a665e14b-86bd-4b41-a228-51377f3e9225 2026-08-04T17:28:16.714Z

make iso produces a bootable schunix.iso (added 2026-08-04). Always a RAMROOT build — a disc that needed a second disk for its root would not be an install medium, and read-only media cannot host a writable root anyway.

Why it is built the way it is. Schunix's loader never calls INT 13h: it drives the IDE registers directly, and stage2 has already switched to protected mode before it reads the kernel. That rules out both El Torito emulation modes (hard-disk emulation exists only through the BIOS) and floppy emulation (2.88 MB cap). So:

  • boot/cdboot.S — a separate stage 1 for optical media. tools/mkiso.sh passes -boot-load-size 25, so the BIOS loads cdboot and all 24 sectors of stage2 before anything of ours runs, putting stage2 at 0x7E00 exactly where bootasm.S would have. cdboot only records the medium and jumps.
  • The medium flag is one byte past the verbose flag, at VBE_INFO_ADDR + 0x101. bootasm.S must clear it or a warm reboot from a disc sends a hard-disk boot looking for an optical drive.
  • stage2main.c gained an ATAPI reader (PACKET + SCSI READ(12), 2048-byte blocks with a one-block cache) and finds where it was loaded from by reading the El Torito boot catalog: LBA 17, pointer at offset 0x47, then Load RBA at catalog offset 40.
  • Do not pass -boot-info-table to xorriso — it patches 56 bytes over offset 8 of the boot image, which is the middle of cdboot's code. That is why the boot catalog is parsed instead.

The trap that cost the most time here: ATAPI's 0x14/0xEB signature is only valid until something issues a command, and the BIOS has just finished reading the disc to load us — so on a CD boot the signature is always stale. atapi_reset() (SRST via the control port at io + 0x206) is what makes the probe work.

Two unbounded waits were hiding behind that, both of which hung with no message on a machine with no ATA disk: waitdisk() in stage2main.c and idewait() in kernel/dev/ide.c. Both are bounded now, ideinit() tolerates an empty channel, and anything that probes a disk must call ide_disk_present() first — iderw() rightly panics on an absent drive.

Check it with pwsh -File tools/bootcheck.ps1 -Iso -Fb, which boots with no hard disk attached at all. See schunix-verify-by-driving-shell.