HI All,
We are designing an application where some data is to be passed from BIOS to the Driver. The data is to reside on some location on the system RAM. Can anyone help me in providing pointers as to how I can reserve some area in RAM in BIOS and ensure that Windows OS (XP /2k) does not use / overwrite that area and later my driver should be allowed to access this memory area.
Should we create a device node in ACPI BIOS?
Thanks in advance.
regards,
john
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I suppose you could create an ACPI device node, and then set up a PnP driver with inf to load for that device. It might be a little awkward to meet ACPI specs on resource inheritance and get the memory declared in the right place, but you could probably do it.
Alternately you could have the ACPI bios declare the memory range as firmware reserved so that NT won’t use it. You could then have a root enumerated driver simply map that area and use it for communications.
Loren
John White wrote:
We are designing an application where some data is to be passed from
BIOS to the Driver. The data is to reside on some location on the
system RAM.
What are you actually trying to do? How MUCH data do you want to pass
from the BIOS to your driver, and how frequently do you want to do it?
The second part of your question (“the data is to reside on some
location on the system RAM”) presumes a solution… but there may be a
better way to accomplish what you are trying to do.
Peter
OSR
The program in BIOS has a magic word that a driver in the OS will need. So we are trying to figure out the best means of passing the data to the driver in the OS.
The size of data would be around 300 bytes.
We need to do this everytime the system boots.
We are planning to use an area of system RAM to be reserved for this purpose. Just looking for some easy way of reserving this memory so that the code changes in the BIOS is minimal. Wish if this could be done without changing the BIOS.
Thanks
regards,
john
“PeterGV (OSR)” wrote:
John White wrote:
>
> We are designing an application where some data is to be passed from
> BIOS to the Driver. The data is to reside on some location on the
> system RAM.
What are you actually trying to do? How MUCH data do you want to pass
from the BIOS to your driver, and how frequently do you want to do it?
The second part of your question (“the data is to reside on some
location on the system RAM”) presumes a solution… but there may be a
better way to accomplish what you are trying to do.
Peter
OSR
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Yahoo! Mail
Stay connected, organized, and protected. Take the tour
try writing it to the EBDA, I could successfully boot windows after
writing data to that section without windows corrupting it.
On 8/24/05, John White wrote:
> The program in BIOS has a magic word that a driver in the OS will need. So
> we are trying to figure out the best means of passing the data to the driver
> in the OS.
>
> The size of data would be around 300 bytes.
>
> We need to do this everytime the system boots.
>
> We are planning to use an area of system RAM to be reserved for this
> purpose. Just looking for some easy way of reserving this memory so that the
> code changes in the BIOS is minimal. Wish if this could be done without
> changing the BIOS.
>
> Thanks
>
> regards,
> john
>
>
>
> “PeterGV (OSR)” wrote:
> John White wrote:
> >
> > We are designing an application where some data is to be passed from
> > BIOS to the Driver. The data is to reside on some location on the
> > system RAM.
>
> What are you actually trying to do? How MUCH data do you want to pass
> from the BIOS to your driver, and how frequently do you want to do it?
>
> The second part of your question (“the data is to reside on some
> location on the system RAM”) presumes a solution… but there may be a
> better way to accomplish what you are trying to do.
>
> Peter
> OSR
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> ________________________________
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour — Questions? First
> check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 You are
> currently subscribed to ntdev as: xxxxx@gmail.com To unsubscribe send a
> blank email to xxxxx@lists.osr.com
>
>
Hi Bedanto,
Thanks for your response. Some computers have EBDA some donot have EBDA can you please provide pointers on how to find if EBDA is present on a computer or not.
Thanks in advance,
regards,
john
Bedanto wrote:
try writing it to the EBDA, I could successfully boot windows after
writing data to that section without windows corrupting it.
On 8/24/05, John White wrote:
> The program in BIOS has a magic word that a driver in the OS will need. So
> we are trying to figure out the best means of passing the data to the driver
> in the OS.
>
> The size of data would be around 300 bytes.
>
> We need to do this everytime the system boots.
>
> We are planning to use an area of system RAM to be reserved for this
> purpose. Just looking for some easy way of reserving this memory so that the
> code changes in the BIOS is minimal. Wish if this could be done without
> changing the BIOS.
>
> Thanks
>
> regards,
> john
>
>
>
> “PeterGV (OSR)”
wrote:
> John White wrote:
> >
> > We are designing an application where some data is to be passed from
> > BIOS to the Driver. The data is to reside on some location on the
> > system RAM.
>
> What are you actually trying to do? How MUCH data do you want to pass
> from the BIOS to your driver, and how frequently do you want to do it?
>
> The second part of your question (“the data is to reside on some
> location on the system RAM”) presumes a solution… but there may be a
> better way to accomplish what you are trying to do.
>
> Peter
> OSR
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> ________________________________
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour — Questions? First
> check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 You are
> currently subscribed to ntdev as: xxxxx@gmail.com To unsubscribe send a
> blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Start your day with Yahoo! - make it your home page
If the magic cookie is in paged in bios space when the boot loaders run (and I assume this is some sort of crypto thing you are going to use to enable access to things) then the trivial thing would be for your driverentry routine to just scan the bios space looking for some sort of magic cookie word that starts the data, then suck it up from there.
That is actually the standard way that some assorted bios extension tables are stored, and may be how your data is already stored.
Of course, if you aren’t a boot loader you should still be able to grab it later without any problems. Worst you would have to do is map in the bios space to your driver for a moment.
Alternately, if you have control of the bios you obviously have control of the platform and know about the memory layout possibilities. You could just have the bios stick the thing at 1MB, and set up the memory mapping in the ACPI tables to show 4K at 1MB as formware reserved. Then you know exactly where to grab the cookie even if you can’t or don’t want to scan the ACPI tables to find it.
Loren
John White wrote:
The size of data would be around 300 bytes.
We need to do this everytime the system boots.
We are planning to use an area of system RAM to be reserved for this
purpose. Just looking for some easy way of reserving this memory so that
the code changes in the BIOS is minimal. Wish if this could be done
without changing the BIOS.
Sounds like the classic “we want to pass the encryption key from a
hooked BIOS INT 13 routine to the Windows storage filter driver” problem.
Since this is a one-time-only thing on boot, then your best bet is
probably to just slap the data into a pre-defined location in physical
memory (followed by some sort of checksum) and then retrieve the data
ASAP with a boot-loading driver.
No actual change to the BIOS code will be necessary in this case.
The downside of this approach (did I just answer a question like this in
this forum recently??) is that whichever 300 bytes of memory you decide
to use – based on empirical testing – it’s possible that a service
pack or OS release will eventually wind-up using that memory.
An alternative that’s commonly used is storing the data on the boot disk
in one of the unused regions. Personally, I prefer that approach.
I wouldn’t go through the hassle of creating an ACPI device and passing
the data out with a pre-defined method. That’s overkill in this
situation for sure.
Peter
OSR
Yes but … storing the data on the boot disk in one of the unused regions
is fine … if they aren’t being used. Seagate trusted drives are now using
those regions and will not allow an un-trusted write to those areas. The
upside to that is that once you have established trust with the drive, you
now have on-drive smartcard capability with multiple dCards.
–
The personal opinion of
Gary G. Little
“PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> John White wrote:
>> The size of data would be around 300 bytes.
>> We need to do this everytime the system boots.
>> We are planning to use an area of system RAM to be reserved for this
>> purpose. Just looking for some easy way of reserving this memory so that
>> the code changes in the BIOS is minimal. Wish if this could be done
>> without changing the BIOS.
>>
>
> Sounds like the classic “we want to pass the encryption key from a hooked
> BIOS INT 13 routine to the Windows storage filter driver” problem.
>
> Since this is a one-time-only thing on boot, then your best bet is
> probably to just slap the data into a pre-defined location in physical
> memory (followed by some sort of checksum) and then retrieve the data ASAP
> with a boot-loading driver.
>
> No actual change to the BIOS code will be necessary in this case.
>
> The downside of this approach (did I just answer a question like this in
> this forum recently??) is that whichever 300 bytes of memory you decide to
> use – based on empirical testing – it’s possible that a service pack or
> OS release will eventually wind-up using that memory.
>
> An alternative that’s commonly used is storing the data on the boot disk
> in one of the unused regions. Personally, I prefer that approach.
>
> I wouldn’t go through the hassle of creating an ACPI device and passing
> the data out with a pre-defined method. That’s overkill in this situation
> for sure.
>
> Peter
> OSR
>
Gary G. Little wrote:
Yes but … storing the data on the boot disk in one of the unused regions
is fine … if they aren’t being used. Seagate trusted drives are now using
those regions and will not allow an un-trusted write to those areas. The
upside to that is that once you have established trust with the drive, you
now have on-drive smartcard capability with multiple dCards.
Interesting. Completely OT: Are there any white papers on all this
stuff Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked,
but I’m interested…
Peter
OSR
Yes there are … somewhere … I’ll see what I can find for you. Phil and I
wrote one but it was internal to what we
were doing with regards to ATA pass through and XP.
–
Gary G. Little
“PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> Gary G. Little wrote:
>> Yes but … storing the data on the boot disk in one of the unused
>> regions is fine … if they aren’t being used. Seagate trusted drives are
>> now using those regions and will not allow an un-trusted write to those
>> areas. The upside to that is that once you have established trust with
>> the drive, you now have on-drive smartcard capability with multiple
>> dCards.
>>
>
> Interesting. Completely OT: Are there any white papers on all this stuff
> Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> interested…
>
> Peter
> OSR
>
And Phil just kicked me in the shins. It seems that there are user sectors
that are generally not used, such as an area between LBA 0 and LBA 64.
That’s an used area of 63 sectors. So I guess I stand corrected.
–
Gary G. Little
“PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> Gary G. Little wrote:
>> Yes but … storing the data on the boot disk in one of the unused
>> regions is fine … if they aren’t being used. Seagate trusted drives are
>> now using those regions and will not allow an un-trusted write to those
>> areas. The upside to that is that once you have established trust with
>> the drive, you now have on-drive smartcard capability with multiple
>> dCards.
>>
>
> Interesting. Completely OT: Are there any white papers on all this stuff
> Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> interested…
>
> Peter
> OSR
>
HI All,
Thank you for your valuable suggestions.
It looks like the best bet is the boot disk.
regards,
john
“Gary G. Little” wrote:
And Phil just kicked me in the shins. It seems that there are user sectors
that are generally not used, such as an area between LBA 0 and LBA 64.
That’s an used area of 63 sectors. So I guess I stand corrected.
–
Gary G. Little
“PeterGV (OSR)”
wrote in message news:xxxxx@ntdev…
> Gary G. Little wrote:
>> Yes but … storing the data on the boot disk in one of the unused
>> regions is fine … if they aren’t being used. Seagate trusted drives are
>> now using those regions and will not allow an un-trusted write to those
>> areas. The upside to that is that once you have established trust with
>> the drive, you now have on-drive smartcard capability with multiple
>> dCards.
>>
>
> Interesting. Completely OT: Are there any white papers on all this stuff
> Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> interested…
>
> Peter
> OSR
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
Start your day with Yahoo! - make it your home page
Here is something about it on Seagate’s web site:
http://www.seagate.com/newsinfo/newsroom/success/D2g42.html
It is mostly marketing stuff with inadequate details, but I like the idea.
Should be safe from even the data recovery guys unless the requestor can
provide the password.
“PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> Gary G. Little wrote:
>> Yes but … storing the data on the boot disk in one of the unused
>> regions is fine … if they aren’t being used. Seagate trusted drives are
>> now using those regions and will not allow an un-trusted write to those
>> areas. The upside to that is that once you have established trust with
>> the drive, you now have on-drive smartcard capability with multiple
>> dCards.
>>
>
> Interesting. Completely OT: Are there any white papers on all this stuff
> Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> interested…
>
> Peter
> OSR
>
well john,
may be the disk looks like the best bet, but tell me, you need to
*load* this information in memory to use it, and that is where the
problem lies, right? Wen I was doing similar stuff, what I found was
emperical approach to loacate a free memory address was a pain. No
matter how hard I tried, windows always over wrote my mem space (
there is no protection at boot time real-mode). Thus I moved my *fav*
data to the top of EBDA and changed the BIOS EBDA size to (size -
MYDATASIZE) and bingo things worked.
ALl machines these days have EBDA, I hope u don’t need to write code
for dinosaur machines, or do u?
On 8/25/05, David J. Craig wrote:
> Here is something about it on Seagate’s web site:
> http://www.seagate.com/newsinfo/newsroom/success/D2g42.html
>
> It is mostly marketing stuff with inadequate details, but I like the idea.
> Should be safe from even the data recovery guys unless the requestor can
> provide the password.
>
> “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > Gary G. Little wrote:
> >> Yes but … storing the data on the boot disk in one of the unused
> >> regions is fine … if they aren’t being used. Seagate trusted drives are
> >> now using those regions and will not allow an un-trusted write to those
> >> areas. The upside to that is that once you have established trust with
> >> the drive, you now have on-drive smartcard capability with multiple
> >> dCards.
> >>
> >
> > Interesting. Completely OT: Are there any white papers on all this stuff
> > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> > interested…
> >
> > Peter
> > OSR
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Hi;
You could try this out. Get the amount of RAM installed on
the system say X MB. Start the kernel with /MAXMEM=X-1MB, there by
reserving the Top 1 Mb of physical memory for your self. Then your
driver can access this memory by MmGetVirtualForPhysical(there by also
document this function).
Regards
Faraz.
On 8/24/05, John White wrote:
>
>
>
> HI All,
> We are designing an application where some data is to be passed from BIOS to
> the Driver. The data is to reside on some location on the system RAM. Can
> anyone help me in providing pointers as to how I can reserve some area in
> RAM in BIOS and ensure that Windows OS (XP /2k) does not use / overwrite
> that area and later my driver should be allowed to access this memory area.
>
> Should we create a device node in ACPI BIOS?
>
> Thanks in advance.
>
> regards,
> john
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 You are
> currently subscribed to ntdev as: xxxxx@gmail.com To unsubscribe send
> a blank email to xxxxx@lists.osr.com
Hii , i am new in the field of Windows driver development.I want to develop
a driver for the printer.In doing so i am facing with 2 problems:
-
I want to customize Default " Printer Document Property page" . I am able
to add a new Tab on that. But i am unable to rename the existing one i.e.
“Layout” & “Paper/Quality” Tabs.
How can i do that ?
-
Is it possible to kill the default "Document Property page " & show my
customize one.
Please tell me asap.Its very urgent.
Mail Id: xxxxx@netcreativemind.com
Regards
asim siddiqui
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Faraz Ahmed
Sent: 25. ágúst 2005 13:17
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Sharing memory between BIOS and Driver
Hi;
You could try this out. Get the amount of RAM installed on
the system say X MB. Start the kernel with /MAXMEM=X-1MB, there by
reserving the Top 1 Mb of physical memory for your self. Then your
driver can access this memory by MmGetVirtualForPhysical(there by also
document this function).
Regards
Faraz.
On 8/24/05, John White wrote:
>
>
>
> HI All,
> We are designing an application where some data is to be passed from BIOS
to
> the Driver. The data is to reside on some location on the system RAM. Can
> anyone help me in providing pointers as to how I can reserve some area in
> RAM in BIOS and ensure that Windows OS (XP /2k) does not use / overwrite
> that area and later my driver should be allowed to access this memory
area.
>
> Should we create a device node in ACPI BIOS?
>
> Thanks in advance.
>
> regards,
> john
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 You are
> currently subscribed to ntdev as: xxxxx@gmail.com To unsubscribe
send
> a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Try MmMapIoSpace
Or yes, try ACPI.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: John White
To: Windows System Software Devs Interest List
Sent: Wednesday, August 24, 2005 10:13 AM
Subject: [ntdev] Sharing memory between BIOS and Driver
HI All,
We are designing an application where some data is to be passed from BIOS to the Driver. The data is to reside on some location on the system RAM. Can anyone help me in providing pointers as to how I can reserve some area in RAM in BIOS and ensure that Windows OS (XP /2k) does not use / overwrite that area and later my driver should be allowed to access this memory area.
Should we create a device node in ACPI BIOS?
Thanks in advance.
regards,
john
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@storagecraft.com To unsubscribe send a blank email to xxxxx@lists.osr.com
Sorry, but convert the disk to GPT and the things will go other way 
0-63 gap is a usual way of creating the MBR partition structure, goes
back to MS-DOS compatibility. Even with MBR you can create the partition
structure where the very first partition on the disk will start at LBA 1,
instead of LBA == TrackSize (63 is the track size for modern disks with faked
CHS values).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Gary G. Little”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 25, 2005 5:00 AM
Subject: Re:[ntdev] Sharing memory between BIOS and Driver
> And Phil just kicked me in the shins. It seems that there are user sectors
> that are generally not used, such as an area between LBA 0 and LBA 64.
> That’s an used area of 63 sectors. So I guess I stand corrected.
>
> –
> Gary G. Little
>
> “PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> > Gary G. Little wrote:
> >> Yes but … storing the data on the boot disk in one of the unused
> >> regions is fine … if they aren’t being used. Seagate trusted drives are
> >> now using those regions and will not allow an un-trusted write to those
> >> areas. The upside to that is that once you have established trust with
> >> the drive, you now have on-drive smartcard capability with multiple
> >> dCards.
> >>
> >
> > Interesting. Completely OT: Are there any white papers on all this stuff
> > Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> > interested…
> >
> > Peter
> > OSR
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Your BIOS hook code can pose itself to the very top of the 640KB of low real-mode memory, hook int 11h and int 15h and pose itself as the EBIOS area not avaliable for the OS. If there was already the EBIOS area, then the hook code must extend it down.
I think this will be the safe way.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: John White
To: Windows System Software Devs Interest List
Sent: Thursday, August 25, 2005 8:01 AM
Subject: Re:[ntdev] Sharing memory between BIOS and Driver
HI All,
Thank you for your valuable suggestions.
It looks like the best bet is the boot disk.
regards,
john
“Gary G. Little” wrote:
And Phil just kicked me in the shins. It seems that there are user sectors
that are generally not used, such as an area between LBA 0 and LBA 64.
That’s an used area of 63 sectors. So I guess I stand corrected.
–
Gary G. Little
“PeterGV (OSR)” wrote in message news:xxxxx@ntdev…
> Gary G. Little wrote:
>> Yes but … storing the data on the boot disk in one of the unused
>> regions is fine … if they aren’t being used. Seagate trusted drives are
>> now using those regions and will not allow an un-trusted write to those
>> areas. The upside to that is that once you have established trust with
>> the drive, you now have on-drive smartcard capability with multiple
>> dCards.
>>
>
> Interesting. Completely OT: Are there any white papers on all this stuff
> Seagate’s doing? Encryption/trusted/etc?? Not that I’ve looked, but I’m
> interested…
>
> Peter
> OSR
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
------------------------------------------------------------------------------
Start your day with Yahoo! - make it your home page — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@storagecraft.com To unsubscribe send a blank email to xxxxx@lists.osr.com