I have an old Asrock B150M Pro4V which doesn’t respond to the power button (completely dead) and I suspect has a bad PCH; I don’t have the exact repair manual, but looking at the Asus B150-PRO D3 (similar MB) repair manual which briefly describes the startup sequence of the PCH I have all the rails/clock up to S5 state (soft off):
Searching on the web I found another user which resolved the exact same issue on the same board with a PCH replacement.
Now the real question: given that a replacement B150 PCH costs ~22€ for a 40€ motherboard, I was wondering if I could replace the bad PCH with a salvaged Z170 from a dead MSI Z170 Gaming M5 board. The stencil for reballing is the same, I couldn’t find the pinout for the PCH but I would dare to suggest it’s the same. Does anyone know if it can be done sofware wise? Do I need to clean the ME config?
based on what you found, this does look like a PCH issue
i think you could try replacing the PCH bc B150 and Z170 use the same physical FCBGA1440 package.
but, it might not work since the Intel ME is prbly locked bc the ME region in the BIOS is tied to the specific PCH SKU
i have some questions :
do you know if boot guard is enabled ?
does your mobo check the PCH device ID via ACPI ?
if everything’s good you could try it but i dont know if it’s worth it bc Intel really tried to make PCH replacements hard and you might encounter other issues
Thanks for the info! I couldn’t check anything because the board was dead.
Yesterday I had a bit of time to FAFO, and the board now powers up with the salvaged Z170 PCH even if the solder mask did get a little bit damaged during clean up on ground pads!
However the board never lifts PLTRST# (which comes from the PCH) and I never get Vcore even if the ISL95824 (responsible for the core & cpu voltage) gets the 1V signal named “VR_ENABLE” on pin 8. I don’t know if the CPU works, it came from a MB that had a PCI-E slot catch fire because of water ingress, and the CPU is responsible of the negotiation with the power IC (the ISL aforementioned), so maybe it’s the CPU dead (or the PCH dead, it’s my second reballing of my life but it went smoother than I imagined…).
Otherwise how can I check if bootguard is enabled if the board doesn’t boot?
I can get almost anything checked (due to naming differences I can’t find everything, even on the Asus boardview) up to… PCH Clock Outputs, named PCH_CK_33M_SIO on the Asrock boardview and going from the PCH to the SIO (Nuvoton NCT6791D pin 15 and 18, “System clock input” and “PCI-clock 33-MHz input” from the datasheet, so I guess that should be it…), then the naming gets completely different even on the same Asus Boardview that the repair manual is for.
I’ve checked many PWROK/PWRGD signal and almost everything is there, but I can’t find an equivalence for “P_VRM_EN_5”, it should go from the SIO to the PCH…
Curious that the Vcore was sequenced as no. 16 but then moved after no. 18 PLTRST#… Maybe an errata?
About the BIOS: I tried updating it with the file from the Asrock website and with the new version the PCH heats up a little bit, with the original untouched it stayed cold.
I also tried dumping after a couple of power on cycles, and it changed, so there seems to be some activity… Here’s the original and the dump: B150 Pro4V – Google Drive
Thanks for providing new files !
So, i checked your BIOS (the one you sent on GDrive) with Ghidra and i think it did flash correctly since it’s completely different from the other one (lots of different blocks). However i found only minor differences with the updated one. The dump one also is slightly different from the update, so it confirms that the PCH is at least partially functional.
For PLTRST#, i found that it could not be assigned probably due to a a dead or uninitialized CPU (since PLTRST# is PCH-driven but CPU must negotiate with VR controller). Or, BootGuard not blocking boot based on current FDR data BootGuard is likely not enforced.
Also Vcore is not present right ?
Because Vcore being not present despite VR_ENABLE being high implies CPU not responding or not completing handshake with ISL95824.
Since you mentioned:
ISL95824 does receive VR_ENABLE (pin 8).
But no Vcore and PLTRST# never asserts.
So, you can ckeck these key signals if you need :
1. VRMPWRGD (Signal 11)
Ensure it’s high (from ISL95824 or related circuitry).
This is needed by the PCH to lift PLTRST#.
2. PCH_PWROK (Signal 10) and PWR_OK (Signal 9)
Both are prerequisites for PLTRST#.
Trace these back from the SIO/PCH logic.
PWR_OK typically comes from the power supply after all rails are stable.
3. H_VID lines
These should be pulled to valid logic levels.
If they float or are stuck, the CPU may not negotiate properly with the VR controller.
4. VRM_EN / VR_ENABLE to ISL95824
Already confirmed present. Good sign.
5. Check if PLTRST is driven low actively or just floating**
If floating, PCH might be dead or not fully powered.
If held low, likely PCH logic is intentionally holding it (i.e., waiting for conditions to clear).
You could try :
checking PCH Clock Outputs (PCH_CK_33M_SIO) if there’s no clock to SIO, PCH may not be fully initialized.
checking CPU_PWRGD and VR_RDY these must be asserted before PLTRST# goes high.
checking with another cpu
try to confirm ISL95824 VIDs are correct because some platforms require CPU VID handshake before Vcore is generated.
Check PLTRST# with scope
Check if PCH is generating clocks (25/33 MHz).
Confirm VRMPWRGD and PCH_PWROK are HIGH.
Verify CPU socket voltages (VCCSA, VCCIO, VCORE rails).
Substitute CPU — likely root cause if ISL95824 is good and gets enable.
