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

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.

I share the some of the view as Alberto to have a common firmware interface.
However, I believe driver architecture still needs to be OSes dependent to
differentiate (good and better) OSes . I believe EFI is heading to this
direction. Nevertheless, Jake said he (and possibly Microsoft) has given up
this dream by only supporting major chipset/bios vendors and OEMs. It is
also not cost effective for embedded system to be built on any common
firmware interface. PC is merely commodity now-a-days. The innovation lies
in smaller devices, which diversity are welcomed.

Bi

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Friday, December 20, 2002 7:46 AM
To: NT Developers Interest List
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@appstream.com
To unsubscribe send a blank email to %%email.unsub%%

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%%