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