BaseTools FMMT handle case where Parent.Data is none (previously easier bug report?)

[jaredmauch]

Discussed in #6558

^{Originally posted by jaredmauch December 18, 2024}
I've found a bug in FMMT and wanted to quickly report it but don't have a chance to do fork() and PR

--- a/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
+++ b/BaseTools/Source/Python/FMMT/core/FMMTOperation.py
@@ -184,12 +184,13 @@ def ExtractFfs(inputfile: str, Ffs_name: str, outputfile: str, Fv_name: str=None
     if Fv_name:
         FindNum = len(FmmtParser.WholeFvTree.Findlist)
         for index in range(FindNum-1, -1, -1):
-            if FmmtParser.WholeFvTree.Findlist[index].Parent.key != Fv_name and FmmtParser.WholeFvTree.Findlist[index].Parent.Data.Name != Fv_name:
+            if FmmtParser.WholeFvTree.Findlist[index].Parent.key != Fv_name and FmmtParser.WholeFvTree.Findlist[index].Parent.Data is not None and FmmtParser.WholeFvTree.Findlist[index].Parent.Data.Name != Fv_name:^M

You can't force a bios vendor (in this case DELL) to fix things, but you can at least fix the parser bug that prevents it from being loaded.

This change resolves the problem that I was having:

  File "/home/jared/bios/edk2/BaseTools/Source/Python/FMMT/core/FMMTOperation.py", line 187, in ExtractFfs
    if FmmtParser.WholeFvTree.Findlist[index].Parent.key != Fv_name and FmmtParser.WholeFvTree.Findlist[index].Parent.Data.Name != Fv_name:
                                                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'Name'

because Parent.Data was None, and it was being referenced here. There may be a better way to fix this issue, but this change is allowing me to move on with my project.

[mdkinney]

@AshrafAliS I think you are working on some FMMT related issues. Can you pull this one in too?

[AshrafAliS]

@jaredmauch is it possible to share the below data.

1. BIOS image
2. Command being used.
3. FMMT dump

[jaredmauch]

@AshrafAliS yeah i can share and some other tweaks i had to do.. sorry missed this follow-up
4f1c52d3-d824-4d2a-a2f0-ec40c23c5916.orig.bin.gz

I'll try to dig out some more of the history I have notes on another toolkit but not edk2 handy.

[jaredmauch]

Here's the other related files

new.Section_Freeform_subtype_GUID_AB56DC60-0057-11DA-A8DB-000102EEE626_SMBiosStaticData.bin.gz
Volume_FFSv2_5C60F367-A505-419A-859E-2A4FF6CA6FE5.patched.vol.gz
Volume_FFSv2_5C60F367-A505-419A-859E-2A4FF6CA6FE5.vol.gz
backup.wyse5070.GJYX1G3.rom.gz

[jaredmauch]

This was while attempting to do a replace on this nested section

from my notes:

SMBiosStaticData
GUID: DAF4BF89-CE71-4917-B522-C89D32FBC59F (EFI_SMBIOS_STATIC_DATA_GUID)
Subtype GUID: AB56DC60-0057-11DA-A8DB-000102EEE626

It's stored within FFSv2 volume 8c8ce578-8a3d-4f1c-9935-896185c32dd3

When you are looking at the dump, 

00000200  ff ff ff ff ff ff ff ff ff ff 00 00 10 17 0b 00  |................|
00000210  03 03 03 00 00 80 04 fe ff 02 00 00 00 00 04 00  |................|

You will see the 0x030303 pattern then after that 0x0000 then the max
memory size, in this case we want to modify it to be 0x8004
(0x0480 due to intel endian)

[AshrafAliS]

Thanks for sharing the files,
can you share the command as well.

[jaredmauch]

I don't have that in my history sadly, but I was likely trying to do a replace of that volume. I'm sure I can try to find what I was doing, but I think that this bios ROM was causing the parse issue as I've seen several different tools not handle it well.

I'd really like to find someone at Dell and see if they can include this change in a fix for an official release as the hardware/bios recognizes 64GB ram but programs the e820 wrong and this is my attempt to patch it for several pieces of hardware that I have.

[AshrafAliS]

Based on available data triggered the PR:
#10614

[jaredmauch]

Thanks for looking at this and proposing a fix. I've been going down this rabbit hole and finding a lot of interesting behaviors with the various tools, and have noticed quite a big difference compared to what I experienced back when I learned asm back on the tandy 1000 :-) I'm trying to fix some bad DMI table data that exists in the wyse5070 bios to see if that will address some of the limitations that I'm facing with the e820 data being bad causing bios trimming.