What does the 0x80 port address connect to?

Question

When sending a command and reading the data from a certain chip, say the RTC, different documents say that we should wait for some time before reading from the device to make sure the data is available. Many pieces of code make a dummy read from the port 0x80. I wanted to know to what device this address location is connected, if any. I am talking with respect to the IA-32 PC architecture.

Solution 1

I/O port 0x80 is traditionally used for POST Codes. (POST = Power On Self Test)

While the system is booting, the BIOS will output a series of debug codes to I/O port 0x80. These are indended for debugging a non-booting system.

In most desktop PCs, you can install a POST code debug board, which is basically a small PCI (or ISA) slot board that decodes I/O writes to I/O port 0x80 and displays the value via 7-segment LEDs.

Normally, POST codes flash by very quickly. However, if your system hangs while booting, you can see what the last POST code was, and use this information to troubleshoot the system.

This site contains a list of the standard POST codes for most BIOSes. However, a Computer/Motherboard manufacturer may insert their own POST codes, so the list is not 100% comprehensive.

After a system has begun to boot the Operating System, the POST codes are not very relevant. However, some OS vendors may use POST code boards as a debugging tool, particularly for places in the code where a printf() may not be practical (e.g. Interrupt Service Routines).

Some operating systems will use reads and writes to I/O port 0x80 as a delaying mechanism. If you need to wait a few microseconds for something to complete, it may be impractical to use full-blown sleep() or delay() timers, so performing a "dummy" read/write to a "safe" I/O address is a light-weight solution. Reads and writes to 0x80 are basically gauranteed to not adversely affect the operation of the system, so it is a good choice for such dummy operations.

You will find that with many older/slower peripheral devices (like your RTC chip), it is sometimes necessary to wait a few usec for an I/O write operation to "take effect". A dummy access to 0x80 is a convenient way to do it.

You may also find code that does dummy writes to 0x80 to "flush" the bus of any electrical "echos". On certains platforms, it is possible to write a value to an unused/invalid I/O address, read back from that address, and see the value you just wrote, even though no hardware is actually at that address. However, if you do a dummy write to another address in between (say, I/O port 0x80), you can guard against this.

Solution 2

Those dummy reads implement a delay; from Linux I/O port programming mini-HOWTO:

The inb_p(), outb_p(), inw_p(), and outw_p() macros work otherwise identically to the ones above, but they do an additional short (about one microsecond) delay after the port access; you can make the delay about four microseconds with #define REALLY_SLOW_IO before you #include <asm/io.h>.

These macros normally (unless you #define SLOW_IO_BY_JUMPING, which is probably less accurate) use a port output to port 0x80 for their delay, so you need to give access to port 0x80 with ioperm() first (outputs to port 0x80 should not affect any part of the system). For more versatile methods of delaying, read on.

Solution 3

You can write (and read) to (from) port 0x80 by using this code in a kernel driver:

(Note that some PCs like mine have a WORD at this location so one can write 16 bits to it.)

Windows driver example:
__outword(0x80, 0x00A0);

This may also be used for kernel debug in cases where you do not have a two machine debug system and you can't use debugview traces for any reason (like the system freezes). Port 80 may be keeping your last debug code for you.

Comments

[phoxis]

Adding to the answer: intel.com/support/motherboards/desktop/sb/CS-025434.htm

[myron-semack]

@phoxis Note the codes you listed are unique to Intel motherboards based on their EFI firmware. That list may not apply to other motherboards.

[phoxis]

Yes they are, my point was that we can use the port to make dummy reads and writes to introduce small delay.