Hi all !
I'm looking at the OpenBIOS project for a relatively long time and it's very
interesting to me. So may be I can help in project development ? I
probably can work on any subsystem which not directly works with hardware -
it can be built-in configuration tool, boot monitor, BIOS16 implementation,
etc. I understand that now project in vary early state, but probably design
of such relatively high-level subsystems can also be useful.
Regards,
Victor
P.S. Sorry for my english...
A little messy mail:
>---------------------------------------------------------
>Media: EEPROM BootDevice BootDevice Any Device
>Code: BootLoader -> BIOS -> OSloader -> OS
I like this one, but I would also want things to be either in EEPROM or Any
device. If we have a mandatory minimal bootloader, which everyone has to compile
in, then optional stuff like loading bios from other device, loadin os-loader
directly from any device, incorporate os-loader in eeprom, run our new fancy
BIOS with hardware independent API's etc should be compiletime options.
If we have multiple choices compiled in, one should be able to press shift or
something to select which one to use at boot time, or else the configured
default is used. This means:
Initiate/test board/chipsets/whatever minimum needed.
Find out how to continue (Load bios etc.) / Test for keyboard (if support
compiled in) input (shift for boot menu, del for config menu etc, and if so,
start menu/config)
Run selected boot-module:
Initiate boot-device (floppy/IDE-controller/scsi-controller/NIC etc)
...
I think I will have the time to develop for this project in a few weeks. What I
don't know how to program, I would like to learn! :) Haven't coded much directly
on hardware yet, except some small asm graphics 'demos', but one have to start
somewhere...
If you want to contact me directly, please do so my email to:
karlea(a)samfundet.no
Karl Erik
--------------------------------------------
Karl Erik Asbjornsen, karlea(a)samfundet.no
http://www.samfundet.no/karlea
W: 73540248 P: 73837153 M: 90738663
Hi everyone,
I've seen there have been lots of discussion on the ML lately. Great! :)
After reading through all the mails I have some thoughts that I'd like to
share.
The GNU issue:
I think we should wait, atleast until we know what the BIOS is going to be
like. There could be some benefits of being a part of GNU, but I believe
there are also some disadvantages, such as loosing part of the freedom
(actually).
There have been talks about what the BIOS should do and support. One
opinion is that it should be extremly small and only support loading in a
bootloader, and never be touched again. Another may be to support older
OS'es using 16-bit INTs.
As I envision it, the BIOS functionality should be rather big. It shall
support all hardware attached to the motherboard, and also other hardware,
through their own BIOS. This way programmers of operating systems won't
have to worry to much about the hardware part. You may think of it as a
HAL (Hardware Abstraction Layer) if you wish.
I think the reason that many programmers have avoided using BIOS routines
instead of their own hardware routines is that they don't know in what way
the BIOS works. It could be really badly implemented and be really slow.
But when the sourcecode is free, they will be able to read the code and
see that these routines are actually highly optimized and probably
couldn't be done any better. (And if they could, they should do so and
send in the patches to openbios.org :-).
When it comes to supporting old 16-bit OS'es I am personally not
interested in supporting them at this time. We don't want any crappy
16-bit OS'es anyway! I think the BIOS should be 32-bit and use protected
mode (flat) all the way through. And if we really, really need to support
16-bit some day, it will be easy to switch back to real mode and implement
the necessary INTs then.
Though I think we should support every existing 32-bit (pmode) interface,
such as BIOS32 and VESA 2.0 protected mode interface (the VESA stuff is
really not up to us, but to the graphicscard manufacturers).
Some people have talked about OpenFirmware (IEEE 1275) support. This sound
like a good idea to me, but since I don't really know what that requires
from the BIOS, I can't make any comment on it. I think I will read through
the homepage later (http://playground.sun.com/1275/home.html). Although I
do know that this would require Forth support, which would be a good
thing, since I believe the PCI specification requires BIOS code in Forth
for PCI devices. (On the other hand using Forth is said to be big and
slow, so I don't know...)
Joel Mansford mentioned that you could have the BIOS setup program run
from your favorite OS, which seems like a good idea to me. Then it could
be very good looking, and vouch for easy tweaking of the BIOS. Preferably
there should also be a complementary setup inside the BIOS, incase the HD
breaks down or whatever.
Concerning hardware compability, I think it will suffice to support newer
PCIset computers to begin with. That would pretty much mean Pentium and
upwards. This is, as I see it, not a big problem at this time. And when we
(or someone else) wants to support older hardware (386/486/non PCI) that
shouldn't be all to hard when we got a working BIOS. This also implies
that I don't think any specific embedded design features should be made at
first.
I also, like many other here, think that we should support as many booting
devices as possible. Perhaps we should begin by supporting floppy and IDE,
and then move on to other things, such as network and USB and so on. This
would be real easy to implement later, due to the modular design.
That is something I believe that _everyone_ agrees of; that OpenBIOS
should use a highly modular design. This will bring several obvious
advantages. I have though of three different places where the modularity
will take place. First is the sourcecode, where many different pieces of
hardware can be supported via preprocessor directives, and separate
sourcefiles. Then just before flashing the BIOS into ROM, there could be
different modules that the user could choose between to change
functionality, but without having to recompile. Lastly there could be some
runtime autodetection of hardware. I think this last thing should be used
very moderately, if at all.
If you are still reading this, I want to apologize for this quite large
post (didn't mean to do it... ;)
Best regards,
Niklas Ekström
Ok, I was now wondering if it's worth someone outlining a list of tasks, and
then people can take/be assigned individual tasks.
I suppose, however, that before then we need to outline some vague specs or
goals.
I believe that someone has already offered their services for the
documentation, and I'm willing to write any kind of user interface/ higher
level code (i.e. not hardware interfaces).
Just some ideas...
Joel
============================================================================
===
A Computer is only as good as its [Non-Commercial] Applications and
Operating System. '98 is the work of the Devil
----------------------------------------------------------------------------
---
To see when I last checked my mail,or when I last received a mail which
is unread goto my homepage at http://www.rdg.ac.uk/~ssu96jm/ and follow
the link. My recommended reply-to address is mailto:Joely@Techie.Com
============================================================================
===
Matthias Wächter wrote:
> On Fri, 5 Feb 1999, Charles Esson wrote:
>
> > First question. Do you think it should just replace what is there now.
> > Or should the job be done properly.
>
> Of course, in my opinion, it should be done properly.
>
> > If you want to do the job properly, then the OS's have to change.
>
> This is why all OSS OSes are so well suited for OpenBIOS - we just have to
> write a new thing like LILO (say, OBLL, OpenBIOS Linux Loader) which
> correctly interacts with OpenBIOS to have all compatible as we need it.
>
> > Basically the Intel PC is a mess, because the bios is a mess.
>
> Well, ... Intel PC is a mess, because BIOS is a mess, because the original
> 8088-XT was a mess. Of course, it was somewhat well suited for the needs
> that time (1986 or so), but I can't understand why there has nothing come
> up with new features, etc.
>
> PS: Do you want to continue talking privatly? I don't have any problem
> with that though it would be interesting for the other OpenBIOS
> subscribers to keep in touch with our thoughts. (feel free to reply publicly)
>
Sorry clicked the wrong dam button.
If it is agreed it has to be done properly, then we have to agree on what the
bios should do.
1) Boot an OS
2) Provide diagnostics
3) Provide a bios ( basic input output services )
And at all times we should remember that the PCI standard specifies that PCI
cards can supply FCODE drivers, that SUN and apple have gone down this path, and
that FREEBSD have gone down that same path.
I see no reason to reinvent the wheel but I do see a good reason to get the
FREEBSD code, unfortunately I have found the boot image but not the source, and I
have no idea who is doing the work.
Regards
Charles
>
> Winschdawos,
> - Matthias
>
> --
> Der Wein mit der Pille ist in dem Becher mit dem Fächer.
> -----------------------------------------------------------------------------
Forgive my ignorance....
Has anyone actually made any progress so far on actually writing a bios
which boots an OS?
I was also wondering if anyone has noticed the way that old and some current
Compaq machines BIOS' work. They seem to have a very simple bios on ROM
which is capable of autodetecting RAM, processor, hdd, fdd etc. but has no
interface, to set the thing up you need the floppy or special partition on
the harddrive. Although from a maintenance point of view I don't like this
it did mean that they were able to make a very comprehensive setup program
with full built-in diagnostics etc. Which ultimately was user friendly since
Compaq used Windows 3.1 as the BIOS set-up OS! No reason why we couldn't use
a nice 'pretty' VGA setup util that sits on the harddrive, or a text one
that runs from Floppy.
I appreciate that this isn't an ideal solution, but I've become very
frustrated with BIOS' that simply don't have the right options for no good
reason like, no option to boot A,ZIP/LS,SCSI,IDE-0 or the like.
As I understand it we are looking for a modular system that can be compiled,
ultimately for any motherboard, is this correct?
Just some Ideas,
Regards
Joel Mansford
============================================================================
===
A Computer is only as good as its [Non-Commercial] Applications and
Operating System. '98 is the work of the Devil
----------------------------------------------------------------------------
---
To see when I last checked my mail,or when I last received a mail which
is unread goto my homepage at http://www.rdg.ac.uk/~ssu96jm/ and follow
the link. My recommended reply-to address is mailto:Joely@Techie.Com
============================================================================
===
Hi,
I have been following this dicussion for a while,
I think the capability to boot of a network (USB, etc) is definitely a
good one, but as long as it is an optional module that the BIOS can
work without. I'm all in favour of the "microkernel" approach (ala
QNX.com )so that a modular approach based on a minimal base is possible.
I think that both pro and con arguments are valid, and the forward
from here is starting with some list of prorities, like starting with
the pre-boot algorithm that reads the state of the Reset Switch to
invoke boot, and optimising this algorithm to account for things like
metastability in digital circuits.
I feel we have a lot to do if this project is to progress.
==
------------------------------------------------------------------
Alex Dinovitser
PhD Student ph: +61 8 8302 1775
Transport Systems Centre fax: +61 8 8302 1880
City East Campus
University of South Australia
Adelaide 5000
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
This is a philosophical question that I am posing here for discussion.
What should the purpose of the BIOS be?
In my mind, the BIOS should be a minimal piece of code, used only to
initialize the hardware to the extent needed to boot the system. This would
include initializing the memory space and boot device, reading the first
block of code from the boot device and turning control over to that block
of code. This "boot block" would then finish initializing the hardware,
loading API's, OS's or whatever, from the boot device.
I believe that all API level services should be provided by the boot block
code that is loaded by the BIOS and not by the BIOS itself.
The idea of the BIOS providing an API is something that developed in the
early days of PC's when each card had its own BIOS/API supplied in ROM on
the card. IBM and the clone makers quickly tried to consolidate these
separate BIOS blocks into a single EPROM. The problem with this solution is
that the BIOS is not flexible, it is very hardware dependent, is optimized
for a single OS and is very complex.
A simple BIOS, whos only task is to initialize the CPU/Memory/Boot Device,
then load and execute a boot block (from the boot device) would be
preferable to trying to replicate the "BIOS as an API" model that is used
in todays PC's.
I think that the "BIOS as a boot loader" model is simple and flexible
enough that it will be easy to maintain (especially in a free software
environment) and easier to evolve as the hardware and software environments
change. All of the intelligence (system initialization and API's) reside
within the code stored on the boot block (rather than in the BIOS code
stored in EPROM/EEPROM).
Using this approach you would not have to worry about optimizing the BIOS
code for any specific OS. The BIOS's only job would be to load/execute the
first block from the boot device and then get out of the way. The first
block stored on the boot device could then contain low level hardware
initialization and API's (if needed) that are optimized for the OS that is
going to be used.
Once control passes from the BIOS boot loader you have complete
flexibility. You could set the system in any mode, load any OS, load a
multiple OS loader, even load an old fashioned 16 bit BIOS into shadow and
act like a legacy PC clone. But none of this code has to be in the BIOS
itself.
The BIOS as boot loader would also be well suited for embedded applications
because it is small, lightweight and can be specifically implemented to
boot from things such as flash, EPROM, network cards, radio modems or other
unusual boot devices.
In all cases the code would simply initialize the hardware then
load/execute the boot block from the boot device. The BIOS would only need
to be as complex as the hardware deems necessary. Support for new and
custom hardware (non boot devices) would only have to be implemented once,
in the OS. Not twice, once in the BIOS and once in the OS.
Thoughts, comments?
Dave
Hiya
To the List Owner:
Could you possible force reply-to header in the list mails please, it
will make it so much easier to reply to the mail, and will ensure that
all mails do not get duplicated to their recipients, and that they all
go back to the list with the use of the 'Reply' button on most mailers
;-)
Thanx
Matthew
