S
Simon Wilton
Does any-one have a method for directly reading and writing the CMOS memory
on the CPU card?
TIA
Simon
on the CPU card?
TIA
Simon
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
N
Nikolai Vorontsov
Hi, Simon!
I'm looking for somewhere to squirrel away about 8 bytes of frequently
changing (several times a day) system data that has to be preserved with
power off. http://www.driverlinx.com/DownLoad/DlPortIO.htm
The system will use CF with EWF. I think I could get it written to the CF,
but this does not seem to be an ideal solution. Most CPU boards have unused
areas in the CMOS, and many BIOSes have functions to access them and sort
out the checksum. I know that I can't get at this memory directly, but has
any-one seen a tool to do BIOS calls, or access CMOS directly, like those to
access ports directly?
G
Greg Tinney
Accessing CMOS bytes is a very simple process using using an index/data
register format in the PC port space (index = port 0x70, data = 0x71). To
do this in Windows, you will have to write a driver (I don't know of any
easy Windows-supplied back doors to access this). The driver is pretty
simple, but with some caveats:
1) I assume your driver should not try standard DDK mapping of I/O
ports, as they are already mapped by Window's RTC driver. You would have to
just have to access ports directly with inp and outp (not the general
Microsoft-recommended procedure).
2) RTC/CMOS access is non-atomic. If you use the standard bank 0 of
CMOS, you run a very good chance of creating race conditions with the
OS/BIOS that may be accessing CMOS or more likely the RTC (real-time clock).
3) BIOS probably checksums the first CMOS bank. If you change bytes in
this bank, if you don't update checksum in correct manner, BIOS may complain
on next boot.
4) Be careful about handling of special bits (such as bit 7) of index
register. Any CMOS/RTC specs should discuss these type issues.
5) Remember first several CMOS values in bank 0 are RTC registers, not
actual storage locations.
Many modern chipsets (including Intel's) provide a second bank of CMOS. Use
of this is probably a safer bet in your case. BIOS may use this for storing
setup or escape-D data, though they often skip the 2nd bank and store this
PNP-type data on the same flash chip (FWH) that stores the BIOS code. You
would need to try to ensure that BIOS does not use the second bank also if
you're application is going to access it.
In short, using BIOS to store application data may not be clean, but it is
possible (depending on resources provided by your motherboard). Unless
Windows provides a back-door method for accessing this throught the RTC
driver, you will probably have to write a driver yourself.
register format in the PC port space (index = port 0x70, data = 0x71). To
do this in Windows, you will have to write a driver (I don't know of any
easy Windows-supplied back doors to access this). The driver is pretty
simple, but with some caveats:
1) I assume your driver should not try standard DDK mapping of I/O
ports, as they are already mapped by Window's RTC driver. You would have to
just have to access ports directly with inp and outp (not the general
Microsoft-recommended procedure).
2) RTC/CMOS access is non-atomic. If you use the standard bank 0 of
CMOS, you run a very good chance of creating race conditions with the
OS/BIOS that may be accessing CMOS or more likely the RTC (real-time clock).
3) BIOS probably checksums the first CMOS bank. If you change bytes in
this bank, if you don't update checksum in correct manner, BIOS may complain
on next boot.
4) Be careful about handling of special bits (such as bit 7) of index
register. Any CMOS/RTC specs should discuss these type issues.
5) Remember first several CMOS values in bank 0 are RTC registers, not
actual storage locations.
Many modern chipsets (including Intel's) provide a second bank of CMOS. Use
of this is probably a safer bet in your case. BIOS may use this for storing
setup or escape-D data, though they often skip the 2nd bank and store this
PNP-type data on the same flash chip (FWH) that stores the BIOS code. You
would need to try to ensure that BIOS does not use the second bank also if
you're application is going to access it.
In short, using BIOS to store application data may not be clean, but it is
possible (depending on resources provided by your motherboard). Unless
Windows provides a back-door method for accessing this throught the RTC
driver, you will probably have to write a driver yourself.