There are a couple of problems with this. You have AMI, Award, Phoenix,
IBM, Dell, Intel, etc. writing BIOS code or buying a basic BIOS development
package from one of the BIOS vendors, but adding their changes,
modifications, and other non-standard features. ABIOS was an idea whose
time never came.
CP/M had a software BIOS that each port of the OS required it to be
rewritten to support the actual hardware. Of course, every vendor had major
variations in their hardware and it wasn’t until the IBM PC that the
hardware became more standardized. Today the change seems to be for more
variations with APICs, and chipsets that support supersets of various
standard chips.
The BIOS as we know it occupies the F000h and sometimes the E000h blocks of
memory. Adding a protected mode version of the BIOS will require some
window where the BIOS can be accessed. It would be possible for Microsoft
to force standardization, but I haven’t heard of any attempt to do so.
Maybe Microsoft doesn’t want to be known for revitalizing the ABIOS.
Also, most BIOS today require much more than the 64KB of old. I remember
the Compaq 386 that had such a small BIOS that they duplicated it in two
32KB blocks within the F000h address block. They seemed to pick random
interrupts to vector into each half even though it could all be handled in
one.
Most chipsets can run in a common mode, but each motherboard vendor usually
releases chipset drivers to provide the full capabilities of their
chipset/motherboard implementation. This fun might be why Jake moved from
the HAL group, because it has to be a real bear to get even the standard
stuff working with all the variations that exist. MS-DOS can run using the
BIOS and usually doesn’t get the full power features the system provides,
but a real protected mode OS needs to be able to do things that are not
simple and common to all chipsets. Intel has had several major problems
with some of their chipsets over the last ten years or so. Intel also has a
vested interest in keeping CPUs and chipsets from running any faster than
documented, but several of the other motherboard vendors want their
motherboards to be the fastest and to support overclocking as much as
possible. Even the IBM PC/AT could be overclocked and the wait states for
memory could be reduced successfully to increase throughput.
Good idea, though, but can you get everyone to buy in? Microsoft would have
to change some of the basic architecture of Windows NT to support more than
two rings, but I guess they decided to keep it at two so more processors
would be compatible.
----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Friday, December 20, 2002 10:46 AM
Subject: [ntdev] RE: Sitting under the OS
> The answer to that is a public and relevant - meaning legacy free,
> processor-architecture free, and dirty-compatibility free - Bios spec.
> Something more or less in the direction of the ABIOS that IBM tried to get
> into place a few years ago. I am a firm believer of the onion-peel model
of
> software development: there should be a Bios that deals with hardware
unique
> to the machine, and that Bios should present a predictable and uniform
> lowest-level OS-independent interface to the world; that API should work
the
> same for Windows, Linux, Beos or whatever else. There should be hardware
> level drivers that, as their name implies, drive the hardware - and the OS
> should sit on a higher level, leveraging on public and standard APIs
offered
> by the Bios and establishing a uniform upper-edge interface to device
> drivers. The way I see it, it is not ok to have lower edge OS interfaces
> that device drivers are required to maintain, neither is it ok to absorb
> platform-specific hardware considerations away from the Bios.
>
> In my mind, I/O handling does not belong in the trusted kernel, but then,
> that requires hardware that many RISC machines don’t have today. It could
be
> easily done in the PC if people took advantage of the multiple protection
> rings: I see no reason why the whole of the I/O handling in an Intel PC
> wouldn’t be better off handled at Ring 1 than at Ring 0.
>
> A problem we have today is that we do not have a lowest level
> hardware-independent public API that everybody can code to. It shouldn’t
be
> like that - the line separating hardware from software handling should be
> sharper.
>
>
> Alberto.
>
>
>
>
> -----Original Message-----
> From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
> Sent: Thursday, December 19, 2002 6:54 PM
> To: NT Developers Interest List
> Subject: [ntdev] Sitting under the OS
>
>
> To some, yes. To most of the people on this list, it just means that
> instead of just needing to test their code and their hardware against
> every processor and every chipset, they also need to test it against the
> matrix of every chipset and every BIOS codebase, too, since the BIOS can
> (and often does) modify the behavior of the underlying chipset. This
> exponential increase in variation of the behavior of the platform mostly
> means that an IHV can’t guarantee you that their hardware works with
> every machine in the world. Take, for example, the guy who was asking
> about how you guarantee isochronicity on the USB with a BIOS that is
> doing 100ms delays.
>
> - Jake
>
> -----Original Message-----
> Subject: Re: UART Handling - was interrupt handshaking
> From: “Moreira, Alberto”
> Date: Wed, 18 Dec 2002 13:22:01 -0500
> X-Message-Number: 21
>
> Well, it’s nice to have some hardware in the machine that one can use to
> sit
> under the OS, no ?
>
> Alberto.
>
> -----Original Message-----
> From: Bi Chen [mailto:xxxxx@AppStream.com]
> Sent: Wednesday, December 18, 2002 1:18 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: UART Handling - was interrupt handshaking
>
>
>
> SMI is used for APM, legacy keyboard/mouse emulation for USB
> keyboard/mouse,
> among other things you guys have mentioned. OS is unware of SMI at all.
> When
> SMI asserts, it puts processor into SMM and BIOS SMM code will take
> over. We
> all wish it along with other legacy go away entirely. However, in PC
> world,
> legacy die extramely hard.
>
> Bi
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%