thank you for the valuable feedbacks. As I can see from the git commits, it was mainly
Timothy Pearson from Raptor Engineering Inc who worked on the kcma-d8 porting. Libreboot
is based on some version of coreboot 4.6. But it seems that after that a number of RAM
related commits has been done,like e.g. this:
Author: Timothy Pearson <tpearson(a)raptorengineeringinc.com>
Date: Sun Apr 24 20:33:29 2016 -0500
mainboard/kgpe-d16|kcma-d8: Update memory test to include second PRNG stage
The existing memory test routine was insufficient to detect certain types
of bus instability related to multiple incompatible RDIMMs on one channel.
Add a PRNG second stage test to the memory test routine. This second stage
test reliably detects faults in memory setup for RDIMM configurations that
also fail under the proprietary BIOS.
Signed-off-by: Timothy Pearson <tpearson(a)raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand
Reviewed-by: Martin Roth <martinroth(a)google.com>
Can someone confirm that the latest libreboot on the kcma-d8 is stable, so that the effort
of the commit 'dichotomy' will be worth it. This means basically
to roll back the commits for the kcma-d8 that has been done since the libreboot fork.
Another approach would be to figure out why only very few RAM modules are supported. I can
offer test support, but the analysis exceeds my knowledge and
skills in this area.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 1, 2019 6:29 PM, Mike Banon <mikebdp2(a)gmail.com> wrote:
works and coreboot doesn't?
Libreboot is some older version of coreboot where all the blobs have
been removed. If something works at libreboot but doesn't work at
coreboot, most likely that means there was a breaking commit at
coreboot which came later than a libreboot release (and, like the rest
of new commits, this breaking commit is going to be inherited by
libreboot in its' next release). When you encounter such a situation,
you should do a commit dichotomy to find out which commit broke the
things and report it, so that maybe it would be reverted or improved
and then the things should become working for you in the latest
coreboot master. Good luck
On Sat, Jun 1, 2019 at 9:28 AM Sean Lynn Rhone espionage724(a)posteo.net wrote:
> For non-ECC modules on the KCMA-D8, I found that Samsung M378B5273CH0-
> CK0, Micron 16JTF25664AZ-1G4F1, and Nanya NT2GC64B88B0NF-CG work with
> I also had SK Hynix HMT151R7BFR4C-H9 which didn't work with Coreboot,
> but worked on Libreboot. Samsung M393B5270CH0-CH9 also doesn't work
> with Coreboot.
> On Fri, 2019-05-31 at 10:00 +0000, up6IfzRzvQCyv9AK4XvYirxDa8 via
> coreboot wrote:
> > There are also differences between 42xx and 42xx/43xx. Below a
> > logfile of coreboot 4.9 with 4225 and 4180.
> > Test with 4365 + coreboot 4.9 and 1x M391B1G73BH0-CK0 in the Slot A2
> > and 1x CPU. The same configuration but with the HMT325U7BFR8A
> > (recommended by raptorengineering.com
) works. I t
> coreboot mailing list -- coreboot(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org