> So why not make up an embedded Linux kernel and load _that_ into the
Serious overkill, I think. There are better solutions in the forms of:
These are designed for the embedded environment and don't carry the
excess baggage you'd be flashing into EEPROM.
(Note that this is going to the OpenBIOS list now.)
Steve Williams "The woods are lovely, dark and deep.
steve(a)icarus.com But I have promises to keep,
steve(a)picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)psychosis.com Body: un/subscribe
[about:16bit stuff in bios/compatibility to DOS/Windows]
> > IMHO this is not the way to go, since many people still have Windows95
> > installed (because of the games), but would like OpenBIOS. I would leave an
> > option that links a set of wrapper functions.
The problem is, that the available space on a flashchip is today 128 k or
256 k, depending on the system. Because 256k chips are still too rare,
I'd suggest that we try to get the most stuff into 128k and maybe only
some not really needed features as the animated logo with mp3 sound at
bootup into the second 128k :-))
> Would it be possible somehow to have the original bios image on the
> harddisk, and then have an option on the boot console where you could
> load it into memory and start it? It may very well not be possible,
> but if it was, then we could concentrate on our stuff, and let the
> original bioses support the win95/98/dos/other os's... Also having
> the possibility to select bios at boot would be a cool feature! :)
> Just a thought...
Well.. This is really a good idea. I once thought about loadable bios
plugins on hd or via network, but that may be very hard.
The easiest way would probably be to load the bios directly from harddisk,
as it can be done on the Alpha AXP boards. We could do this before the cpu
is switched to protected mode or afterwards and switch back to realmode to
load award or ami bios. The first would save some code, the second seems
to me to be the more elegant version, because we can do the whole floppy
stuff in PM (which could be necessary if we want to support ia64 some day)
.signature: No such file or directory
Stefan Reinauer schrieb:
> 1) Do we need the 16bit bios stuff in an OpenBIOS?
> I'd say a clear "NO" here. This does mean, on the other hand, that we
> won't support any proprietary systems like windows or DOS anymore,
> but as for using DOS/Windows, Award and AMI BIOS do a good job, this is
> not really needed.
> People who need more features like netboot and a good console in their
> BIOS very likely use Linux or any BSD flair.
IMHO this is not the way to go, since many people still have Windows95
installed (because of the games), but would like OpenBIOS. I would leave an
option that links a set of wrapper functions.
> I'd suggest C, [...]
Agree. I also have some further thoughts on this, but I'll post them tomorrow.
> 3) Testing platforms
Well, I've got a bunch of testing machines as well as old NE1000 cards here.
If I find some time (and the manual and a NE/2 for my PS/2), I can do some
Also, I think if someone just wants to run Linux and nothing else, a Linux
kernel with the BIOS querying code commented out would do as well. So the main
reason to use OpenBIOS should not be "It loads my Linux
bigger/better/faster/more" but rather "I like to have a boot console" or "My
company saves $200 on harddisks for each computer". Just my two cents.
Also, the BIOS should be optimized towards minimal data storage space rather
than speed. It won't harm speed that much, but the final OS has to live with
all that stuff in RAM.
Dear guys :-)
As you might have noticed, there's not much traffic on this list at the
moment. I'd like to start a bit of discussion right now to get things
1) Do we need the 16bit bios stuff in an OpenBIOS?
I'd say a clear "NO" here. This does mean, on the other hand, that we
won't support any proprietary systems like windows or DOS anymore,
but as for using DOS/Windows, Award and AMI BIOS do a good job, this is
not really needed.
People who need more features like netboot and a good console in their
BIOS very likely use Linux or any BSD flair.
2) Which programming language should be used?
We sure will have to write some init code in assembler, which is OK, if
it doesn't get too much. I think writing in a higher level language is
much easier because a) more people can help the project and b) the code
can easily be maintained. I'd suggest C, as C++ seems to be a bit
bloated for this project. (As well as other languages)
To give anyone the chance to help the project, I'd like to use the GNU
Compiler GCC. Every Linux/BSD user has access to it and it's available
for most other platforms, too(W32 i.e.)
3) Testing platforms
I had a look at bochs some days ago (which now runs fine on my Alpha
AXP without segfaults) though I am not sure whether it is really good
enough for testing (I expect problems with the PnP and PCI init stuff)
I am sure that it's possible to get some test mainboards so that no
developer has to fear to destroy his computer.
You might have a look at my devbios project, a flash bios device for
Linux2.1. It can be found at
The OpenBIOS webpage can be found at
I'll try to get the archive mirrors of the earlier mailinglist discussions
online this week, so stay tuned and don't hesitate starting a new
discussion about the above themes (or anything else)
.signature: No such file or directory