pentiumspeed wrote on 2022-02-04, 18:22:

Yes! you have a problem, Not the IC, the hot spot points to shorted even partial short will do that, you have to check pin by p […]
Show full quote

Yes! you have a problem, Not the IC, the hot spot points to shorted even partial short will do that, you have to check pin by pin on that 206 to find the one that does not look right.
Use diode mode method with red probe on ground, and use black probe to check. Normal is anywhere .200 to .800 diode voltage drop.

ohm measurement will not activate the diode voltage drop or bad IC since the voltage is not high enough.

Diode mode measurements is routinely done on cellphone diagnosis.

Cheers,

I went over all the pins of the 82C206 in diode mode and get good readings around 0.6V voltage drop some a bit lower like 0.4V but within expected ranges I would say.

From diode readings it feels like the IC is OK?

Now the current draw is less, fluctuating between 3mA to up to 7mA. I see some movement upon reset.

I also tried to simply disconnect/reconnect Vcc to the 82C206 while in the POST routine, no change.

I did find a glob of flux which could have been the source of the hot spot underneath the IC? Cleaned up thoroughly with IPA and compressed air now. Cannot see anything with the FLIR camera.

Fun fact is that I get stuck at 0B 0A regardless if 82C206 is powered up or not (I.e., disconnecting Vcc).

Maybe it is just done for? Maybe try to give it a proper reflow with the Hot Air Station?

rasz_pl wrote on 2022-02-04, 21:50:

I was hoping for a listing :) Can you hint where POST_B starts (offset)? Whole dump contains only two occurrences of 0xe680 (out […]
Show full quote

Chkcpu wrote on 2022-02-04, 11:59:

It took me some time to analyze this 2A5ULT40 BIOS - POST_B procedure. 😉

I was hoping for a listing 😀 Can you hint where POST_B starts (offset)? Whole dump contains only two occurrences of 0xe680 (out 0x80, al), and they arent even valid code when looking at bytes around.

LocalBus wrote on 2022-02-04, 15:02:

Brilliant! We have definitely narrowed it down to the 82C206 😀

Im not so sure anymore, at least not the CMOS area. I found few calls to read/write RTC/CMOS at the very start of the bios

F000:E98A read_CMOS
F000:E99B write_CMOS

and they definitely dont block the boot process. It looks to me like the very first thing bios does on warm reset is read CMOS 0xF offset to check for reboot reason https://www.cs.yale.edu/flint/feng/research/B … ly/cmosram.html

Copy code to clipboard

1mov     al, 8Fh
2out     70h, al
3out     0E1h, ax
4in      al, 71h  

reading empty space (206 chip not powered up/in low power mode) would result in undefined values (maybe whatever was last on the bus?), but I still dont know how that would make the bios stop proceeding that late.
I would definitely go once more over all 206 pins under magnification, and measure
pin 6 PWRGD high
7 PSRSTB high
9 TEST low
if you have a scope/logic probe 74 AS being strobed after reset (it has same role as Chip select for accessing RTC/CMOS)

PWRGD high -> confirmed, 5V
7 PSRSTB high -> confirmed, 5V
9 TEST low -> confirmed, tied to GND

Unfortunately no access to a scope or logic analyzer.

I have traced all the IRQs now as well, looks good.

The 82C206 just don't want to play along.

And it is impossible that the failure is at POST code 0C ?

Initialise keyboard; Set NUM LOCK status.

People better than I am will correct me if I'm wrong, but I understand that the BIOS will write out the code at he start of each stage so that the card always shows the current test being run.

That hot spot on the 206 does look oddly localised, but I don't think there are any IR pictures to compare with. 3mA sounds low, could you recheck with the IR camera and see if the hot spot has disappeared?

Given where the hot spot was, I think it might be worth checking resistances from both ground and +5 to the pins on that side (particularly pins 79 to 94, the IRQ pins). That should help check if any transistors have become resistors.

I didn't mention it, but don't suppose you got any photos when the 206 was off the board?

There was someone here: Repair log: Gemlight GMB-386UN 386 Motherboard who fixed their board by replacing the 206. But their symptoms were nothing at all on the POST card.

Correct. When a POST routine is completed, it returns to the caller. The caller then first outputs the code of the next POST via I/O port 80h before calling that POST.

So when you see 0A 0B on the POST card, you know for sure that POST A was completed and POST B is hanging.

snufkin wrote on 2022-02-05, 13:50:

People better than I am will correct me if I'm wrong, but I understand that the BIOS will write out the code at he start of each […]
Show full quote

People better than I am will correct me if I'm wrong, but I understand that the BIOS will write out the code at he start of each stage so that the card always shows the current test being run.

That hot spot on the 206 does look oddly localised, but I don't think there are any IR pictures to compare with. 3mA sounds low, could you recheck with the IR camera and see if the hot spot has disappeared?

Given where the hot spot was, I think it might be worth checking resistances from both ground and +5 to the pins on that side (particularly pins 79 to 94, the IRQ pins). That should help check if any transistors have become resistors.

I didn't mention it, but don't suppose you got any photos when the 206 was off the board?

There was someone here: Repair log: Gemlight GMB-386UN 386 Motherboard who fixed their board by replacing the 206. But their symptoms were nothing at all on the POST card.

Hmm IRQ 11 and 12 sticks out with "only" 1.8kOhm resistance to ground, whereas all the other IRQ pins read 10kOhm IRQ1 - 15 on pins 94 through 79.

Vcc pins also show 1.88kOhm resistance to ground. So maybe we have a short on Vcc to IRQ 11 and 12 bus? Nah can't be, just a very similar resistance to GND reading.

I never lifted the chip from the board, just resoldered some pins. But I would say I am out of ideas so I better just remove it and see what's going on underneath.

I did find a replacement UM82C206F (UMC) on fleabay so maybe I should just pull the trigger on that one in worst case.

Chkcpu wrote on 2022-02-05, 14:00:

Correct. When a POST routine is completed, it returns to the caller. The caller then first outputs the code of the next POST via I/O port 80h before calling that POST.

So when you see 0A 0B on the POST card, you know for sure that POST A was completed and POST B is hanging.

Thanks, yes that makes total sense from a software debugging point of view 😀

LocalBus wrote on 2022-02-05, 14:47:

Hmm IRQ 11 and 12 sticks out with "only" 1.8kOhm resistance to ground, whereas all the other IRQ pins read 10kOhm IRQ1 - 15 on p […]
Show full quote

Hmm IRQ 11 and 12 sticks out with "only" 1.8kOhm resistance to ground, whereas all the other IRQ pins read 10kOhm IRQ1 - 15 on pins 94 through 79.

Vcc pins also show 1.88kOhm resistance to ground. So maybe we have a short on Vcc to IRQ 11 and 12 bus? Nah can't be, just a very similar resistance to GND reading.

I never lifted the chip from the board, just resoldered some pins. But I would say I am out of ideas so I better just remove it and see what's going on underneath.

I did find a replacement UM82C206F (UMC) on fleabay so maybe I should just pull the trigger on that one in worst case.

It's worth checking resistances from Vcc to those IRQ pins as well. Short from Vcc to IRQ isn't impossible. I don't know enough about the IRQ lines (and haven't found a good description). But I think interrupts are rising edge triggered, so it's likely that they'll should have a pull down resistor on them, so that they're not floating if there are no cards fitted. Then a card can pull the line high if it needs to signal the CPU. So those 10k readings to Ground might be internal pull downs on the 206. If so, the 1.8k to Ground sounds wrong.

Found another culprit, this 7406N shows 4.96V on 4Y (Pin 8 ) which goes to pin 80 IRQ 14 input on the 82C206:

Interesting that there is a pull-down resistor between GND (Pin 7) and 4A (Pin 9) ?

Should IRQ 14 be high?

you dont need VGA card when testing, and bad one might screw with something on the bus
are you always testing by fully powering off/on with AT power switch? try using reset button multiple times

LocalBus wrote on 2022-02-05, 13:21:

The 82C206 just don't want to play along.

Take it off with hotair (kapton around to prevent melty melty) and lets see if anything changes?
This threat really got me into investigating bios 😀 Im trying to understand whats up with multiple

1out     0E1h, ax

cant find anything about this port. https://bochs.sourceforge.io/techspec/PORTS.LST for example only lists microchannel peripherals there. This seems to be used for more fine grained debugging, calls to it are sprinkled all over the place when performing hardware initialization, for example some chipset config:

1out     22h, al
2xchg    ah, al
3out     23h, al
4out     0E1h, ax

turning on A20?

1mov     al, 2
2out     92h, al
3out     0E1h, ax

function switching A20:

1mov     ah, al
2in      al, 92h
3out     0E1h, ax
4and     al, 0FDh
5test    ah, 2
6jz      short loc_F89E0
7or      al, 2
8loc_F89E0:
9out     92h, al
10out     0E1h, ax

cache enable/disable based on value stored in CMOS:

1sub_FC4E4       proc near
2                mov     ah, al
3                mov     al, 0BDh ; '+'
4                out     70h, al         ; CMOS Memory:
5                out     0E1h, ax
6                in      al, 71h         ; CMOS Memory
7                cmp     al, 0FFh
8                jz      short locret_FC51C
9                test    al, 80h
10                jz      short locret_FC51C
11                and     al, 7Eh
12                nop
13                nop
14                or      ah, ah
15                jnz     short EnableCache
16
17DisableCache:
18                mov     eax, cr0
19                or      eax, 60000000h
20                mov     cr0, eax
21                wbinvd
22                jmp     short locret_FC51C
23
24EnableCache:
25                mov     eax, cr0
26                and     eax, 9FFFFFFFh
27                mov     cr0, eax
28                wbinvd
29
30locret_FC51C:
31                retn

this got me thinking maybe a better POST card is in order, one with 0E1h readout, logging and radare integration allowing proper trace debugging.

Hmm. So the 7406 is a bunch of NOT gates. Pin 9 is an input and pin 8 the matching inverted output. Pin 9 is grounded through 1k resistor, so pin 8 will default to high, but could still be made low if pin 9 is driven high directly. There's some gunk on the back of the board around that area, and traces go under those chips, so I can't make out what's connected where. Maybe pin 9 goes to somewhere on the 74F32 (U30), the 7474, or somewhere around the 82C571 around the pin 120 corner somewhere.

I'm still a bit suspicious about the 206, with the different resistance readings on the IRQ lines. But nothing to compare against, so it might be ok.

snufkin wrote on 2022-02-05, 16:27:

Hmm. So the 7406 is a bunch of NOT gates. Pin 9 is an input and pin 8 the matching inverted output. Pin 9 is grounded through 1k resistor, so pin 8 will default to high, but could still be made low if pin 9 is driven high directly. There's some gunk on the back of the board around that area, and traces go under those chips, so I can't make out what's connected where. Maybe pin 9 goes to somewhere on the 74F32 (U30), the 7474, or somewhere around the 82C571 around the pin 120 corner somewhere.

I'm still a bit suspicious about the 206, with the different resistance readings on the IRQ lines. But nothing to compare against, so it might be ok.

Yes I agree about the gunk on the backside (hack from factory I believe).

They probably ended up in a bit of a corner when it came to routing IRQ14 to the 82C822 and ISA ports and the 82C206 hanging on the side:

The trace that looks like it is touching pin 8 is isolated from it (but there is an awful lot of solder on that pin so I might as well remove some).

It goes up to a via hole which in turn goes to IRQ 14 on 82C822, here is also a hack with a jumper wire to pin 9 on the 7406.

Not pretty 😀

rasz_pl wrote on 2022-02-05, 15:58:

This threat really got me into investigating bios :) Im trying to understand whats up with multiple […]
Show full quote

This threat really got me into investigating bios 😀 Im trying to understand whats up with multiple

Copy code to clipboard

1out     0E1h, ax

cant find anything about this port.

this got me thinking maybe a better POST card is in order, one with 0E1h readout, logging and radare integration allowing proper trace debugging.

My disassembler writes comments behind instructions or instruction sequences that may need clarification.
Behind each OUT 0E1h, AX instruction is says: Short I/O delay and I have no reason to think it means anything else. 😉

The writer of my disassembler must have know about this BIOS writers trick, to get a short delay with only 2 bytes of code.

You requested a listing of the POST routines, but I can do better than that. I'm now making a listing of the whole BIOS and will put it up shortly. 😀

Jan

Alright, here is the disassembly listing of the whole F-segment, the upper 64KB, of the 2A5ULT40 BIOS. The lower 64KB part contains a SCSI option ROM and is only used when an old ROM-less SCSI adapted is fitted. So I didn't included this part in the dissambly.

I'm using the DOS-based Sourcer disassembler and most names for subroutines, locations, and data structures are made up by me.
This is done via a definition file and making such a file for a specific BIOS takes me about 2 to 3 hours, but the result is a good readable listing.

The listing is a 132 columns text-file that uses tabs for spacing. But Windows's Notepad will display it fine.

I hope this will be educational! 😀

Jan

Chkcpu wrote on 2022-02-05, 17:46:

Behind each OUT 0E1h, AX instruction is says: Short I/O delay and I have no reason to think it means anything else. 😉

While technically correct, same could be said about out 0x80,al 😀 its also provides short IO delay 😉
Not buying it considering this instruction is present after critical operations and often strategically outputs both index/data or function/data combo of called procedure as in my examples above. I looked at another Award bios from 486 era and it also pushed a ton of useful debug data into 0xE1. Maybe Award used their own custom 0xE1 POST card when debugging new bios ports, and didnt bother removing that code.
If you wanted delay youd use nop , xchg BX, BX or jz $+2 like here:

1FE98A read_CMOS       proc near
2                xchg    bx, bx
3                out     70h, al         ; CMOS Memory:
4                jcxz    short $+2
5                jcxz    short $+2
6                xchg    bx, bx
7                in      al, 71h         ; CMOS Memory
8                jcxz    short $+2
9                jcxz    short $+2
10                retn
11read_CMOS       endp

Thank you for the listing! Sweet comments all over the place.

Disclaimer: It is entirely possible that I may have had a beer or two and that I mistakenly start to think I understand some of this stuff. So apologies if this is nonsense.

But this snippet from POST B:

1F000:0880			locloop_121:					;  xref F000:0889
2F000:0880  B0 8A				mov	AL, 8Ah
3F000:0882  E8 E105				call	Read_CMOS		; (E98A)
4F000:0885  A8 80				test	AL, 80h
5F000:0887  74 04				jz	short loc_122		; Jump if zero
6F000:0889  E2 F5				loop	locloop_121		; Loop if cx > 0

looks like a possible halt point. Is this the bit that's checking the UIP bit of the CMOS, and if bit 7 never goes low then it'll be stuck looping? So if the 206 is dead and the bus happens to float high then 0B is where it stays? If so, can the 'jump if zero' be changed to a 'jump', just to see if it makes any progress.

I haven't checked to see if there are any earlier possible halt points, or later to see if there are any other halt points in 0B.

My IDA mystery is solved, it totally failed to detect Jump Table used for POST 🙁

1mov     di, offset post_jumptable ; this is my own label after comparing Chkcpu awesome disassembly 
2mov     bp, 3
3jmp     short loc_F022F
4
5loc_F022F:
6mov     ax, cs
7mov     ss, ax
8assume ss:seg000
9
10loc_F0233:
11mov     ax, bp
12mov     dx, 80h ; 'Ç'
13out     dx, al          ; manufacture's diagnostic checkpoint
14mov     ax, cs:[di]  ; this is where post_jumptable is loaded
15inc     di
16inc     di
17or      ax, ax
18jz      short loc_F0254
19mov     fs, di
20mov     sp, offset off_F0249
21jmp     ax  ; and bam here is where we jump into it, stupid IDA :/

snufkin wrote on 2022-02-05, 20:51:

Disclaimer: It is entirely possible that I may have had a beer or two and that I mistakenly start to think I understand some of […]
Show full quote

Disclaimer: It is entirely possible that I may have had a beer or two and that I mistakenly start to think I understand some of this stuff. So apologies if this is nonsense.

But this snippet from POST B:

Copy code to clipboard

1F000:0880			locloop_121:					;  xref F000:0889
2F000:0880  B0 8A				mov	AL, 8Ah
3F000:0882  E8 E105				call	Read_CMOS		; (E98A)
4F000:0885  A8 80				test	AL, 80h
5F000:0887  74 04				jz	short loc_122		; Jump if zero
6F000:0889  E2 F5				loop	locloop_121		; Loop if cx > 0

looks like a possible halt point. Is this the bit that's checking the UIP bit of the CMOS, and if bit 7 never goes low then it'll be stuck looping? So if the 206 is dead and the bus happens to float high then 0B is where it stays? If so, can the 'jump if zero' be changed to a 'jump', just to see if it makes any progress.

I haven't checked to see if there are any earlier possible halt points, or later to see if there are any other halt points in 0B.

http://www.bioscentral.com/misc/cmosmap.htm

0Ah 10 1 byte Status Register A
Bit 7 = Update in progress (0 = Date and time can be read, 1 = Time update in progress)

yep, it thinks 206 is busy. Now we know 206 is either:
-kept in low power mode
-dead
-Chipset is not sending AS to 206
"AS 71 74 I Address Strobe: An active high input which is pulsed by the System
Controller when the CPU accesses the real-time clock or CMOS
RAM of the 82C206. The falling edge of this pulse latches the
address from the 🤣 bus."

Wow, that is some BIOS forensics analysis going on right here 😀

I can tell you this much, the CPU gets really hot if leaving it on in the 0B state, which would imply that it is looping like nuts to read the CMOS registry state?

Any idea why IRQ14 would be kept high by default for 82C206? I will for sure desolder the pull-down resistor and see if it makes a difference. That is not keeping the 82C206 "busy" ?

Erm, just been looking at that bodge and something's odd. You said that pin 8 went to IRQ 14? It looks like pin 9 has a bodge wire that goes to a via, which also connects to IRQ 14 of the 822. Which would mean that 8 and 9 are shorted together, which with a NOT gate is a bad thing. The PCB trace under the blob o' gunk looks like it might be burnt. I'm suspicious now about that. Can you remove the gunk and give it a closer look? I'm not convinced that pin 8 should connect to that trace at all. I wonder if they found they needed to add a pull down to the IRQ line and this bodge (resistor from pin 7 to 9, wire link from 9 to via) was the easiest way. Maybe pin 8 isn't supposed to be connected to anything.