Making a BIOS on my own...
by Niklas Ekström
Hi everyone,
I just thought I'd post a note on way I've decided to work on a BIOS of my
own. The main reason is that we are getting no where. It's not that I
don't want to be a part of OpenBIOS, rather on the contrary. But every
time I come up with some suggestion, atleast a couple of people will point
of how wrong I am, and the result is that we stand still. I find this very
frustration, since I feel that we should act now so we can have working
BIOS in half a year or so. No one will be happy by us sitting here
arguing without reaching anywhere. The greatest problem I see is that we
have no real (active) leader, that could take decissions for us and say
that this is how we are going to do it, now move!.
If things start to move around here later in, I would like to help out,
but until then I will go ahead and make a BIOS of my own. If someone
happens to agree with my ideas of what a BIOS should be like (should be
pretty obvious from my previous posts), feel free to contact me on the
above email address.
/ Niklas
20 years
- 3
- 2
Clarification....
by Dave
After reading the responses to my "Philosophical question" it became clear
to me that what I was suggesting is more of a boot loader than a bios.
I still think this is a good approach. Separate the BIOS functionality
(standard interface to the hardware) from the boot loader. The reasoning
behind separating the two is that 1) a good BIOS would be as much OS
dependent as it is hardware dependent. 2) Modern operating systems do not
currently take advantage of the services provided by the BIOS.
For an operating system that comes with its own drivers (that work directly
with the hardware) there is little or no need for a BIOS that provides
API's to the hardware. The only need for a so called BIOS is to initialize
the hardware to the point that it can read from the boot device and load
the OS (or an OS loader) into memory. For legacy OS's (Dos, Windows) that
require a BIOS, the Boot Loader can load a BIOS from the boot device
directly into Shadow Ram and execute it as if it where copied from EEPROM
to Shadow Ram.
What I am thinking is something along the lines of a layered approach.
* Boot loader only *
- Linux kernel could be loaded this way
---------------------------------------
Media: EEPROM BootDevice
Code: BootLoader -> OS
* Boot Loader & OS loader *
- Lilo (modified?) could be used this way
-----------------------------------------
Media: EEPROM BootDevice Any Device
Code: BootLoader -> OSloader -> OS
* BootLoader, BIOS and Legacy OS *
- Loads BIOS code from boot device to Shadow,
runs BIOS code (from Shadow) which then boots
legacy OS (such as DOS, Windows etc).
----------------------------------------------
Media: EEPROM BootDevice BootDevice
Code: BootLoader -> BIOS -> OS
* Boot Loader, BIOS, (Legacy OS support) and OSloader *
- Used on a system where multiple OS's must be supported.
BootLoader loads BIOS into Shadow, BIOS loads OS loader
which can be used to select which OS will be loaded.
---------------------------------------------------------
Media: EEPROM BootDevice BootDevice Any Device
Code: BootLoader -> BIOS -> OSloader -> OS
I guess my thinking here is that a boot loader will be a much simpler piece
of code to implement than a full scale BIOS. The first generation
development efforts would focus on providing good boot support for various
boot devices without the added burden of replicating (or inventing new)
BIOS API's.
During development we could use the copy of the BIOS that comes with all
motherboards (moving it to an image on disk) for legacy OS support. Once
the Boot Loader library and the tools needed to create a good OpenBIOS boot
EEPROM are working, efforts can be expanded to creating an open BIOS clone
for legacy OS support (assuming there is still demand for such a thing).
There is a good chance that M$ would make future versions of Windows
(when/if they abandon legacy DOS support) boot without a BIOS if the open
BIOS boot loader works well enough. Everyone wants to save a buck and if a
BIOS is not needed, I am sure the motherboard makers will be happy to ditch
it in favor of a smaller, free, OpenBIOS boot PROM. In the end there may no
longer be a need for the BIOS as we know it.
Then again we could take the path to create a new and improved BIOS model
that would be good enough to actually be used by modern OS's and
motherboard makers. But for that to happen we would have to gain some
credibility in the greater world by producing something that works and is
widely accepted.
Creating a library of boot code (and a system for managing and configuring
it for various hardware platforms) will be a significant challenge given
the number of possible motherboards and boot devices there are out there. I
propose that OpenBIOS boot code would be a good first step goal for a
modular open BIOS project.
Thoughts, comments?
Dave
PS.
A couple of you have mentioned Open Boot. Where can I find out more about
it? Is Open Boot open as in open source or open as in marketing-buzzword
"open". Could this be used as the boot loader part of the project? Is it
something that we could build on?
20 years
- 10
- 14
what we need
by Karl Oehling
>>> But every
>>> time I come up with some suggestion, atleast a couple of
people will
>>> point of how wrong I am, and the result is that we stand still. I
find
>>> this very frustration, since I feel that we should act now so we
can
>>> have working BIOS in half a year or so. No one will be happy
by us
>>> sitting here arguing without reaching anywhere.
>Hello,
> Umm, I personally don't really know much about what's involved
> in writing a BIOS, so I can't really contribute on the initial
> design and requirements generation ( I am opionless ). However,
> if someone would like to point me in a direction, I would love
> to start writing some code.
>Regards,
>Jim
I've just recently gotten on this mailing list, but it appears we have
a startup problem. The tools necessary to write and test code for
the BIOS seem to be lacking. Or maybe we have the tools but we
don't know how to utilize them properly. Suggestions are great, but
as my grandfather use to say, "don't tell me what you're gunna do,
tell me what you tried so far." Well, I for one can't try something. I
don't know step one. I have tools here, eeprom burners, variable
power supplies, and other neat lab stuff. How do I use this stuff (all
the way back at step one: plug in power supply) so we can "get
some product out the door"? Is there anyone on the mailing list
that can tell us what to do?
Karl Oehling
==================================
"A king is not always a bad idea"
==================================
20 years
- 1
- 0
Re: Boot Loader
by Eric R. Kern
> > >Is the intention to have much of the BIOS code
> > >on the hard drive with only the
> > >minimal amount of code on the EEPROM?
> >
> > That is what I was thinking. I think this approach makes it much
easier to
> > modify, update and experiment with the BIOS.
> What if you don't have a hard drive? I don't like this approach.
Another approach that could be used is to have a boot block sector of
code. For those of you who have not programmed BIOS before I'll
explain...
Most PCs shipping today come with boot block code in the EEPROM. A
jumper (or switch) on the board is used to toggle between a boot block
boot and a normal boot. Often this jumper is connected to a GPIO.
Initial BIOS code reads the value of this GPIO and runs the appropriate
code. The boot block code brings up the bare minimum amount of hardware
in order to read a BIOS image off the floppy drive (memory and floppy).
Once this image has been read into memory, the computer reruns the BIOS
code using the image in memory to load the F000 and E000 segments (where
BIOS code usually is run from) rather then the EEPROM. This is quite
useful for testing BIOS code without modifying the code on the EEPROM.
A normal boot, however, would use the code from the EEPROM. By
containing all of our BIOS code in the EEPROM, we allow an end user the
use a system that does not have a hard drive (Net PC ring a bell?).
Remember that we can compress most of the code on the EEPROM (with only
the decompression algorithm and memory bring up code not compressed).
This provides for plenty of code space, especially when you consider
that modern EEPROMs shipping with systems are typically 512K bytes.
Eric R. Kern
20 years, 1 month
- 5
- 5
ROM Space
by Eric R. Kern
> > > This provides for plenty of code space, especially when you
consider
> > > that modern EEPROMs shipping with systems are typically 512K
bytes.
> >
> > Sure? Does anyone have sort of a "table" showing which typical
motherboard
> > has which EEPROMs and its size?
> >
> > I always thought of having only 128 kB of EEPROM memory. Well, if
this
> > would be 256 kB or even 512 kB (and, as you said, think of
compression),
> > then there would be no real need to have any code on the hard disk,
I
> > mean, to complete the BIOS code.
> >
> > Well, this size ... could contain a miniature Linux kernel plus some
> > applications to boot that system... oh, just a thought.
>
> At 512k you could get a complete Linux Kernel in it....
The current line of IBM PC300s all have 512K bytes of ROM space. Now,
if you are talking about supporting 486 systems then those will probably
only have 128K bytes of ROM space. There will not be a table, but a
general rule of thumb (which probably breaks down in many cases) is that
the pentiums have 256K and the pentium IIs have 512K bytes of ROM space.
As far as putting a complete Linux Kernal in the 512K byte part - you
may be able to do that if you get rid of many of the new BIOS features
(such as booting to CD ROM, LS 120, ZIP). You could also pull out the
setup screen and maybe put that on a floppy or hard drive (that's the
screen that is used to tweak various BIOS parameters).
If you are not worried about getting a Microsoft logo then you could
pull out alot more (but Windows won't work).
20 years, 1 month
- 1
- 0
Modularity
by Ed Brinker
I realized just after sending the last message that the problem of loadable
vs. nonloadable is not so difficult.
Just define each BIOS module with a series of attributes
module=(attribute1,attribute2,.....)
module would be hard drive, terminal, ....
attribute 1 would be none, generic or type
attribute 2 would be fixed or loadable
defining the hard drive as
hard drive=(generic,fixed) would tell the BIOS maker to use the one size
fits all BIOS hard drive driver and it would be placed in the ROM.
hard drive=(none,fixed) means that no hard drive is present No driver will
ever be required.
hard drive=(none,loadable) means do not put a HD driver in the PROM but
reserve space for one in shadow ram. It may be loaded later
hard drive=(Promise4030,fixed) means to put a Promise 4030 unique driver
into the ROM and it will not be replaced at run time.
other attributes would indicate special conditions or executions such as
POST (power on self test)
ie.
video=(generic,fixed,post=generic)
or
video=(trident9680,fixed,post=none)
Other parameters could be defined such as terminal= where terminal would
be the system control device (not the display terminal)
For example
terminal=(com1,com1) would mean that a serial device is connected to com
port 1 and that will be used as the primary input/output device.
terminal=(keyboard,vidio) would generate the customary PC interface.
20 years, 1 month
- 1
- 0
Further modularization ideas
by Dave
Here are some ideas as to how a boot PROM might be modularized:
Code Actions
----------------------------------------------------------------------------
---
Boot_commander Reads boot table and calls each boot function (1)
Init_CPU Initialize CPU (2)
Init_Cset Initialize Chip set (2)
Init_MMU Initialize Memory management system (2)
Init_BUS Initialize BUS controller (2)
Init_Display Initialize VGA (2)(3)
Init_Kbd Initialize Keyboard (2)(3)
Init_Console Initialize alternate console device (3)
Init_BootDev0 Initialize First boot device (2)(4)
. Initialize other boot devices (2)(4)
.
Ident Identify the boot prom (5)
Prompt Prompt user (6)
Read Read boot record from boot device (7)
Validate Expand boot record, validate and store into memory (8)
Execute Execute the validated executable (9)
Notes:
1) A simple executor that reads a table of addresses and executes
each program, one at a time. The table would be created by the
make file (or other utility) that links the pieces of code into
the single file burned into the PROM.
- Executor could (optionally) be responsible for initializing
an alarm card, watchdog timer or other failure detection
and notification device (for use in un-manned situations).
2) Perform minimal diagnostic, report error codes to POST address
then initialize the device.
- Maybe the first digit of the post code would show the step in the
boot process (first entry in the boot table is 1, second entry
is 2 etc)? Maybe the second should be specific to the code
running at the time??
- Maybe the POST address should be expanded to multiple
bytes for more detail? Problems with other hardware???
3) If no display device is present, default to using an alternate
device as console. This would be very useful for blind nodes
and embedded systems. A simple version of this would be to
use the serial port. I could see future versions using the IRDA
port or another communication device.
4) Check for and initialize each of the possible boot devices.
A simple system may only have one boot device, a more complex
system may have many.
5) The "ident" code makes a call to each of the other
blocks of code (listed in the boot commanders table), for
the purpose of allowing them to identify themselves,
their state and revision numbers.
6) The prompt code interacts with the user to
select the boot device (or use the default boot sequence
to pick the first avalable boot device if no response),
get a username/password or other validation id.
7) Read boot record from boot device. Maybe use the password or other
validation id to authenticate the users access to the boot device?
8) Expand the boot record into an executable. Maybe use the password
or other validation id to decrypt and expand the boot record??
9) After the boot record is expanded into memory, execute it. I suggest
this as a separate step purely for instinctive reasons. I don't
know exactly what else should be done here, maybe some cleanup?
Maybe just update the POST register?? Probably other ideas in the
future will make it a good idea to separate the execution from
expansion of the code.
I am probably missing some things. Let me know if you see something that is
missing or doesn't make sense.
Idea/question -
Can all code be limited to using relative addressing so no linking is
necessary? Is this possible/reasonable? It would be nice to be able to
create a boot ROM by simply selecting blocks of code and listing the
starting address for each block in the executors table, no make files,
assembly, compiling or linking required.
This would be a very desirable feature. A boot prom could be assembled with
a very simple utility in any computing environment (maybe even written in
Java for portability). You would not need to have specific compilers,
assemblers or other development tools to assemble a collection of code,
create a binary and burn it into PROM.
Thoughts....Comments?
Dave
20 years, 1 month
- 2
- 1
Re: Further modularization ideas
by Dave
At 12:54 PM 2/10/99 +0200, you wrote:
>>Idea/question -
>>Can all code be limited to using relative addressing so no linking is
>>necessary?
>
>Why not to use linking ?
I was thinking that it would be easier to create the configuration too and
have it work on any platform if all it had to do was collect and tabulate
binaries, and convert them to a hex file. If you assume that you are
creating a boot prom for a system that has none, it would be nice if you
could use whatever other systems you do have (M$-win, Mac, Linux, HP, Sun,
whatever) as your boot-prom development system. I think that creating a
working linker and collecting the correct libraries and other resources
etc. would be much more complex task for the developers and certainly
harder to get working for the persons who are trying to create custom boot
PROMs.
>Probably you will need at least one specific tool to burn new image into
>PROM.
Thats pretty much what I was thinking. But I was thinking that having the
tool only responsible for interacting with the user, collecting and
tabulating a set of binaries and then converting them to a single HEX file,
would be much simpler than creating a linker. Of course I may be thinking
of this wrong since I have never written a linker and would not know where
to begin if I had to :)
Dave
20 years, 1 month
- 1
- 0
Fw: Re: Further modularization ideas
by Victor Kirhenshtein
Oops, of course I want to send this to list...
Regards,
Victor
-----Original Message-----
From: Victor Kirhenshtein <victor(a)opticom.lv>
To: Dave <DGMDGM(a)iname.com>
Date: Wednesday, February 10, 1999 12:54 PM
Subject: Re: Further modularization ideas
>Idea/question -
>
>Can all code be limited to using relative addressing so no linking is
>necessary? Is this possible/reasonable? It would be nice to be able to
>create a boot ROM by simply selecting blocks of code and listing the
>starting address for each block in the executors table, no make files,
>assembly, compiling or linking required.
Why not to use linking ? OpenBIOS can come as set of object files and
special configuration tool, which creates a subset of necessary object files
and use linker to produce complete rom image from them. Such process must
not be too complicated.
>
>This would be a very desirable feature. A boot prom could be assembled with
>a very simple utility in any computing environment (maybe even written in
>Java for portability). You would not need to have specific compilers,
>assemblers or other development tools to assemble a collection of code,
>create a binary and burn it into PROM.
Probably you will need at least one specific tool to burn new image into
PROM.
Regards,
Victor
20 years, 1 month
- 1
- 0
NVRAM variables
by Victor Kirhenshtein
An idea on NVRAM layout: maybe it will be useful to create special NVRAM
layout file which describes names, types, and location of all NVRAM
variables. Such file may look like this:
var1 0x08 word ; Variable named 'var1' at offset 0x08 in nvram of type
'word'
var2 0x1F byte ;
etc.
At BIOS build time, this file can be compiled into special structure in BIOS
code, and at run time all NVRAM variables could be accesible by it's names
via special nvram access functions. Then, if you need to change NVRAM
layout for some reasons, you need to change only layout file, no need to
make changes in code or even to recompile it.
Any comments/flames/etc. ?
Regards,
Victor
20 years, 1 month
- 1
- 0