io port 0x80 - usage for debugging during OS development

[feryno]

I have an ASUS workstation MB with G.P. Diagnosis Card. Firmware displays some hexadecimal codes during initialization so in case of fail you can see the failing code and consult MB manual what is the meaning of the displayed code. By reversing firmware binary I found that the firmware writes the 1 byte hexadecimal code into io port 0x80.

Searching forum I found only this topic where they discussed usage of port 0x80 for linux delay
viewtopic.php?f=1&t=33812

Ralf Brown information about this port:

----------P0080------------------------------
PORT 0080 - MANUFACTURING DIAGNOSTICS PORT
Note: sometimes used for a POST hex display

0080 -W Manufacturing Diagnostics port

Of course sending debugging information through serial port transfers more information than 1 displayed byte = 8 bits. There could be a situation when you appreciate this very limited possibility as a last instance choice, e.g. display not yet in working stage, serial port not available, everything runs OK in emulator but you need to run on real hardware where you reveal a problem which was previously silent in emulator. I do not know more MB vendors which use/display this information about POST stage. Newer ASUS MB do not have this G.P. cards included anymore. In my MB the card is inserted into pins dedicated for TPM module (TPM module is not present at my old MB and should be purchased separately). I found that some of newer ASUS Gaming MB have this hexadecimal display wired onto motherboard, e.g. ASUS ROG STRIX X570-E GAMING, its marketing name is Q-code LED. They are usefull when you cause an instability due overclocking settings.
Another usage of this port is to quickly find some interesting parts of firmware during reversing, like this part of code from my firmware which is executed at initializing memory of system:

loc_FFFFF83C:
mov al, 2
out 80h, al ; manufacture's diagnostic checkpoint (POST code)
mov esi, offset loc_FFFFF84D
movd mm7, esi
jmp loc_FFFFF912

Consulting error codes in your motherboard manual you can quickly find the part you are interested in reversing, you just scan for hexadecimal sequence
B0 XX E6 80 (where XX is the hexadecimal error code you found in your motherboard manual, e.g. 02 would be used in the above code sample).

For ASUS you need some older workstation (WS) motherboard type and for newer you need to find some from GAMING series.
I wonder if there is another vendor with this feature. If you have any MB with such a feature please let us know its name.

There is also POST card (PCI add-in card), which is installed in PCI bus connector 1.
https://www.intel.com/content/www/us/en ... -kits.html

I prepared a small 512 bytes boot sector which just teletypes hexadecimal characters written on keyboard into this diagnostic device. Pressing ESC on keyboard continues the booting process.

io_port_80h_POST_diagnostic_message.zip

io port 0x80 diagnostic message

(1.03 KiB) Downloaded 158 times

Here a video what does it do:
https://youtu.be/NKjZQtSTzAM

[Octocontrabass]

Just keep in mind you might not be able to debug ACPI this way.

Here's the list of affected systems.

[xeyes]

Interesting find.

Many years ago I've seen lots of usage of the PCI POST card at a custom PC builder whose business also include repairing computers.

From what I can remember the usage was simple:
For example the BIOS might determine that a RAM module is no good and refuse to boot. It might also generate a few random beeps but to a typical consumer the computer is simply broken.
The consumer would then bring it in, the PC builder's people would plug in the POST card and try to power on, this time the BIOS will display a special code about it.
They would then read the manual, determine that the code means that the RAM is no good and replace the DIMMs one by one.
The POST cards paid for themselves really fast:)

I wonder if there is another vendor with this feature. If you have any MB with such a feature please let us know its name.

Rare to see in consumer space now, the TPM connector is LPC (ISA) and most consumer boards no longer have ISA slots.

You can buy the PCI version on Ebay for cheap, but my feeling is that the BIOS has to route it instead of just pushing numbers out of the port to make it work, thus a board without this feature might have a BIOS that doesn't do the routing. Nowadays vendors making the boards and writing FW all have access to Intel/AMD's JTAG boxes, it's much easier to use that instead so I can't imagine them too excited to keep the PCI POST code feature around in the code.

Simnow still has support and also shows that there are (were?) more ports designated for this purpose, see the screenshot below:

[rdos]

I've not made use of it, but my AMD Threadripper motherboard has a two-digit hex-display that outputs various codes during boot.

Still, at my stage of stability, the crash screen is far more useful and it works in virtually all stages of the kernel startup. However, to be able to inspect things after a crash, I need a PS/2 keyboard, and so I typically only buy motherboards that have a PS/2 connector.

[feryno]

Octocontrabass - interesting info, thank you very much.
xeyes - maybe I should try to buy such PCI card, then I have more possibilities which motherboards to buy. I used SimNow public 4.6.2 a lot, pity that there is no newer public version available. Only one of all the included processors has SVM virtualization present (vp_bd_phase1.bsd) luckily this was enough for my development.
rdos - what is your motherboard vendor and type? PS/2 keyboard is also a must for me, together with serial port (COM).
If possible I will always buy motherboard with this hexadecimal code display feature.

[xeyes]

xeyes - maybe I should try to buy such PCI card, then I have more possibilities which motherboards to buy. I used SimNow public 4.6.2 a lot, pity that there is no newer public version available. Only one of all the included processors has SVM virtualization present (vp_bd_phase1.bsd) luckily this was enough for my development.

I can also run SVM on a CPU called "Family10hDR-L1_B2.id", but you are absolutely correct, would be nice to have a version that's not more than a decade old.

[rdos]

rdos - what is your motherboard vendor and type? PS/2 keyboard is also a must for me, together with serial port (COM).
If possible I will always buy motherboard with this hexadecimal code display feature.

It's this motherboard:
https://www.msi.com/Motherboard/X399-SLI-PLUS

[feryno]

Code: Select all

out 80h,al

does not work anymore on newer motherboards, but writing word or doubleword works, it just writes the low byte (AL) and the higher bits are ignored:

Code: Select all

out 80h,eax

Although there are TL631 cards available, they display only the last one hexadecimal character.
There is a better solution which records the whole stream of data written into i/o port 80h.

ASUS motherboards have 6-1 header named COM_DEBUG which I'm using successfully.
ASROCK has a 4-1 header UART1. I did not test it yet.

The ASUS pinout is here:
https://dlcdnets.asus.com/pub/ASUS/mb/E ... UM_WEB.pdf
chapter 2-17

COM_DEBUG_ASUS.png (3.18 KiB) Viewed 5285 times

The motherboard from the above link has also a jumper to enable the debug port to work (at the cost of redirection of TxD from COM3 to COM_DEBUG - chapter 2-9) so for your motherboard you should very likely adjust some jumper or change some menu in UEFI setup.

For ASROCK I found a settings in UEFI menu to enable the UART1:
https://download.asrock.com/Manual/H510M-HDVM.2.pdf

Serial Port/UART Switch
Select Serial Port or UART for Port 80 debug.

The ASROCK pinout is described here without any guarantee:
https://www.reddit.com/r/buildapc/comme ... re_i_have/

There's three pins, pinout appears to be:
1. 5.1V
2. 3.7V
3. Empty
4. GND

and this:

It spews random data on pin #2 (3.7V, 115200 8N1)

Then you need a USB to TTL adapter or real serial port on your target machine which receives the data. Something like this, it is very cheap, this one costed less than 2 EUR https://pajenicko.cz/prevodnik-wch-ch34 ... a-ttl-uart
Buy a TTL which chip is supported in your OS and download necessary drivers to make it working.

Connect GND (pin 2) from MB to GND pin of TTL (the black cable). Connect TxD (pin 1, transmit data) from MB to RxD pin (receive) of TTL (the white cable, sorry for the white color but I did not have any other color)

On the target machine run putty utility to read the data. If your target machine runs ms win, download it e.g. from here:
https://www.chiark.greenend.org.uk/~sgt ... atest.html

If your target machine runs ms win, launch cmd.exe and this command:

reg query HKLM\HARDWARE\DEVICEMAP\SERIALCOMM

The output of the command looks like:

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM
\Device\Serial2 REG_SZ COM4

Use the putty to record data and also to save a log file as the data are binary (but displayed ASCII), so for reading full hexa values you need to look into the log file using binary viewer. The data are transmitted using this settings:

Code: Select all

baudrate: 115200
data bits: 8
stop bits: 1
parity: none
flow control: none

This is useful for finding a problem when starting a machine or for reversing a firmware (you can find which uefi module sent a hexa code of your interest e.g. using UEFItool and its search menu).
I hope this will be useful for at least someone. It is required in unusual and strange situation. All my machines have serial port, but I have to let it be used by hyper-v and kernel debugger, graphics card is used by guest OS, so for my parent hypervisor this is a way to go.

Here a video (quite low quality)
https://youtu.be/Gnm_tuARqVI

Here the uefi debugging tool with the capability of writing into i/o port 80:
https://board.flatassembler.net/topic.php?t=9689

[FrankRay78]

Out of interest, has anyone managed to emulate debug port 0x80 in QEMU?

I've tried various out commands eg.

Code: Select all

out 80h, al (/ax/eax)

but QEMU monitor for system-i386 always returns:

Code: Select all

i 0x80
portl[0x0080] = 0xffffffff

I've even tried to explicitly set the debug port from the QEMU monitor ie.

Code: Select all

o 0x80 0xAA

with no luck.

[MichaelPetch]

I think QEMU uses port 0xe9. In QEMU and BOCHS you can simply write to port 0xe9 to output debug data. on QEMU you could output it to STDIO with the option `-debugcon stdio`. In BOCHs you can add a `port_e9_hack: enabled=1` to the config file (or change it from =0 to =1 if the entry exists already.

[feryno]

Few months ago I tried ASROCK N100DC-ITX motherboard, by connecting motherboard UART connector (pins 2, 4, pinout matches the description I posted before) to a TTL adapter and it also worked well.
out byte to the i/o port 80 does nothing, it is necessary to out word or doubleword to transfer the data to the TTL adapter - only the lowest byte is transferred, upper bits do not matter and are not transferred

[FrankRay78]

I can't seem to get anything written to port 0xe9 in QEMU, is there anything obvious wrong with the following?

Code: Select all

;mov al, 0xaa
;out 0xe9, al

;mov ax, 0xaabb
;out 0xe9, ax

mov eax, 0xaabbaabb
out 0xe9, eax

jmp $

times 510-($-$$) db 0
dw 0xaa55

And

Code: Select all

nasm -f bin -o kernel.bin loader.asm
qemu-system-i386 kernel.bin -cpu pentium3 -no-reboot -no-shutdown -monitor stdio

I've tried each of the three NASM out statements above, commenting/uncommenting accordingly, but on each occasion the QEMU monitor shows the following:

Code: Select all

i 0xe9
portl[0x00e9] = 0xffffffff

---

UPDATE - Philipp Schuster writes "QEMU exposes the debugcon device at I/O port 0xe9 to a guest. It needs zero configuration from a guest, and you can directly start writing ASCII, UTF-8, or whatever data you like to it." link

[nullplan]

The output is supposed to go to QEMU's stdout, not to the monitor.

[FrankRay78]

Thank you, I've got it working by removing the monitor switch and simply writing a single byte.

Code: Select all

mov al, 'F'
out 0xe9, al

jmp $

times 510-($-$$) db 0
dw 0xaa55

And

Code: Select all

nasm -f bin -o kernel.bin loader.asm
qemu-system-i386 -drive format=raw,file=kernel.bin -debugcon stdio

Emits the following:

Code: Select all

D:\Source\NASM\Out>qemu-system-i386 -drive format=raw,file=kernel.bin -debugcon stdio

(qemu:2640): Gtk-WARNING **: 11:54:08.252: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
F