Shikhin wrote:
Griwes wrote:
First, the bootloader should be file system agnostic, but not filesystem unaware (not that I'm arguing with that "no filesystem needed" from Brendan) - user (= operating system being booted, or it's developer; I'm going to keep using that word for them) should be able to put a filesystem driver, in format specified in specification (for example, with array of function addresses in first X bytes or something; it MUST be simple) in first (starting from Yth; we gotta get 2nd stage somewhere) Z sectors of disk/partition, and keep kernel (or application; who said that it must be kernel? again, let's stick with term "application" here; for more not really rational rationale look at naming paragraph) in some hardcoded location, like `boot/boot.gand` (why `.gand`? See naming paragraph). If those Z sectors aren't in filesystem driver format, they should be treated as application that is to be booted; that would be simple solution for both people wanting to be able to easily booted application, as well as to those wanting to recreate the partition every time they recompile their kernel.
At first looks, it seems to be a nice solution. However, I still don't like the idea of putting anything in the first N sectors. As far as I know (though I may be wrong), ext2/3/4 don't support having any such reserved sectors at the start of the disk/partition. Moreover, entrusting the user to write a filesystem driver... is bad. Of course, we could have some pre-built drivers for each fs, and then put them in the first N sectors. But that'd be almost similar to bluemoon's VBR per filesystem design.
The specification could as well state that "first sector of 2nd stage is X, first sector of driver/application is Y, their lengths are Z and W", and define what dwords/qwords (using NASM/YASM terms) define those values.
Shikhin wrote:
Griwes wrote:
Second, the boot sector should be filesystem aware; that is, I think that should be able to create per-filesystem (M/V)BR template file, that would allow the same code work (after, well, reassembling it) for different filesystems, that use different parts of (M/V)BR, as well as the legacy partition table. Just create template (putting some zeroes at places that shouldn't be overwritten to allow assembler to produce binary, but also creating some kind of 512 byte "mask", so HDD installer - assuming there is one - will be able to write boot sector without overwriting old data). Note: I have no idea how this is done in different OS installers, but I assume they use special filesystem drivers and preassembled boot sectors for supported filesystem; this solution *could* make it simpler and more generic.
I'm sorry, I lost you here. Could you please rephrase the above paragraph, or something?
Yeah, it was a little chaotic ;D
Consider following file, to be included for every FS-specific (or MBR-specific, doesn't matter) bootsector:
Code:
bits 16
org 0x7c00
%macro begin 0
begin:
jmp 0x0:start
%endmacro
%macro code 0
start:
mov ax, 0
mov ds, ax
mov es, ax
; ...all the bootloader code
%endmacro
%macro fill 0
times 510 - ($-$$) db 0
dw 0xaa55
%endmacro
Then, an example of actual bootsector file would be:
Code:
%include "gandboot.inc"
begin
db "Example Label "
; ...whatever is required to be here
code
fill
I would have to think for a moment about generating those masks, though (like: original data - 0x93, 0x54, 0xff, 0xac; bootloader - 0x00, 0xac, 0xac, 0xef; mask - 0x00, 0xff, 0xff, 0x00 => 0x93, 0xac, 0xac, 0xac; hope you get the idea). The point in it is to ease creating bootsectors for exotic filesystems.
Shikhin wrote:
Griwes wrote:
Finally, other features it would have to have, or could have - more important first:
- memory map sanitization - probably not necessary for UEFI (*probably*), but definitely recommended for ol' BIOS
- VBE mode setting (configurable at install)
- getting IOAPICs and LAPICs in known state (it's not much work, after all; by known state, I mean "disable everything you can")
- if it would already mess with APICs, maybe some basic ACPI parsing (like combining various entries of MADT, creating table that doesn't have variable-length entries, maybe - not much people would use it, but having that data parsed by write-once-use-all-the-time tool wouldn't hurt, especially when there is no SRAT and SLIT - applying SRAT/SLIT to that MADT structure and to memory map) - I mean, one table with variable length entries less to parse = profit!
- (?) AP booting (?)
Fine, but: I would recommend against configuration files. Let the specification define bytes in 2nd stage that are responsible for given settings; that would remove the necessity to implement configuration file parsing in bootloader - at the cost of readability of settings, but creating small driver to change those settings based on some kind of CLI or GUI shouldn't be hard (granted you have driver for storage device). For example, in POSIXish environment, the driver could expose `/dev/bootloader`, allowing read/write access in some human-readable format.
Also, you meant PIC, not PIT, right?
And to get truly clean state, you should also - IMHO - at least mask IOAPICs. Plus, I would drop MP support entirely; ACPI is there for really long time.