Attention is currently required from: Eran Mitrani, Julius Werner, Kapil Porwal.
Subrata Banik has posted comments on this change by Kapil Porwal. ( https://review.coreboot.org/c/coreboot/+/82659?usp=email )
Change subject: libpayload/libc: Include region device APIs ......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
What's the overall plan on how we want to do this CSE sync from payload thing? It looks like CL:5570028 is copy&pasting a ton of code from coreboot into depthcharge (including APIs that have different equivalents in depthcharge), that's... not great.
We've generally been trying to keep the region API out of libpayload because it is GPL'ed. So common libpayload infrastructure like FMAP accessors (which would be needed by CSE sync) generally don't use it (e.g. `fmap_locate_area()` just takes raw offset and size pointers). If the goal here is to have a separate copy of the CSE sync code in depthcharge, then it should be written from the ground up to use the usual depthcharge and libpayload interfaces (and not the region API).
If the goal is to make coreboot and depthcharge share the meat of the CSE sync code through commonlib (which, considering the amount of code, may not be a bad idea, although we'd have to see in practice how easy it is to untangle from coreboot-specifics) then we should probably rewrite the inner parts of the CSE sync code to not use the region API and form it into a sort of library that can be called from both coreboot and payloads (if necessary with some kind of callback for reading flash that doesn't involve rdev). Either way, I think the right solution here probably isn't going to involve region API in the payload.
I believe the process should be something like this:
1. Coreboot skips all CSE programming when it sees a Kconfig option (CSE_SYNC_PAYLOAD). 2. Depthcharge should be able to implement something new that is independent of coreboot (without passing function pointers from CB to DC). 3. Any common code that CB and DC would like to use should come through libpayload.
Do you have any feedback on this guideline, @Julius?