February 1999 - OpenBIOS - mail.coreboot.org

Join the project ?
by Victor Kirhenshtein Feb. 9, 1999

Feb. 9, 1999

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

3 2

Re: clarifiaction etc.
by karl-erik.asbjornsen＠thomson-csf.no Feb. 9, 1999

Feb. 9, 1999

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

1 0

Discussion
by Niklas Ekström Feb. 7, 1999

Feb. 7, 1999

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

6 6

Tasks
by Joe'l' Mansford Feb. 5, 1999

Feb. 5, 1999

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

1 0

Re: Philosophical question...
by Charles Esson Feb. 5, 1999

Feb. 5, 1999

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

2 1

(no subject)
by Bill Bond Feb. 5, 1999

Feb. 5, 1999

unsubscribe elusive(a)adisfwb.com

1 0

Progress?
by Joe'l' Mansford Feb. 5, 1999

Feb. 5, 1999

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

3 2

Re: Philosophical question...
by alex dinovitser Feb. 4, 1999

Feb. 4, 1999

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

2 1

Philosophical question...
by Dave Feb. 4, 1999

Feb. 4, 1999

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

6 8

Mail list
by Matthew Sullivan Feb. 4, 1999

Feb. 4, 1999

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

1 0