[coreboot-gerrit] Change in coreboot[master]: amd/pi/00670F00: Add memmap file
Marshall Dawson (Code Review)
gerrit at coreboot.org
Mon Apr 17 22:32:11 CEST 2017
Marshall Dawson has posted comments on this change. ( https://review.coreboot.org/18428 )
Change subject: amd/pi/00670F00: Add memmap file
......................................................................
Patch Set 10:
(1 comment)
https://review.coreboot.org/#/c/18428/10/src/northbridge/amd/pi/00670F00/memmap.c
File src/northbridge/amd/pi/00670F00/memmap.c:
Line 65: * also adjust TOM/TOM2 for the C6 storage, as well as the audio controller.
> CarrizoPI build seems to set CstateModeDisabled (changed from the default o
> CarrizoPI build seems to set CstateModeDisabled (changed from the default of CstateModeC6).
I only have the binaryPI directory that was reportedly used for Carrizo, and I see the same thing. For ST, we copied over the Addendum/StoneyFp4Options.c file for buildOpts.c, and the CStateModeDisabled line is commented.
In poking around with this, I was surprised that 16MB is always allocated regardless of C6 en/disable. The logic is basically if(C6en || PSP_present). You should be able to confirm this in AmdAgesaPkg/Proc/Mem/NB/CZ/mnmctcz.c.
I still think using TOM/TOM2 is OK. The carve off adjusts NBPtr->RefPtr->SysLimit, and this value is used to set TOM/TOM2 in Mem/NB/mnmct.c.
> My concern is that if C6 shifts uma_base by 16MiB, you will have excessive MTRR usage since currently CFG_UMA_ALIGNMENT is set to 4MiB.
Inspired by what board OemPostParams() could still do, I found out that there is runtime option CfgUmaAlignment and if it behaves as I expect it to, it will enforce the alignment for uma_base. But code here ignores any applied alignment.
That's a good thought about the alignment. ST is also compiled for UMA_4MB_ALIGNED. I can't think of a good way to detect that setting in coreboot. It could be worth a cautionary comment though. I don't believe changing the setting will affect the calculation unless 2GB DRAM or less is present, however. 4GB is the smallest DDR module I have to test with and the C6 region is above 4GB. I looked at a Gizmo and TOM is set to 3F000000 (1GB - 16MB).
I had considered maybe adding a check that could report an error if the calculation for UMA base/size doesn't match what InitPost returns.
> you will have excessive MTRR usage...
Do you mean that we'll be burning memory? Or, are you concerned that an additional variable pair(s) might be required?
> So confirm with C6 enabled things still work and please paste /proc/mtrr outputs for both C6 enabled and disabled.
This isn't as interesting as you are hoping because the 16MB is always carved off when the PSP is present:
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-back
reg06: base=0x0ff800000 ( 4088MB), size= 8MB, count=1: write-protect
--
To view, visit https://review.coreboot.org/18428
To unsubscribe, visit https://review.coreboot.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I8ddaa8359536081752fb8e47e49f4d5958416620
Gerrit-PatchSet: 10
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Owner: Marc Jones <marc at marcjonesconsulting.com>
Gerrit-Reviewer: Aaron Durbin <adurbin at chromium.org>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki at gmail.com>
Gerrit-Reviewer: Marshall Dawson <marshalldawson3rd at gmail.com>
Gerrit-Reviewer: Martin Roth <martinroth at google.com>
Gerrit-Reviewer: Paul Menzel <paulepanter at users.sourceforge.net>
Gerrit-Reviewer: build bot (Jenkins)
Gerrit-HasComments: Yes
More information about the coreboot-gerrit
mailing list