Thanks Martin! This was pretty straightforward, as soon as I have my CML v2 device to fully test I'll send patches.
On 9/26/23 18:06, Martin Roth wrote:
Hey Jonathan, I don't see why this should be an issue other than the flash space it consumes. I think it's totally reasonable to want a single image that works for both steppings.
I haven't looked into it (I can't recall a situation where it was needed), but I'd say go for it.
Martin
Sep 26, 2023, 12:28 by jonathon.hall@puri.sm:
Hi all,
As many of you probably know, Comet Lake v1/v2 have different FSP binaries, and hence separate Kconfigs `SOC_INTEL_COMETLAKE_1` and `..._2`. In short, the same SKU could be either depending on the stepping.
We're getting new steppings in future batches of products, which will move them from CML v1 to CML v2. These aren't otherwise "new versions" of the product. It would simplify life for my customers if they had the same firmware image.
From an initial look it seems reasonable to embed both FSPs and select at runtime using the CPUID as suggested by Intel:
- The headers for both FSPs are equivalent (differ only in comments), so there should be no issue switching at runtime
- The _1 / _2 Kconfigs are only used to select FSP headers/binary, nothing else
- It'll cost some flash space, so separate _1 / _2 should continue to exist, but in my case that tradeoff is fine
Has anyone looked into this in the past? Is there any other reason this is not a good idea?
From my initial look, I would try:
- Add another Comet Lake Kconfig, say `SOC_INTEL_COMETLAKE_1_2` (or `..._1_AND_2`, etc.)
- Embed a second FSP - probably add an optional `FSP_FD_PATH_2` to the FSP 2.0 Kconfig, the `..._1_2` SoC Kconfig would then put its second FSP here
- Add a second `FSP_M_CBFS`/`FSP_S_CBFS` (the names of the files in cbfs)
- For `SOC_INTEL_COMETLAKE_1_2`, select the correct cbfs name based on CPUID. Those are only used in a few places, so the impact wouldn't be very large.
Thanks, Jonathon