On Thu, 15 Oct 1998, Oleg Perelet wrote:
> In case system boots from ATA (mechanical IDE or flash based media)
> and has BIOS, standard Setup.s covers it pretty much. I don't see
> any reason for having BIOSless custom computer if you boot from
> ATA or floppy - you end up rewriting(copying) big part of BIOS
> yourself anyway. About the same about VGA - if you got it on board,
> maybe you want to have BIOS too, last one can be reason for discussion
> because some board may have custom VGA based displays.
You've missed my point. The first step to making a generic diskless boot
scheme is to build something people can use. Since everyone has different
boot devices in mind for their embedded projects, the only way to do this
is to choose a simple device most people *do* have - and the simplest is
an IDE drive. If we try to make a "generic" embeddable kernel that doesn't
work on a PC, we've produced something that no one will use. As you
mention, there also exist FLASH devices with an ATA interface, so this
will get many people closer to having a working embedded system. This also
has the benefit of requiring RAM to boot, which some ordinary Linux users
will appreciate.
The kernel already has to rewrite the VGA control stuff - once in
protected mode, using BIOS is a major kludge at best. The only part of VGA
BIOS that is relied upon in most cases is the initialization.
> I can see boot sequence:
>
> 1. Initial jump
> 2. Do minimum board specific init's in protected mode - #ifdef MYBOARD
This must currently be done in real mode, and in assembly, unless you want
to use other than the standard kernel tools.
> 3. Reuse switch to protected mode from standard Setup.s
> 4. Copy image from boot media to DRAM, there is predefined address where
> Linux loads kernel (don't have source around....)
> 5. Prepare kernel startup parameter table (again standard for Lunix).
> 6. Jump to kernel.
> Step 4 is somehow board/boot media specific, but mainly it's
> int LoadImage (long address), pretty much isolated. Step 5
> is mainly filling up parameter block with board specific
> numbers, again - pretty localized.
More or less agreed, except that the memory map details have to be
configurable for a generic system. The above is a pretty big restructuring
of the existing scheme and I suspect everyone who makes a diskless or
BIOSless Linux goes down the same path (I have).
> I'm curious if there are any real live corrections, remarks on this step?
> This obviously don't covers whole startup, next thing will be filesystem's
> etc.
Using the generic RAM disk or my ROM disk driver makes this pretty easy
to deal with. With the ROM disk, it's possible to do things like make a
file system that's inside the compressed kernel image, nothing else
required.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
