RE: MmMapIoSpace( BIOS physical address)?

NTDEV
1

Either method that you describe will work. NT does not reclaim the BIOS
area, specifically for reasons like yours.

It makes me curious, though, how much control you have over the machines
you care about. Are you talking about the BIOS on an add-in card? Or
are you talking about something in the system BIOS itself?

If it’s the add-in card, you’re safe in reading your BIOS Base Address
Register and mapping it with MmMapIoSpace.

If it’s the system BIOS, then you’re probably safe, but you’ve tied your
driver to a specific motherboard.

If it isn’t the system BIOS, then adding data to ACPI isn’t feasible, so
I assume that it must have been the system BIOS you were talking about.

  • Jake

-----Original Message-----

From: xxxxx@yahoo.com (Ntdev Reader)
Newsgroups:
comp.os.ms-windows.programmer.nt.kernel-mode,microsoft.public.developmen
t.device.drivers
Subject: MmMapIoSpace( BIOS physical address)???
Date: 10 Jan 2002 11:13:11 -0800

Suppose, I want to see the BIOS from my WDM driver. The method in the
subject appears to work on my machine. Does anybody know of any
potential problems with this method? Is this possible that the BIOS
memory for some reason might be invisible on some machines or change
the physical address, or something else…?
I’m not going to call the bios, just want to read a data table from it.
My concern is that something might happen like OS might think “hey, why
do we need this BIOS clogging the physical memory space, let’s call some
ACPI methods to disconnect it and free this space for some RAM chips
that
can be installed while the computer is running”. Can this happen, what
do you think? We are discussing another option - to have the data table
added to ACPI and then read it through acpi.sys. This looks like some
additional code in the driver and in the BIOS - much more complex than
just MmMapIoSpace. I like simplicity… but is is not always suitable.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

This is the system BIOS and the device is soldered to the motherboard.
It is Ok for us to have the driver tied to the motherboard. There
will be a model-specific inf-section telling it to check in the BIOS.
So, which one of the two approaches would you choose?

Unfortunately, I still have to do some research on BIOS. It is the
first time I encounter such a task. What confuses me is that I know
that when our testers load a new BIOS into a motherboard it has
a size more like 256kB, 512kB… However, I also know that when
a DOS starts in the 16-bit mode it is likely doesn’t see all 512kB
of the BIOS in its 1MB of address space. Where is the rest?
I don’t know :frowning:

In the first quick test We figured out that when we MmMapIoSpace
64kB at ffff0000, we can see the good old jmp xxxx:yyyy at fffffff0.
I guess we would better put our table somewhere in these 64kB,
then it will probably be visible from DOS too, which won’t harm…

— Jake Oshins wrote:
> Either method that you describe will work. NT does not reclaim the BIOS
> area, specifically for reasons like yours.
>
> It makes me curious, though, how much control you have over the machines
> you care about. Are you talking about the BIOS on an add-in card? Or
> are you talking about something in the system BIOS itself?
>
> If it’s the add-in card, you’re safe in reading your BIOS Base Address
> Register and mapping it with MmMapIoSpace.
>
> If it’s the system BIOS, then you’re probably safe, but you’ve tied your
> driver to a specific motherboard.
>
> If it isn’t the system BIOS, then adding data to ACPI isn’t feasible, so
> I assume that it must have been the system BIOS you were talking about.
>
> - Jake
>
>
> -----Original Message-----
>
> From: xxxxx@yahoo.com (Ntdev Reader)
> Newsgroups:
> comp.os.ms-windows.programmer.nt.kernel-mode,microsoft.public.developmen
> t.device.drivers
> Subject: MmMapIoSpace( BIOS physical address)???
> Date: 10 Jan 2002 11:13:11 -0800
>
> Suppose, I want to see the BIOS from my WDM driver. The method in the
> subject appears to work on my machine. Does anybody know of any
> potential problems with this method? Is this possible that the BIOS
> memory for some reason might be invisible on some machines or change
> the physical address, or something else…?
> I’m not going to call the bios, just want to read a data table from it.
> My concern is that something might happen like OS might think “hey, why
> do we need this BIOS clogging the physical memory space, let’s call some
> ACPI methods to disconnect it and free this space for some RAM chips
> that
> can be installed while the computer is running”. Can this happen, what
> do you think? We are discussing another option - to have the data table
> added to ACPI and then read it through acpi.sys. This looks like some
> additional code in the driver and in the BIOS - much more complex than
> just MmMapIoSpace. I like simplicity… but is is not always suitable.
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

Since you asked, about 128K of the BIOS is sitting between 0xE0000 and
0xFFFFF of DOS-visible space. Another 128K is behind the video
framebuffer, from 0xA0000 through 0xBFFFF. This is the SMI BIOS, which
is only visible when you are running in System Management Mode. (The
chipset turns off the video range decoders when the System Management
Interrupt happens, revealing the BIOS code and data.) The remainder of
the BIOS is usually at the very top of RAM. The BIOS runs in Real Big
mode, which allows it to address all of memory. Frequently, any data
that isn’t specifically necessary for DOS (like an ACPI table) will be
up there.

If I were designing your system, my choice would depend on how much data
you’re talking about. If it were just a little, then I would probably
put it in the 0xE0000 through 0xFFFFF range, making it easy to get to
from DOS. If it were a lot, then I’d put it near the top of memory,
making sure that your table falls outside of the ranges that the BIOS
reports as OS-usable.

Don’t bother with the ACPI solution. There are lots of reasons why
people use ACPI. But in your case, you’d be adding complexity that you
don’t need.

  • Jake

-----Original Message-----
Subject: RE: MmMapIoSpace( BIOS physical address)?
From: Ntdev Reader
Date: Fri, 11 Jan 2002 21:02:37 -0800 (PST)
X-Message-Number: 1

This is the system BIOS and the device is soldered to the motherboard.
It is Ok for us to have the driver tied to the motherboard. There
will be a model-specific inf-section telling it to check in the BIOS.
So, which one of the two approaches would you choose?

Unfortunately, I still have to do some research on BIOS. It is the
first time I encounter such a task. What confuses me is that I know
that when our testers load a new BIOS into a motherboard it has
a size more like 256kB, 512kB… However, I also know that when
a DOS starts in the 16-bit mode it is likely doesn’t see all 512kB
of the BIOS in its 1MB of address space. Where is the rest?
I don’t know :frowning:

In the first quick test We figured out that when we MmMapIoSpace
64kB at ffff0000, we can see the good old jmp xxxx:yyyy at fffffff0.
I guess we would better put our table somewhere in these 64kB,
then it will probably be visible from DOS too, which won’t harm…

— Jake Oshins wrote:
> Either method that you describe will work. NT does not reclaim the
BIOS
> area, specifically for reasons like yours.
>
> It makes me curious, though, how much control you have over the
machines
> you care about. Are you talking about the BIOS on an add-in card? Or
> are you talking about something in the system BIOS itself?
>
> If it’s the add-in card, you’re safe in reading your BIOS Base Address
> Register and mapping it with MmMapIoSpace.
>
> If it’s the system BIOS, then you’re probably safe, but you’ve tied
your
> driver to a specific motherboard.
>
> If it isn’t the system BIOS, then adding data to ACPI isn’t feasible,
so
> I assume that it must have been the system BIOS you were talking
about.
>
> - Jake
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

There is a little bit more to the story of BIOS.

The binary image that you use to flash to the ROM on your motherboard is
quite different from its runtime image because:

  1. Most part of the binary image is compressed. Most of the uncompressed
    BIOS code involves in memory initialization. After memory
    initialization, the compressed part of BIOS will be uncompressed onto
    the RAM by the BIOS itself.
  2. After BIOS post, a large part of BIOS code is simply thrown away by
    the BIOS. For example, the BIOS setup menus, the POST flash screen, the
    memory intialization code, and all other codes that will not be used
    after POST.

and further more, there is the story that Jake described.

-----Original Message-----
From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
Sent: Sunday, January 13, 2002 6:25 PM
To: NT Developers Interest List
Subject: [ntdev] RE: MmMapIoSpace( BIOS physical address)?

Since you asked, about 128K of the BIOS is sitting between 0xE0000 and
0xFFFFF of DOS-visible space. Another 128K is behind the video
framebuffer, from 0xA0000 through 0xBFFFF. This is the SMI BIOS, which
is only visible when you are running in System Management Mode. (The
chipset turns off the video range decoders when the System Management
Interrupt happens, revealing the BIOS code and data.) The remainder of
the BIOS is usually at the very top of RAM. The BIOS runs in Real Big
mode, which allows it to address all of memory. Frequently, any data
that isn’t specifically necessary for DOS (like an ACPI table) will be
up there.

If I were designing your system, my choice would depend on how much data
you’re talking about. If it were just a little, then I would probably
put it in the 0xE0000 through 0xFFFFF range, making it easy to get to
from DOS. If it were a lot, then I’d put it near the top of memory,
making sure that your table falls outside of the ranges that the BIOS
reports as OS-usable.

Don’t bother with the ACPI solution. There are lots of reasons why
people use ACPI. But in your case, you’d be adding complexity that you
don’t need.

  • Jake

-----Original Message-----
Subject: RE: MmMapIoSpace( BIOS physical address)?
From: Ntdev Reader
Date: Fri, 11 Jan 2002 21:02:37 -0800 (PST)
X-Message-Number: 1

This is the system BIOS and the device is soldered to the motherboard.
It is Ok for us to have the driver tied to the motherboard. There will
be a model-specific inf-section telling it to check in the BIOS. So,
which one of the two approaches would you choose?

Unfortunately, I still have to do some research on BIOS. It is the first
time I encounter such a task. What confuses me is that I know that when
our testers load a new BIOS into a motherboard it has a size more like
256kB, 512kB… However, I also know that when a DOS starts in the
16-bit mode it is likely doesn’t see all 512kB of the BIOS in its 1MB of
address space. Where is the rest? I don’t know :frowning:

In the first quick test We figured out that when we MmMapIoSpace 64kB at
ffff0000, we can see the good old jmp xxxx:yyyy at fffffff0. I guess we
would better put our table somewhere in these 64kB, then it will
probably be visible from DOS too, which won’t harm…

— Jake Oshins wrote:
> Either method that you describe will work. NT does not reclaim the
BIOS
> area, specifically for reasons like yours.
>
> It makes me curious, though, how much control you have over the
machines
> you care about. Are you talking about the BIOS on an add-in card? Or

> are you talking about something in the system BIOS itself?
>
> If it’s the add-in card, you’re safe in reading your BIOS Base Address

> Register and mapping it with MmMapIoSpace.
>
> If it’s the system BIOS, then you’re probably safe, but you’ve tied
your
> driver to a specific motherboard.
>
> If it isn’t the system BIOS, then adding data to ACPI isn’t feasible,
so
> I assume that it must have been the system BIOS you were talking
about.
>
> - Jake
>

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com