memory: UEFI reaches userspace, and the ISO grows a hierarchy

Records the four bugs between "boots to cpu0: starting" and "boots to an
interactive shell", the new ioremap rule for device registers, and what
the disc now contains -- including that it is still not a live CD, and
what that would take.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/memory/schunix-iso-boot.md

@@ -5,7 +5,7 @@ metadata:
   node_type: memory
   type: project
   originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
-  modified: 2026-08-04T17:28:16.714Z
+  modified: 2026-08-09T20:03:23.603Z
 ---
 
 **`make iso` produces a bootable `schunix.iso`** (added 2026-08-04). Always a
@@ -45,5 +45,45 @@ message on a machine with no ATA disk: `waitdisk()` in stage2main.c and
 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]].
+Check it with `pwsh -File tools/windows/bootcheck.ps1 -Iso -Fb`, which boots
+with no hard disk attached at all. See [[schunix-verify-by-driving-shell]].
+
+## 2026-08-09: two boot entries, a real hierarchy, and a repair
+
+The disc used to hold exactly one file (`boot/schos.bin`) with 8.3 uppercase
+names and a single El Torito entry. Now:
+
+| | |
+|---|---|
+| `/boot/schos.bin` | BIOS entry, unchanged |
+| `/boot/efiboot.img` | UEFI entry: FAT image built with mtools |
+| `/EFI/BOOT/BOOTX64.EFI` | the loader, also a visible file |
+| `/bin /etc /usr ...` | the staged sysroot, as an ordinary tree |
+
+- **Rock Ridge + Joliet** for real names, permissions and symlinks. **Keep
+  `-cache-inodes`**: the sysroot is a toybox multicall binary with ~240 hard
+  links to it, and without inode caching each link becomes its own copy —
+  28 MB becomes ~200 MB.
+- **`-isohybrid-gpt-basdat`** so `dd` to a stick boots under UEFI. UEFI *only*,
+  and not an oversight: BIOS isohybrid needs syslinux's `isohdpfx.bin`, and even
+  with it this loader reads the kernel over ATAPI, which a stick presented as a
+  hard disk cannot serve. `usbstick.img` is the BIOS-from-USB answer.
+- **The FAT image carries the kernel too.** `BOOTX64.EFI` opens `\schos\kernel`
+  on the volume it was loaded from, which for a UEFI boot is that FAT image and
+  not the ISO 9660 tree. Without it the loader halts with `EFI_NOT_FOUND`. The
+  kernel is therefore on the disc twice; the alternative is teaching the loader
+  to search other volumes, which is a feature, not a packaging tweak.
+
+**`make iso` and `make ramroot` had been broken and nobody noticed.**
+`build/fs-ram.img` was still built by the v1 `mkfs` while the kernel accepts
+only SchFS as root, so the ramdisk was a format it could not mount:
+`schfs root: no SchFS volume on the root device`, in forkret. It is an mkschfs
+image now, which needed **`--exclude` added to mkschfs** — dropping the exclude
+list was not an option, because the ramdisk is linked into the kernel binary and
+what goes into it is a licensing question ([[schunix-ramdisk-root-sizing]]).
+`RAMDISK_NINODES` is gone: SchFS has no preallocated inode table.
+
+**Not a live CD.** The disc boots from the ramdisk embedded in the kernel, not
+from itself. Mounting it would need an ATAPI block driver (`kernel/dev/ide.c`
+speaks only ATA — 0x20/0x30/0xC4, no PACKET) plus an ISO 9660 filesystem behind
+`struct fs_ops`. Only the *bootloader* does ATAPI, in real mode.