Hi, I was using four (and later eight) Crucial CT51272BD160BJ (4GB, ECC, unbuffered) for more than a year (with coreboot 4.7 if I remember correctly) with two Opteron 4284. The only issue I have found is that the memory is running at DDR3-1333 instead of DDR3-1600.
Cheers, Matthias On 04/06/2019 10:53, up6IfzRzvQCyv9AK4XvYirxDa8 via coreboot wrote: > The proprietary BIOS and Libreboot are working well. Also a RAM module that > is directly recommended at the > Raptor Engineering ASUS KCMA-D8 status page > (https://www.raptorengineering.com/coreboot/kcma-d8-status.php) - the 1x DIMM > HMT325U7BFR8A is working. Anything else I have here is not working and > looping with the message: > > DIMM training FAILED! Restarting system...soft_reset() called! > > I tried RDIMMs and UDIMMs and different KCMA-D8 boards - brand new and also > some from fleabay sold from china with revision numbers that are not > mentioned anywhere. Got the same results on all the boards. > > What RAM modules are you using? ECC / non-ECC? What sizes? > > "FYI you need microcode updates with the 43xx CPU otherwise you will have > critical security issues" > > Yes, that is the reason I want to use coreboot and 43xx is the target > platform. Those 41xx are > used just for testing. > > I also tried coreboot 4.6 (release) but got the above error message. Looks > like I have to remove all commits that has been done since the Libreboot > fork. I'm surprised that it's so hard because I thought the KCMA-D8 would be > better supported and tested. > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Sunday, June 2, 2019 10:45 AM, up6IfzRzvQCyv9AK4XvYirxDa8 > <up6ifzrzvqcyv9ak4xvyirx...@protonmail.com> wrote: > >> Hi guys, >> >> 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: >> >> commit 99e27ceb6d913a7a882cc6e7277b881df38dc9ad >> Author: Timothy Pearson tpear...@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. >> >> Change-Id: I44721447ce4c2b728d4a8f328ad1a3eb8f324d3d >> Signed-off-by: Timothy Pearson tpear...@raptorengineeringinc.com >> >> Reviewed-on: https://review.coreboot.org/14502 >> Tested-by: build bot (Jenkins) >> Tested-by: Raptor Engineering Automated Test Stand >> <nore...@raptorengineeringinc.com> >> >> Reviewed-by: Martin Roth <martinr...@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. >> >> Regards >> >> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >> On Saturday, June 1, 2019 6:29 PM, Mike Banon mikeb...@gmail.com wrote: >> >>>> Why libreboot 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 espionage...@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 >>>> Coreboot. >>>> 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@coreboot.org >>>> To unsubscribe send an email to coreboot-le...@coreboot.org > > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
