I’m repairing laptop ASUS GL552VX (Intel HM170). The problem was “the computer does not turn on”. Now I’m stuck at standard problem, power off after 30 min. I have read different articles on this forum, but have not found a solution. So, I need your help. I suppose the original BIOS dumped from the chip was not really “original”. “ME Analyzer” says it is “Configured” not “Initialized”. This means that somebody before me tried to re-flash the BIOS. And that means that I have no serial number, MAC, etc. in the BIOS. But I have all this information on stickers.
So, what has been done? I have tried several versions of BIOSes but eventually I have selected two of them, one is the “original”(see above), another is “real” BIOS found on Internet (“Initialized”).
I cleaned them with “Intel CSME System Tools v11 r32” (according to the guide “Clean Dumped Intel Engine (CS)ME/(CS)TXE…”, D4. CSME 11 - 14 & CSTXE 3 – 4). I used “11.0.0.1205_CON_H_D_PRD_RGN” and “11.0.0.1180_CON_H_D_PRD_RGN” versions from “Intel CSME 11.0 Firmware Repository r54”. With both versions I could turn on computer and load system, but after 30 min it turns off. My “original” BIOS does not show any serial or MAC in BIOS Setup. “Real” BIOS contains some serial and MAC but, of course, they are wrong.
Finally, I have built my own BIOS image. I got “11.8.79.3722_CON_H_DA_PRD_RGN” and downloaded most recent BIOS (v303) from ASUS site (this is “BIOS Region” with header) and build BIOS image. I flashed that image and then using ASUS utility BT2.exe modified serial, model, MAC and even keyboard backlight :). All works, but computer turns off after 30 min.
Yet one thing. During my experiments I set HAP Bit and in this case laptop does not turn off after 30 min. And it seems it works good, but when I shutdown or switch to sleep Windows the laptop does not power off completely, I have to press the power button a few seconds to turn it off. I do all flashes in DOS (win98) booting from USB. After re-flash an image I do “fpt.exe -greset” (almost each time :). Also I disconnected all power sources including CMOS battery and changed memory DIMMs.
MEInfo.exe without parameters has never worked on this laptop. I always get communication error. You can find results of “MEInfo -fwsts” in the attached screenshot.
I still need your help. Below is some additional information. When I boot Windows just after reprogramming flash I see screen “1180-(ME)”. When I press the Power button Windows shutdown but power does not switched off and I have to press a few second Power button again. When I start Windows again (and in all subsequent launches of the computer) I see “1180-(no ME)” and in this Power off and Stand by work properly. But the problem of power off after 30 min remains.
Try re-flashing the entire attached 8MB SPI image, remove all power from the laptop for 1 minute and boot. Check if it stays alive for more than 30 minutes and verify its status via MEInfo tool.
Thanks for your replay. I have re-flashed with "fpt.exe -rewrite -f GL552VX_fix.bin" command and removed all power including CMOS battery for a 1 min. The problem has not gone, the laptop turns off after 30 min…
The output of MEInfo is following:
c:\asus\MEInfo\WIN64>MEInfoWin64.exe
Error 86: Communication error between application and Intel(R) ME module (FWU client) Error 81: Internal error (Could not determine FW features information)
c:\asus\MEInfo\WIN64>MEInfoWin64.exe -fwsts
FW Status Register1: 0x80034055 FW Status Register2: 0x467F0116 FW Status Register3: 0x00000020 FW Status Register4: 0x00085204 FW Status Register5: 0x00000000 FW Status Register6: 0x00400B48
CurrentState: Normal ManufacturingMode: Enabled FlashPartition: Valid OperationalState: CM0 with UMA InitComplete: Initializing BUPLoadState: Success ErrorCode: Debug Error ModeOfOperation: Temporary Disable mode SPI Flash Log: Present FPF HW Source value: Not Applicable ME FPF Fusing Patch Status: ME FPF Fusing patch NOT applicable Phase: Loading ICC: Valid OEM data, ICC programmed ME File System Corrupted: No FPF and ME Config Status: Not committed
There are two possible reasons. Either bad hardware or wrong original dump. GL552VX is not the same as GL552VW or GL552VXK and I’ve seen some dumps configured to use HM175 instead of HM170. So it’s likely that you just haven’t found a valid dump for your exact model so the CSME settings are not appropriate.
The model of laptop is FZ50VX-WS74. ASUS web site allows to select one of two “CPU or BIOS model name” GL552VX and GL552VXK (see asus-support.png). I have some stickers on the mother board where I see GL552VX (see mobo.png). Also I see the model of mother board that is called GL552VW rev 2.1. So I think the right bios is GL552VX. I also saw those versions of dumps for VXK, for HM175, but I did not try them. Is it correct?
Is there a way to diagnose the hardware problem? Can MEInfo help in this? Or is there a way to make sure that the problem is in hardware? I’m confused by the fact that computer works absolutely properly, but only 30 min.
Try these attached SPI images. Start from fix 2 and, only if it fails, try 3 and 4. Each time flash the full SPI image and remove all power for 1 minute before attempting to power on again and test if it works.
Thank your for images and sorry for delay. I have tried all three images twice - fix2, fix3, fi4 and then again fix2… All the time computer turns off after 30 min.
I understand, most probably the problem is in hardware… Ok. There are two results of MEInfo. First one is that I see just after power on after flashing (FirstBoot.txt) and second one is that I see in all subsequent launches of computer (SecondBoot.txt). Also I noticed that if I press Power button after the first boot the computer does not turn off completely and I have to press button a few seconds after the system shutdown.
Ok, last two fix attempts. First try 5 and then 6. Make sure that FPT is actually re-flashing the entire 8MB SPI chip (I think it has a verify parameter?) and make sure to remove all power for 1 minute after each re-flash (press the power button a few times as well while it’s unplugged). At first boot, you can also try a fpt -greset. After the greset restart, check MEInfo -fwsts. The goal is to not see “Debug Error”, “Temporary Disable mode” or similar. If these are seen, it will probably turn off after 30 minutes.
I have tried both images. Alas, the problem has not gone.
You can see the screenshot with FPT command on “fpt-cmd.jpg”. After flashing I disconnected all power sources for more than 1 min and pressed the power button. Results produced by MEInfo after the first boot are there, “FirstBoot-fix5.txt” and “FirstBoot-fix6.txt”. After first boot I executed “fptw64.exe -greset”. Results of second boot are there, “SecondBoot-fix5.txt” and “SecondBoot-fix6.txt”
Does anything change if you flash the attached image via “fptw64 -desc -f fd_f2.bin” followed by “fptw -greset”? Careful on the command, this is not a full SPI image, only the Flash Descriptor region.
I don’t expect the above to change anything. Generally, are you able to re-flash the SPI chip via a programmer or do you rely exclusively on FPT via the unlocked Flash Descriptor? The “Temporary Disable mode” is either set in Flash Descriptor settings (not in this case) or sent via the BIOS during POST (not in this case). So I don’t understand why it’s shown. One (far fetched) theory I have is that maybe the BIOS detects that the FD is unlocked and intentionally sends the “disable” command to trigger the 30 minute watchdog. You know, as a “security measure”. Who knows… But we would need to lock the FD to test that, which will require an external programmer the first time afterwards.
By the way, do you still see that “1180-(no ME)” or similar message? Does it provide any more info? The only thing that 1180 could mean is CSME 11.0.0.1180 version from 2015. Maybe the BIOS expects that version only? Nah, that doesn’t make sense. We could try it of course. At this point we are grasping at straws.
If I flash image 1180.bin I see that result "1180-(no ME)" on the second boot (without "fpt -greset" but with disconnecting power for 1 min). "1180.bin" is the image built by myself and yes, this is version 11.0.0.1180.
Yes, I have the programmer, but I use it as emergency tool only because it requires un-soldering the SPI chip. I used it at the beginning of repairing the laptop. Also I can use method E1 ("Pinmod") from your guide "Unlock Intel FD…".
I have not check yet "fd_f2.bin" because of not sure which version of SPI images should be flashed before. Fix5, Fix6 or Fix2 or may be any of your fixes?
Ok, so we ignore 1180. It has nothing to do with the underlying issue.
Right, I consider fix5 the “best” one (in theory) so far so flash that first. Not that it matters really for the FD re-flash but anyway.
Well if fix5 + fd_f2 does not help, we are officially out of firmware solutions. In that case, you can try locking the FD (flash fix5, fpt -greset, fpt -closemnf) and yes, you can of course unlock it with the pinmod without using the programmer, if you can do it. Pinmod can be hard nowadays with how small the audio chip pins are, that’s why. Honestly I doubt ASUS has added such a “measure” in the BIOS in regards to an unlocked FD but, other than that, I cannot possibly think of anything else besides some sort of hardware issue (PCH, motherboard). In the end, the system is not usable if it shuts down every 30 minutes so you probably have nothing to lose when it comes to locking the FD. It’s up to you though.
We can lock the FD manually if -closemnf does not work due to the CSE being Disabled. I have attached fix 5 with its FD locked. Give it a try with the usual procedure and let’s see.
For information only. To do “pinmod” on this board is quite easy. We have to short two points near the audio chip. See green marks on “mobo-pinmod.jpg”
Ah yes it is indeed fairly easy on that ASUS board. Well, we have tried everything on the firmware side of things. The previous Fix 5 includes a proper/locked FD, stock/clean ASUS BIOS for GL552VX (6th Gen) and proper/clean/updated CSME firmware with settings for GL552VX + HM170 PCH. So it must be hardware. From what I can tell you got the system from someone else so maybe they tried to fix something and caused problems. Maybe a PCH swap? Either way, unfortunately there is nothing more I can think of at this point.
