Ok, it seems that there are some general issues with the RAM compability. Libreboot seems to have some code that has less issues with some RAM sticks, but the stability has yet to be confirmed. For example, I discovered a scenario where the size of the RAM was detected incorrectly. The question now is whether it is worth investing time in the KCMA-D8 or to say that it is no longer supported. Are there alternatives for a secure workstation?
I am ready to put a board aside for regression testing and test different versions of coreboot for lets say the next 1-2 years. I have to organize an eeprom emulator before to save myself the permanent replugging and flashing of the eeprom. But I cannot solve the fundamental 'DIMM training FAILED! Restarting system...soft_reset() called!' problem. I lack the time and knowledge of the topic. But I can do the commit dichotomy, though. Anybody wants to join in? ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, June 5, 2019 1:33 PM, Mike Banon <[email protected]> wrote: > 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]
