Hello - This is a continuation from my earlier post. I tried upgrading my RST OROM from v11.0.0.1124 to v11.2.0.1006, following the AMI UEFI modding guide. Everything went smoothy, up to the point where the flash utility reported “Completed” and the computer rebooted. The BIOS Event log even has an entry that says “BIOS updated” The problem is, the OROM is still showing the older version. I double-checked the modded ROM file on my BIOS update CD using MMTool. I verified the DeviceID, extracted it and checked that it showed the newer version. There was also a SataDriver showing the newer version number. Could there be another instance hiding somewhere or is it more likely that my update just failed?
Thanks,
Tony
Probably its neither the first nor the second option.
Please give us some additional informations:
1. Which mainboard and which BIOS version are you using?
2. Which OS are you running and how did you install it (in LEGACY or UEFI mode)?
3. Have you set your Intel SATA Controller to AHCI or RAID?
4. Did you verify the success of your BIOS modding by extracting the inserted Intel RAID ROM and looking for the version by using a Hex Editor?
- This is a Lenovo ThinkCentre M92p 2988B2U using the latest Lenovo branded AMI BIOS (9SKT72AUS, dated 07/31/2013)
2. Windows 8 was pre-installed in UEFI mode.
3. Controller is set to RAID mode
4. Yes, I opened the boot CD that I had created to do the BIOS update. There is only one BIOS image present (IMAGE9S.CAP) and it has a newer timestamp than the factory one. I opened this file in MMTool and extracted both CSMCORE and SataDriver, and viewed the contents. Both show the new version number.
Thanks for answering my questions.
So your Intel SATA RAID Controller is actually managed by the SataDriver module.
Which was the SataDriver version of the original BIOS and which version did you insert?
How did you realize the actually working SataDriver version?
W8 UEFI install may just mean using GPT scheme in which case either legacy OROM or sata driver can be used. AFAIK the earliest sata driver started from 11.5.
This is all very strange. I don’t think I touched SataDriver when I did the modification, only CSMCORE. It seems as if they are linked to the same file. Both of original Lenovo modules show this near the top:
Intel(R) RAID for SATA - v11.0.0.1124
That is what I still see in my OROM boot screen. My modified/extracted one shows this:
Intel(R) RAID for SATA - v11.2.0.1527
But I see no reference to this in the running system.
In both cases (original and modified), the CSMCORE and SataDriver extracts are identical to one another, verified by checksum. I just re-did the OROM replacement to be sure, and again CSMCORE and SataDriver came out identical.
No, the SataDriver of the original Lenovo BIOS will have a higher version (probably v11.5.0.1702). Furthermore the version of the SataDriver is never shown on top of the file (it is near the middle, close to the text code "SATA").
So your Intel SATA RAID Controller is obviously managed by the "LEGACY" Intel RAID ROM and you can join the Utility by hitting CTRL+I while booting. So your system actually has nothing to do with the SataDriver module of the BIOS.
I am sorry, but I do not really understand what you mean. Which extracted modules are identical?
The Intel RAID ROM module and the SataDriver module are totally different, even if they have the same version.
If the extracted Intel RAID ROM and the SataDriver module of your modded BIOS should be identical with the related modules of the original BIOS, you have done something wrong. Maybe you have forgotten to save the BIOS after having updated the OROM module.
Well although the OROM exists in CSMCORE you should be using the Option ROM link option by ticking the box to replace the legacy OROM (device 8086:2822 or 8086:282a). Same if you want to extract. Note also that this firmware has a capsule header.
I think I’ve found the source of my confusion. The AMI UEFI guide states: “…search for the FileName “CSMCORE”… and highlight the related line”. I had assumed that was part of the process for selecting the right OROM module, and that highlighting SataDriver would extract that module instead. It seems that the output is affected only by selections in the “For Option ROM only” section, is that correct? This would explain why my extracted files were identical. And yes, I seem to be using the legacy OROM anyway making this not very relevant. Sorry for the distraction.
I checked and rechecked the CAP file on my update CD to verify that it shows the newer OROM version (v11.2.0.1527) at 8086,2822. As soon as the update finishes, “Completed” blinks on the screen and then the PC reboots back to the older (v11.0.0.1124) OROM screen.
I tried using a USB thumb drive instead of a CD. This this time I got the message “18 - Error: Unable to start a Secure Flash session” when using the modded BIOS. I noticed that the CD method includes “/capsule” in the AFUDOS command but the thumb drive method does not. It seems like the CD method is skipping an initial pre-check but it still fails at final verification.
I think I have run into “Secure Firmware Update”? Too bad… I did see the notes on “USB BIOS Flashback” for Asus motherboards but this is probably not worth the risk and bother.
Thanks to you both for the guidance.
The behaviour of the AMI Aptio UEFI MMTool regarding the processing of PCI ROM modules (which usualy are within the CSMCORE fie) and other (non-PCI-ROM) modules is different:
- "normal" (= non-PCI-ROM) modules:
If you want to to extract, remove or replace any "normal" BIOS module like the SataDriver one, you have- to uncheck the field "Link present" within the MMTool section "For Option ROM only" (otherwise the MMTool will extract, remove or replace the PCI ROM module, which Link-ID is shown within the "For Option ROM only" section) and
- to highlight the line showing the module you want to extract, remove or replace.
- PCI ROM modules:
If you want to extract, remove or replace a PCI ROM module, you just have to check the field "Link present" within the "For Option ROM only" section and to choose the Link-ID of the PCI ROM module you want to deal with. In this case it doesn’t matter at all, which line has been highlighted.
This is the usual behaviour of the BIOS flashing procedure, if you try to flash a modified .CAP file the "normal" way. That is the difference between BIOS files with the suffix .ROM and .CAP. You can flash a modified .ROM file with the standard Flash Tool, but not a modified .CAP one.
If your mainboard has the "USB Flashback" feature, you should use it. It works fine with modified .CAP files.
Note: You have to rename the BIOS file according to the ASUS USB Flashback rules. Otherwise the BIOS will not be accepted by the USB Flashback method.
I understand now, it’s just that highlighting CSMCORE is presented as an essential step in the PCI ROM mod guide (AMI UEFI version).
Thank you for clarifying. This .CAP file is my only experience with this!
I think my luck has run out here. This seems to be a very Asus-specific feature. There is not any mention of it in the Lenovo manual, nor any specially colored USB jack.
I know this is an old topic, but i have similar problem like op.
I have Zotac Zbox ID-18 and tried to modifiy bios with UBU. It worked well, but i can’t flash bios. It has .bin suffix.
Tried with afuwin and afudos, but the dos version just hangs.
C:\New folder\pb211>afuwin b2110313.bin /p /n /b /r
±--------------------------------------------------------------------------+
| AMI Firmware Update Utility v3.03.01 |
| Copyright (C)2012 American Megatrends Inc. All Rights Reserved. |
±--------------------------------------------------------------------------+
Reading flash … done
Secure Flash enabled, recalculate ROM size with signature…
- FFS checksums … ok
Loading capsule to secure memory buffer … done
18 - Error: Unable to start a Secure Flash session.
Any idea how to override or force flash?
Did you rename the modded BIOS to the original one?
You cannot flash the bios.bin file like it is.
Yes i did rename it to the original name.
Ok, then you will need help from a BIOS modding expert like CodeRush or lordkag.
@Jest
The error comes from the fact that your BIOS is signed and afuwin checks this signature. If you have an embedded flash option in BIOS menu, try to use that. If not, all other options are potential dangerous.
The afuwin guide mentions /capsule and /recovery options to override secure flash, but avoid it. There are multiple reports of bricking the system.
Another one, less dangerous (but still!) is the /gan command. I first read about it in this thread, I just can’t find the actual post to give proper credit. You could be in luck, because there is one report which mentions your exact card working.
Another method could be using AMISCE, but I don’t know if your platform would be supported.
Tried with /gan command and it worked.
Thanks for the help.