To avoid having to run a libreboot / ancient version of libreboot, there is a need for commit dichotomy to find out which commit broke the things - and, if you would like it to happen faster, you'll have to do it by yourself. It shouldn't take too much time: even if you'd start with the ancient coreboot 4.1 (Jul 2015) there would be just 14 dichotomy checks: 2^14 = 16384 and there are slightly fewer commits between them
On Tue, Jun 4, 2019 at 1:20 PM up6IfzRzvQCyv9AK4XvYirxDa8 via coreboot <[email protected]> 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 > <[email protected]> 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 [email protected] > > 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 [email protected] > > > > Reviewed-on: https://review.coreboot.org/14502 > > Tested-by: build bot (Jenkins) > > Tested-by: Raptor Engineering Automated Test Stand > > <[email protected]> > > > > Reviewed-by: Martin Roth <[email protected]> > > > > > > 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 [email protected] 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 [email protected] > > > 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 -- [email protected] > > > > To unsubscribe send an email to [email protected] > > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
