OpenBIOS February 1998

openbios@openbios.org

33 participants
63 discussions

Considered Open Firmware?
by Joel Klecker 26 Feb '98

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

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

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

25 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

Re: [OpenBIOS] OpenBIOS: reality check
by David Kennedy 24 Feb '98

24 Feb '98

On Tue, 24 Feb 1998, Stefan Reinauer wrote: > > 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. > > Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS > even doesn't have it's own filesystem code afaik.. According to all the BIOS code I have read, BIOSs do not have any filesystem code. As outlined before, all they have is sector, cylinder and head code. > > 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. > > Again, modern PC Chipsets allow reading the exact RAM configuration out of > their registers Yes, in a proprietary way. I would like to take this opportunity now to stop and as "Why?" I'm sure it's been brought up, but I don't see the need to rein- vent the wheel when it comes to BIOSs. First off, don't all PCs come with BIOSs? Second, writing a generic BIOS that will encom- pass all the new motherboards, IMO, will be a wasted effort. Aren't the majority of PC chipsets proprietary on how they are initialized for caching, memory configurations, et al? Personal- ly, I see this project as a waste of programming power. As it was said earlier, the only forseeable benefit is to LILO (ini- tially). I don't see much support after that either, unfortu- nately. The idea of replicating the BIOS programming interface is not a worthy effort either, IMO. Everyone agrees that it is old, ante- quated, and kludged. The idea of rewriting all the BIOS routines anew without the legacy baggage is a good idea, but I don't think that you should "hide" the fact that you are doing it. I think, if you are going to rewrite the BIOS routines correctly, a unused interrupt vector should be chosen, and a completely new set of routines should be written. Or perhaps, simply writing a com- plete set of routines to be loaded overtop of the BIOS, so that any programming wanting the GNU BIOS routines would simply in- clude the object file, and call a initialization routine or two (provided of course they are taking complete control of the sys- tem). Those are my ideas for the current project. As an offshoot from this project, I have an idea that I can per- sonally use (or, more specifically, that I wanted to use). Ac- cording to the documentation I have, memory locations from C8000h to E0000h are checked at 2k intervals for the sequence "0xAA55" If it is found, the next byte is a "length indicator representing the number of 512-byte blocks in the ROM." Following that is a far code entry point. The entire ROM also has to be checksummed modulo hex 100 and come up to 0. I think this interface can be used to produce a LILO of sorts that can replace the initial boot loader. A command line interface can be supplied, as well as some code that would investigate the current hard drives, and their partition tables. This could produce a BIOS that is simi- lar to many older "minicomputer" style BIOSs. This interface is checked after all of the initialization sequence occured, and be- fore any bootstrapping. That way, a more modern BIOS can be written without the worry of compatibility between all sorts of different hardware. This has other practical values as well. Since every single PC in existance has a ISA bus, but not all PCs have the same BIOS chip (not even the same number of chips, or the same number of pins), this allows for better distribution. It allows faster development time, since you can easily remove a card to boot the machine to a useable state again. (as opposed to gerryrigging some sort of external platform with a mechanical switch.) Also, hardware illiterites are more comfortable in- stalling an ISA card, as opposed to removing chips off of the motherboard. As for my experience, I have been programming in Assembly lan- guage for 7 years now, concentrating on low level VGA program- ming, rudamentary OS code, as well as custom cards. I have two BIOS listings, one is a 386+ BIOS reverse engineered (obtained freely from x2ftp.oulu.fi I believe). The other is in the back of the IBM Technical Reference Personal Computer AT, 1985. This code is original IBM BIOS code for the 286. (Did you know that they tested each register, conditional jumps and the BOUND in- struction?) Whichever way the project desides to go, I wouldn't mind helping out. I have experience in this area, and I would like to prac- tice my skills in something, that might, quite possibly, do some- thing, for someone, somewhere. ;) -- David Kennedy Vic/Linux and Pet/Linux: RPMs coming soon.

2 1

Hard drives, CMOS/VRAM and some general ideas
by Alle Metzlar 24 Feb '98

24 Feb '98

This past weekend I have subscribed to the OpenBIOS mailinglist, and it took me some time to read all contributions, except for some in the archive. Following are my thoughts in this discussion: CMOS/NVRAM Older PCs use a CMOS of 64 bytes, newer (486 and up) use 128 bytes. Some other systems use up to 4K or 8K of CMOS (MCI/EISA). The first 16 bytes of CMOS are reserved for RTC use: 00h - 09h Time and date fields 0Ah Status Register A 0Bh Status Register B 0Ch Status Register C 0Dh Status Register D 0Eh Diagnostic Status Register 0Fh Shutdown Register The following 32 bytes are most commonly used for ISA configuration data, and the last 16 bytes are generally used for BIOS-specific configuration data, such as Boot sector virus-protection, security, ROM shadow config, and extended CMOS checksum. An additional 64 bytes may be available in the Extended CMOS RAM, incorporated in many chipsets to store advanced config info. >From space in CMOS RAM 16 bytes less are available. Hard disk drives BIOS CHS limits to 1024/255/63, thus supporting up to 8.0325 Gb. IDE CHS limits to 65,536/16/255, thus supporting up to 130.56 Gb. Thus the overall limits are 1024/16/63, supporting only up to 504 Mb. A little resize of storage in BIOS/CMOS would break those limitations, as Microid Research may have done with its MR BIOS. As far as I know the MR BIOS has CHS support for 16384/255?/63? (128.52 Gb). It already did in 1990! I have used a 2 Gb EIDE drive in an old 386DX (1989) ISA machine with an MR BIOS v1.51, though advanced PIO/DMA modes were not available. Some sort of translation is used however, but I haven't figured that out. It isn't LBA according to WD/Phoenix for sure. By the way, MR BIOS supports installation of 8 hard drives and 4 floppy drives, for some years now, and you can boot from all of these. OK, there is the idea of designing an OpenBIOS. Are there any general ideas on how this OpenBIOS should be designed? Most BIOSses still have the IBM compatibility, that is compatibility to the older PC and XT standards, by maintaining a list of vectors to the IBM-compatible vector (AMI calls this the ROM Compatibility Table, Phoenix calls this COMPAS or Compatibility Structure). And what about the INTs. As I recall, Intel reserved 32 ints to be CPU ints. With the 8088 just a few were used, and IBM began to use all non-used but reserved ints for their PC BIOS, which means that we now are stuck up with several ints being both BIOS and Hardware/CPU ints, such as 05h, 10h, 11h, and 12h. Are there any ideas on this, including some possible work-around? BIOS should at least consist of three parts: Power-On-Self-Test (test and initialize various components, and eventually the bootstrap loader), System BIOS (providing the interface between OS and hardware: interrupts), and a setup utility (system configuration). The setup util should be in the BIOS itself, or a special key(combination) should be available during POST if things go wrong, and you can't access the setup program on disk. The setup program should be functional, and doesn't have to have great looks (as the AMI WinBIOS?). -------------------------------------------------------------------------------------------- Alle Metzlar Matrix Technologies P.O. Box 40, NL 1724 ZG Oudkarspel The Netherlands Tel: (+31) 226 316889 Fax: (+31) 226 312157 EMail: matrix(a)xs4all.nl WWW: http://www.xs4all.nl/~matrix/ (Matrix Technologies' BIOS Web) -------------------------------------------------------------------------------------------- Author of: Het BIOS boekje, Uitg. Pim Oets, ISBN 90-5722-013X Das BIOS Buch, Franzis' Verlag, ISBN 3-7723-4832-7 Die BIOS CD-ROM, Franzis' Verlag, ISBN 3-7723-8612-1 --------------------------------------------------------------------------------------------

1 0

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

24 Feb '98

>Is your TinyBIOS commercial or is it somewhere available so that we could >have a look at it? ;-) tinyBIOS is a commercial product. At this point I don't think I can afford to give away the farm. I could potentially release the source for non-commercial use only, but not under GPL. >I thought about USB keyboards I think USB keyboards are a lousy idea. I'd rather use USB ports for devices that really need the bandwidth, and are a hassle to hook up otherwise, such as a scanner. Once you get above two USB devices, you will need a hub, and end up with a desk encrusted in USB cables... >Wrong. Current BIOSs have a simple MSDOS system in their int-Code. MSDOS >even doesn't have it's own filesystem code afaik.. News to me. My BIOS works pretty well without any file system. The only place where some kind of file system is needed is for CD-ROM boot, which I don't support at this point. >> 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. > >Again, modern PC Chipsets allow reading the exact RAM configuration out of >their registers Guess who sets this configuration ? The BIOS. Do you seriously think a PC manufacturer would waste $0.50 on a input port to read the presence detect bits, if he can detect the memory configuration in software, and avoid compatibility problems with SIMMs that don't have the right configuration ? PC designers would sell their grandmother for savings of $10 a system... -------------------------------------------------------------------- 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