M Carling wrote:
Welcome!
I'm the FAQ maintainer, so I'll try to answer your questions.
OpenBIOS is envisioned to serve the needs of MB manufacturers, hobbyists, and embedded systems developers.
Great... :)
There is no list archive yet, AFAIK. This is something we need to do.
O.K., I'll keep every message on my computer, it seems from the low traffic that my 10GB disk won't be filled right away ;) and I'll try to setup a digest and an archive. BTW. feel free to forward me any relevant old message.
The guidelines are still flexible. About the only thing on which there seems to be a clear consensus (that had been controversial) is that OpenBIOS should support (as a compile time option) multiple chipsets in a single executable. This would enable MB manufacturers to compile one BIOS image for all their products.
And now the BIGGEST question: what will that BIOS be, a resource configurator and OS loader and nothing after boot, or it will offer some services to be used after boot, if so what services and how? I think that is the fundamental part of the design guidelines. Related: are those guidelines somewere in a written format, is about the IEEE 1275 ummm.... thing ?????? As for multi-chipset, multi-processor support I think is a good thing and Award's approach with a BIOS boot block who probe and then decompress and load in the shadow memory the relevant module archives stored in ROM is the best, of course YMHO. But somehow I don't thing that the resultant image will be small enogh to be hold in a 128KB Flash like now, I belive this mostly irellevant for Main Boards manufacturers but a BIG deal for embedded systems, of course somebody could want to compile in only the necessary modules.
There is no subproject leader for embedded systems, at this time.
Then to put in another way, is anybody on this list doing embedded BIOS/systems now ??? Please answer here or e-mail me so we can figure out somethig because unfortunately in a embedded system we have a totally different thingie like no "simple" OS loader, maybe even no OS at all, but just a highly optimised API framework and yes I know that somewere is a grossly over-priced Embedded DOS but I don't thing this is a solution. Sugestions and comment wellcome :).
The leader is Stefan Reinauer stepan@linux.de
I don't have any docs on the boards you asked about.
All right, I'll cry just once more: :)
PLEAZZ, pleazz, if some one has access at ALI chips ( mostly ALI 6117C and super I/O) detailed documentation get in touch with me, is important for me and maybe for the Open Source movement.
Cheers, M
All the best, Mircea C.
Hi!
Well, the message is important (from my point of view), but I hope you will receive it just once :-)
A few months ago, I was searching for options to building a BIOS for a custom PC: No graphics card, no hard disk, with sound card, network card (well, say: an MP3 player for the HiFi tower). Of course, I wanted to avoid anything I would not need and I wanted to have anything I need to boot up the thing quickly and easily.
As you see, I found the openbios movement, but what I found was, say, nothing but a vision. Neither a concept nor an idea. Just a vision. A vision of building something similar to what we all already have in our PCs. Of course, the idea of reinventing the BIOS-wheel is great and I thought: Hey, finally _we_ have the choice of how the PC boots up, we can work around any hard disk or booting problem by ourselves.
But as far as I can see the intentions grown up to now, we just sit in here and construct a new BIOS after the Phoenix, AMI, Award etc. with the same API (for best compatibility) which means, with the same main booting features. The idea of booting directly from 32 bit mode was fascinating for me, but what's it for if we have to switch back to 16 bit, implement all API calls again just to boot any OS. I thought, the main purpose of a new BIOS would not _only_ be the fact that it is OSS. We would have the opportunity to make something very new, especially concerning the boot process. The idea of putting the remote boot BIOS directly into the system BIOS is great - but what's it for if we don't invent something really new?
Of course, this is a large project, and my ideas make it even larger :-). But, would f.e. Linux be that great if it would have just been a "better DOS", say, an "OSS DOS"? OK, it would be for free, but what for?
OK, back to topic: My idea (better: brain storm) of the boot process is as follows:
1) Processor switches to 32 bit. 32bit only, no compatibility API in the MAIN BIOS. Well, I think after we implemented all in 32bit, there will be not very much space left for such things.
1a) If, somehow, 16bit compatibility is needed, we could easily implement (if one wants to call it that way) a loader for the old BIOS. Well, only if the BIOS behaves "well" and doesn't try to reload parts directly from the EEPROM chip (well, there is shadow RAM etc. and I am not familiar with it anyway). Alternatively, one (of us) could implement a new 16bit API to enable such compatibility mode. Of course, this topic is not yet finished in any way.
2) (1) implies, that we need NEW OS LOADERS FOR EVERY OS running with this BIOS. Of course, 32bit OSS OSes (FreeBSD, Linux) are easy to handle, Win9x with its DOS loader will certainly not run if booted from 32 bit mode (i.e. will neeed option (1a) or others). Windows NT could profit from our ideas, too, but we would need strong support from MS to locate and setup the NT kernel and all its modules and configurations etc. in memory and to boot it correctly. Other OSes would profit, too, because they all have the same problems: 504MB, 8GB, many others, and of course, the other problems with the old, old API16.
3) The API. Two main options: Interrupts (like in API16, DOS, etc.) or Library calls, which would mean that the BIOS would contain something like a mini-Kernel. Great idea, free for discussion and further development...
3a) support for new hardware and, compared to API16, its changed role in boot-up in the API. F.e. Network Cards as (a) Input (remote boot) and (b) Output (total remote control), of course serial ports, USB, firewire ... modularized (f.e. burn-time selectable).
3b) Security API, support for random number devices and security devices to allow security immediately after/at boot up. Eventually strong encryption/authentication, including passphrase etc.
4) fast boot up, quick OS restore supported by BIOS (well, similar to ACPI).
5) primary hardware setup, but no tuning options at boot time (neither in BIOS setup nor applied by the BIOS itself). Setup options only for primary BIOS duties like boot device selection and according parameters.
Well, the main topics from my point of view for now. A very flat point of view, but a beginning, I think.
Winscheichwos, - Matthias
Well, the message is important (from my point of view), but I hope you will receive it just once :-)
Got only one of this one! :)
A few months ago, I was searching for options to building a BIOS for a custom PC: No graphics card, no hard disk, with sound card, network card (well, say: an MP3 player for the HiFi tower). Of course, I wanted to avoid anything I would not need and I wanted to have anything I need to boot up the thing quickly and easily.
A little off topic maybe, but have you seen the cool car MP3-player at http://www.empeg.com ? Looks cool! If you manage to make a working mp3-box, let me know, would be cool to build one myself!
As you see, I found the openbios movement, but what I found was, say, nothing but a vision. Neither a concept nor an idea. Just a vision. A vision of building something similar to what we all already have in our PCs. Of course, the idea of reinventing the BIOS-wheel is great and I thought: Hey, finally _we_ have the choice of how the PC boots up, we can work around any hard disk or booting problem by ourselves.
You mention the 32bit boot loaders, which seem to be a good thing. I think the vision is to make a bios that we can add needed/cool features to later.
But as far as I can see the intentions grown up to now, we just sit in here and construct a new BIOS after the Phoenix, AMI, Award etc. with the same API (for best compatibility) which means, with the same main booting features. The idea of booting directly from 32 bit mode was fascinating for me, but what's it for if we have to switch back to 16 bit, implement all API calls again just to boot any OS. I thought, the main purpose of a new BIOS would not _only_ be the fact that it is OSS. We would have the opportunity to make something very new, especially concerning the boot process. The idea of putting the remote boot BIOS directly into the system BIOS is great - but what's it for if we don't invent something really new?
Of course, this is a large project, and my ideas make it even larger :-). But, would f.e. Linux be that great if it would have just been a "better DOS", say, an "OSS DOS"? OK, it would be for free, but what for?
And we even have FreeDOS! I think we just need a start, and maybe there could be configurable if you want a clean 32bit bios, or you want a bios16-compatible binary. I think that is the big issue here, as I have said before:
Make it configurable! Then the visions and new ideas can be added and used when wanted.
OK, back to topic: My idea (better: brain storm) of the boot process is as follows:
- Processor switches to 32 bit. 32bit only, no compatibility API in the
MAIN BIOS. Well, I think after we implemented all in 32bit, there will be not very much space left for such things.
1a) If, somehow, 16bit compatibility is needed, we could easily implement (if one wants to call it that way) a loader for the old BIOS. Well, only if the BIOS behaves "well" and doesn't try to reload parts directly from the EEPROM chip (well, there is shadow RAM etc. and I am not familiar with it anyway). Alternatively, one (of us) could implement a new 16bit API to enable such compatibility mode. Of course, this topic is not yet finished in any way.
I mentioned this possibility in a mail a while ago. The problem is where should we store this old original bios where it can't be accidentally deleted? I like this idea, and use (2) for loading linux and other OSS oses, and as you say, maybe we could get M$ to help us make win 2k/9x/NT-loaders later.
- (1) implies, that we need NEW OS LOADERS FOR EVERY OS running with this
BIOS. Of course, 32bit OSS OSes (FreeBSD, Linux) are easy to handle, Win9x with its DOS loader will certainly not run if booted from 32 bit mode (i.e. will neeed option (1a) or others). Windows NT could profit from our ideas, too, but we would need strong support from MS to locate and setup the NT kernel and all its modules and configurations etc. in memory and to boot it correctly. Other OSes would profit, too, because they all have the same problems: 504MB, 8GB, many others, and of course, the other problems with the old, old API16.
3a) support for new hardware and, compared to API16, its changed role in boot-up in the API. F.e. Network Cards as (a) Input (remote boot) and (b) Output (total remote control), of course serial ports, USB, firewire ... modularized (f.e. burn-time selectable).
This is things that are new. Would be cool with a totally remote controllable machine with no display adapter/keyboard at all.
3b) Security API, support for random number devices and security devices to allow security immediately after/at boot up. Eventually strong encryption/authentication, including passphrase etc.
Yes, this is definitely something we would want.
- fast boot up, quick OS restore supported by BIOS (well, similar to
ACPI).
Fast boot up is something I would really like. Just turn on the PC, and it's there! :)
Well, the main topics from my point of view for now. A very flat point of view, but a beginning, I think.
I think you mention a lot of things to discuss here. Come on folks, let's here what you think of this!
One thing I would like is a possibility to load bios images from floppy. That would be a nice way to test the image before flashing it and leave the box unusable... Would be really nice during development.
Regards, Karl Erik
-------------------------------------------- Karl Erik Asbjornsen karl_erik.asbjornsen@capgemini.no http://www.samfundet.no/karlea A: 73540248 P: 73837153 M: 90738663
On Wed, 3 Feb 1999 karl-erik.asbjornsen@thomson-csf.no wrote:
Well, the message is important (from my point of view), but I hope you will receive it just once :-)
Got only one of this one! :)
Its becoming a desease to subscribe to Mailinglists and then create a loop by forwarding any message to the subscribed address back to the list (!) :-(
Should be gone now, I think.
A little off topic maybe, but have you seen the cool car MP3-player at http://www.empeg.com ? Looks cool! If you manage to make a working mp3-box, let me know, would be cool to build one myself!
Well, in short, take a look at http://www.mp3.com/hardware/ to view a lot of hardware solutions for mp3. But I want to build one solution of my own with the features _I_ need. Empeg is nice though not like I expect an mp3 player to be like.
Of course, this is a large project, and my ideas make it even larger :-). But, would f.e. Linux be that great if it would have just been a "better DOS", say, an "OSS DOS"? OK, it would be for free, but what for?
And we even have FreeDOS! I think we just need a start, and maybe there could be configurable if you want a clean 32bit bios, or you want a bios16-compatible binary. I think that is the big issue here, as I have said before: Make it configurable!
Of course, why not, anything is configurable. But keep development and compatibility in mind. I mean, to program (and use) a BIOS16, compatible to the stone-aged API in every PC, is a totally other task than to create a BIOS32 with support for a totally new API, new hardware, a new boot process, new boot loaders etc.
See, what I mean? Either FreeDOS to have a free DOS or Linux to have a better operating system. I think we should start the second approach, make a BIOS32 with a new API. Not having to try to be compatible to the old BIOS16 stuff and to have to implement any workaround _they_ implemented long ago.
I mentioned this possibility in a mail a while ago. The problem is where should we store this old original bios where it can't be accidentally deleted? I like this idea, and use (2) for loading linux and other OSS oses, and as you say, maybe we could get M$ to help us make win 2k/9x/NT-loaders later.
I think, it's not the point whether it can be erased somehow, by a virus or such. I think, if BIOS16 loading can be performed by BIOS32, it is the same problem as having your boot sector destroyed.
If you want to climb up a hill, you _first_ buy special material, cables, helmets, etc. While programming BIOS32, we should, of course, implement a back door for the BIOS16 to boot not only from hard disk (as from any other media supported by BIOS32, remote boot etc.), but also to boot from floppy disk (as you suggest later). Well, then the problem of losing the BIOS16 is the same as losing the boot sector of your OS now: Boot from a floppy (or CD-ROM) containing the BIOS16 and fix your problems!
This is things that are new. Would be cool with a totally remote controllable machine with no display adapter/keyboard at all.
Of course, to have it 100%, the OS has to be willing to play our game, too. But the idea of using all modern hardware, as it is intended, ALREADY AT PRE-BOOT TIME would offer a lot of new visions one can not imagine today. Think of the remote boot process today: One needs an additional BIOS usually plugged into your network adapter (if that one has a socket for it), and the protocol used is, frankly, prehistoric. NetBEUI (RPL) or BOOTP, typically without authentication, compression or encryption etc. are the answers to the demand of centralized administration. The door is open for anyone in the net (assuming a non-switched network) to install a RPL or BOOTP (DHCP) server faking anything the client would need to look as usual.
Fast boot up is something I would really like. Just turn on the PC, and it's there! :)
Yes, but it's a "long and winding road" there.
One thing I would like is a possibility to load bios images from floppy. That would be a nice way to test the image before flashing it and leave the box unusable... Would be really nice during development.
See above. A main topic should be the ability to boot BIOS32 from BIOS16 and vice versa. The first for development and for the hardcord folks with a BIOS16 not being able to be booted from BIOS32. The second is for the time when BIOS32 is the better and BIOS16 is only used for booting all those 16bit OSes (DOS, Win9x) sporadically (to demonstrate how it _was_ somewhen or how it not should become any more :-)).
Winschdawos, - Matthias
On Wed, 3 Feb 1999 karl-erik.asbjornsen@thomson-csf.no wrote:
One thing I would like is a possibility to load bios images from floppy. That would be a nice way to test the image before flashing it and leave the box unusable... Would be really nice during development.
I actually made such a tool not long ago. I sent it via email to Stefan Reinauer so that he could put it on the OpenBIOS homepage, but he hasn't replayed yet :/. Anyway, since it's so very small (2.4kB) I can put it on my own homepage for now. It's here: http://niklas.ekstrom.com/LOADBIOS.ZIP
/ Niklas Ekström
-
karl-erik.asbjornsen＠thomson-csf.no -
Matthias Wächter -
Mircea Ciocan -
Niklas Ekström