Hi folks! I need to insert some modules in my BIOS and i have two volumes with very little free space each. Does this tool allows to shrink one volume in order to free up some space in the other one? Thanks in advance.
The short answer is "no", because it's impossible to do correctly on almost every UEFI BIOS present. AMI implementation uses ROM_AREA array to store volume offsets and sizes, so it must be modified, but I don't have rights to implement such behaviour because of NDA. Phoenix are using the similar approach. Don't know much about Insyde and other vendors, but I won't be surprised if they are using something like that too. You can try to do it manually by changing FvLength and BlockMap fields in volume header with hex editor, opening the file with UEFITool and correcting checksums by rebuilding the affected volumes, but I doubt that modified BIOS will boot. My advice to this: just remove some unneeded stuff like UEFI networking drivers or CSM-related modules to have additional space to fit your modules.
CodeRush can you please explain how to use this to to inject as compressed? I am trying to use this tool for my firmware with Ozmosis
BDMaster, don't be confused by ME and EC, it's just names. The real image there is 6 MB long and consists of 2 parts: 2 MB (16 Mbit) chip 1,where Descriptor, GbE (optional) and ME regions are, and 4 MB (32 Mbit) chip 2, where BIOS and PDR (optional) regions are. EC firmware is normally located in the beginning of chip 2, because that way the vendor can spare the cost of separate EC memory chip. Actually, any region except Descriptor can be split by cross-chip border, because chipset maps both chips sequentially as one memory block, so it's up to the vendor to choose between dual or single chip configuration. You can't backup chip contents with FPT, because FPT works with regions, not chips, and ME region is normally read/write-protected, so the only true way to backup chip contents is to use hardware SPI flasher.
Now It's all perfect and cleared (I got, many time ago, from a friend a fulldump file 6 MB sized containing all Regions and He said to open It using Fitc tool to edit if necessary) ! I have analyzed that file using your UEFITool the only program which show all informations about Bios File and useful to identificate offset starting and size for every Region, so when We want to extract a Generalized Bios Region to use with FPT looking into your tool that Bios, We can. I said about an user and replacing Bios Region into dumps, so now on these new chips dumps I got from this user, They showed inverse disposition 4MB Chip has Descriptor - ME - Bios partialy and 2 MB Chip has the restain half Bios part like Bios is divided in two chunks ?! It's possible this ? You said that normaly It start from 2MB Chip, but It's a manufacturer decision, so It can be that Bios is truncated into first chip and continue on second, Chipset maps them as One Chip It's true ? And looking as FPT read Chips (Chip's Size Sequenze) 1st Chip and 2nd Chip We can understand which one chip is first into sequence, It's true ? I do an exemple : Lenovo IdeaPad G700 FPT -d ... -bios W25Q16BV 2MB 1st W25Q32BV 4MB 2nd Lenovo ThinkPad N581 FPT -d ... -bios W25Q32BV 4MB 1st W25Q16BV 2MB 2nd So into Lenovo IdeaPad G700 Firmware start from W25Q16BV and ending into W25Q32BV 4MB as your explaination, but into Lenovo ThinkPad N581 Firmware start from W25Q32BV and ending into W25Q16BV and in this case Bios Region is splitted. Many thanks for any comma and fullstop You write as It's like GOLD !!! Regards P.S. Many users asked to me about an issue changing CPU, after 30 min. exactly Laptop shutdown, I found looking into fulldump using Fict the Intel® Anti-Theft Technology that stop CPU after 30 min. It can be this the issue ? and as I think It's not possible to modify nothing without an SPIPGM. I hope this will be useful to all users whose want to learn and undertand more . . .
Yes, chipset maps both chips as a single continuous address space (so the last byte of the last chip is located at 0xFFFFFFFF physical address), so it's totally up to the vendor here. The rule to determine which chip is the first is simple: where descriptor region is. 30 minute shutdown is definitelly ATT-related, but I can't say more because of NDA. Nothing to do there with flash programmer because it's hardware-based technology.
Now We have all clear and as I said before, every your word is gold !!! A million thanks CodeRush for your support- Regards P.S. For mine experience FPT chips reading sequence agree with your affermation 1st chip has Descriptor into.
After some long time without releases here it is, UEFITool 0.18.8. Changes: - messages window scrolls to bottom on new messages - more human-readable error messages - hexadecimal numbers now have 0x prefix - paddings are checked to have only 0x00, 0xFF or mixed data - volume free space and pad files are checked to be actually free - VSCC table of flash descriptor is now parsed, flash chip IDs shown in descriptor's information - minor bugfixes Plans for the next release includes dependency expressions parser and initial support of preserving FIT table correctness after modifications.
Another update, UEFITool 0.18.9 Changes: - padding subtypes renamed to Empty and Nonempty - slightly improved error handling - added apriori file detection and parsing - added DEPEX sections parsing Notes: To see the new information obtained after parsing apriori files and DEPEX sections, select RAW section inside apriori file and DEPEX section and look at Information panel. For apriori file there will be a list of GUIDs of files that will be started by PEI or DXE dispacher before any other files. For DEPEX section there will be a human-readable list of DEPEX operations. More info about apriori-file and DEPEX sections can be found in UEFI Platform Interface Spec, Volume 2, which can be obtained from uefi.org.
CodeRush, can you reupload UEfiExtract binary for mac? i can't download it from sendspace... file is offline or sth... Thank you
@Ramalama, will do it ASAP, but I have no reliable build setup right now because my upgrade to OSX 10.10 went a bit wrong.
UEFITool 0.19.1 is out. Changes: - added support for Intel signed GUIDed sections - hex numbers are printed uppercase - empty paddings are shown as Empty(0x00) or Empty(0xFF) - volume size is determined by FvLength header field only - spaces are now allowed for hex pattern search - another messages clean-up UEFIExtract 0.3.2 and UEFIPatch 0.2.2 are out too. - hex numbers are printed uppercase - compiled with new version of ffsEngine Notes: Sendspace is deleting my files for some reasons, that is why I won't use it anymore. All new releases will be posted on GitHub.