On Sun, 22 Jan 2017 12:33:08 +0100 Zoran Stojsavljevic <[email protected]> wrote:
> Hello Stefan, > > In addition what Charlotte wrote to you, I would advise you the following > (as general approach for mem problems): > [1] Please, for testing the memory, use secondary Coreboot payload called > MEMTEST: > [user@localhost coreboot]$ cat .config | grep MEMTEST > CONFIG_MEMTEST_SECONDARY_PAYLOAD=y > CONFIG_MEMTEST_STABLE=y > # CONFIG_MEMTEST_MASTER is not set > > Instead going to SeaBIOS or GRUB2 as payloads. This memtest86+ could (my > best guess) show to you what is wrong with your memory configuration. > > [2] You can also (since you are able to in some cases go to Linux) stop in > GRUB2, after installing from Linux memtest86+ package into the GRUB2 boot > options (this can also help too, my best guess). > > (extra advise: if you use legacy/CSM ON, which is in Coreboot in 99.999% > cases used, it would be much easier for you to deal with memtest86+) Hi Zoran, I am not exactly sure what you are trying to convey. I mentioned that memtest did lock up after some seconds with the vendor firmware in my previous mail. Of course it's the first thing to try when memory problems arise - I just tried to boot Linux to retrieve the e820 map because Nico requested it on IRC. I presume that using memtest as primary or secondary payload or booted from GRUB2 would not produce different results (unless the binaries are different of course), no? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
