Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/43488 )
Change subject: lib: Remove corrupted fmap cache error for psp_verstage ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/c/coreboot/+/43488/1/src/lib/fmap.c File src/lib/fmap.c:
https://review.coreboot.org/c/coreboot/+/43488/1/src/lib/fmap.c@60 PS1, Line 60: (ENV_SEPARATE_VERSTAGE && CONFIG(VBOOT_STARTS_BEFORE_BOOTBLOCK)))) {
No, we do still want it to run in bootblock on zork. […]
It's definitely beneficial to use the cache if possible. I'm a bit confused by the "can't guarantee" part... shouldn't you know at build time whether it will all fit or not? How could that change at runtime?
My main concern here is to find a way to model these things in a simple and platform-agnostic way for the common code. We have this "cache that is initialized in the first stage and expected to exist by later ones" concept in several places (and my CBFS verification stuff is going to add more of those). I think we need a consistent way to model it in a way where Zork can fit in, so ENV_FIRST_STAGE was one idea to do that. Let me know if you have a better one.
If on later AMD platforms you can have an FMAP cache on the PSP but don't have the space to pass it along, that's an even more complicated situation to try to model in a platform-agnostic way. I'd say let's cross that bridge when we get there and maybe hope it doesn't come to that (the FMAP should only be 2K or so after all, it sounds unlikely that you couldn't fit that... we still have the options of reducing vboot workbuffer requirements that we discussed earlier but didn't end up needing).