Let's look at initial startup stage
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.
In case if system boots from EPROM/FLASH etc, most parts of standard
Setup.s are pretty much extra weight, assuming DMA and interrupt
controllers are in sync with standard PC (why reinvent?, most of
PC104 stuff and x86 embedded CPU's follow this)
I can see boot sequence:
1. Initial jump
2. Do minimum board specific init's in protected mode - #ifdef MYBOARD
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.
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.
Oleg.
>- BIOS may or may not be available
>- Kernel image may be in FLASH
>- Reading FLASH address range may require being in protected mode
>- Reading disk image may require being in 16-bit mode to access BIOS
>- Embedded machine may have non-standard interrupt scheme
>- Machine may have different memory map (no 640k-1M hole, for instance)
>
>The current kernel assumes it needs BIOS to read the kernel image
>before it can get into protected mode, and therefore goes through various
>hoops that might not be necessary.
>
>If we assume that we can access the boot device (be it ROM or FLASH
>or network) without either BIOS or full kernel support, then we can design
>a second "generic" boot sequence that goes immediately into protected mode
>and uses a minimal boot driver layer to transfer the kernel from the boot
>device (in the case of ROM, this is a simple copy). Because we'd already
>be in protected mode, we need less boot memory, etc. This is about as
>close to generic as we can get.
>
>For PC development purposes, we could take the "old disk-only" IDE driver
>and rewrite it to only do getblock operations with polling, while ripping
>out all the other block device-related stuff. This gets us to the point
>where we can write a kernel with absolutely minimal BIOS dependence and
>still run on standard PC hardware. I'll look into this..
>
>--
> "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
>
