Update preserve_rom function to check if /tmp/cbfs-init.rom should be used

[mdrobnak]

On the MSI boards, the "internal" CBFS region, which is the default when calling cbfs without arguments, returns no files, or when called with -v, errors:

Header delta          : -29261268
Header magic          : ffffffff
Header version        : ffffffff
Header ROM size       : ffffffff
Header boot block size: ffffffff
Header align          : ffffffff
Header offset         : ffffffff
Header arch           : ffffffff
Failed to find valid header

This patch is an extension of 4d533b3 changes. That change uses flashrom to extract the image of the CBFS if enabled. Here it uses that extracted image to add files to a new image which is to be flashed.

This has been tested on my MSI Z790-P DDR4 board.

[JonathonHall-Purism]

@mdrobnak Thanks for looking into this!

That commit - 4d533b3 - isn't in master, so nothing reads cbfs-init.rom, this can't be merged as-is.

I have some 32 MB flash boards (L1UM v2 and the WIP Librem 16) but the COREBOOT CBFS region is set to 16 MB on both of those so it's still in the memory-mapped region. Does this board actually need a larger COREBOOT region? It may be simpler just to change the region size.

In theory it'd be amazing if we could extend cbfs to know how to read the SPI flash using the PCH, but I'm sure that's not trivial. If we do need this, the workaround to read the whole region ahead of time with flashrom is better than not working at all.

[mdrobnak]

@mdrobnak Thanks for looking into this!

That commit - 4d533b3 - isn't in master, so nothing reads cbfs-init.rom, this can't be merged as-is.

I have some 32 MB flash boards (L1UM v2 and the WIP Librem 16) but the COREBOOT CBFS region is set to 16 MB on both of those so it's still in the memory-mapped region. Does this board actually need a larger COREBOOT region? It may be simpler just to change the region size.

In theory it'd be amazing if we could extend cbfs to know how to read the SPI flash using the PCH, but I'm sure that's not trivial. If we do need this, the workaround to read the whole region ahead of time with flashrom is better than not working at all.

Ah, I didn't 't even look. This was from a discussion in the Dasharo support channel, the commit was referenced there, and I saw linuxboot/heads and didn't realize it wasn't merged. The short answer is, due to keeping compatibility with MSI's FlashROM functionality, the layout for serial # stuff etc, I was told yes it needed to be larger.

So I guess the options here are to bring in the other change with this, or to re-open my closed PR on the Dasharo side of things. Or, something else?

To your point, yeah I wish it was 'just working' as it's a LOT faster to not have to read this in on boot.

-Matt

[tlaurion]

@JonathonHall-Purism @mdrobnak I wasn't aware of @mkopec's 4d533b3 and other associated work downstream but this seems to show need of extending flashtool's https://github.com/osresearch/flashtools/blob/master/cbfs.c to be able to read things directly instead of abusing of flashrom which is slow at applying workaround here.

@JonathonHall-Purism going flashrom path would make this work out of the box today, but this approach is less than ideal.

[mdrobnak]

I took a quick look at the file and that's out of my expertise at the moment, so I'm unable to help there unfortunately.

[mkopec]

I agree that the ideal fix would be to extend flashtools with support for alderlake's extended BIOS window. The original patch to use flashrom was more of a workaround than a real fix.

[tlaurion]

@mkopec @mdrobnak so best course of action is to revive PR on dasharo side and have the board and config upstreamed under linuxboot/heads as previously discussed. That board and config doesn't exist under Heads upstream which is an issue for proper collaboration and upstrwamig and bleeding edge testing of fixes.

[mdrobnak]

@mkopec @mdrobnak so best course of action is to revive PR on dasharo side and have the board and config upstreamed under linuxboot/heads as previously discussed. That board and config doesn't exist under Heads upstream which is an issue for proper collaboration and upstrwamig and bleeding edge testing of fixes.

Ok will revive the Dasharo PR for now then.

[tlaurion]

Opened Dasharo/dasharo-issues#897 to track issue downstream. Closing this PR, needs to come from Dasharo team.