AMD-specific structures parsing

[Ykidia]

• added AMD Embedded Firmware Structure parsing;
• fixed jump to tree view item when clicked in parser info window - when inserting items not only at end (for example, CREATE_MODE_BEFORE), QModelIndex::row() of all superior items at same level becomes invalid and needed to be updated;
• added correct CPU addresses mapping if more than single bank detected, checking that CPU addresses adding only for UEFI image or BIOS region items info;
• added QComboBox to gotoAddressDialog with banks list (if more than single), to specify in which bank to search and jump.

Tested compiling and working on Windows, Ubuntu 25.04, macOS Sequoia.

TODO:

• display EFT(s) as in FIT: need more time to decide how it should look (replace table in FIT and rename FIT? add another dock EFT and use some smart logic to show FIT/EFT if one these docks not hidden? somehow else?);
• always detect platform for a bank even without combo dirs: need more researching on various images;
• get maximum info about file types and their purpose, to name them more correct and accurate: need more researching;
• detect and validate headers for most of files, based on https://github.com/coreboot/coreboot/blob/main/util/amdfwtool/amdfwtool.h#L384: need more researching;
• much much more testing! I need images, lots of images, the older the better.

This PR is based on:

• Patrick Rudolph's great work: https://github.com/PatrickRudolph/UEFITool/commits?author=PatrickRudolph
• Coreboot's amdfwtool: https://github.com/coreboot/coreboot/tree/main/util/amdfwtool
• some researching and experiments on Genoa/Turin boards.

[NikolajSchlej]

Traveling now, will be able to review in 3 weeks, so it will have to sit here for a while.
@vit9696, check this out, meanwhile,

[vit9696]

Before starting to review this more precisely, I would like

• to move unrelated changes to a separate PR
• to decide whether to use Kaitai for structure parsing

[vit9696]

A lot of code here performs manual parsing. Why do not you use Kaitai?

[Ykidia]

I don't know Kaitai. Was reading something but not enough - I have no time for it now.

[Ykidia]

PR is updated, mostly to get rid of all unrelated changes. @vit9696, please, check.

[NikolajSchlej]

Just returned from a surgery, will take me about a month to recover from it, hope to return to UEFITool development after that. I will review the changes here when capable.

[NikolajSchlej]

Tested locally on multiple AMD images, looks really nice and promising, thanks a lot. Merged.

[AkechiShiro]

Thanks a lot for the work being done here, really appreciate it,

These changes haven't been released yet into a new release (last release was made June 16 and may not be using the new_engine but rather the old_engine)

Just would like to test them real quick too, I could probably just build from the HEAD commit on the new_engine branch and try it out most likely, is that a recommended approach @NikolajSchlej @Ykidia @vit9696 ?

[NikolajSchlej]

I'm planning a release soon, but meanwhile you can build the last commit, as you suggested, and test that way.

[Ykidia]

@NikolajSchlej
You mentioned that you’d need about another month to fully recover, so I figured I’d have time to prepare an improved version of my PR (new commit). The current implementation has a couple of issues I’ve already addressed.

For example, the relationships between structures aren’t always clear - especially in complex images like for the ASUS ROG STRIX X570, where there are so many interconnections that it becomes hard to understand “who belongs to whom.”
Another issue was the dynamic size of the FET (yes, I’m now consistently using this term, instead of "EFT"), which varies across platform and CPU generations and wasn’t being detected correctly. I’ve already solved both of these problems.

However, there’s one remaining issue I’m still working on: file attributes. The problem is that file attributes are stored in the table entries, not in the files themselves. But a single file can have multiple parent table entries, which might specify conflicting attributes at the same time.

Showing attributes in the table entry info makes sense - but hiding them in the file info feels uninformative and ends up being quite inconvenient in practice. So I’m currently figuring out the best way to handle this.

Would you be okay giving me a bit more time to sort this out? 😊

[NikolajSchlej]

Sure.

As for conflicting attributes, check if that is really the case, and show them both in the table (where they can't conflict) and in the file info (where instead of just "Attributes" for non-conflicting case there will be "Attributes (Bank0)" and "Attributes (Bank1)") or something alike.