David Chow <[EMAIL PROTECTED]> writes:
> I felt that LinuxBios make assumption you are using DOC (DiskOnChip), on the
> other hand, there are much cheaper solution and even better than DOC.
Nope it doesn't make that assumption. DOC currently has the advantage
that it can plug into a standard ROM socket. So people doing embedded
type applications with a SIS chipset can take a commodity motherboard,
a DOC and don't need anything else.
I have 2 boards running linuxBIOS right now, and am working on my
third. None of them uses or will use a DOC, and one of them is
incapable of using int 13. The alpha doesn't have an int instruction
or an interrupt vector table.
> This is what I am planning to do. We are concerning a removable storage flash media
>to
> give more flexibility of our hardware. If we use LinuxBios to load linux, and
> then use Linux to load something, you assumed DOC is availble to store linux or
> the BIOS is large enough to provide all the facilities.
On x86 you need 512KByte you can actually do with a little less but
there aren't smaller parts. 256KByte is almost reachable, but
squeazing a kernel down that small is hard.
> Since most of the bootloader today uses INT13.
Only on x86. And only because it is the only game in town.
You need it mostly becase in 512 bytes of code there isn't much else
you can do.
With linuxBIOS we feed it an ELF executable that happens to know what
it is doing. There interface is much simpler, and you don't need to
keep your BIOS around after you start the next program.
> Our flash media compatible with ATA IDE so that we
> are now quite happy to stay in my current setup. The only thing I am worrying is
>
> that the Award BIOS takes too long to get to the boot loader. Now I can load any
>
> operating systems with my firmware.
If you really need the boot any OS capability you can either stay with
Award. Do both while linuxBIOS matures. Or provide coding
documentation for your hardware, and a big enough flash to load
linuxBIOS and your customers might just write linuxBIOS for your
hardware.
I don't think anyone would be adverse to someone coding up x86
backwards compatibility for linuxBIOS, and I'd even give you a design
sketch of what it takes. The only big requirement is that code isn't
mandatory in linuxBIOS.
For future projects I don't want x86 backwards compatibility because I
want an interface that works on all the platforms I produce code
for. alpha, x86, and possibly any cpu linux runs on. It's nasty to
have to switch bootloaders every different machine.
A big reason there is little interest in x86 backwards compatibility
is that it is needlessly complex. There are much simpler solutions.
We just assume you OS is an OS and not an app.
Eric
