Help microcode update for Aspire-531P Acer BIOS v1.22 :

Special Topics CPU Microcodes
1

I have updated the firmware with the hexa code editor (the CBROM tools are not functional in this case) “copy/b” thanks to the right tutorial.

The new microcode is perfectly detected by MC extractor.

I performed a rebuild with UEFITool (using UEFITool NE to confirm the location) to correct the Checksum I thought.

However, this does not allow you to boot correctly: black screen…

Obviously I don’t know why what causes the anomaly at the boot I must have missed an episode, help would be welcome thanks

microcode.zip (14.2 KB)

BIOS_Acer_1.22_A_A.zip (3.1 MB)

2

@Kjose - Yes, that means failed edit , could be anything, I’d have to see a copy of your modified BIOS to try and see what the problem was with your edit.

MC Extractor only shows what microcodes it finds, it does not do any type of BIOS integrity checking or anything like that to possibly tell you if anything was wrong with the BIOS file itself.
Nor does UEFITool unless you know what to look for, how to check certain things etc. And UEFITool itself can break a BIOS, so again, hard to speculate without seeing a copy of your mod BIOS attempt.

copy/b doesn’t make any sense to me, so maybe this tutorial you found is incorrect, or outdated for your model? I modify BIOS all day, for all kinds of random models, and use hex editor all the time, that doesn’t ring any bells to me, however it may apply only to some specific hex editor?
Yes, any BIOS you can open in UEFITool (UEFI BIOS), is not going to work with cbrom as that is very old legacy BIOS type tool. This is Phoenix UEFI BIOS, sometimes tricky to edit if you are changing microcode sizes.

Not sure which checksum you were correcting? I see the stock BIOS has two incorrect checksums, those could possibly be corrected, but maybe best left as-is by manufacturer unless you have flash programmer to recover from failed flash.
And yes, I see one of those is in the exact volume we edit for this, not ideal, crappy BIOS engineers I’ll update in this instance due to that, but normally I’d leave it as-is. Actually, after my entire edit the “Correct Checksum Should Be” given by UEFITool stays the same before/after, so I will leave as-is
Did you insert or paste over the old 306A9? If you inserted, you may have pushed down the CMDB entry or something, and that would break it? Again, hard to guess, I’d have to see your file before I could try to see for sure what happened.

Here, I think this should be OK, all uCodes updated

uCodesUPD.png



http://s000.tinyupload.com/index.php?fil…109234988592705

3

Thank @Lost_N_BIOS , I’ll try to be specific.



I understand, my modified BIOS for the specific CPUID (with latest ME) below without be rebuild with UEFITool.



Indeed, no clarification from me, please excuse me, so I will correct that; I based myself on this tutorial (Phoenix48): [Guide] How to update the CPU microcodes on a non-UEFI Award/Phoenix BIOS located at "ALTERNATIVE: The HxD Editor way to do it."




FileSystem GUID: FFF12B8D-7696-4C8B-A985-2747075B4F50 (with UEFITool)



I also noticed that, I did two reprogramming, one with a bios without modifying the checksum, the other with: in both cases it is the black screen…



The old code 306A9 is from MC Extractor since fw1.22, and is easy to find by editing fw1.22 with HxD, once highlighted in blue, I copy (the new 306A9) and overwrite (on the old 306A9) and save a new copy.

The new code is obtained with the tool Intel Microcode.dat Converter, (microcode source Intel github).



It would be nice to know because I feel like there’s something I’m missing



I only tried it with the new 306A9 thinking I would minimize the risk of error…

NEW306A9.zip (2.96 MB)

4

@Kjose - You’re welcome, and thank you too. I gotcha, copy/paste in-place edit is what you did, that is kind of what needs done, but it needs done in a certain way.

On the checksum, I think it should be left as-is, I’ve seen this often and sometimes it’s fine to fix, but in this case I don’t think it matters because before/after edit, the suggested correction checksum by UEFITool remains the same
You’d expect this to change if you edit the module, but it doesn’t, so I think it should be left alone, should be fine as it original is by manufacturer

You can get all updated microcodes hear, easier place for you to check later if you ever need again, this is maintained by creator of MC Extractor and the owner of this forum - Plutomaniac
https://github.com/platomav/CPUMicrocodes/tree/master/Intel

Did you test the BIOS I made for you yet?

You mentioned with latest ME? You never mentioned updating ME on your original message, it’s possible if you did this it was done incorrectly too.
Did you follow the clean ME guide, and transfer your settings from original ME to the new ME FW? If not, this could be why it’s failing, or some other reason too. Checking BIOS now.

How are you flashing? Did you test this BIOS version flashed in as it is (stock), without editing it? Never mind, for now, this doesn’t matter, the issues are all as noted below (This is broken BIOS in various ways)
Good thing, your microcode edit itself looks fine to me , but BIOS broken at various places and should not be used, will not boot - as you already know now

* Edit - OK, not sure what all you have done, but I see several errors in that BIOS not in the original BIOS.
You can see these things in the parser tab by opening stock BIOS side-by-side with your mod BIOS, using UEFITool NE version (51 and then check with 55 too for last point, or check with 55 for all). BIOS would be broken due to any single one of these issues below.
1. Checksum error on main BIOS volume (FVCompact)
2. Checksum error on Memory Init Module
3. Main volume corrupt (FVCompact, decompression failed) = VERY BAD
4. EVSA Store messed up, padding extended past data etc, all failed entries above = a mess - this checked in UEFITool NE 55
Additionally, this volume is not parsed into an expandable item in UEFITool NE 55 with stock BIOS, yet it is in your mod BIOS, probably due to all this being broken

Also, on the ME FW Update, I don’t know what you did, or how you did it etc, but I compared an extracted ME FW region I did the update/clean/transfer process from vs the ME Region in BIOS you sent, 40-50 differences, so your ME FW update was not done correctly either.
I compared to stock and it doesn’t match that either, so at least you didn’t straight swap in the ME FW without any settings/configuration applied

Test my BIOS with the updated microcodes, if it’s OK, I’ll send you new one with updated ME FW in it too.

5

Thank @Lost_N_BIOS , and so, I updated (with flash programmer) your BIOS -Acer Aspire-531P-1.22-uCode-UPD-Mod- as an attachment and everything works: fascinating !

Indeed I had previously integrated the last ME blob (with Flash Image Tool) which worked before the 306A9 update. I must not have done things right, it’s obvious because it doesn’t work

I would like to master the correct update of the micro code to be autonomous and unlock hidden functions (nothing certain), and understand why anotherAcer BIOS v2.18 was released at the almost same time and with a different version number…

But before that how did you manage to update the micro code from a bios stock in this case ?

6

@Kjose - You’re welcome! I didn’t know you were using flash programmer, that’s not ideal for what you asked to be done. For use with flash programmer you need to flash the stock BIOS using stock update method, and then dump that with programmer, then modify that dump (Too late now).
If you don’t do that you can loose all your original NVRAM, Serial, UUID, and possibly LAN MAC ID too.

Good to hear the BIOS I made works, thanks. Yes, I am not sure what you did on ME, maybe you didn’t follow the guide exactly as I did? Our extracted ME regions post-update to the exact same version file do not match

You’d have to ask Acer why another BIOS update at near same time, probably ME change or microcode change etc, for security reasons. Often there is lots of bug-fixes done too, and even when they provide a change log it rarely if ever shows all the changes *This applies to any/all companies

To update the microcodes, I selected the beginning of the first microcode and then selected to the end of the last microcode >> 620048 - 634848 << This = body of microcode volume, selecting all the microcodes and this = 14800h in size
Then in new hex file I made a blank file that length to represent all current/original microcodes. Then at UEFITool NE, see the padding file size following microcodes (CC14h) and add that size to the end of the blank file, you now have the total allowed space for microcodes.
So, now >> 14800 + CC14 = 21414 MAX Space available for microcodes and any padding you want. Select this area in the stock BIOS, from 620048 to 64145B, this = your total allowed amount 21414h (43 4D 44 42/ CMDB will be directly following the end of your selection)

Back on the new blank you have open in hex editor, copy and paste your microcodes one directly after another. Each new microcode must start on a multiple of 400h, so 400, 800, C00, 1000, 1400 and so on.
If you do not land on a multiple of 400h, then use FF filler to next multiple and then paste next microcode at the next multiple of 400h. In this case, while updating all, I did not have to use any filler, always landed on multiple of 400h
Once done updating all microcodes, select all, copy, and go back to your stock image where you have selected the 21414 area mentioned above and paste this new contents into it’s place over the old.

That is all

If you wanted to do it how you originally tried, updating a single microcode only 306A9, you would need to go to 631C48h in stock BIOS, this is start of original 306A9 microcode.
From there, select a range of 3800h, this is size of new microcode (old = 2C00h), so now you should have selected 631C48-635447 = 3800h
Then open the new microcode in hex, copy and go back to stock BIOS selection of 3800h and paste the new microcode over the old, don’t use insert as that will push/move down data and change the file sizes/locations etc.

7

Thank you @Lost_N_BIOS you for your decisive indications, ready-to-use microcores Intels are a good thing.



Indeed, I totally omitted this procedure. I wonder if it is possible to perform a precise backup of the NVRAM / SN / UUID / NIC MAC data for later reinjection ?
I discovered a tool to regenerate DMI information (MPRW), but the Mestate command indicates "ICC Not programmed" : Is that important ?

Also I made a backup with the flash programmer (fw 2.18) and strangely this backup when we reprogram it in external flash the system starts but the screen is black.

Also I am unable to use a fw stock v2.18 because it is encapsulated in an archive that exceeds 10mb and that cannot be opened.

The Bios blob in v2.18 from my backup (which I can access with Flash Image Tool) is unusable (black screen).



I got the ME blob "8.1.70.1590_1.5MB_PRD_RGN.bin" from "Intel ME 8 Firmware Repository Pack r20" just rename and replace and finally regenerate an 8mb archive no more and no less.



Apparently versions 2.xx have a relationship between the UEFI boot and Windows 8 and I have the impression that this adds increased security that does not allow an operationnal update with an external flash programmer (and I don’t know why).



Yes I have 14800h in size.



I added a row of FF values directly after the lasts microcodes to get CC14 (value confirmed in UEFITool NE).


So, now >> 14800 + CC14 = 21414 MAX Space available for microcodes and any padding you want. Select this area in the stock BIOS, from 620048 to 64145B, this = your total allowed amount 21414h (43 4D 44 42/ CMDB will be directly following the end of your selection)[/quote]

Ok for 620048 to 64145B !



This 400h value cannot be invented equally, is it also like that for other references (HP, Insyde etc.) ?



I was able to update the microcodes according to your instructions and I add that the order of the new microcodes is not identical so the checksum (of the final bios archive file) of the final file should be the same as yours, if I try to reconstruct the same order the result should be perfectly identical .



With the bios I had used I stopped at the value block 634847 and not 635447 :

-I notice that my micro code is imputed from 634847 !
-No chance it works, the overwriting is limited to preselection, it is mandatory to preselect the range of the new microcode.

The fw stock v2.18 trapped in a capsule (big BIOS.cap) : http://s000.tinyupload.com/index.php?fil…276363854963985

Now I have to understand what’s wrong with the latest ME blob and the errors you observed with the Bios 1.22 .

8

You cannot backup all that board specific data now, you wrote over it with stock BIOS (Without any data in these places, so all FF or other generic placeholders in it’s place)
Yes, you could have backed up this data easily, same as with any time you write any BIOS, especially with a programmer, you make a backup first. Then you always have this copy of the original contents.
You cannot regenerate this info with any tools. Some tools work with some BIOS, to inject data you give it, but you must have this data in the first place. Sometimes some of this is on board stickers, especially serial and LAN MAC ID.
Check all stickers on the board and inside casing of the bottom (inside and outside of bottom casing), and be sure to look on, around, and under the memory sticks too, sometimes sticker is hiding there.

Sounds like your backup you are testing is not a valid backup. Did you use same software version to make it, that you are now using to write the BIOS in?
Send me this backup you have, maybe I can find your original data and put it back into the BIOS I made you, if the file is valid backup that is.

Yes, that is incorrect method to do ME update, you must use this method so your original ME FW settings get transferred into the new ME FW.
Still not sure what you did, since your ME Region I extracted did not match the stock one, which it sounds like you simply swapped in, so it should have matched when I compared. Anyway, that is not how this is done, follow guide below.
[Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization

Sorry, I have no clue what you mean about version 2.xx not compatible with flash programmer. You can program anything you want, provided it is a proper BIOS file for this type of programmer it will run just fine.
Stock BIOS is not meant to be programmed in, and never can you program anything in a capsule, so maybe either of these is what’s making you think it’s not working. If you want to get onto BIOS 2.xx, flash to it using normal update method.
Then dump BIOS with programmer if you need to modify it, then re-program.

I don’t know what you mean about 400h value “invented equally”? As for other BIOS, no, not all BIOS need this, some can use 400 or 800, others it does not matter and you can past directly in a row with no concern of alignment. All depends on the BIOS.

I don’t know what you mean about your updated microcode file and order of microcodes now? If you did not put them in same order I did that does not matter, they can be in any order. Checksum is not relevant to this, and will not change anyway.
If you mean overall checksum of the BIOS, checked with hex editor or something, yes, your file should match mine provided you use stock and update all microcodes same as I did. If you do not use same order, I don’t know if checksum would be different or not?
If you get different, then put them in same order I did, then if you get different still, BIOS may not be valid and you did something wrong again?

As for your last statement >> With the bios I had used I stopped at the value block 634847 and not 635447
I don’t know what you did or why/how etc. Don’t waste your time trying to figure it out, just toss that file and start over and do it like I mentioned.
Yes, on stock BIOS the end of the last microcode is at 634847 (631C48-634847 = original 306A9 microcode, size 2C00h), select 631C48-635447 and copy/paste the new microcode in there if you only wanted to update 306A9 (this = new microcode size 3800h)
Overwriting being limited to selection is only about how your chosen hex editor works. I gave you the exact full size of the area to select and overwrite.

If you want to get on BIOS 2.18, flash that using standard BIOS update procedure for this motherboard, whatever that process is. Then dump the BIOS with programmer and send to me, I’ll update it for you.

9



Ok, except the mac address, this tracking information is theoretically useless for the proper functioning of the machine…especially if the warranty is outdated.



This is the backup of the functional fw 2.18 on this motherboard done before the various tests and trials, maybe it is damaged because I can boot but only get a black screen, an error during the backup via the flash programmer seems very small to me because it would be a first for me and because until now with systems of a previous generation I have not encountered this black screen problem, on the other hand I have lost the data of SN/UUID/ etc.



Ok



Ok



Ok, I’m mainly interested in why the capsule is so big and what it contains and why…



About "[…] value cannot be invented equally" : I could have said "a logic that repeats itself is not a coincidence also"…

Ok, ultimately it all depends on the BIOS.




Sometimes order counts, sometimes it doesn’t, it’s mostly to know in this case…




When the order changes the microcodes changes, the checksum is not the same, which does not prevent the correct functioning.



The checksum of the final and identical file when the order and the same.



Yes everything works well thanks to this indication, I explain the error in the previous post I made but it’s fixed



Details about this subject :

-I am currently with the 1.22 updated microcodes
-The standard procedure around 2.18 is blocked, the cmd launcher of v2.18 returns the message to me :

Please update to the same type of BIOS (v1.x)
ERROR 235 - OEM check failed from BIOS service!

If the argument /ver (after Winflash32) since is deleted there is no more error :

the system indicates that it will shut down or restart, otherwise nothing happens.

I manually restart at the reboot the screen is black and the system remains on for several minutes without any update on the horizon.

I turn the system back on and off at 1.22 .

Finally my original backup fw 2.18 (before of all the tests, and which worked very well) as a reminder if I reprogram it allows me to boot but the screen remains does not light up : here

If you are can to modified this version (microcodes, blobe ME and clean) I think I have a good chance of having to reprogram it externally, to start, otherwise I could try from version 1.22 with the FD unlocked.

10

Wow, you quote too much I have to read, scroll down to reply, scroll up to read, repeat, repeat etc. We’re the only ones talking here so no need to quote me

Yes, unless you were still in warranty period for RMA’s, the serial and UUID really don’t matter (unless tied into windows activations and you find that gives you issues)
LAN MAC ID is really the only important thing, but NVRAM is as well, sometimes loss of that can cause all kinds of stability issues, even after it rebuilds itself sometimes an entire volume is lost and cannot be recreated.

You said “This is the backup of 2.18” Where?? The rest of that sentence doesn’t make sense to me, sorry, unsure what you are trying to say.

The capsule is only 50h >> What you see below is the entire capsule, unsure what you mean?
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Yes, that is stupid of them to build BIOS like this, empty capsule when purpose of capsule should be some security check/signature etc, and half the BIOS blank, so dumb BIOS engineering on two fronts here that’s OEM’s for you
Half that capsule BIOS is empty filler (FF @ 6.38MB), rest is flash tool, some padding files, and some BIOS update modules - not a complete BIOS either, this is a BIOS upgrade not something you can program.

About the 400h, this is an alignment thing, some BIOS look for microcode to start on certain alignments/offsets, some do not, all depends on the BIOS type as to if it needs this and or what alignment is required.

Microcode order never matters, they are all loaded by BIOS, whatever CPU is detected then further uses it’s specific microcode.
Order change does not change the microcodes, at all. As mentioned, checksum may differ if you switch orders, this is due to compressed BIOS modules and values vary as it compresses depending on where data is -
I assume, I did not test this myself, but I will now to be sure. I will edit in answer here - yes, this is confirmed >>

MD5-SwapuCode-Compare.png



Sounds like this 2.18 BIOS is not for your system, show me Lenovo page for your exact system that shows both these BIOS. Ahh! So you were on 2.18 before? We should have started there!!! I mean, you should have gave me that to update originally, no reason for us to be using the old BIOS!!

Thanks for your 2.18 backup, I will check it out. Since you cannot reprogram this and boot, sounds like it’s not a valid backup, otherwise should be no issue, it should be just like you never copied it off there.
Do you erase, then blank check before you write/verify? If not, that may be why it’s failing for you when you write it back.

I did not unlock the FD in the BIOS I sent you, but I can do that for you real quick if you want, this isn’t going to help you update to 2.18 though.
I’ll let you know what I find with your backup of 2.18, heading out now though so it wont be until later on.

11

Thank you for your answers


For the moment I have not observed any warning nor found a way to save the NVRAM, if this is important in some systems it would be necessary to update the tutorials accordingly (I’m wondering if my BIOS 2.18 may require information from the NVRAM that no longer exists and that’s why it brick the system ?)

I concentrated my first efforts on 1.22 because it works and especially because it was available in stock without prowess, it should be noted that the Acer stock BIOS 1.xx and 2.xx are two series that are released almost at the same time and apparently Acer does not allow the migration from a 1.xx to 2.xx version and vice versa.

But from now on I will focus on the latest versions of fw !

I tried with erase / blank before programming my BIOS backup 2.18 it seems to me that yes, I will try again…

Acer Product Support

12

It’s too late now, about original NVRAM, you’ve erased it. The only way to save it was a proper full backup. Some of it may be OK in your original backup, but hard to know, and you can only try it once you get back on 2.18 anyway.

I see, this 2.18 backup is what you tried to mod initially, that I told you was broken in many ways. It’s broken before you did anything, bad dump, this is why it bricks the system when you try to program it back.
All the errors I pointed out to you at post #4 about your initial mod, actually are caused by the corrupted dump you modified, and none may be due to your editing, all I mentioned there are present/issue in your backup so it’s a bad dump.
This is why it wont program back for you even without modifying it, it’s a bad dump from the start. You’ll have to get 2.18 flashed back in and then dump it again.

I looked at the batch file for 2.18, and it appears as if it will fail if you do not have the original OS, Sub, and Build (Whatever all that is), I assume original Operating system and build #/Ver, but unsure what sub means. Removing the HDD totally may get around this kind of OS check, not sure.
AC must also be connected. I see on the download page for 2.17, “For Win8”, so this must be the OS it checks for, what build etc I have no idea. Confirmed here - https://community.acer.com/en/discussion…om-1-xx-to-2-xx
More similarly related (These edits don’t apply to your exact flash package though, since your BIOS and flash package is not Insyde BIOS type) - http://catchtito.blogspot.com/2013/05/ho…om-1x-bios.html
I see this also, about flashing a dump from 2.xx while on 1.xx BIOS, however your dump is not good, so not ideal either - https://www.bios-mods.com/forum/Thread-R…to-v2-18?page=2

So, if you had a good dump from your original 2.18 then you could program it back anyway, being the bad dump initially is the only problem now.

I inspected the flashing file itself too, and you can use /force command, so adding that to the stock maybe you can run from command line like you see below
WinFlash64.exe /force /bcp /sd /ver /cvar /v /endkey /silent /bbl /cac /cbp 30 /file %UMAROM%

If new error, you may need to remove some of the other flags, or put /force at end (Before /file), unsure

You can also try adding this switch, this disables all BIOS checks like version, date, type, etc >> /sa

Additionally, removing this could help as well >> /ver
So maybe >> WinFlash64.exe /force /bcp /sd /cvar /v /endkey /silent /bbl /cac /cbp 30 /file %UMAROM%

Yes, when using programmer, always, erase then blank check, before you write/verify

13

Thank you again @Lost_N_BIOS !

You confirm that my dump of 2.18 is therefore unusable, dump remains a high-risk practice, the situation is therefore critical.

I no longer have the original operating system (win8) that I deleted 100% (including the recovery partition).

I made attempts to flash in 2.18 from a win7 and from a bootable live xp usb flash drive following your advice but without success :

WinFlash64.exe /force /file %UMAROM%
(with “/force” imposes no other options).

WinFlash64.exe /bcp /sd /cvar /v /endkey /silent /bbl /cac /cbp 30 /file %UMAROM%
(without “/ver”)

In both cases under win7 the system shuts down, reboot but the screen does not light up and finally the update process does not start, with the live xp usb I force the reboot but always the same with the screen…

WinFlash64.exe /sa
(does not work)

Would Acer have been so mean ? it’s almost irrational ! -the extension .cap is specific to the UEFI which increases security on many levels including the source fw - I would have to test from a live win10 usb win10 to complete my attempts, I’ll try to find that but if you know a good reference usb live iso win8/win10 do not hesitate to make it known.

I had tried “crisis mode” with my 2.18 but it never worked :

-Plug USB storage into USB port.
-Press Fn + ESC button then plug in AC power.
-Press Power button to initiate system CRISIS mode.

even the boot block would be damaged or it’s a another procedure I don’t know about.

14

Yes, all the reasons I told you that your original mod BIOS was bad, applies to the dump you said was original dump too, so I assume your mod may have been OK originally if the dump was good you were working with.
Yes, dump always needs to be checked to be sure it’s good, valid, and proper, before you erase and do anything. Not every dump will be perfect, sometimes you need to use certain software or version of software
Always make a few dumps and compare too, unless you are certain you know what works and then have checked the file after you dumped it.

2.18 requires Win8 or above to install that BIOS, but that is using normal methods, this is mainly due to how they’re trying to restrict it and how the OS is setup to boot (UEFI mode). All that can be changed in BIOS

In your first two described attempts, do those again but with main hard drive removed. IE, try to do the same from DOS with winflash32, it may not work in DOS, but I’d try and see.

As explained already, the capsule is empty = 50 bytes of FF, thus they are stupid and this has nothing to do with security/flashing etc. They did this because some systems shipped with Win7/1.xx BIOS (legacy) and others shipped with Win8/2.xx BIOS (UEFI)
Then, you did this, not them Always go slow, have someone check things for you if you are not sure, wait, do not proceed with anything BIOS related, when you don’t know for sure. Otherwise you end up in this kind of situation, or worse, at least you can boot the system
But yes, in general I agree, they should allow user to choose what BIOS they want, obviously anyone can change the BIOS setting to UEFI/Secure boot mode or legacy, if they leave the setting there and let user flash either BIOS. Yes, it’s dumb!

Can you find some other dump from same exact system with 2.17 or 2.18? If yes, give me a link, maybe I can fix your original dumped BIOS.
I’ll see what I can do with your dump and the stock file, maybe I can sort it out I think I can fix it, but one may loose your NVRAM, since it’s corrupted in the dump, but we can also try with that as-it-is too.

As for crisis recovery, this needs to be done in a certain way, and I’m not sure it works around this kind of BIOS issue.
USB Should be small (128MB-2GB), formatted to FAT32, and BIOS should be on root of USB (not in folder) and BIOS has to have a certain recovery name and extension (usually .fd or .rom, not a capsule and you can’t simply rename that cap file)
But really, all BIOS you download from them is partial/update, to update/change what’s already onboard BIOS. None are complete BIOS, so crisis recovery from 1.xx to 2.xx isn’t going to be possible anyway.

Also, if you want, I can unlock FD in next/all BIOS I sent, then you can flash BIOS via Intel FPT from them on out, as long as with any/all BIOS you program in you unlock the FD if flashing the entire BIOS (usually only BIOS region flash needed though, so you’d leave unlocked FD alone and in there)
* Edit - for now, please test this, let me know outcome - this has FD Unlocked and SMM lock disabled too, so after you program this on you should be able to flash with FPT now (FPTw.exe -bios -f filename.bin) >> Backup via >> FPTw.exe -bios -d filename.bin
http://s000.tinyupload.com/index.php?fil…761772891118267

If this boots for you, before you check out anything else such as serial, LAN MAC ID etc, please backup the BIOS via FPT, and then immediately try to reflash the BIOS region via FPT, show me the error if you get any. If error is in red, do not proceed or you will have to programmer recover.
FPT is here, you need V8 ME System tools from Section C - Intel Management Engine: Drivers, Firmware & System Tools
FPT must be ran from admin command prompt >> find Flash Programming Tool folder, and inside that a Windows or Win/Win32 folder. Select that Win folder, hold shift and press right click, choose open command window here (Not power shell).

15

@Lost_N_BIOS , here are some news :

-WinFlash32 is 100% 32 bit: it returns an error (cannot run in DOS mode…).

-The file you sent me, after programming, is not operational (boot ok but screen off).

-I searched for a BIOS UEFI 2.xx, I discovered a dump in fw 2.11 and that works on the system (original file) : http://s000.tinyupload.com/index.php?fil…648526875421647

I was able to update to UEFI 2.18 from a live xp with “Winflash32 /force …” I rebooted the system and the update is done without any problems .

The FD being blocked on the current 2.18 (“fpt -d spi.bin” rejection)

Dump attempts :

I don’t know why but my dump attempts fail systematically: the extraction is filled with FF FF FF

However the chip is perfectly detected by for programming software, and without errors.

I tried it with AsProgrammer v1.4.0, CH341Programmer v1.1.1.32, CH341A v1.13,18,29,30,34, disconnected reconnected USB programmer and the clamp again and again, I tested on another chip the detection is good and the reading possible, incredible !

edit : I’m going through the whole process again,

With this chip I have always had to use a precise software to inject the fw (otherwise = directly bricked) and the procedure works well.

In the meantime I have obtained Dump 2.18 but they are not identical and systematically corrupt.

edit : Good finally after having failed too much with the extraction by external programmer (it’s curious), I unlocked the FD of the fw 2.11 and updated to 2.18 (which did not rewrite on the FD, and therefore always unlocked) is performed a dump via FPT : http://s000.tinyupload.com/index.php?fil…756195766710668


This version will be able to serve as a basis for the nexts steps

16

Sorry to hear the last BIOS I sent didn’t work either . Good you found 2.11 dump, and good it works on your system too! Great you updated to 2.18 already too. Now, send me dump from programmer off your system with 2.18, then I can see about putting back in your correct info.
Once connected, as in, once you can read it properly with any software, leave it connected and don’t move anything around. Then you can dump, no need to keep reclamping once you are connected and detectable.
Ahh, I see you got it finally. So FPT dump of complete and working 2.18 BIOS from your system? If yes, great, I will check it and then we can just FPT flash.
If BIOS lock or SMI/SMM lock enabled, you’ll have to use grub/setup_var or H20UVE or program once more with those locks removed, so you can fully write anytime with FPT (FD locks aren’t the only possible locks).
Or, did you already test complete FPT Dump (FPTw.exe -d FileName.bin) and then flash it back (FPTw.exe -f FileName.bin) And it flashed back? If not, please test that now and if you get error, stop, show me the error, and do not reboot yet

* Edit - how did you “update” to 2.18 from 2.11? I’ve not checked the 2.11 dump yet, but the last 2.18 FPT dump you posted is missing an NVRAM volume (EVSA), so looks like built on top of incorrectly flashed 2.11 or 2.18 (FPT or programmer flashed stock BIOS instead of actual dump)
At least it’s working for you though * Edit, yes, this is the problem, the original 2.11 dump you started on is not a properly dumped BIOS. This was incorrect flashed (however) to stock 2.11, then dumped. So, now you are here

So, what is your goal from here on out, provided I do not need to further unlock BIOS settings mentioned above?

17

For your bios, I tried two programming to be sure but without success, so I looked for alternative bios it was not obvious but my system is based on the same basis as other references that use the same bios, which is not obvious to know at Acer unlike HP.


The FD lock is not the only one, indeed I confirm that there is another lock:
FPTw.exe -f FileName.bin
returns the following warning and error:

PDR Region does not exist
GBE Region does not exist

Error 28 : protected range registers are currently set by bios, preventing flash access. Please contact the target system vendor for an option to disable protected range registers.

Do you know what the “PDR” is ?



2.11 to 2.18 :

In the beginning, the system was delivered with an original BIOS 2.xx and then updated to 2.18 with the normal procedure.

With the external programmer I made a backup of 2.18 but the latter is faulty and there is no NVRAM information (UUID…), (on this subject I wonder if my external programmer is not faulty, maybe there’s protection or I don’t know what, but it doesn’t make sense) , and I had to decide to use 1.22 because my backup is 2.18 broken, but since I found a dump 2.11 :

then :

I opened 2.11 on HxD modify the values here (FD Unlocked)
I programmed 2.11 unlocked, externally.
In Setup 2.11 switched from AHCI to IDE and from UEFI to Legacy
Started live xp and launched the command (process to 2.18) :

WinFlash32.exe /bcp /sd /cvar /v /endkey /silent /bbl /cac /cbp 30 /file %UMAROM%

(without /ver)

I restart manualy

The update screen appeared (TDK OEM updater…) it was very short, the system stopped.

at restart I am 2.18 unlocked = extraction is possible.

(formerly I tried with /force but this erases the UUID/Tracking in the 2.18)

–
The objective of benefiting from a BIOS in its flashable version and the other programmable version :

In its latest version 2.18
Including microcodes updates.
Including the latest ME Blog and clean it .

Disable ME and delete it.

Allow visibility of the hidden options in bios 2.18 (but I don’t have the information to do so, even if there are few options).

UUID and tracking information has not made the system unstable since 2.11.

What other improvements could be made

18

I thought they may not work, was only hoping we could get lucky.

PDR = Platform Descriptor Region, this is not used in your BIOS
GbE is Intel Gigabit LAN (MAC ID stored here, when this LAN is used and this module in BIOS) - this not in any of the BIOS I’ve looked at for your system either, so must be using Non-Intel LAN, or Intel LAN that’s only FAST LAN not Gigabit LAN

Error 28 - FPRR/PRR - Flash Protected Range Registers is a lock sometimes that can be enable/disable in BIOS settings (like BIOS lock), other times a BIOS mod is required to remove it (bypass it) in an internal BIOS Module (often PCHInitDXE or Powermanagement, but I’ll have to hunt it down in this BIOS)
On this, before I do anything, just like you disabled BIOS lock, please disable SMM lock >> 0xC4
You may need to change two values (unsure which you used before for BIOS Lock, RU or grub/setup_var)? After that, try FPT flash again and see if you get same error or different.
SMM LOCK, VarStoreInfo (VarOffset/VarName): 0xC4, VarStore: 0x1, QuestionId: 0x1C8, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 A6 3A 02 3B 02 C8 01 01 00 C4 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
Default: DefaultId: 0x0, Value (8 bit): 0x1 {5B 0D 00 00 00 01 00 00 00 00 00 00 00}
Default: DefaultId: 0x1, Value (8 bit): 0x1 {5B 0D 01 00 00 01 00 00 00 00 00 00 00}
One Of Option: Disabled, Value (8 bit): 0x0 {09 0E 03 00 00 00 00 00 00 00 00 00 00 00}
One Of Option: Enabled, Value (8 bit): 0x1 {09 0E 02 00 00 00 01 00 00 00 00 00 00 00}

If you never did disable BIOS Lock previously, sorry I maybe got confused here. We want both BIOS Lock and SMM/SMI lock disabled in your base BIOS.
Anyway, if you never disabled BIOS lock before, let me know, and I will do both in the BIOS instead and send to you for testing

I knew you originally had 2.xx BIOS. Your original dump of 2.18 BIOS is corrupted, not valid dump, this is the only issue here. No protection, just a bad dump is all.

Disable/delete ME is not suggested, this will cause fans to run at 100% and likely other stuff to fail or work improperly as well (CPU multi, memory multi, etc)
If you want to carry on from where you are now with 2.18 - I can update microcodes and ME if you want, I will see about unlocking (I hate Insyde BIOS, so no promises and this may take some testing/fail/brick/recovery/testing/repeat to find exact unlock for the menus)
I can also try to find and bypass the PRR lock for you, this may require the hassle I mentioned above with Menu unlock too, but sometimes I can find this much easier than menu unlock.
Is your LAN MAC ID in there/working, check Ethernet cable connected and see if you get internet or not.


* Edit @Kjose - Here is large set of BIOS to test, this is to test getting around the lock at FPT flash from within windows. Program each on, then reboot to windows, and try to flash BIOS via FPT.
Let me know if error same or different for each one. You can stop testing at the first one that allows the flash, let me know which one it is.
These all built from VA410218viaFPT.BIN as base, no other changes for now except to see if we can get around error 28.

!!! I Almost forgot, some BIOS have a bug that can get around sometimes!!! Please test now, put system to sleep (S3 sleep) for one minute, then wake it up and try to FPT flash again.
If no luck, carry on with below, or if luck, you can still carry on with below if you want to get it removed from BIOS anyway.

1. SetOnly.bin *
2. PCHIOnly.bin **
3. PCHBProO.bin
4. PCHIBproB.bin ***
5. 12.bin (1+2) ****
6. 13.bin (1+3)
7. 14.bin (1+4) ***

 = I think, higher changes of success - But please test all (And in order listed) if you don’t mind.
Unless you run into one that works, then stop there, no further testing needed, and shouldn’t be wasted time trying more after find success
http://s000.tinyupload.com/index.php?fil…540481320486575

19

Thank @Lost_N_BIOS , Indeed, apart from the FD unlocking I have not yet tried to disable the BIOS lock and SMM/SMI lock but I see that BIOS offers BIOS for this purpose.

By the way, this is a BIOS named “Phoenix SecureCore Tiano”, You can try unlocking the menu “VT-X virtualization” (just this menu if it is available), VT-X which is enabled by default but which should be suggested to be sure it is active or not, however it’s just if you think you can make it happen, and if you think it’s easily, otherwise it’s not essential and if yes it’s just for a few tests…

Yes I confirm the LAN MAC ID is functional.

I tried the S3 and S4 standby mode and no anomalies to report: each time well awakened.

So I programmed every BIOS in the order of the list, however none of them allowed to work around error 28 with fptw.exe -f fileName.bin

1. SetOnly.bin *
2. PCHIOnly.bin **
3. PCHBProO.bin
4. PCHIBproB.bin *****
5. 12.bin (1+2) ****
6. 13.bin (1+3)
7. 14.bin (1+4) ****

Unlocking methods have apparently changed ?

Disabled and/or deleted ME remains optional, if you agree to update the microcodes and ME this will be an opportunity for me to test faster the different software which does not seem to be good indicators on Meltdown and Spectre vulnerabilities (among others).

20

@Kjose - BIOS Lock + SMM/SMI Lock would need disabled to FPT flash, I didn’t check during this comment if they both are enabled by default, but I see above I did check on SMM/SMI and it’s enabled and needs disabled first.
I checked, BIOS Lock is disabled by default, so you should only have to disable SMM/SMI lock, but then may also need the edits done I made above in that x7 BIOS test package.

Yes, I can make settings visible for you that are hidden. I’m not sure what you mean there on your VT-d comments
Intel(R) VT for Directed I/O(VT-d) is in your BIOS (System Agent (SA) Configuration page), and may be grayed out (can’t tell on my end). Setting itself is enabled by default
Intel(R) Virtualization Technology is in your BIOS as well (Processor Config page), same as above, may be grayed out I can’t tell. Setting itself is enabled by default

S3 sleep was not something you needed to test. This was a test for BIOS bug that gets you around the FPT/167 or 28 error. Put system to sleep S3 only, wait one minute, then wake system up and try to FPT flash the BIOS region via your FPT backup.
Some BIOS have a bug, where you normally get 167 or 28 FPT error, putting system to sleep for one minute then wake it up and this error does not happen. Hope you get what I mean now

You are hitting error 28 possibly due to how you are using FPT. You only need to flash the BIOS region, so should only be using the following command >> FPTw.exe -bios -f filename.bin
FD is already unlocked and programmed in, so no need to write FD or ME right now, so FPTw.exe -f biosinfull.bin is not needed. Only BIOS region flash is required for mod BIOS, and you unlocked ME at the FD, so anytime you wanted to reflash the ME only that can be done via >> FPTw.exe -me -f me.bin
So, now, all tests will need redone on each BIOS. But, first try to FPT flash without doing anything, on stock BIOS, if you get error 28, then do S3 sleep check, then if no luck still, reflash all those BIOS I made and try again with proper FPT command.

If no luck still, then programmer only for now

I don’t think disable ME is a good choice, especially in a laptop, but it’s your system Yes, I can update the microcodes again… once all settled.
You have a programmer, so aside from convenience to flash via FPT, this is a lot of hassle for no real reason. However, I do think once you use one of the BIOS above with SMM lock disabled (ie BIOS #1) you will be able to flash BIOS region via FPT