I see. Anybody perhaps would have a working A15 with SLIC 2.1 for the Dell Precision M6300? Does someone know what the 'enhancement' in A15 is at all??? Thanks
Still here! Have been spending quite a lot of time over the last few weeks rewriting some of the tool to better handle module manipulation.... almost done A
I'm trying to modify the BIOS for an ASUS A55BM-E motherboard with 2.50 beta 2 (after trying 2.19). I have tried Dynamic and New Module but when I have tried to flash the BIOS I get the error "Security Verification Failed". I also tried DMI but got the message "DMI is empty". Any suggestions? Thanks, Tom
Post a link and I will look. Dynamic won't work with new ASUS. Most of the image is digitally signed. Normally a new module mod will work but sometimes you have to direct the tool to put them in (normally) the second firmware volume. DMI has to be done with an image of YOUR dumped BIOS not a downloaded one. A
To reflect the amount of changes under the hood. Although outwardly not much has changed there were 3 code paths for dealing with module manipulation (one to replace/delete, one to insert and one to resize) and all 3 were actually out of sync. Now there is just one. There were 3 code paths for scanning/dumping modules, now just 1! A
Don't use the RW report - rarely needed for EFI Also adding a SLP string will change modules that are digitally signed. I think you can flash EFIs that fail digital signature thru the USB flashback system on some ASUS boards as this doesn't check signatures It isn't really a bug - when a RW report is loaded the tool will look again and try and select a better method to mod - and dynamic is always (up until EFI anyway) considered least invasive. RW reports are really only relevant for some Phoenix and Dell mods. Tito/Serg008/Others - can anyone think of any EFI situations where you have to have a RW report - because I can't - but you guys know my tool better than I do!! If we can't think of any then I will disable RW report for EFI. Thanks, A
Thanks! That fixed it. I'm not a stupid person but when it comes to BIOS modification I'm very a much a "Get the tool and follow the instructions" sort of guy with only a basic understanding of what all the bits do. If the field was available I assumed I had to put something in there. With something like this I always RTFM before I start but looking at it again you do mention that RW files are required for "ANY Phoenix or Insyde mod and SOME Dell" so obviously I need to RTFM better! In the past I have only used the AMI tool (without problems). Is it the case that the SLP should always be left blank for a Phoenix BIOS or should it be left blank just for the 'New Module' method? Thanks to andyp and Serg008 for your help (and the tool!)
For newer Asus EFIs, its better to leave the SLP tab to avoid the security verification. Besides, its basically useless to install XP on these newer mobos (& thus SLP string is useless).
There is better solution for capsule header removal, because the header structure is known: Code: // UEFI 2.0 capsule header typedef struct { EFI_GUID CapsuleGuid; UINT32 HeaderSize; UINT32 Flags; UINT32 CapsuleImageSize; } EFI_CAPSULE_HEADER; // AMI Aptio extended capsule header typedef struct { EFI_CAPSULE_HEADER CapsuleHeader; UINT16 RomImageOffset;// offset in bytes from the beginning of the capsule header to the start of capsule volume UINT16 RomLayoutOffset;// offset to the table of the module descriptors in the capsule's volume that is included in the signature calculation FW_CERTIFICATE FWCert; //ROM_AREA RomAreaMap[1]; } APTIO_CAPSULE_HEADER; Header removal must be an option, I think, because it's required for any board if modified BIOS will be flashed by hardware SPI-programmer, but not required for anything, except Asrock, if it will be flashed by normal flashing tools.