Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36290 )
Change subject: arch/x86/cbmem.c: Drop API to save cbmem_top across stages ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2: Code-Review-2
(1 comment)
I'm pretty confident about the -2 here.
And seemingly no easy way to fix it either...
AGESA needs nvram storage to get back Sub4GCacheTop amongst other things and you also need to also have nvram storage for coreboot to do do the same?
First, UMA size decision is dynamic inside InitPost() (normal boot path) and related hardware registers are inside some indirect access bank. => Need to rely on vendorcode/blob calculations and the structures passed using the AGESA API.
Second, for S3 resume path, InitResume() parameter structure does not return required data to resolve cbmem_top() in romstage and the related UMA hardware registers are not restored until S3LateRestore in ramstage. => Cannot resolve cbmem_top() from hardware for S3 resume.
Third, S3DataBlock.NVStorage and VolatileStorage are to be considered as private or anonymous. From what I recall, they are regscript-style replays and UMA size might be in VolatileStorage anyways. => Parsing S3DataBlock is a worse choice than stashing raw cbmem_top() in nvram.