VOGONS

Advantech Atom board not starting when hot - The PowerGood mystery

Topic actions

First post, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

Hi all - you might have seen my last video where I tinker with an Advantech Touch minicomputer sporting an old ATOM. The board refused to start at a specific temp but always starts when cold.
With hot/cold I determined the issue was with the Northbridge, I re-flowed it but the issue remained.

After many comments, I took some notes and had a look at the board again.

There is an LTC3728 chip at the back, responsible for some voltage generation. I found its PowerGood signal was always LOW - hence the chip was determining that one or both the reference voltages coming back to the chip to the VOSENSE1 and VOSENSE2 via voltage divider, was off. Well, the voltages were not off - reading very close to the expected 0.8V - yet the PowerGood was always low.

The attachment SCR-20260409-qbfd.png is no longer available

The PowerGood goes to an AND gate where it compares to 5V and outputs either 0V or 5V depending on whether PowerGood is high or low.

The signal then goes to a Winbond W83627. If not mistaken it goes into pin 87, ATXPGD. Looking at the datasheet, a LOW ATXPGD would prevent the Winbond's own PowerGood1 and 2 to be active high.

The attachment SCR-20260409-pzps.png is no longer available

However.

1. PowerGood1 is ALWAYS high, even if I force the ATXPGD line to 0V with a resistor to ground
2. I accidentally broke the LTC3728 chip, I shorted pins 28 and 27 and now pin 28, PowerGood, doesn't go to ground anymore. So that gave me the opportunity to test the board with that PowerGood signal set HIGH instead of LOW, signalling "a good voltage all the time". Result: unchanged, the board starts when cold but not when hot. Winbond's PowerGood doesn't seem to care about the ATXPGD signal coming in.
3. I forced the Winbond's PowerGood OUT to LOW and the board still starts! ๐Ÿ˜
4. This doesn't seem to be the C2000 issue. I can see 33MHz clock on the LPC connector and it looks fine.

This doesn't make much sense. Why is there an ATXPGD signal if the Winbond seems to ignore it? What is the purpose of the POWERGOOD signal going out of the Winbond if that doesn't prevent the board from starting? That said, I see the ATXPGD signal can be disabled in the parameters of the Winbond - how can I check those parameters?

With "starting" I mean: Hearing the RAM error beeps. I removed the RAM because the board would beep immediately when in a working state or be silent when not trying to start. I'm assuming that if a PowerGood signal was missing, the logic would prevent any code execution?

I was so happy, I thought I had found the issue with the LTC chip but no. And now I made it worse ๐Ÿ˜€

Any suggestions?
Thanks!

Below how PowerGood works on the LTC3728, it's a simple logic

The attachment SCR-20260409-qavz.png is no longer available

Below the logic behind the Winbond's powergood signals

The attachment SCR-20260409-qabu.png is no longer available

Below the register which enables or disables the ATXPGD signal input monitoring

The attachment SCR-20260409-qakd.png is no longer available

My Youtube channel: https://www.youtube.com/@tony359

Reply 1 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t
tony359 wrote on 2026-04-09, 17:27:

What is the purpose of the POWERGOOD signal going out of the Winbond if that doesn't prevent the board from starting?

maybe its not wired into Atom cpu powergood input nor chipset PWROK at all?
Chipset generates its own powergood, uses inputs like PWROK, VRMPWRGD, THRMTRIP# and THRM# to determine if its ok to start
sadly those pins are in the middle of bga package like PWROK at AA4 so the only way to be sure its driven right without having diagram/boardview would be to desolder chipset ๐Ÿ˜ฎ

tony359 wrote on 2026-04-09, 17:27:

That said, I see the ATXPGD signal can be disabled in the parameters of the Winbond - how can I check those parameters?

Winbond is not programmable (no flash) so those parameters can only be changed on a running system

tony359 wrote on 2026-04-09, 17:27:

I'm assuming that if a PowerGood signal was missing, the logic would prevent any code execution?

yes, afaik no chipset powergood will mean staying in reset internally
https://www.intel.com/content/dam/doc/datashe โ€ฆ 7-datasheet.pdf
"a signal is considered to be in the functional operating mode after .... PWROK for signals in the core well"
"The ICH7 drives PLTRST# (Platform Reset) inactive a minimum of 1 ms after both PWROK and VRMPWRGD are driven high."

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 2 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member
rasz_pl wrote on 2026-04-09, 20:39:
maybe its not wired into Atom cpu powergood input nor chipset PWROK at all? Chipset generates its own powergood, uses inputs lik [โ€ฆ]
Show full quote
tony359 wrote on 2026-04-09, 17:27:

What is the purpose of the POWERGOOD signal going out of the Winbond if that doesn't prevent the board from starting?

maybe its not wired into Atom cpu powergood input nor chipset PWROK at all?
Chipset generates its own powergood, uses inputs like PWROK, VRMPWRGD, THRMTRIP# and THRM# to determine if its ok to start
sadly those pins are in the middle of bga package like PWROK at AA4 so the only way to be sure its driven right without having diagram/boardview would be to desolder chipset ๐Ÿ˜ฎ

Probably - then what is the purpose of having the ATXPGD and the Winbond's POWERGOOD signals? And why the Winbond is still outputting its own POWERGOOD signal if ATXPGD is low?
So weird the chipset has its own powergood. I'd thought a powergood signal coming from a VOLTAGE CONTROLLER would have more "authority" than anything else! ๐Ÿ˜

Winbond is not programmable (no flash) so those parameters can only be changed on a running system

So what would be the point in being able to tell the Winbond to ignore the ATXPGD if that happens BEFORE parameters can be sent?

yes, afaik no chipset powergood will mean staying in reset internally https://www.intel.com/content/dam/doc/datashe โ€ฆ 7-datashee [โ€ฆ]
Show full quote

yes, afaik no chipset powergood will mean staying in reset internally
https://www.intel.com/content/dam/doc/datashe โ€ฆ 7-datasheet.pdf
"a signal is considered to be in the functional operating mode after .... PWROK for signals in the core well"
"The ICH7 drives PLTRST# (Platform Reset) inactive a minimum of 1 ms after both PWROK and VRMPWRGD are driven high."

As you rightly said, those signals cannot be checked without black magic so I am a bit stuck.

The latest progress is that there IS BIOS activity even when the board fails to start. I'm then trying to read the LPC POST codes. So far I haven't found the right wire order but I've just noticed the LPC all go to the Winbond so I can trace from there.

I don't think I'll get much from that but I'd like to find out!
Wish me luck.

Thanks for your help!

My Youtube channel: https://www.youtube.com/@tony359

Reply 3 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t

this thread is continuation of CK505 help so its easier to follow earlier talk

tony359 wrote on 2026-04-09, 21:28:

Probably - then what is the purpose of having the ATXPGD and the Winbond's POWERGOOD signals?

just because chip provides this functionality doesnt mean system designer has to use it

tony359 wrote on 2026-04-09, 21:28:

And why the Winbond is still outputting its own POWERGOOD signal if ATXPGD is low?

maybe its something else pulling it up on the pcb?

tony359 wrote on 2026-04-09, 21:28:

So weird the chipset has its own powergood. I'd thought a powergood signal coming from a VOLTAGE CONTROLLER would have more "authority" than anything else! ๐Ÿ˜

nothing has/should have more authority than chipset ๐Ÿ˜€ Designer decides what goes into chipsets VRMPWRGD input, can be only cpu VRM, can be combined with input from monitoring chip, atx_powergood or/and other rail generators.
LTC3728 powergood going to W83627 might be strictly for ACPI purposes to be read by firmware/bios/OS.

tony359 wrote on 2026-04-09, 21:28:

Winbond is not programmable (no flash) so those parameters can only be changed on a running system

So what would be the point in being able to tell the Winbond to ignore the ATXPGD if that happens BEFORE parameters can be sent?

datasheet suggests ACPI

tony359 wrote on 2026-04-09, 21:28:

The latest progress is that there IS BIOS activity even when the board fails to start.

Oh that is surprising. I would fully expect chipset refusing to start due to powergood/thermal alarm. I would not expect BIOS to have monitoring step earlier than ram initialization. Weird.

tony359 wrote on 2026-04-09, 21:28:

I'm then trying to read the LPC POST codes. So far I haven't found the right wire order but I've just noticed the LPC all go to the Winbond so I can trace from there.

there is also https://github.com/stacksmashing/pico-tpmsniffer ( or maybe https://sigrok.org/wiki/Protocol_decoder:Lpc but maybe not Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards) that could be modified to show you all IO activity - you could see if/what exactly bios tries to do on those failed silent boots on ISA/LPC bus, like does it access Winbond registers at all?
Also you could try sniffing BIOS read to see how much is executed and where its getting stuck on a failed boot with logic analyzer and PulseView/sigrok spiflash decoder https://sigrok.org/wiki/Protocol_decoder:Spiflash

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 4 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member
rasz_pl wrote on 2026-04-09, 22:47:

this thread is continuation of CK505 help so its easier to follow earlier talk

Apologies, I had forgotten I asked about this project before!

just because chip provides this functionality doesnt mean system designer has to use it

Of course but then I don't understand why there are components to take the ATXPGD to the Winbond if it's not being used.

tony359 wrote on 2026-04-09, 21:28:

And why the Winbond is still outputting its own POWERGOOD signal if ATXPGD is low?

maybe its something else pulling it up on the pcb?

Ah, good point.

tony359 wrote on 2026-04-09, 21:28:

Winbond is not programmable (no flash) so those parameters can only be changed on a running system

So what would be the point in being able to tell the Winbond to ignore the ATXPGD if that happens BEFORE parameters can be sent?

datasheet suggests ACPI

Could you elaborate?

tony359 wrote on 2026-04-09, 21:28:

The latest progress is that there IS BIOS activity even when the board fails to start.

Oh that is surprising. I would fully expect chipset refusing to start due to powergood/thermal alarm. I would not expect BIOS to have monitoring step earlier than ram initialization. Weird.

Indeed, that is why I left it for last, I was confident the board was dead as a dodo but no.

there is also https://github.com/stacksmashing/pico-tpmsniffer ( or maybe https://sigrok.org/wiki/Protocol_decoder:Lpc but maybe not Re: dISAppointment - LPC to ISA adapter - ISA on modern motherboards) that could be modified to show you all IO activity - you could see if/what exactly bios tries to do on those failed silent boots on ISA/LPC bus, like does it access Winbond registers at all?
Also you could try sniffing BIOS read to see how much is executed and where its getting stuck on a failed boot with logic analyzer and PulseView/sigrok spiflash decoder https://sigrok.org/wiki/Protocol_decoder:Spiflash

I don't think I am ready to dig a lot more into this issue - I hope the post codes might share some light on what is failing but then it might be the end of the road for this board. I'm not Adrian and looking into these things is fun but takes forever (and kind people's help!) ๐Ÿ˜€
If this was NOT BGA, it would be easier. But with BGA, 90% of the signals are inaccessible...

Thanks so far - I'll let you know what I discover tomorrow!

My Youtube channel: https://www.youtube.com/@tony359

Reply 5 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t
tony359 wrote on 2026-04-09, 23:06:
rasz_pl wrote on 2026-04-09, 22:47:
tony359 wrote on 2026-04-09, 21:28:

So what would be the point in being able to tell the Winbond to ignore the ATXPGD if that happens BEFORE parameters can be sent?

datasheet suggests ACPI

Could you elaborate?

no ๐Ÿ˜€ I know only enough about ACPI to not like it ๐Ÿ˜€ its some kind of interface between BIOS and OS that lets OS know what resources BIOS has at its disposal and to read/control them. Like fan speeds, voltage monitoring, lid close detection that sort of stuff

tony359 wrote on 2026-04-09, 23:06:

But with BGA, 90% of the signals are inaccessible...

good candidate for some BGA rework practice ๐Ÿ˜€

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 6 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

datasheet suggests ACPI

Could you elaborate?

no ๐Ÿ˜€ I know only enough about ACPI to not like it ๐Ÿ˜€ its some kind of interface between BIOS and OS that lets OS know what resources BIOS has at its disposal and to read/control them. Like fan speeds, voltage monitoring, lid close detection that sort of stuff

ahah I didn't mean to explain me what ACPI is but what you mean with "datasheet suggests ACPI".

tony359 wrote on 2026-04-09, 23:06:

But with BGA, 90% of the signals are inaccessible...

good candidate for some BGA rework practice ๐Ÿ˜€

ahah maybe. But once I remove the chip, I have access to the signals but then the chip is not there anymore ๐Ÿ˜€

I don't feel like doing this, yet ๐Ÿ˜€

The attachment 1600px-Pyramid_Syscon_live_probing.jpg is no longer available

My Youtube channel: https://www.youtube.com/@tony359

Reply 7 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

Success! I was able to track the LPC pinout and I was able to get post codes.

The below are the post codes of a working POST sequence until it hangs on "no system drive" or something like that

data: b2
data: b3
data: b4
data: b6
data: b7
data: b0
data: b1
data: b2
data: b6
...
data: b7
data: b8
data: cf
data: cf
data: c0
data: c1
data: a0
data: 01
data: 02
data: 03
data: 04
data: 05
data: 06
data: 07
data: 08
data: 09
data: 10
data: 11
data: 12
data: 13
data: 14
data: 15
data: 16
data: 17
data: 18
data: 19
data: 20
data: 21
data: 22
data: 23
data: 24
data: 25
data: 26
data: 27
data: 28
data: 29
data: 30
data: 31
data: 32
data: 33
data: 34
data: 35
...
data: 36
data: 37
data: af
data: 0c
data: c3
...
...
โ€ฆShow last 153 lines
...
data: c5
data: 01
data: 02
data: 03
data: 04
data: 05
data: 06
data: 07
data: 08
data: 09
data: 0a
data: 0b
data: 0c
data: 0d
data: 0e
data: 0f
data: 10
data: 11
data: 12
data: 13
data: 14
data: 15
data: 16
data: 17
data: 18
data: 19
data: 1a
data: 1b
data: 1c
data: 1d
data: 1e
data: 1f
data: 20
data: 21
data: 22
data: 23
data: 24
data: 25
data: 26
...
...
data: 27
data: 28
data: 29
data: 2a
data: 2b
data: 2c
data: 2d
data: 2e
data: 2f
data: 30
data: 31
data: 32
data: 33
data: 34
data: 35
data: 36
data: 37
data: 38
data: 39
data: 3b
data: 3d
data: 3e
data: 3f
data: 40
data: 41
data: 42
data: 43
data: 44
data: 45
data: 46
data: 47
data: 48
data: 49
...
data: 4a
data: 4b
data: 4c
data: 4d
data: 4e
data: 4f
data: 50
data: 51
data: 52
...
...
data: 53
data: 54
data: 55
data: 56
data: 57
data: 58
data: 5a
data: 5e
data: 5f
data: 60
data: 61
data: 62
data: 63
data: 65
data: 66
data: 67
data: 68
data: 69
data: 6a
data: 6b
data: 6c
data: 6d
data: 6e
data: 6f
data: 70
data: 71
data: 72
data: 73
data: 74
data: 75
...
data: 76
data: 77
data: 78
data: 79
data: 7a
data: 7b
data: 7c
data: 7d
data: 7e
data: 7f
data: 80
data: 81
data: 82
data: 83
data: 84
data: 85
data: 86
data: 87
data: 88
data: 89
data: 8a
data: 8b
data: 8c
data: 8d
data: 8e
data: 8f
data: 90
data: 91
data: 92
data: 93
data: 94
data: 95
data: 96
...
data: ff

What is the meaning of those sequential numbers?

The below is what happens when the system fails to post - I tried multiple times and it's always like this.

...
data: b2
data: b3
data: b4
data: b6
data: b7
data: b0
data: b1
data: b2
data: b6
data: b7
data: b8
data: cf
data: cf
data: c0
data: c1
...
data: a0
data: 01
data: 02
data: 03
...

Now, how to interpret those? My BIOS says "Phoenix AwardBIOS v6.00PG" - it's an AWARD BIOS, right? Phoenix just bought the company then.
So this document should work https://blog.theretroweb.com/2024/01/20/award โ€ฆ /#Version_600PG

How do I match what I've got with the codes mentioned on that document?

My Youtube channel: https://www.youtube.com/@tony359

Reply 8 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t
tony359 wrote on 2026-04-10, 09:51:

ahah I didn't mean to explain me what ACPI is but what you mean with "datasheet suggests ACPI".

:-]
those pins are listed belonging to
"5.10 Advanced Configuration and Power Interface
The Advanced Configuration and Power Interface (ACPI) "

tony359 wrote on 2026-04-09, 23:06:

post codes

03h Initial Superio_Early_Init switch
does sound plausible and encouraging, but to be 100% sure you would have to decompile bios and verify the codes match.
Either manually - you can follow https://github.com/raszpl/430FXL2Cache, or try AI as its stupid good at this sort of task nowadays.
Superio is Winbond, so Winbond might be blocking the boot after all and sniffing LPC to see whats going on might give more clue.

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 9 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

thanks!

03h is listed on a different revision of the BIOS though. Do you think it still applies? If that is the case it's encouraging indeed.

I did save a copy of the BIOS at some point as I was concerned it might get corrupted by the endless ON/OFF cycles. Let me see what I can do. Thanks for now!

PS: how do you upload a firmware to AI? I have Perplexity but neither bin nor zip files are supported.

Edit: a free run on Claude accepted the BIN file. Below is the outcome.

I'll have a look at the Winbond a bit more. I re-soldered its legs already, someone mentioned a crystal nearby but it looked connected to the ethernet chip, not the Winbond. I see pin 18 is "clock input", either 24 or 48MHz. I'll check where that comes from.

Based on a thorough analysis of the BIOS dump, here's what I can tell you: [โ€ฆ]
Show full quote

Based on a thorough analysis of the BIOS dump, here's what I can tell you:

---

## BIOS Dump Analysis: Chrostie TCP-650H

### Confirmed BIOS Identity
- **Phoenix Technologies, LTD** โ€” BIOS v6.00 PG, dated **11/04/2010**
- Chipset: **Intel 945GSE** โ€” this matches the Atom N270 (Diamondville) platform
- The 2MB file is an Award/Phoenix hybrid with LZH-compressed modules

---

### POST Code Architecture

This BIOS has **two distinct POST code layers**:

**BootBlock codes (hardware, uncompressed โ€” C0โ€“CF range)**
These are output by the BootBlock (starting at the reset vector `F000:E05B`) before the main BIOS is decompressed:

| Code | Offset | Meaning |
|------|--------|---------|
| `0x01` | `0x1FF769` | Early BootBlock init start โ€” clear memory, set stack |
| `0xC0` | `0x1FE1F8` | SuperIO/Chipset early detect |
| `0xC1` | `0x1FE32E` | Flash/ROM detect |
| `0x0C` | `0x1FE4D0` | CPU mode transition (enters protected/unreal mode) |
| `0xC3` | `0x1FE4E4` | Decompression target memory setup |
| `0xC5` | `0x1FE512` | Launch decompressor (jumps to decompressed BIOS) |
| `0xCF` | `0x1FE580` | Fatal error / CPU detection failure |

**Main BIOS codes (decompressed โ€” B0โ€“BF, then 01โ€“FF)**
These come from the main BIOS body (`TPC650~2.BIN`, LZH-compressed, 128KB decompressed):

| Code | Meaning |
|------|---------|
| `0xB0`โ€“`0xB8` | Early CPU/cache initialisation steps (found at `0x1F0013`โ€“`0x1F0129`) |
| `0x03` | **SuperIO Early Init** โ€” where your board hangs |

---

### The POST `03` Hang โ€” What It Means

POST code `0x03` is output by the **main BIOS body after decompression**, during **SuperIO early initialisation**. At this point the BIOS has already:
1. Successfully decompressed itself (code `C5` completed)
2. Initialised the CPU and basic cache (B0โ€“B8)
3. Is attempting to communicate with the **Super I/O chip** (likely a Winbond/ITE device) via the LPC bus

**Why it fails when hot:** The code `0x03` checkpoint represents the BIOS trying to detect or configure the Super I/O chip. When the board is cold it completes; when hot it hangs. This strongly points to:

1. **Super I/O chip thermal issue** โ€” the SIO chip itself (likely an ITE IT8718 or similar โ€” common on 945GSE boards) fails to respond when hot. Check it for cold solder joints or thermal stress cracking.
2. **LPC bus instability** โ€” the LPC traces or pull-up resistors become marginal at temperature. Check for dry joints near the ICH (I/O Controller Hub).
3. **Voltage rail sag when hot** โ€” the 3.3V or LPC_CLK rail feeding the SIO may droop under thermal load. Worth scoping.
4. **Crystal/clock issue** โ€” the 14.318 MHz clock feeding the SIO can drift at temperature.

### Recommended Steps
- **Reflow or reball** the Super I/O chip โ€” it's the most likely culprit
- **Check LPC pull-ups** (typically 10kฮฉ to 3.3V on LAD[0:3] and LFRAME#)
- **Freeze spray test** โ€” spray the SIO when hot to confirm it's the failing component
- If the SIO responds to freeze spray, replacement is the fix

My Youtube channel: https://www.youtube.com/@tony359

Reply 10 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t

>"where your board hangs"

you primed LLM ๐Ÿ™ LLMs are statistical hallucination machines not build to say "I dont know". Telling it what you want to hear often leads to confabulation just to satisfy inference reward function, makes LLM fixate on an idea and fall into local minima.
At least it looks like it did give you address of function generating 03 post code? ask it for decompilation of that function or do it yourself in IDA/Ghidra and feed decompiled code back (in fresh session or entirely different AI) so it can interpret it and tell you what the code is trying to accomplish (just init? reading sensors?). I would also double check with logic analyser if LPC bus is really not working when hot.

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 11 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

I tried Ghidra before for something else, I had no idea where to start. Any pointers to get started?

Yes, I know LLM "hallucinate" and tend to assume a lot.

One thing I can check is to inspect the LPC bus in working/not working conditions and see if I see something different. But if the RPi is able to read codes, I'd imagine the LPC is working?

I appreciate a logic analyser would be the next step. I'm kind of debating whether I want to invest quite some time on this or not. I definitely feel more positive now that we have pointers away from the BGA stuff! One thing I'll check is to inspect the surroundings of the Winbond - I didn't focus around there.

My Youtube channel: https://www.youtube.com/@tony359

Reply 12 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

Right, I had another free query with Claude ๐Ÿ˜€

I'm not sure how useful and "not hallucinating" the below is.

BTW, the BIOS is attached, in case someone wants to take a peek.

This feels interesting though, I'll definitely have a look around the Winbond.

The decompression is producing output but it's clearly not valid x86 code โ€” the data has extremely high zero-byte density (57%) and the non-zero bytes cluster around values `0x0e-0x1a`, which is characteristic of a **second layer of compression or encoding**. The decompressed TPC650~2.BIN is itself further processed before execution. This is common in Award BIOS โ€” the main module is doubly compressed.

Let me take a different approach and work directly from the uncompressed BootBlock region, which is where POST code `0x03` must originate from, plus examine the dispatch table more carefully.Now I have enough to give you a thorough and accurate answer. Let me compile this into a clear analysis.

Based on deep analysis of the BIOS dump, here is what I found about POST code `0x03` and the functions leading to it:

---

## POST Code `0x03` โ€” Origin and Execution Path

### The critical finding: POST `0x03` is NOT in the BootBlock ROM

Exhaustive scanning of the entire 2MB image finds **zero** instances of the `B0 03 E6 80` (`MOV AL, 03h; OUT 80h, AL`) instruction sequence. POST code `0x03` is output by the **decompressed main BIOS body** running in RAM โ€” specifically from within the LZH-compressed `TPC650~2.BIN` module (74,769 bytes compressed โ†’ 128KB decompressed). It cannot be extracted without a working double-decompressor chain.

### What runs BEFORE POST `0x03` โ€” the full traced sequence

**Phase 1 โ€” BootBlock (ROM, uncompressed):**

| POST | ROM Offset | Pseudocode |
|------|-----------|------------|
| `0x01` | `0x1FF769` | BootBlock starts; zeroes 0x0000โ€“0xA000 in RAM with `REP STOSW`, sets stack |
| `0xC0` | `0x1FE1F8` | Reads SuperIO index port `0x2E`; checks if chip responds. On **hot failure**, halts here at CF handler |
| `0xC1` | `0x1FE32E` | Flash/ROM size detect and checksum validation |
| `0x0C` | `0x1FE4D0` | Enters unreal mode (LGDT/LIDT; loads CR0 PE bit; disables A20 gate wrap) |
| `0xC3` | `0x1FE4E4` | Sets up decompression target buffer at `0x10000:0000` |
| `0xC5` | `0x1FE512` | Jumps to Award LZH decompressor at `0x1EE852`; decompresses `TPC650~2.BIN` |

**Phase 2 โ€” ROM shadow trampoline (still in ROM, F000:0013):**

After `C5` completes, the decompressed BIOS is in RAM but the CPU is still in ROM. A trampoline at F000:0013 handles early CPU init:

| POST | ROM Offset | Pseudocode |
|------|-----------|------------|
| `0xB0` | `0x1F0013` | `XCHG ESP,EBP` (save 32-bit state); CPUID family/stepping check |
| `0xB1` | `0x1F0020` | CPU feature flags test (CPUID.EDX); SSE2/HTT bits checked |
| `0xB2` | `0x1F002C` | L2 cache type/size via CPUID leaf 4 |
| `0xB3` | `0x1F005F` | FPU/MMX/SSE init; `0F 6E C0` (MOVD MM0,EAX) to test MMX |
| `0xB4` | `0x1F0075` | SMM base relocation (`WRMSR MSR 9Eh`) |
| `0xB6` | `0x1F0083` | Microcode patch check and load (`WRMSR MSR 79h`) |
| `0xB7` | `0x1F0100` | MSR final setup; `0F 6E C0` MMX test then `0F 7E C7` stores result |
| `0xB8` | `0x1F0127` | CPU init complete; `XCHG ESP,EBP; RET` โ€” returns to ROM dispatch |

**Phase 3 โ€” Decompressed BIOS dispatch table (RAM):**

The ROM dispatch table at `0x1FF79C` then calls into RAM functions:

| POST | Handler | Meaning |
|------|---------|---------|
| `0x05` | `F000:F7B4` | KBC (8042) detection: reads port 0x64, tests `A8 03` status bits |
| `0x0B` | `F000:F873` | Shadow RAM/BIOS copy setup: `REP MOVSW` from F000:7000 |
| `0x0C` | `F000:F8AD` | CMOS checksum read and verify |
| `0x0D` | `F000:F8B1` | CMOS defaults restore if checksum bad |
| `0x10` | `F000:F8FA` | PCI bus enumeration start |
| `0x11` | `F000:F92E` | CPU speed detect |
| `0x41` | `F000:F932` | (Reserved/vendor) |
| โ†’ **`0x03`** | *RAM* | **SuperIO early init โ€” called from within one of the above** |

### What POST `0x03` ("Initial SuperIO_Early_Init switch") actually does

Based on the 945GSE + ICH7 platform and the strings found in the BIOS (`945GSE`, `Intel(R) Atom(TM)`, `PPMINIT.ROM`, `SPIFLASH.BIN`), POST `0x03` represents the point where the BIOS attempts to:
โ€ฆShow last 55 lines

1. **Enter the SuperIO configuration mode** โ€” drives the LPC bus, typically writing `0x55` or `0x87, 0x87` (ITE) or `0x55` (Winbond) to the index port (usually `0x2E` or `0x4E`)
2. **Read the SuperIO chip ID register** (usually logical device 0, register 0x20)
3. **Compare the ID** against a table of known SuperIOs
4. **Branch** to the appropriate init path ("switch" in Phoenix terminology)

The pseudo-C reconstruction of what this function does:

```c
// POST 03: Initial SuperIO_Early_Init switch
void SuperIO_EarlyInit(void) {
    outb(POST_PORT, 0x03);        // Signal checkpoint to LPC debug port
    
    // Try primary SIO index port (0x2E)
    outb(0x2E, 0x20);             // Select chip ID register
    uint8_t chip_id_hi = inb(0x2F);
    outb(0x2E, 0x21);
    uint8_t chip_id_lo = inb(0x2F);
    uint16_t chip_id = (chip_id_hi << 8) | chip_id_lo;
    
    if (chip_id == 0x0000 || chip_id == 0xFFFF) {
        // No SIO responded at 0x2E, try 0x4E
        outb(0x4E, 0x20);
        chip_id_hi = inb(0x4F);
        // ... repeat for alternate port
    }
    
    // Switch on chip ID to select init routine
    switch (chip_id) {
        case 0x8716:  // ITE IT8716
        case 0x8718:  // ITE IT8718
        case 0x8720:  // ITE IT8720
            SIO_ITE_Init();
            break;
        case 0x52xx:  // Winbond W83627
        case 0xB02x:  // Nuvoton NCT67xx
            SIO_Winbond_Init();
            break;
        default:
            // Unknown SIO - hang or continue with minimal config
            // THIS IS WHERE THE BOARD HANGS WHEN HOT
            POST_hang();
    }
}
```

### Why it hangs when hot

The hang at `0x03` means the switch statement hits the `default` path โ€” the SIO chip ID read returns `0x0000` or `0xFFFF` (no response). When the board is hot, the Super I/O chip (most likely an **ITE IT8718F** or similar on the LPC bus) either:

- Fails to respond to the configuration-unlock sequence within the timing window
- Returns a corrupted chip ID due to a marginal LPC signal level
- Loses power momentarily due to a cold-solder or failed decoupling capacitor on its VCC pin

The freeze-spray test on the SIO will confirm this immediately. On the TCP-650H with a 945GSE, the Super I/O is almost certainly the small SOIC near the LPC header โ€” if it responds to cooling, that's your target for reflow or replacement.

My Youtube channel: https://www.youtube.com/@tony359

Reply 13 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t

It got impressively far at first finding main post bootblock loop at

seg000:F769                 mov     al, 1
seg000:F76B                 out     80h, al

but is just spewing garbage now ๐Ÿ˜€ F000:F8AD is pci config not cmos checksums etc.
It cant find post 03 "because its in compressed portion of the bios" despite this post code running before C5 decompression ๐Ÿ˜€ but still produced tons of text telling you what 03 does without ever seeing it ๐Ÿ˜€

It couldnt find A0 01 02 03 codes etc because Phoenix bios author are cucks and did it like this:

seg000:1AD0                 mov     ax, 0FF03h
seg000:1AD3                 out     80h, ax       
seg000:1AD5                 mov     esp, offset loc_F1AE8
seg000:1ADB                 pslldq  xmm4, 2
seg000:1AE0                 pinsrw  xmm4, esp, 0
seg000:1AE5                 jmp     jmp     sub_F2177

;-] 16 bit write to non existent 16bit IO port, hardware breaks it down to two 8 bit writes. AH to 81h and AL to 80H.
Whatever POST code 03 is doing is under loc_F2177
and this is where we crash and burn

seg000:2177 sub_F2177       proc near               ; CODE XREF: seg000:loc_F1AE5j
seg000:2177
seg000:2177 ; FUNCTION CHUNK AT seg000:1595 SIZE 00000045 BYTES
seg000:2177 ; FUNCTION CHUNK AT seg000:1649 SIZE 0000006F BYTES
seg000:2177 ; FUNCTION CHUNK AT seg000:4991 SIZE 00000078 BYTES
seg000:2177
seg000:2177                 mov     ebx, 8000h
seg000:217D                 mov     ebp, 78000h
seg000:2183                 and     ebp, 0FFFBFFFFh
seg000:218A                 mov     eax, 0E8h ; 'F'
seg000:2190                 mov     esp, offset loc_F21A3
seg000:2196                 pslldq  xmm4, 2
seg000:219B                 pinsrw  xmm4, esp, 0
seg000:21A0                 jmp     PCI_Read_Byte_Safe
seg000:21A3 ; ---------------------------------------------------------------------------
seg000:21A3
seg000:21A3 loc_F21A3:                              ; DATA XREF: sub_F2177+19o
seg000:21A3                 test    al, 1
seg000:21A5                 jz      short loc_F21AE
seg000:21A7                 and     ebp, 0FFFAFFFFh
seg000:21AE
seg000:21AE loc_F21AE:                              ; CODE XREF: sub_F2177+2Ej
seg000:21AE                 mov     eax, 0E4h ; 'S'
seg000:21B4                 mov     esp, offset loc_F21C7
seg000:21BA                 pslldq  xmm4, 2
seg000:21BF                 pinsrw  xmm4, esp, 0
seg000:21C4                 jmp     PCI_Read_Dword_Safe
seg000:21C7 ; ---------------------------------------------------------------------------
seg000:21C7
seg000:21C7 loc_F21C7:                              ; DATA XREF: sub_F2177+3Do
seg000:21C7                 test    eax, 1000000h
seg000:21CD                 jz      short WarmBoot_check
seg000:21CF                 and     ebp, 0FFF9FFFFh
seg000:21D6                 or      ebp, 80h
seg000:21DD
seg000:21DD WarmBoot_check:                         ; CODE XREF: sub_F2177+56j
seg000:21DD                 mov     edi, 0FED14120h
seg000:21E3                 test    byte ptr es:[edi], 1
seg000:21E8                 jnz     short WarmBoot_confirmed
seg000:21EA                 mov     dl, 8
seg000:21EC                 mov     dh, 13h
seg000:21EE
seg000:21EE SMBus_Read_loop:                        ; CODE XREF: sub_F2177+BFj
seg000:21EE                 mov     al, 2
seg000:21F0                 mov     esp, offset loc_F2203
seg000:21F6                 pslldq  xmm4, 2
seg000:21FB                 pinsrw  xmm4, esp, 0
seg000:2200                 jmp     SMBus_Read_Byte
seg000:2203 ; ---------------------------------------------------------------------------
seg000:2203
seg000:2203 loc_F2203:                              ; DATA XREF: sub_F2177+79o
seg000:2203                 jb      short SMBus_Read_ERROR
seg000:2205                 cmp     al, dl
seg000:2207                 jnz     short WarmBoot_confirmed
seg000:2209                 mov     al, 15h
seg000:220B                 mov     esp, offset loc_F221E
seg000:2211                 pslldq  xmm4, 2
seg000:2216                 pinsrw  xmm4, esp, 0
seg000:221B                 jmp     SMBus_Read_Byte
seg000:221E ; ---------------------------------------------------------------------------
โ€ฆShow last 36 lines
seg000:221E
seg000:221E loc_F221E:                              ; DATA XREF: sub_F2177+94o
seg000:221E                 test    al, dh
seg000:2220                 jnz     short WarmBoot_confirmed
seg000:2222                 jmp     short SMBus_keep_tryin
seg000:2224 ; ---------------------------------------------------------------------------
seg000:2224
seg000:2224 SMBus_Read_ERROR:                       ; CODE XREF: sub_F2177:loc_F2203j
seg000:2224                 xor     ebp, ebx
seg000:2227
seg000:2227 SMBus_keep_tryin:                       ; CODE XREF: sub_F2177+ABj
seg000:2227                                         ; sub_F2177+C1j
seg000:2227                 test    ebx, 40000h
seg000:222E                 jnz     short loc_F223A
seg000:2230                 shl     ebx, 1
seg000:2233                 test    ebp, ebx
seg000:2236                 jnz     short SMBus_Read_loop
seg000:2238                 jmp     short SMBus_keep_tryin
seg000:223A ; ---------------------------------------------------------------------------
seg000:223A
seg000:223A loc_F223A:                              ; CODE XREF: sub_F2177+B7j
seg000:223A                 test    ebp, 78000h
seg000:2241                 jz      short WarmBoot_confirmed
seg000:2243                 clc
seg000:2244                 jmp     short loc_F2247
seg000:2246 ; ---------------------------------------------------------------------------
seg000:2246
seg000:2246 WarmBoot_confirmed:                     ; CODE XREF: sub_F2177+71j
seg000:2246                                         ; sub_F2177+90j ...
seg000:2246                 stc
seg000:2247
seg000:2247 loc_F2247:                              ; CODE XREF: sub_F2177+CDj
seg000:2247                 pextrw  esp, xmm4, 0
seg000:224C                 psrldq  xmm4, 2
seg000:2251                 jmp     esp
seg000:2251 sub_F2177       endp

My very optimistic guess is its looping indefinitely at SMBus_Read_loop or SMBus_keep_tryin because it cant find something on SMBus. Ram in on SMBus but temperature sensors can also be on smbus. Maybe when system is getting hot ram connector pin responsible for smbus no conger conducts?

added partially decompiled ADS DS3630-945 bios source

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 14 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

Thanks so much for disassembling that for me.

Yes, AI can be so misleading because it comes up with rubbish without even mentioning "I'm not sure about that" - as you say, AI is not trained to say "I don't know".

Temp sensors would be inside the Winbond, right? I see the chip has an SMBus interface. You're suggesting that maybe the SMBus itself gets affected and the routine in the BIOS can't use it anymore and it gets stuck in there?
SMBus for the RAM is to read the SPD chip?

The system fails to POST with no RAM as well so we can exclude a RAM SPD issue but as you say it might be that the bus is getting affected by a mechanical issue. I can check that.

I'd imagine I could probe the SMBus and compare in a working/non-working state and see if I spot differences.

Would it be possible to add "debug outputs" to the BIOS so to add custom codes in that routine? It would tell us where the routine stops.

Thanks again for your time on this! I feel like I am a student here!

My Youtube channel: https://www.youtube.com/@tony359

Reply 15 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t
tony359 wrote on 2026-04-12, 09:57:

Yes, AI can be so misleading because it comes up with rubbish without even mentioning "I'm not sure about that" - as you say, AI is not trained to say "I don't know".

"This is the key part." "Yes, you're absolutely right โ€” and this is the key point." would say pandering AI while it bullshits you ๐Ÿ˜€
But its still fascinating how good they are when they lock in. It did decompile raw x86 binary without IDA/Radare after all! like those old timey autistic coders of 6502 days who programmed in HEX because they memorized whole instruction set ๐Ÿ˜€ it just got lost as its context window filled in or even overflowed. Thats why its best to do small steps and keep whipping it back on track.

tony359 wrote on 2026-04-12, 09:57:

Temp sensors would be inside the Winbond, right?

Winbond has ADCs for reading different sensors, but its on different bus and not touched here.

tony359 wrote on 2026-04-12, 09:57:

I see the chip has an SMBus interface.

Winbond has own SMBus interface, but BIOS is not talking to Winbond
Bios is using IO on 500-506h range, those are typically mapped to ICH7 SMBus (pins C22 B22) by BIOSes
https://www.intel.com.au/content/dam/doc/data โ€ฆ 7-datasheet.pdf
"14.2 SMBus I/O Registers"
its "easy" to recognize if you ever programmed intel SMBus

seg000:49D7                 mov     dx, 502h
seg000:49DA                 mov     al, 48h
seg000:49DC                 out     dx, al

48h send to 502h (SMBASE + 02h Host Control) is 0100 1000
"14.2.2 HST_CNTโ€”Host Control Register (SMBUSโ€”D31:F3)"
bit 6 Start and 4:2 010 "Byte Data" - this sends something to SMbus and can read back reply
Transmit Slave Address Register :

seg000:49C5                 mov     al, cs:[bx+4A0Dh]
seg000:49D1                 or      al, 1
seg000:49D3                 mov     dx, 504h

1 set here means Read. We are doing a Read from Address (upper 7 bits) fetched from some bios table.

seg000:4A0D                 db 0A0h ; รก
seg000:4A0E                 db 0A4h ; รฑ
seg000:4A0F                 db 0A4h ; รฑ
seg000:4A10                 db 0FFh

A0h is shifter one bit to the right (upper 7 bits) so in reality we are trying to talk to 50h - standard SPD ram address for slot 0.
SMBus_check does 4 SMBus_Read_loop loops trying inclementing offsets in that table.
A4h shifted is 52h standars SPD address of slot 1.
BIOS was written with 4 DIMM sockets in mind so someone filled it with bogus entries 3 (another 52h) and 4 (7fh total nonsense) instead of editing number of iterations.

tony359 wrote on 2026-04-12, 09:57:

You're suggesting that maybe the SMBus itself gets affected and the routine in the BIOS can't use it anymore and it gets stuck in there? SMBus for the RAM is to read the SPD chip?

yes initially, but no longer after sleeping on it ๐Ÿ˜€
because we are reading SPD values from offsets 2 checking if value = 8 meaning DDR2, and 15h (Byte 21) is
https://www.simmtester.com/page/news/showpubn โ€ฆ +SPD+Definition
"SDRAM Module Attributes' something about registers and FETs
TLDR it does sanity checking if RAM is present and compatible type

... but you decided to check without RAM so it would always stop here with PC speaker siren ๐Ÿ˜
it looks like you posted POST codes from successful boot with ram installed, and the second one from failed boots but with ram removed "because its faster to test" ๐Ÿ˜€

seg000:1AD0                 mov     ax, 0FF03h
seg000:1AD3                 out     80h, ax         ; manufacture's diagnostic checkpoint
seg000:1AD5                 mov     esp, offset loc_F1AE8
seg000:1ADB                 pslldq  xmm4, 2
seg000:1AE0                 pinsrw  xmm4, esp, 0
seg000:1AE5                 jmp     SMBus_check
seg000:1AE8 ; ---------------------------------------------------------------------------
seg000:1AE8
seg000:1AE8 loc_F1AE8: 
seg000:1AE8                 mov     ax, 0EEE0h
seg000:1AEB                 jb      ALARM_BEEP_LOOP
seg000:1AEF                 mov     ax, 0FF04h
seg000:1AF2                 out     80h, ax

if ram is found and compatible we will ALWAYS see POST 04, if ram is not present we will ALWAYS call ALARM_BEEP_LOOP and you should hear beeps
but the problem is that "mov ax, 0EEE0h" because the first thing ALARM_BEEP_LOOP does is

seg000:2015 ALARM_BEEP_LOOP:
seg000:2015                 mov     ax, ax
seg000:2017                 out     80h, ax

so POST code 03 should be followed immediately by either 04 or E0

WTF, computer is hanging while taking on SMBus for no reason. Both SMBus_Read_Byte and SMBus_check are super robust and will _always_ return no matter what with info if ram is installed.

tony359 wrote on 2026-04-12, 09:57:

Would it be possible to add "debug outputs" to the BIOS so to add custom codes in that routine? It would tell us where the routine stops.

yes and I even did that couple of times for other people on vogons in the past, but that was with much older simpler bioses
I dont know anything about checksums for Award 6.0 ๐Ÿ™
For me the most logical next step would be to just skip post 3 editing bios so it jumps straight to performing Post code 4
funnily enough Post code 4 DOES involve LPC ๐Ÿ˜€ but only to reset LPC bus and restart whole computer when it encounters Power Management Status it doesnt like. Sadly we never enter POST 4 so while it does sound like something that would involve powergood, we arent reaching this far.

TLDR: WTF. It seems to freeze while doing normal IO thro ICH7 SMBus. Just somehow electrically damaged SMbus would NOT cause this.

Everything is pointing at defective chipset/cpu. Have you tried the old chestnut of pressing on BGA chips during test to make sure balls arent cracked underneath?

also if your heart is still in it try reading post codes of a failed boot with ram installed

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 16 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member
rasz_pl wrote on 2026-04-12, 22:31:

... but you decided to check without RAM so it would always stop here with PC speaker siren ๐Ÿ˜
it looks like you posted POST codes from successful boot with ram installed, and the second one from failed boots but with ram removed "because its faster to test" ๐Ÿ˜€

Probably - I ran the first test with the board running ok then I started warming it up and took several tries so I believe I removed the RAM at some point as it's 2 seconds vs 8 seconds ๐Ÿ˜€
I can try again with the RAM installed if that helps.

TLDR: WTF. It seems to freeze while doing normal IO thro ICH7 SMBus. Just somehow electrically damaged SMbus would NOT cause this.

One of my viewers said they had exactly the same problem with the same model and they resolved by replacing the southbridge. I don't know what kind of diagnostic was behind that statement though.

Everything is pointing at defective chipset/cpu. Have you tried the old chestnut of pressing on BGA chips during test to make sure balls arent cracked underneath?

Oh I've been pressing and poking and bending for hours. Plus, I re-flowed the Northbridge. I'd imagine if it was BGA cracks, I would see a change in behaviour - even temporary - on the adjacent southbridge. I could try re-flowing the southbridge but the (plastic) CFlash reader is underneath.

also if your heart is still in it try reading post codes of a failed boot with ram installed

Shall do!

Thank you so much for your assistance so far, I'll re-read your cool message tomorrow and try to follow the programming a bit more!

My Youtube channel: https://www.youtube.com/@tony359

Reply 17 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

Post Codes with ram. No 04 I'm afraid.

First batch is a normal boot process. Second is after warming up the board (didn't take much).

Does this bring new data to the table?

STARTED
initializing the lpc bus sniffer program
Filter: 0x08002000
program loaded at 3, sm: 0
System clock is 198000 kHz
Starting to sample the POST codes.
...
...
...
...
...
...
...
...
...
...
...
data: b2
data: b3
data: b4
data: b6
data: b7
data: b0
data: b1
data: b2
data: b6
data: b7
data: b8
data: cf
data: cf
data: c0
data: c1
...
data: a0
data: 01
data: 02
data: 03
data: 04
data: 05
data: 06
data: 07
data: 08
data: 09
data: 10
data: 11
data: 12
data: 13
data: 14
data: 15
data: 16
data: 17
data: 18
data: 19
data: 20
data: 21
data: 22
data: 23
data: 24
data: 25
data: 26
โ€ฆShow last 301 lines
data: 27
data: 28
data: 29
data: 30
data: 31
data: 32
data: 33
data: 34
data: 35
data: 36
data: 37
data: af
...
data: 0c
data: c3
...
...
...
data: c5
data: 01
data: 02
data: 03
data: 04
data: 05
data: 06
data: 07
data: 08
data: 09
data: 0a
data: 0b
data: 0c
data: 0d
data: 0e
data: 0f
data: 10
data: 11
data: 12
data: 13
data: 14
data: 15
data: 16
data: 17
data: 18
data: 19
data: 1a
data: 1b
data: 1c
data: 1d
data: 1e
data: 1f
data: 20
data: 21
data: 22
data: 23
data: 24
data: 25
data: 26
...
data: 27
data: 28
data: 29
...
data: 2a
data: 2b
data: 2c
data: 2d
data: 2e
data: 2f
data: 30
data: 31
data: 32
data: 33
data: 34
data: 35
data: 36
data: 37
data: 38
data: 39
data: 3b
data: 3d
data: 3e
data: 3f
data: 40
data: 41
data: 42
data: 43
data: 44
data: 45
data: 46
data: 47
data: 48
data: 49
...
data: 4a
data: 4b
data: 4c
data: 4d
data: 4e
data: 4f
data: 50
data: 51
data: 52
...
...
data: 53
data: 54
data: 55
data: 56
data: 57
data: 58
data: 5a
data: 5e
data: 5f
data: 60
data: 61
data: 62
data: 63
data: 65
data: 66
data: 67
data: 68
data: 69
data: 6a
data: 6b
data: 6c
data: 6d
data: 6e
data: 6f
data: 70
data: 71
data: 72
data: 73
data: 74
data: 75
...
data: 76
data: 77
data: 78
data: 79
data: 7a
data: 7b
data: 7c
data: 7d
data: 7e
data: 7f
data: 80
data: 81
data: 82
data: 83
data: 84
data: 85
data: 86
data: 87
data: 88
data: 89
data: 8a
data: 8b
data: 8c
data: 8d
data: 8e
data: 8f
data: 90
data: 91
data: 92
data: 93
data: 94
data: 95
data: 96
data: ff
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
data: b2
data: b3
data: b4
data: b6
...
data: b7
data: b0
data: b1
data: b2
data: b6
data: b7
data: b8
data: cf
data: cf
data: c0
data: c1
...
data: a0
data: 01
data: 02
data: 03
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
.

My Youtube channel: https://www.youtube.com/@tony359

Reply 18 of 19, by rasz_pl

Posted onย 
User metadata
Rank l33t
Rank
l33t

I forgot to ask for normal boot without ram just to validate computer is really running the decompiled code ๐Ÿ˜€, in theory should stop at 01 02 03 E0
sadly that means its just getting stuck while using ICH7 SMBus. I think this is the first time bios accesses SMBus.
BIOS itself is connected to ICH7 on and data goes ICH7 (southbridge) > DMI link (early almost PCIe link) > GMCH (northbridge) > CPU meaning everything in this path must work if you see POST codes.

It keeps pointing at ich7 or maybe 945 defect that somehow triggers when accessing smbus? if ich7 was to somehow crash it would stop execution as afaik cpu caches are disabled at this point

https://github.com/raszpl/sigrok-disk FM/MFM/RLL decoder
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module (AT&T Globalyst)
https://github.com/raszpl/386RC-16 ram board
https://github.com/raszpl/440BX Reference Design adapted to Kicad

Reply 19 of 19, by tony359

Posted onย 
User metadata
Rank Member
Rank
Member

Thanks - I'll get codes for "working with no RAM" too.

Yes, I can imagine that finding the exact issue is not possible - but at least we have a pointer to the southbridge. I can try poking around it. One thing I noticed is that if I warm up the area around the southbridge, the board will eventually stop posting. But who knows, maybe it was the northbridge getting hot because of my tries.

I'd like to inspect the SMBus for anomalies and take a look around the SB.

I might remove the southbridge and re-ball it. Or maybe see if I can source another one if they're not expensive. But I'll probably have to remove the CF reader at the back first.

The big breakthrough (!) of this analysis is that it's not a "powergood"issue as I though. I thought the board was completely dead when not posting but it's not.

Thanks for now!

My Youtube channel: https://www.youtube.com/@tony359

Go to top of page Go to top of page
Back to General Old Hardware
Close window
Close window