OpenBIOS February 1998

openbios@openbios.org

33 participants
63 discussions

Introduction
by Jim Stewart 04 Mar '98

04 Mar '98

Hello all, I've been lurking on the mailing list for about a week now and I'd like to say hi. I have an interest in Bios code because I've written the Bios for our Flashlite series of controllers and I'm interested in building an embedded Linux machine. As far as contributions go, I can't give you my code, but I do have the source to a PC/XT Bios, written in Masm, that was freely circulated a few years ago. It does work, I've burned it into eproms and booted from it and I've used just a little code from it. It's not very pretty, but if there is any demand, I'll post it for downloading. Concerning Microsoft OS's and Bios, at least in the case of Win95, I have it on pretty good authority that the OS uses *none* of the Bios functions. This is documented in "Unauthorized Windows 95" and confirmed by the VP of engineering at Award Software. What I got from my discussions with him is that the current microsoft philosophy is for the Bios to initialize the hardware and sorta give the os clues as to what's out there and nothing more. Whether this is relevent to your efforts is not real clear yet as I haven't been on the list very long. In any case, I'll be lurking, and if I can be of any help, let me know. Regards, Jim --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

4 3

BIOS UI
by nuke＠bayside.net 01 Mar '98

01 Mar '98

i, for one, would like to state my opinion on the UI of OpenBIOS. i *DO NOT* want a command-line driven one. if i have to RTFM just to do what Award does with three keystrokes (autoconfigure a hard drive), i'll just give it up. something nice could be done with say, arrow keys and highlight bars maybe? i remember the old BBS days at 2400, with everyone trying to draw huge artistic works out of the regular ASCII characters.. maybe the BIOS shouldn't resemble some big elite ANSI, but that sort of interface is nice. and since this is going to specifically *for* the x86 PC, why not let it get interesting? we can use direct video memory access, no problem. earlier today, i saw an Award system doing its POST, but it started as a blank.. *during* the memory test, the whole thing quickly skidded onto the screen. that was pretty cool. i suppose my point is that we shouldn't try and make this thing so scary and esoteric.. true, many of us are unix people, but not everything has to be so dull and cryptic. i think a command-line BIOS is a bad idea, unless it's made *very* simple. _ _ __ __ _ _ _ | / |/ /_ __/ /_____ | Nuke Skyjumper | | / / // / '_/ -_) | "Master of the Farce" | |_ /_/|_/\_,_/_/\_\\__/ _|_ nuke(a)bayside.net _| --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] Summary: Booting the OS
by Joel Klecker 28 Feb '98

28 Feb '98

At 15:41 -0500 1998-02-27, <nuke(a)bayside.net> wrote: >System Commander is a very excellent Text-UI based bootloader, compatible >with damn near everything, written and sold by some company named V-Tech. >Norton Commander is a very excellent Text-UI based file manager by John >Socha released by Symantec Corporation. i recommend use of them both, but >unforunately only one of them has been cloned by the GNU.. i was kind of >hoping OpenBIOS would end up being a GNU-equivalent of System Commander. Have you seen the GRUB bootloader? (maybe it looks similar) I suggest getting the Debian grub sources[1] if you wish to try it on a Linux system (the plain grub sources require booting from a floppy to install grub). I am using that version of grub, and I consider it far superior to lilo. grub has a small first stage which then loads a protected-mode second stage, the second stage presents a nice full screen menu interface, the interface also supports reconfiguring, creating new comfigurations, etc. [1]<ftp://ftp.debian.org/debian/hamm/hamm/source/admin/grub_0.4.orig.tar.gz> and <ftp://ftp.debian.org/debian/hamm/hamm/source/admin/grub_0.4-1.diff.gz> -- Joel "Espy" Klecker Debian GNU/Linux Developer <mailto:jk@espy.org> <http://espy.org/> <ftp://ftp.espy.org/pub> God shows his contempt for wealth by the kind of person He selects to receive it. -- Austin O'Malley (1858-1952) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Summary: Booting the OS
by Florian Wunderlich 28 Feb '98

28 Feb '98

Here's the summary of our discussion about booting the OS and how it is done in the minicomputer world. This is not about integrating a new HAL into the BIOS; its just about how the BIOS should load and execute an OS from disk/net/... . - The "unintellingent" approach: c/h/s et al David Kennedy <dkennedy(a)engsoc.carleton.ca>, said that he boots his Next with the following command: bsd(0,0,0) [kernelname] but made not clear what "kernelname" means (passed to a secondary loader?). I booted (before its death) my Sun/CV (68k, SysV) with a command like b sd(0,0,0); syntax is clear. - The "we load an intermediate loader" approach: OpenBoot, ... James Laferriere, <babydr(a)nwrain.net>, said he boots his Sparc 4/xx series with a command like: /sbus/esp@0,800000/sd@3,0:a This is Sun OpenBoot 3.x syntax, as far as I understand, from Sun's OpenBoot 3.x Command Reference Manual, section The Device Tree. (www.sun.com) James states that the BIOS understands UFS(Solaris type) filesystems, too; but it seems to me that this is only true for the secondary boot program. The primary OpenBoot boot code does not understand more than TFTP and simple I/O. Quote from Sun: "Often, the program loaded and executed by the boot process is a secondary boot program whose purpose is to load yet another program. This secondary boot program may use a protocol different from that used by OpenBoot to load the secondary boot program. For example, OpenBoot might use the Trivial File Transfer Protocol (TFTP) to load the secondary boot program while the secondary boot program might then use the Network File System (NFS) protocol to load the operating system. Typical secondary boot programs accept arguments of the form: filename -flags where filename is the name of the file containing the operating system and where -flags is a list of options controlling the details of the start-up phase of either the secondary boot program, the operating system or both." Pros: Bootcode in the EPROM can be small and simple, and need to know only the Right Things; but in contrast to the conventional lilo-style boot, you can have a real comfortable boot prompt, with fq path name to the kernel etc. Cons: If your hdd or whereever you load the second loader from is broken you got a problem. With a litte extensions to the BIOS (network!), this is a fancy lilo. - The "we waste some space on hd only for our kernels" approach: BSD, DOS+loadlin A simple filesystem on a special partition. Pros: We do not need to know anything of a complex filesystem; but we can use different kernel images. Cons: Where are the pros, I have all those with lilo already. Stupid thing. - The "we implement a complex fs, network, cdrom, tape, ... <fill in your favorite killer device driver, at least 512k in size>" approach: Ok, why not just implement it in the firmware of your harddisk? Imagine, an ext2fs harddisk :-). This is the bootrom-on-my-nic-approach. What we wanted (David Kennedy): - Network boot - Boot from any partition - Booting a Linux kernel directly/Filesystem support, so we can easily specify above Linux kernel - A powerful BIOS UI (most likely command-line driven) - Extended hardware diagnostics in flash ROM To conclude, I think the only interesting thing is to improve lilo; without replacing the entire BIOS, I do not see any possibility to make things like diskless boot etc. work without Boot EPROMS on NICs. The best thing IMHO is to adopt OpenBoot for 80x86 machines. It has a well-thought concept, an UI (huh, forth :-), you can write your own hardware diagnostics, and with the secondary-loader-approach, you can do the other things as well. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

4 3

OpenBIOS == Open Boot/Firmware?
by Geir Frode Raanes 27 Feb '98

27 Feb '98

On Fri, 27 Feb 1998, Chris Arguin wrote: As an innocent bystander just entering the show, it appears to me that you are trying to reinvent the wheel here. Have you yet discussed the possibility of simply implement Open Boot (on Sun) or Open Firmware (on PowerPCs)? Same thing. It's availeable on PCI PowerMacs through a three-button combo at powerup. Allows for insertion of device drivers through interpreted/semicompiled Forth code and U*IX like device trees. It is an open standard; IEEE 1275-1994. More important, it *works*. Now. Probabely the best place to read about it is on the home page of the Open Firmware Working Group at; http://playground.sun.com/pub/p1275/ But let me quote some highlights from FirmWorks home page: http://www.cuviello.com/_portfolio/_FirmWorks/technology.powerfeatures.html --- Open Firmware encodes the drivers in a machine-independent language called "FCode". FCode is a byte-coded "intermediate language" for the Forth programming language. The same FCode driver can be used on systems with different processor types. Open Firmware can debug hardware, operating system software, plug-in drivers, and even the firmware itself through Interactive Debuggers. The Open Firmware client interface allows the OS to examine the device tree, temporarily use Open Firmware device drivers, display progress messages on the console device, allocate memory, and utilize other Open Firmware services. Usually, after the OS is fully initialized, it assumes responsibility for most of these tasks, and Open Firmware is no longer needed until the machine is rebooted. The device interface specifies the full set of FCode primitives guaranteed to be available to an FCode driver. A full-featured Open Firmware implementation, including debuggers, network protocols, selftest diagnostics, drivers for on-board devices, keyboard maps, graphics device support libraries, fonts, and on-line help, usually requires between 128K and 256K bytes of ROM space. --- Oh, by the way - SILO, the SPARC/Linux loader have no problems reading the ext2fs filesystem and thus first search out 'silo.conf,' reading that and since find the approriate kernel image. No need to rerun SILO just because of an updated 'silo.conf.' OTOH, SILO itself has to be placed somewhere/anywhere OpenBoot can find it. Usually that means sector one of the first partition, but details may be specified to Open Boot. Unfortunately, I see a problem in how to lobotomate Open Boot to allow legacy BIOS services to be implemented. Perhaps the Quarterdeck Quick Boot feature with a BIOS image reinsertion when needeed is the way to go. -- http://devworld.apple.com/dev/technotes/tn/tn1062.html http://devworld.apple.com/dev/technotes/tn/tn1044.html http://www.forth.org/ -- Geir Frode Raanes Omega Verksted NTNU, Trondheim Norway. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Hello
by Jeroen Jacobs 27 Feb '98

27 Feb '98

Hi, I just subscribed to this mailing-list and I read the discussion about implementing FS-code into the BIOS. There a few things you should consider first: * Every OS (DOS, Win95/NT, Linux, OS/2 ...) should be rewritten to use this new filesystem. * You should also include drivers for Hard-disks (E/IDE, SCSI). Can 1 ROM module hold all this code ?? * What kind of filesystem should it be ?? At least it should contain long filenames-support, user-permission flags and maybe auto-defragmentation. In my opinion it would be best to let the OS do the FS-code. Greetings, Jeroen Jacobs Internet: jjacobs(a)mail.dma.be Fidonet: 2:292/516.2 --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Hi.
by 9732520＠lewis.sms.ed.ac.uk 27 Feb '98

27 Feb '98

I just subscribed a couple of days ago and was trawling through the recent messages and a couple of things came to mind: 1) Any 32-bit OS cannot use int's below 0x1f for their own use. That is why the BIOS is not used (apart from the fact it isn't 32-bit). In protected mode, these interrupts are used or reserved by Intel to signal various exceptions such as FPU overflows or page faults etc. So any BIOS that was to be used by these OS's would have to use int's above 0x20 or another call method like fixed addresses for entry to functions. (which may just be a call to the actual location) and also keep the interrupt controllers out of these int numbers. 2) I assume 32-bit code is used as much as possible, ie. start up in real mode and switch to protected mode asap. and then deal with all the rest. It doesn't make much difference for boot really, but functions used by OS's should really be 32-bit now (name one *decent* real mode 16-bit OS). Otherwise, the project looks interested and may be of some use. Mark Scott marks(a)dai.ed.ac.uk Department of Artificial Intelligence, Edinburgh University God is real unless declared integer --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 2

Re: [OpenBIOS] Filesystem code
by Joel Klecker 27 Feb '98

27 Feb '98

At 10:54 +0000 1998-02-27, David Woodhouse wrote: >cpa(a)hopper.unh.edu said: >> What if, at some fixed point in *every* filesystem, the filesystem >> provided an interface to use it. That is to say that the read/write >> functions, etc, are actually BUILT IN to the filesystem. They have to >> be somewhere anyway, and this will (in theory) export them to any OS >> or program that wants to use them. > >Nice idea. Not very practicable though. > >Didn't the Mac do something like this, or was that only hardware drivers? Hardware drivers, and only disks at that. The Mac ROMs know just enough about disk devices to find the partition table, and load the disk's driver off of the driver partition. -- Joel "Espy" Klecker Debian GNU/Linux Developer <mailto:jk@espy.org> <http://espy.org/> <ftp://ftp.espy.org/pub> God shows his contempt for wealth by the kind of person He selects to receive it. -- Austin O'Malley (1858-1952) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] OpenBIOS: reality check
by Florian Wunderlich 27 Feb '98

27 Feb '98

>FW = Florian Wunderlich <florian.wunderlich(a)tec.med.uni-muenchen.de> >FW> Filesystem code in a _BASIC_ input/output system is not a good idea >IMHO. > > The firmware on IBM-PCs can no longer be correctly termed solely an >input/output system. The emphasis was on BASIC, as shown with upper case letters, and maybe we should remind that fact. What I wanted to express is that FS code does not belong to the BIOS or M/B firmware or whatever you want to call it. It depends on the operating system, not on the hardware, and in consequence, it should be implemented in the os. >OS> Note, I did not say I think it should be part of the BIOS code, just >that it >OS> should reside in ROM. > > With all due respect, this is a technical mailing list, not an English >lesson. :-) We are not computers. We can (hopefully :) figure out >what other human beings mean without needing literal terms. Huh. May I repeat that? :-) --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Microkernel BIOS
by Igor Babanov 26 Feb '98

26 Feb '98

Wants to offer on discussion an idea and its glance to the development new BIOS. Idea is based on ideas to apply to BIOS, as a small multitasking operating system kernel.(microkernel architecture). If asked by simple words, this kernel consists of microkernels (hard determined) and minimum kit of managers of resources (practically always used in all systems).Other managers of resources can loading from Flash (when initializing) or from the disk (ROM, Flash, HDD, Net) dynamically, on the measure of need, under the work system. MicroKernel BIOS consists: 1 Scheduler. 2 Universal mechanisms of messages communication ( aplicable between process, in network, in multiprocessor, in graphic, and etc exhibits). 3 Interruption Handlers of lower level. 4 Universal mechanisms autoconfiguration myself and the whole around. 5 Universal mechanisms of accompaniment of new managers of resources. Main purpose: 1 To Use BIOS as microkernel for the whole operating system as a whole (rather then for the sake of compatibility only, initial configuration and bootstrap) 2 Buildings BIOS module. At the appearance of new versions of devices - are changed versions of managers of devices. At the appearance of new technologies - is added new manager of resources, written on narrowly defined rules. 3 Developers hardware deliver only one programme manager of device, used as a central to drivers for all operating systems practically. Main difficulties: 1 Compatibility and emulation old BIOS. 2 Choices of universal standards for the issue of reporting, autoconfiguration, accompaniments of new managers and e.t.c. 3 New programme interface Developments to BIOS calling. Old interface herewith too must work, but be considered as a temporary exception. 4 Commercial and political and etc contradictions. Best regards, Igor Babanov --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0