Hi,
Was trying to understand the correct figure for the free remaining space in a firmware volume and I noticed that UEFITool’s ‘Volume Free Space’ for firmware volume 02 differs slightly from MMTool’s report slightly. So I was wondering who is correct?
Thanks
@davidm71 :
Why didn’t you personally address your question to CodeRush, the author of the UEFITool?
This would enhance the chances to get an answer.
in my own experience in biosmodding with little freespace Bios, i can say you UEFITooL is better than MMTooL.
Some experience with very little freespace show me UEFITooL is Far Better.
@davidm71 ,could you please be more specific about the difference?
MMTool tend to align all file sizes to 8 (which works, but it’s out of spec). so UEFITool may report from 0 to 7 bytes more free space than MMTool, but it’s a harmless quirk in the later.
I was just trying to understand firmware volume structure and was curious about how to calculate the correct amount of free space in each firmware volume. I thus created an MMTool report on my Z87 bios file and looked at the total file size of each volume and the free space amount at the bottom of the report. Anyhow Uefitool lists one file that says something like ‘volume free space’ and on the right it would report the size in hex and dec amounts. I noticed that for some volumes that file size matched nicely with MMTool as far as how much free space was there, and for like the main firmware volume #02 the free space was almost identical short of a 1000 bytes 520 vs 519. In the last volume you had to add up the buffer file sizes to come at the same number as MMTool, but not for the 02 volume where all the Satadriver and other ffs files are located. So I was kind of confused. Thanks.
The correct amount of free space will actually depend of a definition of “free space”.
Specification defines free space to be all bytes from the end of the last file of the volume to the end of the volume itself, so volume_header_offset_of(last_file) + size_of(last_file) + size_of(free_space) = size_of(volume).
There’s, however, another possible definition of free space: maximum size of a file that can still fit into the volume. This size will be 0 - 7 bytes less because of default file alignment of 8, or even lesser if the alignment is set to be more than 8 (like it’s for Volume Top File, for example).
Actually, because EFI FFS doesn’t define any order, it’s possible to rearrange files to have less alignment gaps between them by solving a knapsack problem. This will be implemented in UEFITool NE after I can get to it’s development again.
Uh huh… Thanks.
@Coderush,
Im experimenting with Ozmtool to add nvme modules (instead of oz modules) into my bios and i noticed that despite having on 5kb free it can squeeze about 50 kb of nvme file modules into the second volume and still have 2kb free at the end. How can it do this when MMTool refuses to do so? Does it automatically compress those files upon insertion? Think Uefitool acts in the same manner. How is this possible?
Thank you
The volume you are talking about should be inside a compressed section. Such volumes can be grown in size without any major problems, but they still need to fit in enclosing uncompressed volume afterwards. UEFITool tries to grow a non-root (i.e. one inside compressed item) volume if there’s no free space to fit new files. Here is the actual code: https://github.com/LongSoft/UEFITool/blo…ngine.cpp#L3479
Thanks @Coderush,
I’ve been studying that code and trying to get a better understanding. For example there are like 200 some firmware ffs files within the main volume. I have made note that their parent volume has for example eb5000 bytes which is like 15421440 decimal bytes and looped through each one and summed up all their bytes to equal 15415558 bytes which is like 5882 bytes free which leaves no room to add a 20k module you would think but what your telling me is your code grows the size of the parent volume to make room for the inclusion of the added files? Therefor why does MmTool not allow adding extra modules that UEFItool or commandline utilities based on your code allow?
So basically I’m trying to modify the utility to estimate how much compressing of non essential files based on free space on the volume. Finding that its not black and while or cut in stone. In matter of fact in one case after adding three ffs files I ended up with more free space than I had before! So fwiw I have QT framework setup and having fun experimenting making modifications here or there. Noticed though you left the ‘Size’ property on Treemodel not finished though and I successfully was able to finish that part up such that you can tell how big each module is by accessing its size property. New to C++ but getting the hang of it. Thanks for everything.
EDIT: So after studying the firmware volume structure you are correct. Your UEFITool regrows the third ffs v2 firmware volume nested within the second firmware volume which has a total space of like 12 mb and the compressed firmware volume has lke no more than 6 mb leaving like another 6mb of free space! So why the hell are we deleting networking modules, and satadriver files to make room for our modded firmware files?!!!
Doesn’t make sense!
I do not understand why the whole OSM community wants to add anything into the DXE volume in the first place. SPI flash is slower than any modern HDD or SSD, and EFI System Partition is a perfect place for such files, but instead of using ESP for it’s purpose, OZM folk want to get rid of it to spare 200 Mb of drive space. It makes no sense, FW modifications lead to countless problems, but many people still want “the native experience” of OZM integrated into the FW.
Why the hell you all do it? I don’t know. I’ve implemented internal volume grow because it’s easy and requires very few changes in the FW (root volumes are much harder to resize, I must say).
I see your point. Makes me wonder why some firmware modules have quite a few modelules already compressed such as coredxe for certain rom files I’ve come across. Since you can regrow the main volume wouldn’t there be performance benefits uncompromising whatever ffs file that was compressed and re insert then uncompressed considering you can expand the volume?
Thank
It makes no sense to change any defaults the was selected by platform manufacturer. You can try decompressing DxeCore, if it was compressed originally, but if it will work or not - depends solely on the implementation in a given FW image. EFI decompression is limited by SPI throughput only, and the difference of compressed/uncompressed is extremely small on any CPU better than 400Mhz Quark.
I know it’s a lot of fun to mess with EFI, but if you just want to insert a NVMe driver and get your drive to be bootable - there’s no reason to repack anything, just insert the driver to the end of DXE volume and be happy.
Your right. Your Uefitool does the job nicely and should be the recommended app to use. I’ve repurposed the ozm tool to do the same on a command line for simplicity. Fernando asked if I’d write a guide using your uefitool for the uninitiated so going to help out and do my part. Thanks.