Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35029 )
Change subject: soc/intel/{cnl, dnv, icl, skl}: Make top_of_ram align ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/c/coreboot/+/35029/1//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/35029/1//COMMIT_MSG@10 PS1, Line 10: alignment requirments.
What is the further motivation here? Reducing variable MTRR usage?
Yes.
The algorithms take into account natural alignment. However, if the memory map is not aligned well then cbmem_top() should be the entity providing the alignment.
Do you mean memmap.c logic will take care of alignment part?
All the algorithms in question already try to fit the requested address and size to meet mtrr natural alignment requirements. I'm suggesting that if there is an address which isn't aligned to high enough granularity we should just have cbmem_top() enforce a better alignment to optimize for MTRR usage at the expense of stranded DRAM. That said, it's easier said than done when it comes to FSP deciding memory maps and needing to deal w/ the reserved space.
I believe from KBL time, we have enforce memory map alignment in CB space as well so its not true that FSP is deciding everything on reserving some random memory that CB is not aware of. design of memmap.c is taking care of transparent memory layout between FSP and CB. I'm quite sure we will get aligned memory in cbmem_top but the question was raised here that set_var_mtrr is wokring because cbmem_top is aligned, what if cbmem_top() is not align and we are still using set_var_mtrr hence i have ensured alignment again in this file. But now as we have lost romstage.c and its been using from common location, i believe we don't have any mean to apply these changes.