"Eric W. Biederman" wrote:
> 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
There is still lot of reason to detect and load IBM XT legacy roms, such as most of the
SCSI controllers does their confrigurations through a program living in ROM. It is
hard to
find a motherboard chipset that support large flash bios. The largest one I found is
4Mb
which is 512KB . Anything larger will not work under x86 protected real mode. I am
sticking
with Award at the moment. But would like to do more research using Linux BIOS, I don't
mind
contribute any work if it meets our requirements. You know, as a product developer is
not
for fun, we have to look for flexibility, compatibility and stability. Like the m-sys
DOC
firmware still providing int13 calls to make it DOS bootable as many of the old apps
are
still running DOS. Switching to the new environment will be in the future, not now.
But if
it does, why would we stay with a dum Intelx86? Many RISC processor is much better and
have
better direct addressing which most of us are looking for.
David
