Oh I see, he smaller Intel ME .bin files (the ones provided here for example) are usable with FWUpdLcl and for version updating only. Got it. Also, I found some updated oROMs by “looting” the bios from other Clevo models with certain identical hardware (I’ll use MMTool for these). Specifically:
[197B-0250] JMicron JMC25x LAN PXE v1.0.10.0. The stock is v1.0.9.0. [10DE-0DF4] Nvidia VBIOS v70.08.53.00.C0 from 17/06/2011. The stock is 70.08.53.00.12 from 06/04/2011. The rom is from another Clevo laptop with a 540M 1GB (mine has 2GB). I opened both roms with NiBiTor to see if there are changes. I did find 2 minor ones: Display Boot Messages & Sub-System ID and a more important difference regarding memory speed. It seems my card runs at 900MHz whereas the other at 800MHz. In theory if I change these according to my stock ROM it should work perfectly fine. Updating the rom while keeping OEM settings. I have attached both roms with NiBiTor in case you want to take a quick look.
1. Since the flash descriptor is locked normally, it is my understanding that other users who will use the modded bios will need to execute MESET.exe first and then flash the updated BIOS in order to update the ME region. The question is, should I use fpt or afudos to update the ME region? I know afudos has a “me update command” but I’ve never seen someone use that. They mostly use ftp for ME and then afudos for BIOS & EC. So if I use afudos I’m thinking of a batch file for MESET.exe (step1), reboot and another batch file to update BIOS-ME/EC (step2) which will shutdown the laptop when afudos is done and reapply the lock. If I use fpt for ME I would have 3-step batch files: MESET.exe (step1), reboot and update ME with fpt (step2), call another batch to update BIOS/EC with afudos (step3) and shutdown to reapply lock.
2. Do you happen to know how to merge the BIOS & EC of AMI systems into one file? I couldn’t find anything about it around the web.
3. What tool did you use to extract the oROMs & Microcodes in such a nice way (name, dev_id etc) as seen here?
You should do a full test after replacing that Nvidia VBIOS. Normally you shouldn’t use a VBIOS designed for less memory, maybe only to use its EFI section. But since the differences are small and your laptop has Optimus with screen connected to iGPU (check!), you can jump to this updated VBIOS. Too bad FermiBiosEditor doesn’t work with this ID, it would have been the appropriate tool.
1. This is not needed. The descriptor is to prevent unauthorized access, not to prevent normal flashing. The ME should update with main BIOS, if not, try to add /ME argument to step 2. If you can find someone to test this for you, you should just give him the Clevo flasher pack with just the stock BIOS file replaced with modded. If he doesn’t see a ME version bump, experiment with /ME argument or FPT. Or you can try this on your own, by flashing the stock BIOS or an older ME, check ME version, then flash modded BIOS and check again.
Basically you would use step 1 for EC and step 2 for BIOS + ME using afudos. If it fails to update ME, add a step 3 for ME update with FPT.
2. If they are offered as two files, leave them as such. What I see is that Clevo has offered an older BIOS version .06 as EC container. This older BIOS has EC 1.00.06, while 07 has EC 1.00.05. Nothing else is different. It might be possible to add the EC from older file, but why risk it? You would still have to use a separate .bat with /E command to flash EC on its own, so you would just save space, nothing more. But with what cost?
3. I used my own script, which was developed on top of UBU and with code from UEFITool. I have posted an older version in UBU thread, but lately I have added more options to it, with a very sluggish code, that couldn’t be appealing to real coders. Still, it does the job for me.
I tested the JMC25x and 540M oROMs. The JMC25x is indeed updated, just for the sake of it. I modified 70.08.53.00.C0 according to my card’s settings and I flashed it. It seemed fine at Windows but doesn’t work for anything 3D-related with driver crashes and corruptions. I rolled back to 70.08.53.00.12 and left it alone.
So, the ME is not updating with normal flashing. With MESET, only FPT proceeds. First I update ME, then EC and then BIOS. However, afterwards when I restore default bios settings this happens:
It happens on the fly. If I save the settings after that, it gets stuck like this which means you cannot boot from anything except CD/DVD’s. To fix it, I have to restore the default ME and reflash the EC & BIOS with three consecutive commands. It has to be ME/FPT related since I never had problems with the modified BIOS itself.
EDIT: So after some tests I concluded that it has nothing to do with my modded BIOS but entirely with the updated ME inside it. I tested both StockME+StockBIOS & StockME+ModdedBIOS. As long as the ME was not updated the weird problem was never appearing. I found a way more elegant solution though which does not require FPT or MESET. I will use the DOS version of FWUpdLcl with the v7.1.60.1193 ME Update. It works like a charm.
Basically all this time I was trying to find a way to bypass using FITC v7.1.20.1197 to rebuild the ME (after manually inserting it and fixing OEM settings) since I’ve read that it rebuilds broken images resulting in bricks. That only leaked version is flawed when it comes to 6-series systems.
However, I still don’t understand what it is I did wrong when manually inserting the dumped ME, causing the boot order issue. I’m thinking it has something to do with the ME coming from a dump. Do you have any idea?
Regarding the ME issue I was having earlier in this thread:
The problem was the dumped ME as I suspected. Basically even for ME, you cannot use a dump to update it (even your own dump for your own laptop) as it’s not clean. The image shown above is the result of a “bricked” ME. For 7-series and up systems this could mean a BIOS brick but 6-series systems are able to work without a functional ME and so I was able to recover my laptop’s ME functionality. Instead I used FWUpdLcl tool + ME 7.1.60.1193 1.5MB image to update the ME without needing any extra tools like MESET or the “scary” FPT flasher. You can find the FWUpdLcl tool + ME update file at this forum here:
Kind of weird that ME doesn’t update. Maybe the BIOS has to be built with instructions to update the ME region when a new version is found. My version of a normal flow would be to update EC, then BIOS and then ME, followed by a shutdown with user approval.
I don’t know why you had problems with including ME in BIOS. You should know that it is best to shutdown the system after this kind of flashing and reset CMOS. Another step would be to reset EC if problems are to be found. I also have found problems with this latest ME on another laptop, twice finding that the driver-firmware connection has been lost, most likely from firmware corruption. In both cases it was solved with just a simple command of dumping the BIOS. Either this firmware has problems or the procedure is quite sensitive and must be done in a precise order (EC -> BIOS -> ME), followed by shutdown, reset defaults, reset EC. But if this has the same bugged outcome, I see no reason to use it when you can just flash the updated ME separately.
As for the dumped ME, I don’t see how it can brick your own laptop. It it where the case, then FPT should not touch the ME region, otherwise you will get a brick. Intel FPT works by writing the image as you provide it, no matter what it contains, as long as it is the right size. Any user can dump his ME with FPT, then flash it back, so how would the hex method fail, when it uses the same bytes? I still think it is either the ME itself or a procedure glitch (the flashing itself, not your modding). But you are already covered, so don’t feel compelled to run any more tests.
It is safer the way you have done it, the end user won’t feel a difference.
The procedure that I follow at my released mods is basically a single batch file:
afudos BIOS /E /P /B /N which updates the main block + EC FWUpdLcl -f ME -allowsv which updates the ME with the update firmware afudos /q /shutdown which terminates the system which is important as you already said
I have learned that if you use FWUpdLcl it automatically resets the ME after flashing it. FPT does not do that and so the shutdown or me-reset is indeed needed in that case. The thing is that even if I succeeded in embedding the ME inside the BIOS, I would have to use MESET.exe, FPT & Afudos to update everything. Now I only need afudos and FWUpdLcl which are much safer tools. And indeed the end-user will not notice any difference at all. Well according to Prema who is a legend at Clevo bios modding my ME was bricked because it’s not clean coming from a dump. It sounds strange to me as well since it came from my own system but I don’t know. I do trust him as he knows a lot more. You can find what he told me HERE.
This is a little irrelevant to my HM65 modding but it has to do with ME. I noticed that station-drivers & fernando have full 1.5MB ME firmwares for flashing with FWUpdLcl for 7-series and up systems and that confused me. I thought that only update files can be used with that tool. So I did a little digging between my HM65 and Z77 system and came to that conclusion mentioned in the ME Thread:
Indeed, embedding ME is longer and dangerous, so you have done the right thing. About the brick, Prema could be right, since I don’t have access to a newer system to test. But it should be easy: take a system with 8.xx or 9.xx firmware, update to one of Station-Drivers latest image, dump the ME with FPT (not working on most systems, needs HDA pin-mode). Then take the clean image from Station-Drivers and past the settings from the firmware inside official BIOS. Last step is to compare the two of them.
At first I thought that FWUpdLcl works with both images, since it parses the image to find $MN2 or $MAN signature and update from there. But you might be right, only 7.xx and newer are capable of that, since 6.xx and older packages always come with only the small update image.
No, it was just an example of a test to compare a dumped ME (using FPT) with an official ME patched using FITC. This will show if the dump is really dirty as compared to a clean image updated with OEM settings.
