Hey, Andy! Yeah, we are working together. Thank for chiming in over at bios-mods. I've tested this build: 1. New version seems to solve the missing header issue and I quite like that it doesn't require to unpack the image in two stages, but this bring another problem for us, Dell-Phoenix Tiano users. To create a recovery capsule it was required to truncate (for Tiano 2.2 (based on UEFI 2.3.1) no truncation is required) the actual bios capsule (the F33.. file that is decompressed after the first stage with earlier versions) by 0x180000 bytes to include BIOS and EC regions and this file has to be named BIOS.cap (SystemCdExpress and FatLitePei modules carry this name if you need to determine it .. for Tiano fw these modules are called differently then the usual modules you extract the info for recovery name). Now that the entire image gets compressed right away without doing it in two stages, there's no such possibility with the latest version. Of course one could use the earlier, say 2.02, version for this, but I guess the old approach would have been useful, really.. since this is the way we test things. Dell-Phoenix Tiano doesn't require the chip to be reflashed in crisis boot mode, it loads a temporary bios into ram and uses it as a rescue to boot DOS/OS/SHELL and reflash the chip with provided tools. 2. DSDT reintegration is still not working properly from Advanced menu, an 0xFF byte gets added at the end of ACPI module. All we get upon booting is a black screen and no activity what so ever, I guess it just fails to load ACPI tables from the modules properly. If i try to rename 7E374E25-8E01-4FEE-87F2-390C23C606CD_1_946.ROM into aml, decompile it to dsl with iasl, edit to my liking and compile it with optimisations rename back to rom and try to replace it as if it was a regular module, then 0xFF is also added, checksume gets corrected, but machine boots into a black screen. If I don't change anything and attempt just to reintegrate a dsdt with zero alternations, it adds 0xFF again and adjusts the checksum accordingly, but computer fail to start. If I extract the ACPI 7E374E25-8E01-4FEE-87F2-390C23C606CD module, remove the 0xFF byte at the end, adjust the checksum, decrementing one byte at offset 0x14 and replace the module using PT the machine boots fine. Later has been found and confirmed by HairyCube and myself.
The Asus p8z77 version 1805 series bios seems can not be modded anymore. They always failed the security check during updated.
Please try 2.14 version in first page of this thread. I think i've found and fixed the FFh padding 'bug' (although it is deliberate code - but I can't for the life of me remember why I put it in) Andy
Andy thanks a lot for the new version and your support i really appreciate it...... As for the slic mod it's still unsuccessful, i don't know if it is any help but i have as attachments tha acpi table extracted from rw everything of the original bios and the one i modded with v2.14 of phoenix tool with Dynamic method, SSV2 gives me error.... Original: View attachment 20786 Slic mod: View attachment 20787 My regards, ribben
I see...... the 2.1 SLIC is there but the oem/table id fields are being replaced Will Ix In the mean time the most obvious solution would be to mod with the ACER 2.1 SLIC so the change of the oem/table ID doesnt matter Andy
The Asus p8z77-v pro bios 1805 has been changed its structure. it's different from 1708. I modded 1805 with phoenixtool 2.14 and earlier verions but the outcome were failed in security check and could not be flashed. I flashed witn Asus built in EZ updater 2. Any idea?