Eric Seppanen wrote:
> On Tue, Feb 13, 2001 at 10:29:02AM -0500, [EMAIL PROTECTED] wrote:
> >
> > Does anyone know what problems we might run into by setting a random or
> > arbitrary loader ID? we have to set something.
>
> >From linux/Documentation/i386/zero-page.txt:
>
> 0x210 char LOADER_TYPE, = 0, old one
> else it is set by the loader:
> 0xTV: T=0 for LILO
> 1 for Loadlin
> 2 for bootsect-loader
> 3 for SYSLINUX
> 4 for ETHERBOOT
> V = version
>
> They've got seven left, so it seems unlikely anyone would refuse to assign
> linuxbios number 5. But searching on LOADER_TYPE gives no location where
> it's actually used to test for anything, so I'd bet that if you set it to
> something nonsensical (0xFF?) I doubt anyone would ever notice.
you have to be careful; the boot stuff is mixed C/asm and doesn't share .h
files very well... lots of notes saying if you change this here be sure to
change
it in xxx too.
arch/i386/boot/setup.S checks this: grep for "type_of_loader" and you can see
it for yourself.
originally linux loaded at 64k, but this limited kernel to about 512k
(remember junk at 640k -- 1M)
newer "big" kernels load above 1M using bios calls to move memory in
"protected mode".
this flag (or one closely related -- i forget) tells kernel where to find its
self, so I don't know if you can just pick at random.
the LILO documentation has an excellent description of the boot process,
detailing the early memory maps,
where paramters and command line are stored, with illustrations and
everything; I suggest looking these over.
LOADER_TYPE *IS* referenced once in arch/i386/kernel/setup.c as well.
this could all use some cleanup in the PC BIOS and LinuxBIOS cases: the
assembler's alignment mechanisms aren't used
optimally; a lot of hand calculated offsets & padding are used, making the
code harder to understand and more susceptable
to breakage - every single byte counts in many parts.
I would be content to let the PC BIOS case stay as it is; it's not like
cleaning up a little loader code the PC architecture would
suddenly make sense. But in the LinuxBIOS case, I think ultimately there
should be an kernel config option for LinuxBIOS vs PC BIOS. #ifdef out a lot
of the PC stuff, put in cleaner LinuxBIOS versions. Also, some things should
support passing arguments by pointers, with the PC BIOS case just hard-coding
the value (to where LILO is hard-coded to put them) into
a macro that optimises away, but removes restrictions and assumptions that
limit LinuxBIOS. Like 1st 1k for BIOS data area, paged frame buffer access
at 0xC000, parameters in zero-page,etc. we could have a really clean
(simplified) memory layout.
