OpenBIOS

openbios@openbios.org

4297 discussions

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

26 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

Considered Open Firmware?
by Joel Klecker 25 Feb '98

25 Feb '98

Several people have mentioned Sun, HP, SGI, etc. workstations boot firmware as examples of kinda the approach the project may want to take. Open Firmware was originally based on Sun's OpenBoot 2.x, and UltraSparcs use OpenBoot 3.x, which is Open Firmware compliant (according to the below site), OF is IEEE standard 1275, and seems quite well thought out, and can do pretty much everything stated as desireable on this list. Other platforms that use OF include most PReP and CHRP-compliant PowerPC machines. The problems I can see is that it is (probably) too big to fit the space we have to work with, both in flash and NVRAM, and x86 processor bindings are not quite there yet, also, it is very unlikely that it could handle booting Windoze, DOS, etc. However, it may still prove useful as reference, see <http://playground.sun.com/1275/> for info. I will quote the description from the above site: << OPEN FIRMWARE DESCRIPTION. Open Firmware is the only firmware standard in existence to have its own song. Download or listen to Mitch Bradley singing the Open Firmware Song (278k). Open Firmware is the non-proprietary name of firmware complying with IEEE Std 1275-1994. OpenBoot (tm) is Sun Microsystems trademark for the firmware product shipping on over one million SparcStations(tm) and SPARCServers(tm) since 1989. Apple Computer's newest line of PCI bus-based Power Macintosh(tm) desktop systems are shipping with Open Firmware. Among Open Firmware's many features, it provides a machine independent device interface, which can be used to boot plug-in cards without providing OS-specific and/or machine dependent binary programs on the plug-in card. This feature enables plug-in card manufacturers to easily support several independent computer architectures without needing to supply different firmware for each one. Open Firmware is based on Sun Microsystem's OpenBoot 2.x implementations and complies with ANS (ANSI) Forth. (Information on ANS Forth is provided courtesy of Athena Programming, Inc.) You can also get additional information about Forth and the Forth Interest Group on the World Wide Web at Forth Interest Group Home Page. OpenBoot 3.x, currently shipping on Sun's 64-bit UltraSparc based systems, complies with the Open Firmware standard. Open Firmware is now shipping on Apple Computer's 604-based, PCI bus, PowerMac systems. Read how Apple Computer describes PCI bus and Open Firmware. Table of Contents. >> Regarding size, <http://www.firmworks.com/www/size.htm> has this to say: << Size 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. In some system environments, unnecessary features may be omitted, making it possible to fit Open Firmware in a single 128K byte ROM. >> There's a more detailed description at <http://www.firmworks.com/www/ofw.htm> -- 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

What is the point, a new BIOS or utilities in ROM?
by oskjaeve＠sivos.rl.no 25 Feb '98

25 Feb '98

As a newbie on the list I allow my self a couple of critical remarks and a few possible stupid questions. A quick scan of historical postings makes me think the group would benefit from clearing up a few things. There seems to be a demand for having certain functions in ROM. File system code has been mentioned, and also a boot loader of some kind to get rid of LILO. Making the BIOS be more than a BIOS would be a mistake in my opinion. The BIOS is sopposed to be the hardware abstraction layer, and I think it should be kept that way. If we need a better BIOS, then we should build one. I think a discussion on BIOS topics and how we could improve it, would do us good. Please don't confuse it with where the BIOS is stored. Pulling a new BIOS from disk after startup from a primitive ROM based BIOS, is ok. If the code is a hardware abstraction layer, it is still a BIOS. If we would like to move code normally kept on disk to ROM, like putting file system code or a LILO-killer in ROM, then let us do so. But let us not make it part of the hardware abstraction layer code. So what are the goals? Putting file system code, a LILO-killer, networking software or other code in ROM because it is better than pulling it from disk? Or is it to build a better hardware abstraction layer? Or both? If I may suggest a utility that I think belongs in ROM rather than on disk: an improved memory test. Note, I did not say I think it should be part of the BIOS code, just that it should reside in ROM. (ROM is, by the way, a pretty hopeless acronym because a read only memory is totally useless. Even PROM doesn't make any sense, how can one program a read only memory? If we'd known better back in the stone age, we would have called it a WORMM, write once read many memory, or something...) For the benefit of further discussions, I suggest we somehow make it clear wether we are talking about putting non-BIOS type of code in ROM or if we are talking about actual BIOS code. -- Odd Skjæveland oskjaeve(a)sivos.rl.no --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

3 2

Re: [OpenBIOS] OpenBIOS: reality check
by Benjamin Scott 25 Feb '98

25 Feb '98

DK = David Kennedy <dkennedy(a)engsoc.carleton.ca> DK> Hmm... I certainly hope that I never get a system without an ISA DK> bus. I have way too many specialty cards that require it. Well, I doubt ISA will ever go away totally, but you may see it relegated to specialty systems. Depending on your application, you may find your existing ISA system suitable forever. Or, it may be time to move your specialty cards over to PCI. :-) DK> With the dozen or so PC chipsets out there, can all these differ- KD> ent versions of the initialization code be effectively created? This is an important point. I don't know how things work at that low a level. It is entirely possible that we're biting off more then we can chew. On the other hand, the IBM-PC world is full of de facto standards. We may find much of the chipset support is the same. DK> This one has been done over and over. But it's done with a BIOS DK> chip on the network card using the technique I discussed before. I would like to have more control over the network boot process, including specifying host and boot image at boot time. I haven't seen anything that does this using the ROM on a netcard, though I am far from an expert. Being able to "ping" from the boot monitor prompt would be a handy tool, too. DK> Again, because of the multitude of network boards, I forsee it DK> being very difficult to offer this in a generic BIOS. We don't have to support every network card ever made. Supporting just a few (ie, NE2000, 35x9, etc) would get us support for a large number of systems. And it is a universal agreement that our firmware code should be modular, allowing the user to select which features (such as drivers) they wish to include in the final firmware image. DK> This is a rather easy extension. But the more important one is DK> to boot off of any controller type (SCSI, EIDE, ...) That's a little more complex, but should be doable. I don't think we have to support every SCSI card on the market -- I think it should be possible to select the interrupt services provided by disk controller BIOSes. I'm pretty sure that's what my BIOS does now by offering me a "Boot SCSI or EIDE first?" option. DK> Actually, all BIOSs (to my knowledge anyway) have extended hard- DK> ware diagnostics. The problem is that nobody knows about it. Which is effectively the same as not having them. :-) Perhaps it would be better to say "Extended hardware diagnostics which we can *use*". :-) DK> Unfortunately, enhanced security is not feasable, especially if DK> someone reaches into the case and jumpers the "clear CMOS" DK> jumper. "It is important to realize that any lock be be picked with a big enough hammer." -- Sun System and Network Admin Manual In other words, it is impossible to make a system full-proof. But a more intelligent password system, encrypted BIOS passwords, and the like, would be one more step in the right direction. :-) DK> I would spend good money on a machine that can boot without a DK> graphics card, and a keyboard. Many systems can, if you set both keyboard and video to "Not Present" in BIOS setup (or with jumpers). But it should be possible to do a better job. Of course, some hardware may just flat-out not work without (for example) a VGA card present, but that's bad hardware, not our fault. :-) DK> and the machine has room for all of my custom ISA cards. What exactly do all these custom ISA cards *do*? <G> me> While the idea of implementing a whole new set of BIOS calls -- either me> to be more powerful or faster, or to run in protected-mode -- sounds me> appealing, it would be totally useless. DK> I don't see a need to reimplement all of those calls either. Es- DK> pecially since most of them are kludged anyway. Rewriting them DK> to new specs (in 386 Protected mode) could get rid of code bloat DK> in the Linux kernel, and could pave the way for some tiny embed- DK> ded OSs. I think you missed me point entirely. What I said was, reimplementing all the BIOS calls (or creating new ones) to provide a protected-mode interface would be pointless. See my previous message for the reasons why. :-) DK> Well, rudamentary filesystem code would be acceptible, I think. DK> Enough to find the kernel. That's all I'm taking about. I don't mean full read/write/accounting support. Just enough to find the kernel file on disk, load it into memory, and boot it. Nothing more. DK> How does other command line BIOSs do it? Some just pass control to a secondary boot loader using a standard interface (I'm told Suns do it this way). Others (eg, MILO for the Alpha) actually include Linux filesystem drivers into the firmware, giving you the ultimate in flexability. I'm suggestion something in-between. :) -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

OpenBIOS: reality check
by Pascal Dornier 25 Feb '98

25 Feb '98

The purpose of a BIOS is to create independence between hardware and operating system. A streamlined BIOS can be quite compact. For example, my own BIOS, tinyBIOS, is about 10k lines of assembly source, < 16KB of object code). The code is mostly 16 bit, with 32 bit code used where it makes sense (e.g. memory test) or is required (32 bit PCI entries). 16 bit code is more compact. Assuming no unnecessary delays, system startup time is dominated by hard disk spinup time, and cannot be reduced any further. If desired, custom boot loaders can be installed in the remaining flash space. I've done this for one of my customers (they're using their own non-UNIX kernel and file system). > reentrant BIOS code so we can leave out drivers from the kernel(s)? Why bother ? We're talking about a few KB worth of code. On some platforms, execution out of BIOS space can be slower due to hardware constraints (cacheability of BIOS space etc). If you try to keep this code in the BIOS, you will have extra overhead for generic OS hooks etc. > On Systems with 4MBit Flash (are there any?): Kernel in Bios What if the kernel gets any bigger ? Most boards have 1 Mbit or 2 Mbit flash anyway. > USB Support Unless you need to boot through USB, probably bad idea. This belongs in the OS. > PCI/EISA/PnP Support EISA ??? what's that <g> ? ISA PnP should be implemented at the OS level, if at all. PCI PNP is much simpler and more likely to be reliable. > MSDos Filesystem code A standard BIOS doesn't know about the file system, all it does is load the first sector on the disk. The rest is up to the boot loader of the operating system. > repeat the same procedure for any cards which bring their own BIOS > (SCSI, video, etc.) Do you want to spend the rest of your life doing this ? > obtain complete documentation on how you query SIMMs/DIMMs/etc. > (including common bugs) This is generally based on a trial and error detection procedure (set biggest possible size, then find out how many address bits really work), rather than presence detect bits. > add some backward-compatibility interface for people needing DOS > or one of its offsprings (Maybe not) Highly desirable, DOS is a much easier environment for low level debug. > implement some clever auto-configuration mechanism Yes, this is key. Setup screens are evil. My BIOS doesn't have one. Finally, who are you writing this for ? For the individual user, I think it will be better to leave the BIOS on their system board alone. The savings in boot time etc. will never pay back for the effort spent playing with the BIOS. For the industrial user (embedding Linux or FreeBSD in a custom designed system), they can easily afford to license a commercial product from the usual suspects (Award, AMI, Phoenix, Systemsoft, General Software, moi). In volume, this can be as low as $0.10 per unit. For small volume users, adaptation cost (either at the BIOS vendor or on their side) will be higher than the license cost. If you want to make the UNIX platform more suitable for embedded use: - Make the file system fault resilient. Existing boxes (e.g. http://www.whistle.com ) have to include a UPS to protect the file systems. Costs lots of money, and doesn't protect against software induced crashes. - Flash file system support. Aggressively reduce size of minimum system (e.g. for routers). 1 MB = $5 or more. It's coming down, but slowly. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

5 4

32bit development environment
by Stephen Williams 24 Feb '98

24 Feb '98

If youall are going to write this OpenBIOS thing in 32bit mode, I would like to offer up a C/C++ development environment that would suit this project nicely. Take a peek at uCR at <http://www.picturel.com/ucrhome.html>. Source is available, as are the compilers (EGCS) precompiled. To make it go, someone would need to write a linker model and startup code. I already have thread switching for i386, but not interrupts. It is plenty small enough for the limited flash of a typical PC. I have TCL 7.6 ported to this environment. This port is currently tied to the ISE board (a Picture Elements product) but I can fix that if there is demand. It should be plausible to write call gates into 32bit code from 16 bit mode, but I don't really know. If you think all the work should be done in 16bit mode, then I doubt this will be helpful. -- Steve Williams "The woods are lovely, dark and deep. steve(a)icarus.com But I have promises to keep, steve(a)picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)
by Pavel Machek 24 Feb '98

24 Feb '98

Hi! > The core-bios would boot up like most BIOSes do now, by requiring lilo or > something like that. But with the user-extention to support ext2fs and > FAT, you could then do something closer to the Sun bootloader. Sun bootloader does *NOT* have any filesystem hardcoded. It just knows how to boot initial 8K block from SCSI (something like MBR) and pass command line to it. It is this 8K block which knows filesystems. I don't think bios should understand fs: you don't want to have partition just because of booting. I do not think that we should change current system anytime soon. Pavel PS: Did anyone try to flash that bochs bios into flash and see if it boots? -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

2 1

Re: [OpenBIOS] OpenBIOS: reality check
by Pascal Dornier 24 Feb '98

24 Feb '98

>I believe the main problem of today's BIOSes is that they're designed to run in >real mode. A protected mode OS will either have to switch to and from real and >protected mode to perform I/O (which isn't very neat, and incurs quite a lot >of execution overhead) or ignore the BIOS entirely and provide its own I/O >routines (which is a waste of coding effort). It'll be good if there's a BIOS >that can provide some sort of protected mode framework (possibly amounting to >a microkernel?) within which an OS can access BIOS services in true protected >mode. (Proprietary ROM BIOS extension cards will probably have to be modified >to fit into this scheme, but that's another story...) That's been done in 1987, the so called ABIOS (advanced BIOS) in IBM's PS/2 systems. It was intended to be for OS/2. I don't know whether it got used at all, but the idea died together with the Microchannel architecture. Nobody missed it ever since... Today's protected mode OSs use their own drivers to avoid switching modes. And switching modes on 386 and later CPUs is much faster than it was on the "brain-damaged" 286. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

1 0

Jump to page: