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
