OpenBIOS

openbios@openbios.org

4297 discussions

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)
by David Woodhouse 21 Feb '98

21 Feb '98

hawk(a)ttlc.net said: > > Could someone please tell me where protected-mode code will be > useful in the BIOS firmware? Initial memory and other hardware checks, and then some of the INT 15h functions for copying memory around above 1Mb. Oh, and of course the BIOS function to switch into protected-mode :) Also PCI and APM BIOS32 functions. Other than that, I don't see any point in extra protected-mode functionality - as you rightly say, anything running in protected mode is going to have its own drivers already. > I believe the single most important goal of this effort should be > modular design. If we make the design modular, most everyone can be > happy. Agreed. Most of the things we've been talking about recently have been proposed extensions which would be separate modules, so those who don't see the point don't have to use them. We have very little dispute about the core of the project, other than the fact that we're not entirely happy about LPGL but it seems to be the best option so far suggested. Regarding the module support: We can either link them at flash time, or have the BIOS search through the available modules when it boots. I prefer the latter, because it doesn't involve any intelligence on the part of the linker, and the extra headers required won't take up a significant amount of space Each module object needs a header, much like the existing BIOS extensions have. In it we need to store: length, checksum, entry point. We could also do with a flag indicating the invokation order, and whether it needs to remain in memory when it's done (for when we've uncompressed into RAM). For example, a chipset optimisation module would be loaded early, and not remain in memory. An IDE disk driver providing INT 13h functions could be loaded later, and will remain in memory. A boot loader will be loaded last. The power-up vector will point to a routine which does an inventory of the available modules, and invokes them in the correct order, uncompressing them from flash into RAM as required. This boot loader will provide certain basic functions for reading data from the CMOS and other things that a number of other modules will require. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] More comments and a proposal for priorities
by John Labovitz 20 Feb '98

20 Feb '98

Markus Kaufmann <kaufmann(a)pks-software.de> said: > A BIOS isn't something that you change daily like the newest > developer kernel. Once you have a perfect BIOS, you should never > change it. to interject a philosophical point here: this is why we're doing an *open* BIOS project -- to rid ourselves of the accepted myth that Thou Shalt Never Change The BIOS (unless the manufacturer tells you to, via an upgrade). yes, we should make it clear that BIOS changes are dangerous and could result in a nonbooting system, but that doesn't mean that someone who got some fancy new file system, device, etc., shouldn't be able to boot directly off it once the BIOS extension is available and installed. however, i do agree with the general point of not cluttering up the new BIOS (and our time devoted to this project) with too many features; things like grub-in-bios should definitely be considered options that are worked on in parallel or sequential to the core code, and compiled/linked in optionally by the user or distribution. john --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] More comments and a proposal for priorities
by Markus Kaufmann 20 Feb '98

20 Feb '98

Hi, At 17:05 20.02.98 +0530, Arjun Roychowdhury wrote: >I feel that while writing a BIOS, we must provide a small set >of very poweful operations instead of bloatingt the BIOS to include >one & all. I am strongly for adding prot-mode code, but only when >necessary. wheras prot. mode code will add extra bytes in size, >the advantages are obvious. However, IMHO, one should not just >rewrite the entire BIOS using prot. mode. Real mode code does >have its advantages, esp. in areas where mem. consumption is >not so critical. The real mode vs. prot. mode: If you want to support DOS, you have to rewrite the normal BIOS in real mode. Any protected mode extensions can't use these functions and have to reimplement them. If you wan't to boot from protected mode, you need your own SCSI-drivers, small VGA-Drivers and so on. Bye Markus Kaufmann --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

We have a testbed and initial code to work from - if we want it.
by David Woodhouse 20 Feb '98

20 Feb '98

Because the license of Bochs only permits using it "for the use it was intended", I've asked the author for permission to use it for testing our BIOS, and he's agreed. Furthermore, he's given us permission to do as we like with the BIOS implementation that he included with it, as a starting point for our project. I've put his rombios.c up for anonymous FTP at dwmw2.robinson.cam.ac.uk in /pub/bios, along with the Bochs distribution code. ------- Forwarded Message From: bochs(a)world.std.com (Kevin P Lawton) Subject: Re: Using Bochs for testing new BIOS code. To: Dave(a)imladris.demon.co.uk (David Woodhouse) Date: Thu, 19 Feb 1998 21:59:06 -0500 (EST) Dave, Yeah sure. Go ahead and use Bochs for this purpose. It'll be good for both of us, in that you may find hardware emulation inconsistencies etc, and give feedback. I'm not very attached to the BIOS I wrote. There was a big need for one, so I wrote it. I used 'bcc', the only freeware compiler that I could find at the time to generate 16bit-only code. I'd be interested in knowing what your tools of choice end up being. The BIOS is certainly not written in the best style (the interface between ASM & C I'd like to have different etc), but it's somewhere to start. Feel free to copy whatever BIOS source you need. I'd like to see a good freeware BIOS, and will be certain to use it with Bochs, if it turns out well. It would be nice to use a BIOS which has been tested on real hardware. This way I could shape up my hardware emulation. Keep in mind, I had no concern for timing of IO port accesses. You won't see any waiting in between IO accesses, since in emulated world you don't have to worry about how fast the IO device can handle this. Best of luck to you. - -Kevin Lawton Bochs Software Company > Hi Kevin, > > I'd like to ask your permission to use Bochs for testing purposes in the > development of OpenBIOS (http://www.linkscape.net/openbios/) > > OpenBIOS is a very new project, the aim of which is to provide an efficient > modular BIOS replacement for Intel PCs, with functionality such as serial > console support, proper chipset optimisation, RAID, etc. The list of ideas has > been vast, and with a proper modular design the end-user should be able to pick > and choose the modules he wants for his system. > > The project is probably going to be released under LGPL, allowing hardware > manufacturers to produce proprietary binary modules to support esoteric > hardware, while still retaining the freedom of the GPL on the majority of the > code. > > Naturally, the idea of blowing a piece of code we've just written into the > precious flash ROM of our PC and rebooting tends to frighten us somewhat, so > we'd like to use Bochs for emulating the PC environment in which our BIOS will > live. > This we would achieve by replacing the binary BIOS image used by Bochs with > our own work. > > As I sincerely doubt that this comes under the category of using Bochs "for the > use it was intended", I'd like, on behalf of the development team, to ask for > your permission to do so. > > Furthermore, (pushing our luck a little further :) ), if you would permit us > to use sections of your own BIOS code from bios/rombios.c as a starting point, > it would be very much appreciated. > > We would not envisage using significant amounts of your code in the final > release, but it would provide a very useful base to work from, on a project > that is so far only vapourware (although we've only been at it for less than a > week, so that's excusable) > > Thankyou for your time. > > Dave. ------- End of Forwarded Message ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

General comments
by Benjamin Scott 20 Feb '98

20 Feb '98

Hello all, Okay, a friend of mine got me so interested in this that I had to sign up. And, having signed up, I of course have to put my two-bits worth in. It's an Internet tradition! :) In regards to some stuff on the OpenBIOS homepage (OB being quotes from the homepage).... OB> Sun-like bootconsole I think this is one of the coolest aspects of this project. I've always liked things like DEC's SRM console for hardware-level control. They give you a lot of power and control and don't get in your way. For our purposes, they are also simpler to program, easy to extend for new features (just add commands and/or variables), and typically use less memory then full-screen menus. They also work on serial consoles. OB> Remote administration (?) I think I might have a better idea: Make the BIOS data structures available via a standard interface to the OS, allowing query and set. This is a good idea anyway (makes system administration easier), and lets the OS handle all the network transport and management protocol stuff. I don't really see any need to have the BIOS support it directly. Why complicate things needlessly? (Of course, if there is a legitimate need for this, by all means, let's do it). Would be nice if you could return to the BIOS UI from the OS via function call or hardware (like the HALT switch on DEC systems). I suppose you might even be able to return control to the OS, if you didn't make any intrusive changes, but I dunno if that would be useful. OB> no Unneccessary hardware detection that makes startup slow OB> no 16bit Code OB> no MSDos Filesystem code While I agree that we should dump anything that is around simply because it was there first, let's not fall into the trap of getting so hooked on redesigning things we forget reality. For one, any x86 CPU starts in real mode, so you'll need at least a 16-bit stub to init protected mode. Some expansion cards that provide BIOS extensions don't work well in protected mode (older stuff, true, but Linux has always been good on that front). Real-mode code is sometimes simpler or smaller then protected-mode, too. Likewise, DOS FAT has two advantages: It's simple (easier to support) and nearly universal (almost everything supports it). I guess my main point is, we should try to avoid arbitrarily declaring what "Must" and "Must Not" be. Make the code design as modular as possible, and you can include whatever you want. Developers will support what they know or need. Users can choose what they want and like. This mirrors the design of the Linux kernel itself, and I think it is a very good design policy to follow. Chris Arguin (chris.arguin(a)unh.edu) posted a suggestion for a source code tree. If I may be so bold to make some suggestions/changes: ui/ <- user-interface and UI extensions cli/ <- command-line interface fsm/ <- full-screen menu mouse/ <- mouse support (maybe?) gui/ <- GUI (if we get really bored :) drivers/ <- device drivers for boot and BIOS function support ide/ scsi/ <- how do we tie this in with SCSI cards that have their own INT13 BIOS? write our own drivers for the SCSI chipset? usb/ <- can USB support boot devices? net/ <- network cards (for BOOTP) init/ <- handles system initialization and the like boot/ <- OS boot stuff (standard MBR, Linux kernel, BOOTP) std/ <- standard BIOS call implementation (like good ole INT13) ext/ <- OpenBIOS extensions (dunno what they are yet, tho :) misc/ <- the ever-popular "other" category Comments, suggestions, flames, etc? -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 2

Re: [OpenBIOS] Licensing of the code.
by David Woodhouse 20 Feb '98

20 Feb '98

Dean Gaudet wrote: > > I think a big sticking point will be the license Intel requires for the > microcode update software. That license may dictate the license you'll > have to use for this project. In fact that license may even preclude a > free software project. > > Without the microcode updates you may have a hard time supporting intel > chips. What's the license? The procedure is documented in the "Pentium Pro Processor BIOS Writer's Guide" at ftp://ftp.intel.com/pub/IAL/p6/pppbios.pdf (Chapter 8) It's also available at http://www.sandpile.org/80x86/mcupdate.shtml I can see no mention of a restrictive license on the algorithms presented. Or did you mean the actual microcode update, as opposed to the code which loads it into the CPU? ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] serial console
by Dean Gaudet 20 Feb '98

20 Feb '98

On Thu, 19 Feb 1998, Benjamin Scott wrote: > Oh, I agree the need for a serial console in some for exists. But > consider: Such server farms are pretty much going to be running either > some flavor of Windows, some flavor of Unix, or Novell Netware. Windows > is out, as it *requires* GUI. Unix (Linux and BSD) should be able to > use a serial console without any sort of goofy video emulation > hardware. That leaves Netware as the only benificiary of such a > hardware-based product, and I can't say I see a big demand for it. :-) No, the linux serial console requires linux to be running. I want a serial console the most when the operating system *isn't* running. > I covered the software above. Do we actually know how much hardware > writes directly to video memory? I know of some stuff that uses BIOS > calls for the very reason of compatability; BIOS is guarenteed to be > there. If your SCSI card's (or whatever) BIOS is well-behaved, it isn't > a problem. Grab a buslogic or adaptec scsi card and watch them put up full screen menus from their bios. > While you can't respond *directly* to such activity, you could run a > timer loop that checks the video memory emulation region for changes > periodically and refreshes the VT screen every so often. Good old DOS > DOORWAY did something very like that. And you would only need to do > this if you have hardware that ignores BIOS and writes directly to > memory. It's trivial to map the display itself, yes. But what you can't do this way is react to vga register writes. There's nothing critical about using vga though, the card could emulate hercules. > Much cheaper, though. :) But doesn't solve the problem. It's not reliable, so you can't really trust it to pull you out of critical situations. > The RESET button works for me. :) Now, if you don't want to go over > and press the button on the system, then yes, things are more > difficult. Your serial-console card could include a remote way to reset > the machine. The BIOS alone can't do that. But I think it would be > cheaper to run a long length of twin-lead wire to the reset-switch > connector on the mainboard then design and manufacture a whole new > hardware product. :-) What if the system is 60? 100? 600? 1000? miles away from you? > Yes, Sun has many advantages over the PC. As does SGI, DEC, HP, and > the like. The primary advantage of the PC has always been *cost*. And > special hardware defeats that goal. :-) Not really. In truth you could do most of what I've suggested so far with a UART, and some lead that lets you trigger SMI. If you can get yourself into SMM then you don't need to have anything special on the card. Once in SMM the bios has complete control of the system... which leads to software solutions. That gets you remote console for reboots, and for unix once its booted. But it still doesn't get you support for scsi cards which do direct screen writes. Dean --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] Licensing of the code.
by David Woodhouse 20 Feb '98

20 Feb '98

I said: >I believe that we could use the LGPL for this. dcinege(a)fuckthejunkmailers.org said: > The problem comes in if they have to directly modify any of our > libraries. Since this is so low-level it may be impossible to work > around them in some situations. Then let them produce their own copy of the offending module - they're going to be fairly small modules anyway, so it shouldn't be too much of a hardship. I appreciate that's not particularly ideal, but I suspect it might be the best we can do. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 4

Development environment, testing, sample code...
by David Woodhouse 20 Feb '98

20 Feb '98

I suggest that we use dev86 for our development environment. It includes a C compiler capable of generating both real mode and protected mode code, along with libraries for each and binutils, amongst other toys. Its output formats include Linux OMAGIC, ELKS, DOS .COM (small or tiny model), and - this is the important one - standalone code. It has libraries suitable for each target. It can be found at http://www.linux.org.uk/ELKS-Home/dev14.html I've also been investigating testing possibilities - Dosemu and Bochs seem to be the main contenders. Of these, Bochs does a more complete emulation of the hardware. So much so, in fact, that it can even run Win95 in an X window, albeit slowly. In general, the BIOS in Dosemu does callbacks into the Dosemu code, while the Bochs BIOS code actually tries to manipulate the hardware, letting the Bochs host code trap and emulate the actual IO accesses. This means that we'd be better off testing our BIOS code under Bochs. Bochs is available at http://world.std.com/~bochs Remember, though: > The general registration fee for BOCHS is $25 per workstation, PC, or > X-terminal, and should be paid by check in U.S. funds to: > > Kevin Lawton > Bochs Software Company > 528 Lexington St. > Waltham, MA 02154 Both Bochs and Dosemu have BIOS code which we can learn from, but can't copy. Bochs is commercial, and Dosemu GPL. Neither can be used if we intend to release OpenBIOS under LGPL. The interesting bits are: bochs-980124/bios/rombios.c and dosemu-0.97.3/src/base/bios/bios.S ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] comments and ideas
by David Woodhouse 20 Feb '98

20 Feb '98

dcinege(a)fuckthejunkmailers.org said: > Stephane Boyer wrote: > > we already have a 16bit bios! and they work well enough. if you dual-boot > > dos/Linux , fine stay with a 16bit bios, but if you only use Linux, > > wouldn't you want a bios that was specificaly made for it. > No. I have several linux servers here. Durign the rarity that they > reboot I could care less about the BIOS. > On my own workstation I have DOS, NT, 2 installs of OS/2, and Linux. > That's where I need the flexablity of a new BIOS (with boot loading > features, etc) Agreed. We should (IMnsHO) concentrate on getting the normal BIOS up and running before adding the esoteric new features - we want to change one thing at a time. Getting it to work at all is going to be complex enough, without changing the kernel boot procedure at the same time. Clean 32-bit boot functions are a reasonable goal, but we need the basics first, and we need to formulate a proper specification for the 32-bit interface before we even think about implementing it. Let's leave it till later, and try to design something that other OS's will consider using. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Jump to page: