On Tue, 13 Oct 1998, Oleg Perelet wrote:
> Hi guys, newbee in here.
> Little bit of background:
> We are building embedded computer for data acquisition, CPU board
> has AMD Elan sc4000 processor (one of embedded 486 flavors),
> 16MB dram, 2mb sram, 2mb flash, Crystal Ethernet chip and misc.
> stuff on it, no video, no BIOS.
> Currently it is running QNX, I was under impression that going with
> QNX will make things smooth ... not for us, I ended up writing
> complete bootstrap, file system drivers etc, support from QNX just
> sucks and for that $$$ that they ask and all problems that we have
> with them, screw it!
> Anyway I looked at lunix and already started to mess up startup.S and
> boot related files, but then I discovered this list, so my first question
> is:
> I'm sure bunch of people already done this, is there any canonical place
> where you guys share embedded changes for LINUX? I'll just hate to repeat
> what was done zillions of times.
Most of the patches that are "portable" - namely ROMdisk, ROMFS, serial
console, no virtual terminals, etc. have either been posted to this list
or are already incorporated into the mainstream kernel (2.1.x, primarily).
What remains are fairly specialized solutions for booting and dealing with
FLASH. Most of these are heavily dependent upon specific variations in
architecture, etc. Right now the boot sequence makes many assumptions that
may or may not be true for a given embedded platform. Making a generic
boot strategy may or may not be possible. Here are some of the
considerations:
- 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.."
