Folks, I have been pretty busy at work and home recently. I have had a trawl of the thread and will try to summarise outstanding issues here - in no particular order. 1) MXM parsing (@ .NetRoller 3D) - could you point to more info?? why would we want to do this?? 2) Better support for SLP1.0. Just to confirm these offsets: +BB0 "ASUS_FLASH" -CF0 "SAMSUNGPC" +A7E "BenQHub" -12D2 "LG Electronics" -C00 "Sony Corporation" +B75 "MSI-PC" or "MSI-PenNote" -BC0 "Gateway" -BC0 "Tektronix" -BCA "Dell QuantaDell Computer" 3) Inserting modules (@KaminoReal) 4) Replace already compressed modules (@Apokrif) 5) Encryption of HP EFI 6) Empty module replacement as default for Acer 7) New Asus patching Could someone just clarify which asus need a dyanmic mod (with lock patching) and which need the bios dumping from ROM and various bytes modified?? Do all ASUS EFI work with this new method?? Is there a consistant pattern in which bytes need modding?? Anything else i've missed?? Andy
Andy, I’ve an idea how to do #3 & #4 in "user friendly manner". Not posting yet - you might come with better approach. PM me when you are ready to hear mine
andy for me personally-I was having problem with slp string in asus p867pro bios 1600-it just did not work. Mdl member qtm kindly helped me out and he thinks the reintegrate a062 module all slp string is missing in tool 1.85-see post #1936 this will explain thanks again for a great tool
bad eng However, those positions must be determined to be "00 00" or "FF FF" and enough space to write slp string, Otherwise brick
Yep. Done that already. I have implemented SLP support for those strings Added support for already compressed modules Fixed Acer emtpy modules THe code is already there to insert new modules, I just need to add something. New release soon!! Andy
Hi, Andy! I have a trouble while trying to build Thinkpad X220 Bios using your great Tool. The error is already known: Unable to compress... I tried 1.85 and 1.86b4 - same result. I had a go inside the issue and realized what is happening. This BIOS has Tiano compression method. I did measurement and realized that the EFIDC.exe tool compresses the BIOS file (DUMP\TEMP.ROM) using Tiano within 15 seconds. However after 10 seconds the Tool kills EFIDC process and says "Unable to compress ..." Please implement a wait till the compressor's process complete its work. A constant wait is not a good idea here. Otherwise it will be connected with CPU speed. However on my C2D 2.4 (locked at 2.4) it compresses 15 sec.
Hi Just to keep u all informed. I have 'happened' accross a copy of MMTool for EFI. I can't say where or share it or output unfortunately. But I am setting up my tool to insert/extract modules in the same way. I am doing it through the tree view you see when u press verify, as that should be easiest. But it will be possible through the manual mode by putting in the DUMP directory as well - although each will work in a slightly different way. Should be out in the next few days. Andy
It already does check to see if completed, but a few of the tools it runs have a habit of randomly freezing, so unfortunately the absolute time check is needed as well. I will increase to 20sec. Andy
Heh, I just put my C2D's SpeesStep into 600 Mhz mode and measured time of the compression. The result of this bios is 27 seconds! Please set this timeout at least to 60 seconds. You can put "wating 60 seconds till finish of the module compression..." message into log window during this wait. UPD: Or you can remove this timeout in RunEFIDC method only, and keep timeouts for other tools you run.
Just checked and is same I got some time ago, a correction, the version is 4.17.0001 not 4.17.0002 As I said the tool is very unstable and old(2007) A new version I doubt it will leak considering that the full AMI APTIO package is like 50K $... I will wait for Andy tool, I know it will do a great job.
Honestly. You're of little help. You wanted to reply to my post simply to state a discrepancy of version numbers from 4.17.0002 to 4.17.0001? Are you that hard up for recognition of contributing to anything? I was aware of the output of the report already. I suppose they made a mistake with the MMTool.txt that was included, as well. It has version 4.17.0002. Did it ever occur to you that the programmer didn't intend for the output of the report to have version 4.17.0001? That would make more sense as to what "mistake" was made. Anyways, no more replies to you since I doubt there is anything of use to come from it. Anyone care to share a higher version number MMTool 4.x for the Aptio firmware?
Yes it was for that, so people will know that the version you uploaded is the same as the one leaked long time ago... As for the rest of your reply i will ignore...