SchOS/boot/uefi/README.md
Nexoniarz 26bca020b6 licence: SchOS is GPL-2.0-or-later, no longer Apache-2.0
Nexoniarz is the sole author and SchOS was never published under
Apache-2.0, so this is a straight relicence. LICENSE is the FSF GPLv2 text,
every first-party SPDX header moves to GPL-2.0-or-later, and NOTICE,
README.md, docs/licensing.md and the site say so. projects/schfs-linux
follows the rest of the tree.

The GPL gives copyleft: a fork has to ship its source. It also lifts the
old "Linux drivers, never" rule, since GPL-2.0-only code combines with
GPL-2.0-or-later. "Or later" leaves room for GPLv3, but one binary still
has to pick one version, so docs/licensing.md now keeps Apache-2.0 and
GPLv3 code out of the kernel to keep Linux code possible there. BSD
4-clause code goes from "avoid" to "no", because the advertising clause
is GPL-incompatible.

LDLS still ships no .ko. That boundary is now project policy rather than
a legal requirement, and ldls.md, devices.md and licensing.md section 6
say so. refmod declares license=GPL, and ldls-check passes (27 checks).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-22 08:48:45 +02:00

29 lines
1.5 KiB
Markdown

<!-- SPDX-License-Identifier: GPL-2.0-or-later -->
# UEFI loader
The loader. This directory once existed only so the BIOS path could be moved
into `boot/bios/` without pretending the split was hypothetical; it is now the
only path there is.
See `../README.md` for the hand-off contract a loader has to satisfy. The
short version: the kernel wants long mode with paging on, its ELF segments
placed, a 24-byte-entry E820-shaped memory map, and framebuffer geometry — and
it does not care which firmware produced them.
What this will need, in rough order:
1. A PE/COFF target. clang can emit one directly
(`--target=x86_64-unknown-windows -fuse-ld=lld-link`), so no new toolchain:
the same LLVM install already builds every other target here.
2. The handful of UEFI structures actually used — the system table, boot
services, `LOADED_IMAGE`, `SIMPLE_FILE_SYSTEM`, `GRAPHICS_OUTPUT`. Written
from the specification rather than by importing gnu-efi or EDK II, which is
both a licence question and a large dependency for something this small.
3. `GetMemoryMap` translated into the same 24-byte entries `e820.c` already
parses. Not a second format for the kernel to learn.
4. `ExitBootServices` before touching the memory it described.
5. Graphics Output Protocol for the framebuffer, filling the same
`VBE_INFO_ADDR` structure the kernel reads.
The image goes at `EFI/BOOT/BOOTX64.EFI` on a FAT ESP, which also means the
ISO carries a single El Torito EFI entry.