Date: Sat, 25 May 1996 06:44:22 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, wpaul@skynet.ctr.columbia.edu Cc: freebsd-hackers@FreeBSD.org Subject: Re: three stage boot again Message-ID: <199605242044.GAA16289@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> The 64K restriction could be avoided by linking the real mode parts
>> separately accessing them through call gates or software interrupts.
>In other words, more magic.
Only slightly more. Less magic in the protected mode part.
>I'm not actually using the same table left behind by the bootstrap:
>as soon as the program runs, it copies itself over the old bootstrap,
>carrying with it its own compiled-in table, and it resets the GDTR
>to use this table instead. The values in the table are actually
>the same, but the location has changed.
See locore.s for something similar. The GDT and IDT are relocated in
advance so that the old ones can be used while the relocation is being
debugged.
>This was one place where I got confused because of the differences
>between the Mach code and ours. The fact that our bootstrap actually sets
>some of the values at run time didn't help. For example, in table.c in
>the Mach code, a segment descriptor looks like this:
> {0xFFFF, 0x1000, 0x0, 0x9E, 0x40, 0x0}, /* 0x08 : boot code */
>But in our biosboot code, the descriptor for the same segment looks
>like this (after being filled in at run time, that is):
> {0xFFFF, 0x0, 0x1, 0x9E, 0x40, 0x0}, /* 0x18 : boot code */
This was intended to be for dynamic relocation of the boot code, which
would have been more useful when the entire kernel+bootstrap had to be
loaded below 640K. If it worked, you could relocate the code by copying
it and jumping to its beginning. Perhaps some of the complications for
it can be deleted now. Other parts of the support for dynamic
relocation got deleted/broken.
>> > an OMAGIC binary. The code needs to be changed to check the magic
>> > value of the binary and only skip the space for ZMAGIC binaries
>> > instead of doing it unconditionally.
>
>> It should know nothing about binary formats. It should simply load files
>> and jump to offset 0 in them. There should be code at offset 0 that
>> understands the binary format.
>Then you'd have to change the kernel too since it is written in a
>particular binary format (a.out, ZMAGIC) which the bootstrap does
>special things to accomodate. The trouble I was having was that the
The kernel can know what format it is linked with and use less general
code to initialize itself. Self-initialization tends to be simpler.
OTOH it all needs to be written in assembler.
>Now what I'd really like to do is to slam biosboot and netboot
>together at high speeds.
Don't forget fbsdboot :-(. I've always wished that it loaded the stage
2 bootstrap and not the full one, but there is a problem with that: the
main point of fbsdboot is to load using drivers that aren't available
at the BIOS level. Also, you can't get back to the BIOS level after
starting DOS (because of hooked vectors). Thus it doesn't work to load
kernel(s) into memory and then switch to the standard bootstrap.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605242044.GAA16289>