Attention is currently required from: Nico Huber, Subrata Banik, Patrick Rudolph. Sridhar Siricilla has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/61380 )
Change subject: soc/inte/common: Add support to control coreboot and Intel SoC features ......................................................................
Patch Set 2:
(1 comment)
File src/soc/intel/common/block/cse/cse_lite.c:
https://review.coreboot.org/c/coreboot/+/61380/comment/aa6d1636_5828800e PS2, Line 666: is_cse_fw_update_enabled
So, if I read it correctly there is no restriction while reading OEM sections prior or post FSI. […]
As I have highlighted earlier adding Kconfig is always costly plus its maintenance effort, who will maintain this addition and deletion, plus pulling that CL into upstream chromium etc. etc..
Valid concern! Let's come back on this once proposal is ready. Ok?
- Using OEM section for storing SoC debug information. which ideally can be managed using a soft-strap under debug strap.
Soft strap is not advisable as this visible for other programs(Windows). Having the debug capability part of OEM Section, it gives more flexibility to coreboot to add/remove any functionality.
- Default value for bit-field, example: `1` is disable and `0` is enable or vice versa,
No plan to use bit fields. Each feature gets 1 byte slot in the OEM section. Value "1" is for invert the predetermined coreboot/SoC feature, for other values (0xff or any), no action.
- Any restriction this OEM region read need to be discarded in in FSI image. if yes, what is the boot time impact.
Hmm, I don't see any penalty
4.Comment suggests that, there are plan to add more configuration using OEM region and added a library. But what those configuration are not very clear just reading the commit msg.
I will share the proposal (if you are willing to share your experience here) once it is ready.