On Tue, Feb 13, 2001 at 01:04:00PM -0500, Jeremy Jackson wrote:
> >
> > 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.
Isn't that 16-bit code? If so, linuxbios doesn't use that part. In any
case, it's only checking to see that the ID is nonzero-- we already knew
that zero doesn't work.
> 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,
Most of this is irrelevant to linuxbios because it's mostly just bending
over backwards to deal with being stuck in 16-bit land.
> 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.
Yes, and again, all it's checking is that LOADER_TYPE is nonzero before
trying to load the initrd.
To be more clear, what I meant was there doesn't appear to be any place
where the code distinguishes between one nonzero value and another nonzero
value (i.e. if LILO do X, else if LOADLIN do Y). If you can find code
like that it'd be useful to know about it.
> 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.
>
