Thanks for the explanation CodeRush. Can I modify the original DSDT stored in AmiBoardInfo if the module is still in the same length with UEFITool? Which one should I modify and replace, the ffs file or the its body file (fbd)? And I guess I'll have to rebuild it after replacing? And what if I want to replace a ffs with another modified one (wrong checksum, but same length before it being modified)? Sorry, I can't make my questions more understandable...
There is a PE32+ image section inside AmiBoardInfo.ffs module. You can extract the body of this section to have BIN file (let's name it ABI.bin here), replace your DSDT with HexEditor in this file (it's better be the same length or smaller, just add enough 0xFF bytes to it's end in that case), then "Replace body..." of that PE32+ image section to the modified file. Check that newly created section (marked as "Replace") has the same size as old one (marked "Remove"), and then save your modified BIOS image. PE32+ image has a place for CRC32 checksum in it's header, but it's not used by UEFI executables and remains zero in all images I have seen. Checksums of parent FFS file will be recalculated automatically during image rebuild. Answer "Yes" after successful rebuild, if it opens correctly - you are done. If you have a file with wrong checksums, just mark it to rebuild (Ctrl+Space), and checksums will be recalculated during image rebuild, then save the modified image.
Hi coderush, great tool so far, an option to re-compress all modules would be fantastic to harvest some free space, do you think it makes sense? best regards
Nope. Tiano compression have no parameters, so recompression wil be 100% useless, LZMA have some, but you will free about 50 Kb of space for the price of longer startup. The best way to earn some space is to reorganize and resize volumes, shrink ME region to it's normal size of 0x1f0000 if it's bigger, and to remove useless modules such as Tcp4.ffs and so on.
0.17.1 is out like a day ago, but I forgot to mention it. It's a small code-cleaning release, made because 0.17.0 binary for OSX was buggy and has bad fonts. Changes: - added "NVRAM" module type (detection algorithm needs to be done better, I know) - fixed typos in source code - Monaco 10pt is a new default font for OSX builds
0.17.2 is out. Bugfix release once again. Changes: - Pad file GUIDs will now be preserved after volume modification (thanks AMI for not following UEFI PI specs)
BDMaster, thank you for your report, files and suggestions. HP files are not well-formed UEFI images (they are encrypted, I think), others have some non-critical structure flaws, but it can be tolerated. Prenamed output files is a good idea, will be done in one of next releases. Extract all is a nice feature to implement, will be done too.
0.17.3 is out. Minor bugfix release. Changes: - descriptor access settings was shown incorrectly, now solved I have a very limited time for any projects because of my master thesis, so UEFITool's development may stall for a bit, but if you have found a bug - I will try to solve it ASAP. There will be another bugfix release in 1-2 days, I think.
I think that EFI file is not an UEFI Image, but a single executable, so the answer is no, but you can try and report anyway.
0.17.4 is out Changes: - solved a bug in wrong volume size calculation in rare cases - added diagnostic message if FvLength and size calculated using BlockMap are different - solved a bug that lead to unneeded PEI files relocation - rebuild action on volume will now relocate PEI files in it Thanks to lordkag for reporting.
Checked this out on my Zotac Z77 board - it doesn't work for me even after starting DXE driver and then running the image itself. It just returns EFI_SUCCESS and does nothing more. I can't figure out all dependencies of that EFI application, but I'm sure it's possible to transfer it, but it will be rather hard to do so without actual board to test. And I can't see how this feature can be somewhat useful ti dedicate much time for it's development, sorry.