Hi there, KGPE-D16 friends.
1) Please look at my not-merged-yet "AMD_XMP" changes on review.coreboot.org: they could help you to either use a XMP 1 or XMP 2 memory profile (should exist on ALL your sticks), or - preferably - to set up your custom memory profile that will override the SPD values. This way, maybe you could figure out the values to make your RAM sticks run stable. You'll need to port this code to AMD fam10h architecture to which KGPE-D16 belongs (if I'm not mistaken), hopefully that wouldn't be hard.
2) USB is broken at floppy-based OS - maybe fam10h could have the same "IRQ routing" issue as fam15h has. Sophisticated OS like Linux somehow get around this issue, while the more simple OS couldn't.
3) Glad you liked my floppy patches and collection: there are certainly a lot of goodies that are fun and useful. Usually the latest revisions of these, and other, unofficial patches could be automatically obtained with a csb_patcher.sh script from 33509 change to save your time - I'm trying my best to keep up this stuff with a coreboot master, as well as to get merged at least some of these changes to reduce this maintenance.
Best regards, Mike Banon
On Thu, May 14, 2020 at 9:28 PM Peter Stuge peter@stuge.se wrote:
ragnaros@tenebr.is wrote:
- For 32GB configuration (2 x 16GB sticks), installing to the
closest orange slot of each CPU would not boot, it booted when I installed the sticks to the second closest orange slot of each CPU.
If you install memory modules as far *away* from CPU/chipset as possible then you create more margin in DRAM signal integrity, which can make the system work more reliably even if memory initialization is not perfect.
The reason is that signals reflect everywhere on the memory bus. When the chipset drives signals and modules are installed nearby, the signal will reflect back at the last slot and possibly interfere with either the controller's request or the DRAM's response.
The same happens when the DRAM drives signals, in response to requests. They go out from the DRAM and both left to the chipset and right towards those unpopulated memory slots, and then reflects there, possibly interfering with what the DRAM sent or with the next request from the controller.
Mainboard memory busses, especially with many slots, go right up to the limit of physics, and yes there is supposed to be a little bit of margin and there are some workarounds available, but all of that is the responsibility of the memory initialization, and it's very easy to not get everything 100% right. Then stuff doesn't always work.
With this in mind, the safest bet should be, to populate a single DRAM module per channel, as far away from the chipset as possible.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org