GOP instead of VBE, and the same reasoning. There are no mode numbers
worth hardcoding here: the firmware publishes however many modes the
hardware can do and which index means what varies by machine, so the menu
is built by walking them. Press R within four seconds for a list, then
either a mode number or Enter to type a size. 800x600 stays the floor.
Fixes a header bug this is the first code to notice. The spec's order in
EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE is MaxMode then Mode; efi.h had them
swapped. Info, SizeOfInfo and FrameBufferBase sit at the same offsets
either way because both fields are UINT32, so the framebuffer worked
perfectly and nothing was wrong until something asked how many modes
existed -- and was told the current mode number instead. Zero, on a
machine reporting thirty.
QueryMode and SetMode were void* padding and now have real prototypes;
ConIn likewise, so the loader can read a key. Under OVMF the console
includes the serial line, which is where `make qemu-uefi` puts it and
where the person actually is -- the same mistake the BIOS menu made first
time round.
Verified over serial against OVMF: 30 modes enumerated; picking listed
mode 14 gives 1280x1024; typing 1024x768 gives 1024x768; no key keeps the
firmware's mode and boots. All reach schinit. bootcheck 108 [ok].
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Option 4 asks for a width and a height and then goes looking for a mode
that matches, instead of picking from three hardcoded numbers.
AX=4F00 returns a controller info block whose VideoModePtr is a far
pointer to a 0xFFFF-terminated list of mode numbers; each is asked what it
actually is with AX=4F01, and the first that reports the requested size at
32bpp wins. That is the fix for the table, not an addition to it -- the
table was wrong the first time it was written (0x146 was "1600x1200" and
is 320x200x8 here), and a table can only ever describe machines somebody
happened to test.
800x600 stays the floor: the console, the splash and Schcom all assume at
least that, and smaller would be a different set of assumptions rather
than a smaller number. Below it, or a size the BIOS cannot do, says so and
keeps 800x600 rather than failing to boot.
Scratch buffers at 0x31000 and 0x31200, clear of the mode info block at
0x30000 and everything else in that page -- the flags at +0x100, the e820
map at +0x208 and the RSDP slot at +0x600.
Verified over serial: 1280x800 comes up at 1280x800, which is in no table
anywhere and is the point; 640x480 is refused as below the minimum;
3000x2000 reports no such mode. Presets 1-3 and the no-key timeout are
unchanged. bootcheck 108 [ok]. stage2 is 20932 of 24576 bytes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The menu shipped working only for someone driving the emulated keyboard,
which is nobody. `make qemu` runs -serial mon:stdio, so the terminal the
developer is sitting in front of is the serial line -- and the menu read
INT 16h, which is the PS/2 keyboard. Keys went nowhere.
The prompt was invisible for a second reason: BIOS teletype writes to the
VGA text screen, and `make qemu` attaches virtio-gpu alongside stdvga and
shows that one, so the text landed on a display nobody was looking at.
So print16 now writes to both the screen and COM1, and the menu accepts a
key from either source. The transmitter wait is bounded, because a machine
with no serial port reads 0xFF from the status register forever and would
otherwise hang the loader on exactly the hardware that cannot say why.
Also: four seconds rather than two, which is not long when the prompt has
to be read first; the chosen digit is echoed, because a serial line has no
local echo and the menu otherwise looks like it ignored the key; and the
timeout says "keeping 800x600" instead of silently moving on.
Verified three ways: typing r then 2 over serial gives 1024x768, sendkey r
then 3 on the keyboard gives 1280x1024, and no key at all prints the
timeout and boots 800x600. bootcheck 108 [ok].
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The VBE mode was the literal 0x143 in stage2.S, so 800x600 was the only
resolution the system could ever have. Real mode is the only place this
can be chosen: setting a mode is INT 10h, stage2main.c already runs in
protected mode, and the kernel has no modeset path -- so whatever is
picked here is what the framebuffer, the console and Schcom all get.
Press R at the prompt within two seconds for 800x600, 1024x768 or
1280x1024. It boots on its own otherwise: a loader that waits for a
keypress is a machine that does not come back up after a power cut.
The depth is checked before the mode is set, and that is not belt and
braces. 0x146 was in the table as 1600x1200x32 and this VBE returns
320x200x8 for it -- a mode the BIOS accepts, so an error return never
happens. It boots and then everything above renders garbage, because the
console, the fbdev ioctls and the compositor all assume 32bpp. Only
numbers verified to come back as the advertised size at 32bpp are listed
now, and anything else falls back to 800x600.
Verified by driving the monitor's sendkey: 1, 2 and 3 come up at
800x600, 1024x768 and 1280x1024 respectively, all reaching schinit, and
no key at all still gives 800x600. bootcheck 108 [ok], schcom-test
passes.
Typing an arbitrary size is the obvious next step and deliberately not
guessed at here: it wants enumerating the BIOS's own mode list
(INT 10h AX=4F00) and matching on width and height, which would replace
the magic numbers rather than add more of them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
find_rsdp() scanned the EBDA and 0xE0000-0x100000. That is a BIOS
convention, and UEFI firmware is under no obligation to leave a copy
there -- OVMF does not. So the kernel found no RSDP, no MADT and no
IOAPIC, and nothing routed IRQ 4. Serial output is polled, so the machine
booted all the way to a shell prompt and then ignored every key, which
reads as a broken console rather than a missing table.
The UEFI loader reads the RSDP out of the EFI configuration table,
preferring ACPI 2.0 for its XSDT, and leaves it at SCHBOOT_RSDP_ADDR --
the same low-memory hand-off block the e820 map already uses, now
described in include/schboot.h so the two sides cannot disagree.
The kernel validates it rather than trusting it: the BIOS path never
writes that slot, so there it holds whatever was in memory, and following
a wild pointer faults before there is anything to report the fault with.
Signature and checksum do that. It deliberately does not require 16-byte
alignment -- that rule is about searching the BIOS area, and OVMF's RSDP
sits at 0x3f77e014, so demanding it threw away the one address this code
exists to use.
UEFI now reports "acpi: 1 cpu, lapic at ..., ioapic id 0" and the ISO
boots to an interactive shell: uname, ls /bin (241), writing and reading
a file, ps, /proc/schfs -- all driven over serial.
BIOS unchanged: bootcheck 108 [ok], same ACPI line as before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Loads the kernel from the ESP, places its ELF segments, records the
framebuffer, translates the UEFI memory map into E820 entries, exits boot
services, builds the page tables the kernel expects and jumps. Verified
under OVMF: the kernel starts, brings up PCI, VGA, e1000 and the RTC, and
reaches "cpu0: starting".
UEFI structures are written from the specification rather than importing
gnu-efi or EDK II -- a large dependency for two hundred lines of use, and
a licensing question the project does not need to answer. clang emits
PE/COFF directly, so this needs no new toolchain.
The kernel gained a second entry point. The multiboot entry is 32-bit
code that climbs into long mode itself, and firmware that already put us
there would have to drop back down only to climb out again -- a mode
switch whose failure mode is a triple fault with no console. So entry.S
publishes its 64-bit entry the same way it publishes the multiboot
header: a magic to scan for, SCH64BOO, with include/schboot.h owning the
constants so the two cannot disagree. That header goes *after* the
multiboot header, never before: header_addr says the multiboot header
lives at mboot_load_addr, and the BIOS loader computes the kernel's file
offset from it.
The kernel loads its own GDT at that entry rather than the loader doing
it. Arriving in long mode means arriving on the firmware's descriptors,
and the first thing depending on the kernel's own selectors faulted --
"unexpected trap 13 ... cs=38", a long way from the cause.
KNOWN LIMITATION, diagnosed and not yet fixed: e820_init takes the usable
run *containing the kernel*, which under OVMF ends at 8 MB -- the
firmware places an ACPI NVS region at 0x800000, so the run is genuinely
fragmented. The map is truthful and untruncated (21 entries); the
assumption of one contiguous run is BIOS-shaped. The fix is for the
kernel to free each usable region rather than one range, which touches
kalloc and deserves its own change rather than the tail of this one.
BIOS boot is unaffected: 27 checks, no failures.
boot/bios/ now holds the MBR, the El Torito stub and the real-mode stage
2; boot/uefi/ is empty and documented.
Separate directories rather than #ifdefs, because the two share almost
nothing. A BIOS loader lives in 16-bit real mode, reaches the firmware
through software interrupts, and walks itself up into long mode. A UEFI
loader is a 64-bit PE that the firmware has already placed in long mode
with paging on, calling services through a table of function pointers.
What they do share is the hand-off contract, which boot/README.md now
writes down: ELF segments placed, long mode, a 24-byte-entry memory map
at E820_MAP_ADDR, framebuffer geometry at VBE_INFO_ADDR.
That contract is the point of documenting it now. UEFI's GetMemoryMap
returns EFI_MEMORY_DESCRIPTORs, and the right move is to translate them
into the entries kernel/arch/x86_64/e820.c already parses rather than
teach the kernel a second format.
Build output paths under $(BUILD)/boot are unchanged; only sources moved.
Removes the "-unix" element and with it any trademark exposure to The
Open Group.
The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.
schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).
Two things the rename broke, both found by the bootcheck suite:
- shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
The shorter marker left the write running two bytes past the literal
and the compare reading past the data, failing a file-backed mmap
that was working correctly. Now written and compared through one
constant with sizeof.
- bootcheck asserted a 31-byte file after appending to
"hello-from-schunix"; the shorter string makes it 29.
Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.
An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.
No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.
