Improve Integrated Firmware Image (IFWI) support

[platomav]

IFWI is already being used at APL platform and will soon be used on the mainstream platforms too. Most of the work has already been done by Coreboot over here, meaning parsing of BPDT, module extraction, addition, deletion, creation etc. This project could be helpful as well.

Some notes:

• IFWI can be found either at BIOS or Engine region of Flash Descriptor
• Reserved1 region at Flash Descriptor is now called Device Expansion
• The Engine version detected by UEFITool can now be taken from CSE_BUP (Type 2) partition

As for samples, you can use any OEM APL SPI image.

[skochinsky]

I'm not so sure about "will soon be used on the desktop side". It seems to be mostly intended for eMMC storage (i.e. very compact devices). IIRC it began with Intel phone chips and was also used in Intel Joule and Edison boards and some BayTrail tablets.

[platomav]

The one used by Intel at Apollo Lake is called IFWI 2.0 and is supposed to be used across SPI, eMMC & UFS devices. By "desktop" I meant mainstream platforms, wrong wording. It is likely that we'll see it at CNL mobile (LP) systems. Either way, APL has been out for a year now and every image I've seen uses IFWI. So it's worth adding that functionality to UEFITool.

[ThePlexus]

Are there any plans to add IFWI 2.0 to UEFITool? or is this a dead end for apollo & gemini lake and UEFITool

[NikolajSchlej]

It's not a dead end, and new ME parser has initial support for IFWI 1.6, so adding 2.0 will be easier now.

[NikolajSchlej]

Should be fixed after this commit: https://github.com/LongSoft/UEFITool/commit/90ff19692d209c1d26af0a77266f990351e60c08 However, lots of images I've tried have issues with the last FFS volume having incorrect size and crossing the boundary between BIOS and DevExp region, so I'm not closing this issue for now until this new code gets some actual testing.

[platomav]

Great work Nikolaj!

I'm going to ignore CSE firmware related IFWI module bugs for this issue. These deserve their own place.

The minimum size for BPDT header is 0x200 and the maximum is 0x1000 so such an adjustment can remove the padding after it. It's probably always 0x200 (min) for now as not a lot of entries are needed.

The BPDT Checksum does not seem to be checked or displayed. It's not used at APL/GLK but it is used at other platforms so it might be useful to add that if its value is not 0. At BPDT v1 (IFWI 1.6 & 2.0) it is 2 bytes (CRC-16 ?) and covers data from BPDT up to and including S-BPDT. At BPDT v2 (IFWI 1.7) it is 4 bytes (CRC-32) and covers BPDT (Header + Entries) without Signature.

At dumped/initialized APL/GLK images, the DevExp1 region is populated with CSTXE $FPT Data modules (the same Data/Non-Code modules as found at the IFWI 1.6 CSME structure - which is actually called CSE Layout Table). It's basically the extension of the IFWI for Engine data, after first boot. Currently DevExp1 is not parsed by UEFITool but it should be very simple. If an $FPT is found, parse it like it's a regular Engine region.

The classic (at this point) APL/GLK bug with the last FFS volume size crossing over DevExp1 should be fixed automatically by UEFITool in my opinion. I guess it is similar in nature to the stupid OEM practice a few years back when they left the BIOS limit to 0x0 at the Flash Descriptor. If UEFITool can automatically adjust it and fix it upon rebuilding (when that's implemented) then great.

[NikolajSchlej]

The minimum size for BPDT header is 0x200 and the maximum is 0x1000 so such an adjustment can remove the padding after it. It's probably always 0x200 (min) for now as not a lot of entries are needed.

• [ ] Update BPDT header size

The BPDT Checksum does not seem to be checked or displayed. It's not used at APL/GLK but it is used at other platforms so it might be useful to add that if its value is not 0. At BPDT v1 (IFWI 1.6 & 2.0) it is 2 bytes (CRC-16 ?) and covers data from BPDT up to and including S-BPDT. At BPDT v2 (IFWI 1.7) it is 4 bytes (CRC-32) and covers BPDT (Header + Entries) without Signature.

• [ ] Verify BPDT checksum(s)

DevExp1 region is populated with CSTXE $FPT Data modules

@platomav, could you please attach such an initialized dump

• [x] Parse DevExp1 as ME region

the last FFS volume size crossing over DevExp1 should be fixed automatically by UEFITool in my opinion I'd really like to disagree here, but I haven't ever seen an image that's not broken this way, so it's probably the only suitable approach.

• [ ] Implement workaround for last volume in IFWI 2.0 region to not cross the region boundary

[platomav]

could you please attach such an initialized dump

apl_dump.zip (change the extension to rar instead of zip)

Verify BPDT checksum(s)

Sample of IFWI 1.6/2.0 Checksum

[NikolajSchlej]

Enabled DevExp1 region parsing as ME region in 95c8381, but looks like some SPS/server systems use it for something else than FPT, so it's either needs to be detected as FPT region first, or just skipped. Because I don't have any FPT parsing yet (was interested in code much more than in data), it probably makes sense to disable DevExp1 parsing for now, but I'd like to listen to some feedback before it can be decided for real,

[platomav]

I don't have any FPT parsing yet (was interested in code much more than in data)

You do. The current implementation is exactly what I meant. Show $FPT partitions and their details, like in a normal Engine region. $FPT is just a Partition Table. The difference is that a normal Engine region also has CODE partitions like FTPR and NFTP (where the firmware version is retrieved) but the parsing of the $FPT does not change in either case. I think the current implementation in UEFITool is good.

so it's either needs to be detected as FPT region first, or just skipped.

You can check if the region starts with $FPT and if it does, parse as Engine otherwise ignore. Generally, this is only applicable to IFWI 2.0 (APL/GLK) and not IFWI 1.6 or 1.7. At the latter two, this "data" partition is implemented in CSE Layout Table as "Data Partition" (which also starts with $FPT). Here are some pictures which explain IFWI 2.0 and what I'm talking about:

In my opinion, this is how it should be done:

• If BPDT patterns (Green/Yellow) are detected at the start of the BIOS region, then you have IFWI 2.0. As an extra check, the BPDT version should be 1.

• If no BPDT patterns are found at BIOS start and CSE Layout Table is detected at the start of the Engine region, then you have IFWI 1.6 or 1.7. Unfortunately the CSE LT is a terribly simple structure so figuring out if it's actually one is difficult. For UEFITool, I guess you can check if $FPT exists there (pre-IFWI) or "other data" (CSE LT). Once you have a CSE LT, go to first Logical Boot Partition (LBP1) and check the version of BPDT. If it is 1 then you have IFWI 1.6 whereas if it is 2 you have IFWI 1.7. At IFWI 1.6 & 1.7, ignore Device Expansion region as it is not used as CSE Data Partition. Terrible way to find things but that's how Intel designed it unfortunately.

[NikolajSchlej]

You do.

Well, kind of yes, and also kind of no, because that particular FPT is a data-only region, and I have no parsers for such.

As for that better detection, I'll leave this issue open for now, but will consider this improvements to be of low priority.