OpenBIOS February 1998

openbios@openbios.org

33 participants
63 discussions

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

19 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 19 Feb '98

19 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 19 Feb '98

19 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 19 Feb '98

19 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 19 Feb '98

19 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 19 Feb '98

19 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 19 Feb '98

19 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

Re: [OpenBIOS] comments and ideas
by Stephane Boyer 19 Feb '98

19 Feb '98

===================================================================== sboyer(a)smegheads.montreal.qc.ca Tel: (514)-457-6124 root(a)smegheads.montreal.qc.ca Stephane Boyer L I N U X 691 Surrey ------------------------------- Baie d'Urfe, Quebec the choice of a GNU generation. CANADA H9X-2E8 On Thu, 19 Feb 1998, Pavel Machek wrote: > Hi! > > > what is really needed, is a a true 32bit bios for people that single > > boot > > Linux. this bios should boot directly into protected mode (this way it can > > load uncompressed kernels). > > Why is it needed? Linux can live with current bioses. There's no need > for 32bios. Linux can do that things itself. What is needed is 16bit > bios. > 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. Steph! --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] serial console
by Markus Kaufmann 19 Feb '98

19 Feb '98

Hi. At 04:29 19.02.98 -0800, Dean Gaudet wrote: >If you haven't done it before, try administrating a sun box over serial. >Enjoy the ability to halt and reboot the system, to upgrade the kernel >without fear, to even reinstall the system completely without being at the >physical console. There are many servers from Sun and HP (and others) where the serial port IS the console. When i got my HP server, i tried to connect my VGA screen to it, but i couldn't find the port. I looked closer and realized the small label at the serial port "COM1/console" . These HP servers (and workstations) are able to boot from harddisk, network, CDROM and tape (DAT). I don't know, if they are able to boot from floppy (probably not, since they haven't one). Bye Markus Kaufmann --- 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 19 Feb '98

19 Feb '98

On Thu, 19 Feb 1998, Benjamin Scott wrote: > Dean Gaudet wrote: > > The best idea I've ever heard for a serial console on a PC is an ISA video > > card that behaves like text-mode VGA only, > > While it would be a good idea, it has two problems: Cost and kludge. > Such a thing is going to cost a good amount of bucks, being so rare, and > it really is a kludge to support weirdness on IBM-PCs. rare? Every PC in use at any ISP that has any sense could use one of these. Consider the current situation -- in order to have a farm of machines you need to use expensive video/keyboard multiplexing devices or deal with the pain of switching cables all the time. Plus you have no remote administration of your machines -- telnet doesn't count, it's only useful when the system is in multiuser mode. > > Remember that ISA/PCI cards have bioses on them, and those bioses expect > > to play with a video card. > > I have seen a system boot headless (no video at all), but yes, most > software and some hardware expects to be able to play with video > memory. booting isn't what it's all about. What if during the boot your scsi card gave you a diagnostic? It'd sure be nice to see the diagnostic. > One solution is to just not use (or fix) such > hardware/software. Good luck. > Another is a software version of your above serial > console card. Hardware and software doesn't really want to talk to a > video card, just be able to write directly to video memory (and maybe > play with a couple of video registers). I am fairly sure we can create > a region of "video memory" from the BIOS for such stuff. We could then > either attempt to convert it to serial, or just ignore it, depending on > specific needs. The video registers I'm not sure about; can we hack > together an emulator for them using just BIOS code, or do we need actual > hardware? Won't work. Your VGA emulation needs to react to reads and writes. You "can't" do that -- ok I lie. If you build your system so that it goes into protected mode, and then do a v86 emulation to totally fake out the bios then you can do it. But you still won't be as solid as a hardware card. > > Plus you've got a more reliable method of generating an NMI/reboot which > > you'll absolutely need. > > Why? Without reboot control remote administration is useless. The serial ports on a PC have no way of generating an NMI (or an SMI), so you have no way of ensuring that the system is recoverable from a kernel failure. If you haven't done it before, try administrating a sun box over serial. Enjoy the ability to halt and reboot the system, to upgrade the kernel without fear, to even reinstall the system completely without being at the physical console. sun's serial ports and boot prom are designed to be able to control the system -- a break will send the equivalent of an NMI and bop you into the prom, from anywhere. PCs do not have this luxury. Granted there are probably some easy hardware hacks that would let you trigger an NMI (or better yet, an SMI) in response to a serial event. Dean --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0