Attention is currently required from: Paul Menzel, Dinesh Gehlot.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74255 )
Change subject: soc/intel/cmd/block/cse: Add config option for storing fw version info ......................................................................
Patch Set 13:
(1 comment)
File src/soc/intel/common/block/cse/Kconfig:
https://review.coreboot.org/c/coreboot/+/74255/comment/366f9476_206a7c65 PS13, Line 48: config SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION : bool : default n : depends on DRIVERS_INTEL_ISH : help : This configuration option stores CSE FPT partitions' version in CBMEM memory. : This information can be used to identify the currently running firmware partition : version.
Sorry, for bringing this up again. No idea, if it was answered in another change-set comment, but I think, it should be clear from the Kconfig description.
- Why does this need to be configurable, and cannot be enable unconditionally?
I can't add the details in the code itself as it may not be appropriate. let me explain here, since CNL there are many devices that opt for ISH but starting with ADL devices, we are planning to enable ISH update feature hence, everytime, we would like to update the ISH, we need back the version to compare again the updated version. mostly it will be done as part of the automated script running at os level and the only input we need is to retrieve the ISH version.
Hence, this feature should be applicable to the platforms those who would like to enable this feature and doesn't applicavle to add devices that choose ISH KCONFIG by default.
- Why does this information need to be stored in CBMEM? If the firmware is updated in coreboot, why can’t coreboot read the version information directly? Is it some boundaries between stages? I thought mainly CBMEM is used to pass information to later programs like payloads or the OS (CBMEM console).
there is a cost to send HECI cmd on every boot like 200ms where else if we could be able to read the version and store into cbmem, we can reuse it in multiple warm reset. Thats the reason, we have opt for cbmem. most likely in future i will drop cbmem and get into some more persistent NVS memory to even avoid running the cmd on cold resets.