| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Nexoniarz
|
ed77244df0 |
boot/uefi: the system information panel, and the offset that faked a version
ui_panel was written for this screen during the loader restyle and then never called -- dead code sitting in boot/common/ui.c waiting for the row that would use it. This is that row: F8 -> System Information, showing firmware vendor and revision, UEFI revision, CPU brand, usable memory, current mode and whether ACPI was found. Everything is read when the screen is drawn rather than captured at startup, because the resolution row above it can have changed the mode, and a panel still reporting what the machine booted with is worse than no panel at all. Two facts are deliberately read through the same code that feeds the kernel -- efi_type_to_e820() for what counts as usable memory, and find_rsdp() for ACPI. A panel with its own idea of either would be a second implementation to keep in step, and the ACPI line exists precisely because a missing RSDP means no MADT, no IOAPIC and no SMP, which has already been debugged once from the far end. The screenshot caught a bug in the screen it was taken to verify: UEFI revision read "21587.2286". EFI_TABLE_HEADER begins with a UINT64 Signature, so Revision is at offset 8 and I had read offset 4 -- the upper half of "IBI SYST", formatted as a version number. It now reads 2.7 under OVMF, which is correct. Verified by driving the menu over the QEMU monitor and reading the pixels: five rows with the hint updated to 1-5, the panel centred, and every value cross-checkable -- EDK II, firmware 1.0, UEFI 2.7, "QEMU Virtual CPU version 2.5+" against -cpu qemu64, 1018 MB of the 1 GB given, 1280x800 matching what fbshot captures, ACPI present. The highlight sits 9 px inside both panel borders, symmetric. F8 has a 1.5 s window, so the capture presses it repeatedly through boot rather than guessing when OVMF finishes -- and only F8, since any other key breaks the wait and boots. Also: every ESP drive now says format=raw. QEMU warned about probing the format on each of the fifteen or so places that attach it, which is new noise on what is now the only boot path. 110 [ok], no failures, no warnings. |
||
|
Nexoniarz
|
651899220c |
boot: the BIOS loader is gone
1449 lines of boot/bios/, tools/sign.pl and tools/padstage2.pl, plus the build rules, the disk image and the ISO entry that existed to carry them. Everything since roughly 2012 boots UEFI, and CSM -- the firmware-side BIOS emulation that lets a legacy loader run on such a machine at all -- has been going away since Intel dropped support for it in 2020. So this is not a path being retired early; it is one whose remaining hardware is already the exception. The cost was never the code, it was the tax on everything near it. Stage 2 had a 65-sector ceiling it overflowed silently -- 25440 bytes against 24576 -- and because the kernel is written at sector 1 + STAGE2_SECTORS, an overflowing loader was overwritten by the very kernel it was loading. The resolution list could not be shared with UEFI either: VBE mode setting is INT 10h, so matching it needed unreal mode, which is the riskiest code in the tree for a feature that already worked elsewhere. What replaces schos.img is the staged ESP, handed to QEMU as a virtual FAT volume. That is a development arrangement and not an installable disk; a real GPT image with a real FAT partition is the installer's job, and until it exists nothing here writes a disk a machine boots unaided. Secure Boot is untouched too -- the loader is unsigned. The ISO keeps one El Torito entry, the FAT image holding loader and kernel. It never booted from a USB stick via BIOS anyway: the firmware presents the stick as a hard disk while stage2main.c read the kernel back over ATAPI. The 32-bit multiboot entry in entry.S now has no caller and is left in place. Deleting kernel entry code is its own change with its own way of failing silently, and it should not ride along with this one. Ported with it: run.ps1, the six screenshot tools, and schcom_test.sh, each with its own OVMF varstore copy so no run inherits another's UEFI variables. Two things this shook out. OVMF now belongs in `all`: nothing boots without firmware, `make clean` wipes build/ including the copy fetched from the host, and a clean followed by a build left every run script throwing. And it cannot be listed as a prerequisite at the top of the file -- make expands prerequisites when it reads the line, and $(OVMF_CODE) is defined further down, so naming it there appends nothing and says nothing. Verified from a clean tree: 110 [ok] and no failures on the full suite, the ISO boots with no hard disk attached, schfs-check passes, schcom's end-to-end pixel test passes, and fbshot captures a real 1280x800 frame. |
||
|
Nexoniarz
|
686d5cf006 |
init survives stray signals; commands are 4-34x faster
Two bugs reported from actual use, plus a test harness that had stopped testing. init could be killed by Ctrl-C, taking the machine with it. SIGINT goes to the foreground process group, init is pgid 1, and any window where tty_fg_pgrp is 1 -- before a shell claims the terminal, after one exits, or between the two while the key is held -- lands it on init. init has no handler, so killed was set, exit() ran, and exit() panics outright on initproc. Spamming Ctrl-C at a frozen program is exactly the input that finds that window. POSIX and Linux both discard a default-action signal for pid 1; init_ignores() now does the same, SIGKILL included, because init is not killable from userspace on any Unix. Everything was slow because BSIZE was 1024 while a SchFS block is 4096, so every block cost four IDE requests, each with its own interrupt and sleep/wakeup. exec() of the 800 KB toybox binary meant ~800 round trips. The giveaway: `seq 1 200`, which touches no file and prints nothing, cost the same 2.0s as `cat /bin/toybox`, and `ls | wc -l` cost exactly double -- both dominated by loading the same binary twice. BSIZE is 4096 now, one request per SchFS block, and NBUF is 256 blocks (1 MB) rather than 90 KB -- smaller than the binary every command execs, so nothing was ever still resident. ideinit() issues SET MULTIPLE MODE, which is what makes a 4096-byte transfer legal: READ/WRITE MULTIPLE move the drive's multiple count per interrupt and nothing had ever set it, which is the real reason idestart() carried a sector_per_block > 7 panic. seq 1 200 2.02s -> 0.06s ls /bin 2.76s -> 0.68s ls /bin | wc -l 4.68s -> 0.73s And the harness. bootcheck called Find-Qemu from a param() default, which is bound before any function in the body exists -- so it died on its first line and printed an error containing neither "FAIL" nor "Exception", the two things being grepped for. It had not run since it was made host-portable. Worse, an earlier index-based edit had deleted the Expect blocks for -Tty, -Usb, -Sock, -Ps and -Evdev, so five of the seven modes asserted nothing at all. Restored, and the USB run gets its own 16 MB build/usbstick.img: it had been pointed at build/fs.img, which nothing builds since SchFS became root, so QEMU refused to start. 242 checks across seven modes, all passing, and make schfs-check green. |
||
|
Nexoniarz
|
754d96ebc5 |
tools: group scripts by what runs them
tools/windows/ .ps1 (pwsh, so usable from Linux and macOS too)
tools/posix/ .sh
tools/python/ .py
tools/ .c and .pl
The .c and .pl files stay at the top level because they are not
host-specific: the build compiles or invokes them on every platform.
Call sites updated in the Makefile, ports/mk/port.mk, docs and the
project memory. The one thing that does not survive a move on its own is
a script deriving the repo root from its own location -- all nine
PowerShell tools used Split-Path $PSScriptRoot -Parent, and memory-sync.sh
used dirname/.., both of which quietly become tools/ one level deeper.
Two levels now.
Two pre-existing Windows failures surfaced while verifying, both real and
neither caused by the move:
- schfs_fsck.c did not compile under mingw at all: --extract uses
POSIX mkdir(path,mode), symlink() and link(), none of which mingw
has. That took the whole tool with it, and `make schfs-check` with
it. mkdir maps to _mkdir; symlink and link fail loudly rather than
writing a regular file in their place, because an extracted tree
that differs from the image while reporting success defeats the
point of --extract.
- the round-trip test then failed at `ln -s`, since Git Bash cannot
create symlinks without developer mode. It skips with a message now.
Not a fudge: mkschfs's mingw build cannot see a symlink either, so
the test would have compared a tree with none against an image with
none and called it a pass -- coverage reporting itself as present
while being absent.
Verified on Windows: build clean, all seven bootcheck suites green,
make schfs-check passes.
|
Renamed from tools/dispshot.ps1 (Browse further)