Memtest86+ failing on coreboot system.

[Knut Kujat]

Hello,

I've finally got my board working with Coreboot now I started to stress
test the whole system to know if it is stable. Now, when I'm trying to
test my memory with Memtest86+ it doesn't starts! instead it shows correct
information about my cpus and caches but at "Memory" there is just a 0K
and in the middle of the screen a "0K LxBIOS" what is that mean? After
waiting a few minutes I'm getting the whole screen full of rubbish symbols
and than the monitors goes off.

I already tried several versions of memtest86+ without luck. I know there
is a payload with Memtest86+ I haven't tried yet but I just don't think it
will make any difference, won't it?

THX,
Knut Kujat

[ron minnich]

can you remind us what hardware this is?

ron

[Knut Kujat]

Hi,

sorry, of course. I did the necessary changes on the alrady existing
supermicro h8dmr_fam10 board to make it work on a h8qme_fam10.

Supermicro H8QME-2+
4 CPUs (Opterons)
16 GB ram
MCP55 PRO
AMD 8132

I used the memtest that comes with the OPENSuse 11.2 installation CD I
also installed memtest to my grub boot menu.
Seems like memtest doesn't find any memory at all?! But linux boots fine
and recognized the whole memory amount. I already did some benchmarks and
they finished without any problems.

thx.
> can you remind us what hardware this is?
>
> ron

[ron minnich]

memtest in many ways is not my favorite program. I would rather have a
simple non-"GUI" tester, because in the past I've had trouble with it
(it can fail) when it did not like the device it was trying to do its
"GUI" on.

Also, the way memtest finds top of memory can fail on some chipsets.
Have not seen that for a while but I did see it.

No idea if any of  this is your problem but ...

ron

[Knut Kujat]

OK, thx anyway. I found another one "memtester 4.1" usable from linux so
it won't test the whole amount but memtest86 doesn't either :P.

bye!
> memtest in many ways is not my favorite program. I would rather have a
> simple non-"GUI" tester, because in the past I've had trouble with it
> (it can fail) when it did not like the device it was trying to do its
> "GUI" on.
>
> Also, the way memtest finds top of memory can fail on some chipsets.
> Have not seen that for a while but I did see it.
>
> No idea if any of  this is your problem but ...
>
> ron

[Myles Watson]

> I used the memtest that comes with the OPENSuse 11.2 installation CD I
> also installed memtest to my grub boot menu.
> Seems like memtest doesn't find any memory at all?! But linux boots fine
> and recognized the whole memory amount. I already did some benchmarks and
> they finished without any problems.

Your problem sounds very similar to the one I had.

Memtest looks to see if you have LinuxBIOS tables, but doesn't support
tables in high memory, so it fails.  Since you are using SeaBIOS, you'd
prefer that it used the BIOS tables.  I modified SeaBIOS to destroy the
marker for the LinuxBIOS tables after reading them (since they are no longer
useful.)  It's a hack, but it's quick and easy.

Suggestions:
Use a similar hack to destroy the signature so Memtest doesn't get confused
Use a version of Memtest that already supports high tables.

Thanks,
Myles

[Knut Kujat]

Ah, ok! I'll try this.

At least now I know from you and ron that it isn't necessary my ram thats
failing.

thx a lot!
Knut.
> > I used the memtest that comes with the OPENSuse 11.2 installation CD I
> > also installed memtest to my grub boot menu.
> > Seems like memtest doesn't find any memory at all?! But linux boots fine
> > and recognized the whole memory amount. I already did some benchmarks
> > and
> > they finished without any problems.
>
> Your problem sounds very similar to the one I had.
>
> Memtest looks to see if you have LinuxBIOS tables, but doesn't support
> tables in high memory, so it fails.  Since you are using SeaBIOS, you'd
> prefer that it used the BIOS tables.  I modified SeaBIOS to destroy the
> marker for the LinuxBIOS tables after reading them (since they are no
> longer
> useful.)  It's a hack, but it's quick and easy.
>
> Suggestions:
> Use a similar hack to destroy the signature so Memtest doesn't get
> confused
> Use a version of Memtest that already supports high tables.
>
> Thanks,
> Myles

[Stefan Reinauer]

On 1/22/10 12:36 AM, Myles Watson wrote:
> I modified SeaBIOS to destroy the
> marker for the LinuxBIOS tables after reading them (since they are no longer
> useful.)

Unless you ever plan to change CMOS settings, or update your BIOS and
want flashrom to know _reliably_ what mainboard you're using.

Stefan

[Myles Watson]

> On 1/22/10 12:36 AM, Myles Watson wrote:
> > I modified SeaBIOS to destroy the
> > marker for the LinuxBIOS tables after reading them (since they are no
>
> longer
> > useful.)
>
> Unless you ever plan to change CMOS settings, or update your BIOS and
> want flashrom to know _reliably_ what mainboard you're using.

I did say it was an ugly hack :)  I should have said that I only used that
broken version of SeaBIOS when I wanted to run Memtest.  Since it's a pretty
simple change, maybe someone should push high tables support upstream into
memtest.

Thanks,
Myles

[Ward Vandewege]

On Fri, Jan 22, 2010 at 12:09:59AM +0100, Knut Kujat wrote:
> sorry, of course. I did the necessary changes on the alrady existing
> supermicro h8dmr_fam10 board to make it work on a h8qme_fam10.

I'm interested in your port. It should go into the tree. Do you want to send
a patch to the list?

Thanks,
Ward.

[Knut Kujat]

Hi,
I would love to send the new board to the list but there are several
issues still remaining like:
- SMBus gets irq 0 instead of 5
- ACPI not working
- booting interrupts for about 4 minutes on "Stage: loading
fallback/coreboot_ram @ 0x200000 (360448 bytes), entry @ 0x200000"

and the strangest thing: I created a new folder h8qme_fam10 (I was
working in h8dmr_fam10 all the time)  made the different changes to be
able to compile everything correctly and now it refuses to boot. It just
halts somewhere or does several soft resets at different places.

bye!

PS: Ward, if you are still interested I can send it to you.

Ward Vandewege escribió:
> On Fri, Jan 22, 2010 at 12:09:59AM +0100, Knut Kujat wrote:
> > sorry, of course. I did the necessary changes on the alrady existing
> > supermicro h8dmr_fam10 board to make it work on a h8qme_fam10.
>
> I'm interested in your port. It should go into the tree. Do you want to send
> a patch to the list?
>
> Thanks,
> Ward.

[Patrick Georgi]

Am 25.01.2010 17:13, schrieb Knut Kujat:
> Hi,
> I would love to send the new board to the list but there are several
> issues still remaining like:
> SMBus gets irq 0 instead of 5
> ACPI not working

We have lots of boards with (at best) incomplete ACPI support. That
shouldn't stop you from releasing :-)
> booting interrupts for about 4 minutes on "Stage: loading
>
> fallback/coreboot_ram @ 0x200000 (360448 bytes), entry @ 0x200000"

You could try to dump the MTRRs right before loading the ramstage. 4
minutes sounds like there's some problem with caching.
> and the strangest thing: I created a new folder h8qme_fam10 (I was
> working in h8dmr_fam10 all the time)  made the different changes to be
> able to compile everything correctly and now it refuses to boot. It just
> halts somewhere or does several soft resets at different places.

Did you check that there is no h8dmr_fam10 or H8DMR_FAM10 in the new
directory? Is that directory hooked up in kconfig (if you're using
kconfig, that is)?
If you mix up the names, it might just build a mix of code for your
board and another supermicro board.

Patrick

[Knut Kujat]

Patrick Georgi escribió:
> Am 25.01.2010 17:13, schrieb Knut Kujat:
> > Hi,
> > I would love to send the new board to the list but there are several
> > issues still remaining like:
> > SMBus gets irq 0 instead of 5
> > ACPI not working
>
> We have lots of boards with (at best) incomplete ACPI support. That
> shouldn't stop you from releasing :-)
> > booting interrupts for about 4 minutes on "Stage: loading
> >
> > fallback/coreboot_ram @ 0x200000 (360448 bytes), entry @ 0x200000"
>
> You could try to dump the MTRRs right before loading the ramstage. 4
> minutes sounds like there's some problem with caching.
> > and the strangest thing: I created a new folder h8qme_fam10 (I was
> > working in h8dmr_fam10 all the time)  made the different changes to be
> > able to compile everything correctly and now it refuses to boot. It just
> > halts somewhere or does several soft resets at different places.
>
> Did you check that there is no h8dmr_fam10 or H8DMR_FAM10 in the new
> directory? Is that directory hooked up in kconfig (if you're using
> kconfig, that is)?
> If you mix up the names, it might just build a mix of code for your
> board and another supermicro board.
>
> Patrick

I was very careful with not mixing names. I tried to just rename the
existing folder as well with the same result, it's just so annoying
because I know I must be forgetting something really stupid.

thx,
Knut Kujat.

[Myles Watson]

> Patrick Georgi escribió:
> > Am 25.01.2010 17:13, schrieb Knut Kujat:
> > > Hi,
> > > I would love to send the new board to the list but there are several
> > > issues still remaining like:
> > > SMBus gets irq 0 instead of 5
> > > ACPI not working
> >
> > We have lots of boards with (at best) incomplete ACPI support. That
> > shouldn't stop you from releasing :-)

I agree.
> I was very careful with not mixing names. I tried to just rename the
> existing folder as well with the same result, it's just so annoying
> because I know I must be forgetting something really stupid.

If you send it to the list, others will be able to help you spot things.  As
long as you're working toward making it better, I don't think anyone minds
having ports that are "in progress" in the tree.

Thanks,
Myles

[Patrick Georgi]

Am 25.01.2010 17:13, schrieb Knut Kujat:
> booting interrupts for about 4 minutes on "Stage: loading
>
> fallback/coreboot_ram @ 0x200000 (360448 bytes), entry @ 0x200000"

For this issue, the following change might help:
--- src/cpu/amd/mtrr/amd_earlymtrr.c    (revision 5054)
+++ src/cpu/amd/mtrr/amd_earlymtrr.c    (working copy)
@@ -45,8 +45,13 @@
         /* enable write through caching so we can do execute in place
          * on the flash rom.
          */
-        set_var_mtrr(1, CONFIG_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
MTRR_TYPE_WRBACK);
+#if defined(CONFIG_TINY_BOOTBLOCK) && CONFIG_TINY_BOOTBLOCK
+#define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE
+#else
+#define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
 #endif
+        set_var_mtrr(1, REAL_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
MTRR_TYPE_WRBACK);
+#endif

/* Set the default memory type and enable fixed and variable MTRRs
          */

If it does, please let us know, so we can add it to the tree.

Regards,
Patrick

[Knut Kujat]

Patrick Georgi escribió:
> Am 25.01.2010 17:13, schrieb Knut Kujat:
> > booting interrupts for about 4 minutes on "Stage: loading
> >
> > fallback/coreboot_ram @ 0x200000 (360448 bytes), entry @ 0x200000"
>
> For this issue, the following change might help:
> --- src/cpu/amd/mtrr/amd_earlymtrr.c    (revision 5054)
> +++ src/cpu/amd/mtrr/amd_earlymtrr.c    (working copy)
> @@ -45,8 +45,13 @@
>          /* enable write through caching so we can do execute in place
>           * on the flash rom.
>           */
>    set_var_mtrr(1, CONFIG_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
>
> MTRR_TYPE_WRBACK);
> +#if defined(CONFIG_TINY_BOOTBLOCK) && CONFIG_TINY_BOOTBLOCK
> +#define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE
> +#else
> +#define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
>  #endif
>    set_var_mtrr(1, REAL_XIP_ROM_BASE, CONFIG_XIP_ROM_SIZE,
>
> MTRR_TYPE_WRBACK);
> +#endif
>      /* Set the default memory type and enable fixed and variable MTRRs
>       */
>
> If it does, please let us know, so we can add it to the tree.
>
> Regards,
> Patrick

Hello,

#if defined(CONFIG_XIP_ROM_SIZE)
         /* enable write through caching so we can do execute in place
          * on the flash rom.
          */
         #if defined(CONFIG_TINY_BOOTBLOCK) && CONFIG_TINY_BOOTBLOCK
           #define REAL_XIP_ROM_BASE AUTO_XIP_ROM_BASE
         #else
           #define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
         #endif
         set_var_mtrr(1, REAL_XIP_ROM_BASE,
CONFIG_XIP_ROM_SIZE,MTRR_TYPE_WRBACK);

#endif

It still hangs at

"Stage: loading
fallback/coreboot_ram @ 0x200000 (360448 bytes), entry @ 0x200000"

for exactly 2min 28sec so I think it speed up a little :).

Thanks I really appreciate your help.

Knut Kujat.

[Peter Stuge]

Knut Kujat wrote:
> Now, when I'm trying to test my memory with Memtest86+ it doesn't
> starts!

How are you trying to start it?
> I know there is a payload with Memtest86+ I haven't tried yet
> but I just don't think it will make any difference, won't it?

Using memtest as payload is the only way I have tried, and it works
for me. Feel free to grab http://stuge.se/memtest.elf and try if
using that as payload works any better.

//Peter