Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38701 )
Change subject: soc/amd/common/biosram: Add functions to get/set bootram used ......................................................................
Patch Set 4:
Patch Set 4:
Patch Set 4:
What is the motivation to consume non-volatile 8-bit accessible biosram registers here instead of DRAM and migrate these to CBMEM? You need persistent .earlyram.data anyways implemented across early stages.
Adding a small section in .earlyram.data seems acceptable. We'll need to copy that to cbmem in romstage, then use the info stored in cbmem during ramstage.
Yes. That's the design used for pretty much everything else that has to migrate from bootblock to ramstage.
That biosram is comparable to CMOS nvram and/or PCI config scratchpad. You should avoid use of it unless absolutely required, and from what I remember we find arguments during amd/stoneyridge for doing this with CBMEM top location and possibly UMA allocation size.
I can't say how it will look like with picasso, but previously it was necessary to lock the layout of .car.data with the first shipped bootblock build. This has to do with having read-only bootblock and verstage builds as root-of-trust. Just saying, moving things to .earlyram.data later on may get tricky.
About 25% of biosram is already consumed? Previous AGESA had some of it's own (undocumented) reservations in that memory too. I think that's why coreboot started to fill that region from the end instead?