Mike Banon has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40291 )
Change subject: vc/amd/agesa/f.../Proc/Mem/Tech/DDR3: Support XMP memory profiles ......................................................................
Patch Set 18:
Patch Set 17:
Can you add debug print statements to the if statement
if (!DctChannel.D18F2x94_dct0.Field.DisDramInterface)
to see what branch is chosen, and what values it is set to?
In AMD Family 16h (from 2013 instead 2012) the code seems to have been moved to `src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbInitKB/GfxIntegratedInfoTableKB.c`.
Paul, thank you for advice! memps0_freq got 0 value from a function GfxLibExtractDramFrequency, which returned zero because there wasn't a "933" entry at GfxMemClockFrequencyDefinitionTable. After I inserted 933 to it, now a board successfully boots as 1866MHz 9-9-10-27 (with AGESA, CL-tRCD-tRP-tRAS , tRP is always 1 digit higher than CL/tRCD for some reason) as told by memtest86+ 5.01, and already 2 successful passes ;-) (using memtest86+ 4.37 for testing because 5.01 always gives me lots of false positives at a certain range, no matter what board or RAM).
f14 doesn't have this table, and f16kb table already has a 933 value in its' table at src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbGfxIntTableV3/GfxLibV3.c , so it could also run at 1866MHz but only with overclocking a memory controller / northbridge, which isn't easy to do because of hardcoded base clock at many places
So happy with results :) Should I move a change to "Gfx table", and maybe also the northbridge's "128 -> 256 bytes" SPD change which is outside of ./src/vendorcode/, to the separate changes?