Reading physical Address 0xE0000

NTDEV
1

Hi All,

My application needs to read the physical memory 0xE0000 (BIOS contents), so
I have written a driver which takes the pysical memory, maps it and reads
the contents and return them to the application.

For this I am using MmMapIOSpace to map the physical addresss and
READ_REGISTER_UCHAR_BUFFER to read memory contents.

My problems is the driver is able to read the contents of the memory on some
systems, but returning junk character (0xFF) on some systems. But if I read
address 0xF0000 it is working correctly on all the systems

Is there any special characteristics for address 0xE0000, why am I seeing
this behaviour.

Any information is helpful.

Thanks,
Kedar.

2

Is your driver loading on the devnode for the device with the bios? Are
you waiting until the lower drivers have processed a START IRP to ensure
the device is powered on?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kedar
Sent: Tuesday, May 11, 2004 12:53 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Reading physical Address 0xE0000

Hi All,

My application needs to read the physical memory 0xE0000 (BIOS
contents), so I have written a driver which takes the pysical memory,
maps it and reads the contents and return them to the application.

For this I am using MmMapIOSpace to map the physical addresss and
READ_REGISTER_UCHAR_BUFFER to read memory contents.

My problems is the driver is able to read the contents of the memory on
some systems, but returning junk character (0xFF) on some systems. But
if I read address 0xF0000 it is working correctly on all the systems

Is there any special characteristics for address 0xE0000, why am I
seeing this behaviour.

Any information is helpful.

Thanks,
Kedar.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Hi,

I may be totally wrong but what a particular system may map to old real
mode bios addresses
under 1MB boundary is up to the manufacturers. Given that current
systems have much larger
bios implementations that may not fit in old 8086 bios area I would
think that manufacturers may
choose to place this some place high in 4GB memory range. Address
0xF000 may contain up to
64K of bios image that is at least in part able to execute in 8086
mode. 0xE000 may not have any
bios code mapped in as that was the way original IBM design had it.

ned

Kedar wrote:

Hi All,

My application needs to read the physical memory 0xE0000 (BIOS contents), so
I have written a driver which takes the pysical memory, maps it and reads
the contents and return them to the application.

For this I am using MmMapIOSpace to map the physical addresss and
READ_REGISTER_UCHAR_BUFFER to read memory contents.

My problems is the driver is able to read the contents of the memory on some
systems, but returning junk character (0xFF) on some systems. But if I read
address 0xF0000 it is working correctly on all the systems

Is there any special characteristics for address 0xE0000, why am I seeing
this behaviour.

Any information is helpful.

Thanks,
Kedar.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@colorts.com.au
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Hi All,

My driver loads as other drivers and does not sit in the BIOS drivers stack.
Whenever an application sends an IOCTL with the physical address to be read,
the driver does the following code

MappedAddr =
(PUCHAR)MmMapIoSpace(physicaladdress,pAddrInfo->ulNoofBytes,MmNonCached);
if(MappedAddr)
{
ULONG bytestoread = pAddrInfo->ulNoofBytes;
RtlZeroMemory(MappedAddr,pAddrInfo->ulNoofBytes);
READ_REGISTER_BUFFER_UCHAR(MappedAddr,Contents,bytestoread);
//copy the buffer to user buffer
RtlCopyMemory(outputBuffer,Contents,bytestoread);
information = bytestoread;
ExFreePool(Contents);
MmUnmapIoSpace(MappedAddr,bytestoread);
}

The code works fine for the address 0xF0000, but fails for 0xE0000. But when
I dump the contents of 0xE0000 from the Debug utility there are some
contents in that.

Any information is helpful.

Thanks,
Kedar.

5

I don’t really understand the phrase “BIOS drivers stack.” But from it, I’m
guessing that you’re talking about an add-in BIOS on a plug-in card’s ROM.
In that case, you’re not guaranteed that it is mapped into memory unless the
device is started. Furthermore, the PCI spec explicitly allows a device to
share decoders between its “option ROM” and other BARs, meaning that even
when the device is started the card may not decode its ROM unless it has
been specifically set to do so by a device-aware driver.

In any case, I think that you’re out of luck until you get your driver into
the right stack.

–
Jake Oshins
Windows Kernel Group

This posting is provided “AS IS” with no warranties, and confers no rights.
“Kedar” wrote in message news:xxxxx@ntdev…
> Hi All,
>
> My driver loads as other drivers and does not sit in the BIOS drivers
> stack.
> Whenever an application sends an IOCTL with the physical address to be
> read,
> the driver does the following code
>
> MappedAddr =
> (PUCHAR)MmMapIoSpace(physicaladdress,pAddrInfo->ulNoofBytes,MmNonCached);
> if(MappedAddr)
> {
> ULONG bytestoread = pAddrInfo->ulNoofBytes;
> RtlZeroMemory(MappedAddr,pAddrInfo->ulNoofBytes);
> READ_REGISTER_BUFFER_UCHAR(MappedAddr,Contents,bytestoread);
> //copy the buffer to user buffer
> RtlCopyMemory(outputBuffer,Contents,bytestoread);
> information = bytestoread;
> ExFreePool(Contents);
> MmUnmapIoSpace(MappedAddr,bytestoread);
> }
>
> The code works fine for the address 0xF0000, but fails for 0xE0000. But
> when
> I dump the contents of 0xE0000 from the Debug utility there are some
> contents in that.
>
> Any information is helpful.
>
> Thanks,
> Kedar.
>
>
>