Hello Maciej,
14.09.2021 12:24, Maciej W. Rozycki:
Would you be able to share a disassembly of the piece of BIOS code in
question? I can read x86 assembly, so maybe the interpretation of the
10/28/41/89 cookie can be inferred from it. The high nibble looks
remarkably like a bit lane selector and swizzling is clearly visible, but
Ok, I've solved the puzzle.
High nibble is a ready-to-use bitmask for chipset reg 0x44 (so indeed,
it is 1 << X).
Now, in low nibble, bit 0 selects one of two (0x42 or 0x43) chipset
registers and further bit 3 selects one of two halves, and bits 1 and 2
are apparently ignored. So actually, 10-28-41-89 is then just a freaky
representation of simple 1-2-3-4 numbering. Good news it is exactly the
numbering I chose when converting from $IRT to the supported $PIR
format, and then it just worked (Some more details about my testing with
this converted table where reported in my followup messages a bit
earlier, you have probably seen them already).
Here is the relevant code with my remarks:
f9c1d: test al, 0x01 // Here AL bit 0 = Edge/Level CMOS setting.
f9c1f: pushf
f9c20: mov ah, dh // Here DH = PIRQ from $IRT table.
f9c22: shr ah, 4 // PIRQ's high nibble is a mask to set/clr E/L bit in
reg 44 (1 << X)
f9c25: mov al, 0x44 // AH is ignored.
f9c27: call read_chipset_reg_AL // Register value returned in AL
f9c2a: or al, ah
f9c2c: popf
f9c2d: jnz .+4 (9c33)
f9c2f: not ah
f9c31: and al, ah
f9c33: mov ah, al
f9c35: mov al, 0x44 // Write AH to chipset register number 0x44.
f9c37: call write_chipset_reg_AL
f9c3a: mov al, 0x42
f9c3c: mov ah, dh
f9c3e: and ah, 0x01
f9c41: add al, ah // PIRQ's bit 0 is reg 42/43 selector (X >> 1)
f9c43: mov ah, al // AH is ignored
f9c45: call read_chipset_reg_AL // Register value returned in AL
f9c48: test dh, 0x08 // PIRQ's bit 3 is reg's nibble selector (X & 1)
f9c4b: jz .+3 (9c50) // Here 0 value selects lower nibble.
f9c4d: ror al, 0x04
f9c50: and al, 0xf0
f9c52: or al, dl // Here DL contains wanted IRQ number to set.
f9c54: test dh, 0x08
f9c57: jz.+3 (9c5c)
f9c59: ror al, 0x04
f9c5c: xchg ah, al
f9c5e: call write_chipset_reg_AL
I fail to guess the algorithm from this pattern. Given that the PIRQ
routing handler is chipset-specific we could try interpreting just the
high nibble, but would it work for the next system with the same chipset?
This is certainly unclear. However, 10-28-41-89 can be arithmetically
verified for consistency against the numbering scheme described above.
So a respective test could be added somewhere. Also, prime numbers 1 to
4 could probably be treated as valid numbering, too. Everything else
should probably be refused unless some other numbering scheme pops up.
Also who is the BIOS vendor? Maybe they would be able to tell us
something about the "$IRT" BIOS service.
It is some regular AMIBIOS (American Megatrends) from 486 era, for
EXP8449 motherboard, here is a manual I found for it:
https://www.elhvb.com/mobokive/Archive/Oldman.ixbt.com/mb/Expertboard_8449/exp84491.pdf
Datasheets are not always right, but this one is the best source we have
for this chipset.
Well, my testing has shown that practically, with your patch all works
fine, including IRQ sharing. So other than this unclear numbering
problem, I think it can be considered correct and usefull.
Thank you,
Regards,
Nikolai
Maciej
