|I'm glad I asked the question.
|
|Are there any books or docs on the boot process? As well as i386 I use a
|mklinux computer; vmlinuz seems to be on the host system as well as
|on the linux partition; the boot process seems to metamorphose as it
|proceeds. I stand back in awe-ful admiration and wish I knew what was
|going on. Yes, yes, I can google, but a little direction might help.
|
|Nick
Not that I'm aware of. You can pretty much derive the necessary workings
of a bootstrap loader from first principles. The main task of a
bootstrap loader is to get all the kernel's bytes into memory at the
desired addresses and then jump to the start address. The complications
are in the details. Some complications are due to the awful PC
architecture and some are inherent.
Addresses: Obviously you want the loader to be small to maximise the
memory available to load the kernel. That's why LILO uses addresses from
0x90000-0x9FFFF. Unfortunately when disk-on-chip devices came out, they
decide to put some drivers there. So coders had to make a special
version of Linux that expects the kernel parameters in the 0x80000
segment and use a specially configured LILO.
Disk reading: Linux drivers are not running when LILO boots so it must
rely on BIOS routines for disk reading. Unfortunately some idiot in the
past decided that 10 bits would be enough for the cylinder field in the
BIOS call, hence the infamous 1024 cylinder limit. With recent BIOSes and
LILOs extended BIOS calls are used.
Kernel parameters and environment information: The kernel needs to know
about the environment, e.g. what display is connected, and also receive
parameters from the user. The complication in the x86 PC architecture is
that BIOS calls are only available from real mode. The kernel runs in
protected mode so is not able to (easily) make BIOS calls. So a separate
code segment (setup.S) collects this information and leaves it where the
kernel can access them. However when video cards that can take away
memory from the top of the available range came out, it became necessary
to provide a loadable module (agpgart.o) that informed the kernel the
video card would be taking the top X MB of memory.
Loader format: Any format that specifies what's in memory is ok but it
should be no more complicated than needed so that the loader does not
have to do things like resolve symbols, which requires keeping a lookup
table. Since the kernel is all of one piece with no unresolved symbols,
that's no big deal. However there is the aforementioned setup segment.
x86 kernel images also have a floppy boot sector at the beginning,
originally there so that the kernel could be copied raw to floppy disk
and it would boot. Unfortunately some pieces of information are stored
near the end of the block, e.g. root device, video mode.
Compression: Compression helps shorten loading time trading off a slight
delay at boot up while decompressing. In x86 kernel images it's done as
a small decompressor prefixed to the kernel binary.
Ramdisk: Ramdisks are extremely useful. The Linux kernel has provision
for loading ramdisks itself, which means you have to pass parameters to
tell it which device it's on and the offset on the device. It can also
expect the ramdisk to be preloaded by the loader (e.g. LILO, Etherboot)
and then you have to tell the kernel where in memory it is.
Network loading: Network loading introduces another limitation and that
is there is no random access device to seek on, the image comes as a
stream of bytes. This means that the loader format should have
sufficient information (usually a roadmap at the beginning of the image)
to guide the loading of the rest of the image.
Booting from other operating systems: Loadlin loads the kernel image
from DOS and non-PM Windows. It has to undo a lot of the setup that
Windows does, e.g. flush caches, unload memory managers, before it can
load Linux. Again, it has to move itself out of the main memory area
where Linux will be loaded. For implementation reasons, loadlin
simulates the effect of setup.S and doesn't actually run it.
CPU architecture: Fortunately not all CPUs require such ugliness.
Others don't have the real/protected segmented/flat mode braindamage.
(The 8086 architect should be whipped with lots of Thai chilli noodles.)
On some CPUs it's actually so straightforward that you wonder why all
the drama with the x86 is needed.
Linux BIOS: There is a project to run Linux directly after booting. Just
load the kernel, go straight into protected mode, jump into Linux and
let it initialise all the hardware. It can boot Linux really fast,
currently you often see the BIOS take longer to initialise hardware than
Linux takes to boot. One drawback is that you need the cöoperation of
the motherboard manufacturer.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
