February 1999 - OpenBIOS - mail.coreboot.org

Making a BIOS on my own...
by Niklas Ekström March 8, 1999

March 8, 1999

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

3 2

Clarification....
by Dave March 8, 1999

March 8, 1999

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?

10 14

what we need
by Karl Oehling Feb. 26, 1999

Feb. 26, 1999

>>> 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" ==================================

1 0

Re: Boot Loader
by Eric R. Kern Feb. 12, 1999

Feb. 12, 1999

> > >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

5 5

ROM Space
by Eric R. Kern Feb. 12, 1999

Feb. 12, 1999

> > > 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).

1 0

Modularity
by Ed Brinker Feb. 10, 1999

Feb. 10, 1999

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.

1 0

Further modularization ideas
by Dave Feb. 10, 1999

Feb. 10, 1999

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

2 1

Re: Further modularization ideas
by Dave Feb. 10, 1999

Feb. 10, 1999

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

1 0

Fw: Re: Further modularization ideas
by Victor Kirhenshtein Feb. 10, 1999

Feb. 10, 1999

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

1 0

NVRAM variables
by Victor Kirhenshtein Feb. 10, 1999

Feb. 10, 1999

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

1 0