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.
This commit is contained in:
Nexoniarz
parent
531ef120ef
commit
754d96ebc5
26 changed files with 127 additions and 39 deletions
|
|
@ -1,91 +0,0 @@
|
|||
#!/bin/sh
|
||||
# Build a bootable SchOS ISO.
|
||||
#
|
||||
# tools/mkiso.sh [output.iso]
|
||||
#
|
||||
# The disc boots through El Torito's "no emulation" mode, which is the only
|
||||
# one of the three that fits how SchOS actually loads itself.
|
||||
#
|
||||
# floppy emulation caps the image at 2.88 MB; the ramdisk-root kernel
|
||||
# alone is bigger than that.
|
||||
# hard disk emulation presents the image through the BIOS's INT 13h, and
|
||||
# SchOS's loader does not use INT 13h -- it drives
|
||||
# the IDE controller's registers directly, which
|
||||
# cannot reach a BIOS-emulated drive.
|
||||
# no emulation the BIOS loads a chosen run of sectors at 0x7C00
|
||||
# and gets out of the way. That is this.
|
||||
#
|
||||
# So the layout below is deliberate: -boot-load-size is 1 + STAGE2_SECTORS,
|
||||
# which makes the BIOS place both boot/cdboot and the whole of stage2 in memory
|
||||
# before anything of ours runs. That puts stage2 at 0x7E00 -- byte for byte the
|
||||
# arrangement bootasm.S produces on a hard disk. From there the only difference
|
||||
# is that stage2main.c reads the kernel back with ATAPI instead of ATA.
|
||||
#
|
||||
# STAGE2_SECTORS comes from the environment, set by the Makefile, because this
|
||||
# same number also lives in boot/bootasm.S, boot/stage2main.c and the dd offsets
|
||||
# in schos.img's recipe. It was previously written out by hand in three
|
||||
# separate spots in this file alone, and raising it for the boot logo is what
|
||||
# turned that from a latent hazard into a broken image.
|
||||
#
|
||||
# NOT using -boot-info-table on purpose: it patches 56 bytes over offset 8 of
|
||||
# the boot image, which is the middle of cdboot's code. stage2main.c finds
|
||||
# where it was loaded from by reading the El Torito boot catalog instead.
|
||||
|
||||
set -e
|
||||
|
||||
BUILD=${BUILD:-build}
|
||||
OUT=${1:-schos.iso}
|
||||
STAGE2_SECTORS=${STAGE2_SECTORS:-48}
|
||||
STAGE2_BYTES=$((STAGE2_SECTORS * 512))
|
||||
LOAD_SIZE=$((1 + STAGE2_SECTORS))
|
||||
STAGING="$BUILD/iso"
|
||||
|
||||
CDBOOT="$BUILD/boot/cdboot"
|
||||
STAGE2="$BUILD/boot/stage2"
|
||||
KERNEL="$BUILD/kernel/kernel"
|
||||
|
||||
for f in "$CDBOOT" "$STAGE2" "$KERNEL"; do
|
||||
[ -f "$f" ] || { echo "mkiso: missing $f -- run make first" >&2; exit 1; }
|
||||
done
|
||||
|
||||
# The three pieces must be contiguous and at these exact sizes: stage2main.c's
|
||||
# readseg() finds the kernel at sector (1 + STAGE2_SECTORS) of the boot image,
|
||||
# so a short stage2 would silently shift the kernel out from under it.
|
||||
cdboot_sz=$(wc -c < "$CDBOOT")
|
||||
stage2_sz=$(wc -c < "$STAGE2")
|
||||
[ "$cdboot_sz" -eq 512 ] || { echo "mkiso: cdboot is $cdboot_sz bytes, expected 512" >&2; exit 1; }
|
||||
[ "$stage2_sz" -eq "$STAGE2_BYTES" ] || { echo "mkiso: stage2 is $stage2_sz bytes, expected $STAGE2_BYTES (STAGE2_SECTORS=$STAGE2_SECTORS)" >&2; exit 1; }
|
||||
|
||||
rm -rf "$STAGING"
|
||||
mkdir -p "$STAGING/boot"
|
||||
|
||||
cat "$CDBOOT" "$STAGE2" "$KERNEL" > "$STAGING/boot/schos.bin"
|
||||
|
||||
# xorriso if it is here, mkisofs otherwise. Both accept the El Torito flags
|
||||
# below unchanged -- xorriso's -as mkisofs mode exists precisely to be
|
||||
# argument-compatible with it. The fallback is not academic: there is no xorriso
|
||||
# package for Windows in scoop, where this is developed, but cdrtools provides
|
||||
# mkisofs.exe.
|
||||
if command -v xorriso >/dev/null 2>&1; then
|
||||
MKISOFS="xorriso -as mkisofs"
|
||||
elif command -v mkisofs >/dev/null 2>&1; then
|
||||
MKISOFS="mkisofs"
|
||||
else
|
||||
echo "mkiso: need xorriso or mkisofs on PATH" >&2
|
||||
echo " Windows: scoop install cdrtools" >&2
|
||||
echo " Debian/Ubuntu: apt install xorriso" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
$MKISOFS \
|
||||
-quiet \
|
||||
-V SCHOS \
|
||||
-A "SchOS" \
|
||||
-b boot/schos.bin \
|
||||
-no-emul-boot \
|
||||
-boot-load-size "$LOAD_SIZE" \
|
||||
-o "$OUT" \
|
||||
"$STAGING"
|
||||
|
||||
echo "==> $OUT ($(wc -c < "$OUT") bytes)"
|
||||
echo " qemu-system-x86_64 -cdrom $OUT -boot d"
|
||||
Loading…
Reference in a new issue