I am pretty sure that you meet the same the same problem.

It seems to be ridiculous. Please check the maillist about this issue.

http://www.coreboot.org/pipermail/coreboot/2010-February/055730.html

If everything goes as I expected, the following patch can fix your problem

at any revision.

Zheng

Index: src/arch/i386/coreboot_ram.ld

===================================================================

--- src/arch/i386/coreboot_ram.ld   (revision 5153)

+++ src/arch/i386/coreboot_ram.ld   (working copy)

@@ -1,7 +1,7 @@

 /*

  *   Memory map:

  *

- *   CONFIG_RAMBASE         

+ *   CONFIG_RAMBASE

  *                     : data segment

  *                     : bss segment

  *                     : heap

@@ -19,7 +19,7 @@

  */

 /*

  *   We use ELF as output format. So that we can

- *   debug the code in some form.

+ *   debug the code in some form.

  */

 INCLUDE ldoptions

@@ -62,7 +62,7 @@

             . = ALIGN(4);

            _erodata = .;

-     }    

+     }

      /*

       * After the code we place initialized data (typically initialized

       * global variables). This gets copied into ram by startup code.

@@ -101,11 +101,10 @@

      _end = .;

      . = ALIGN(CONFIG_STACK_SIZE);

      _stack = .;

-     .stack . : {

-           /* Reserve a stack for each possible cpu */

-           /* the stack for ap will be put after pgtbl in 1M to CONFIG_RAMTOP range when VGA and ROM_RUN and CONFIG_RAMTOP>1M*/

-           . = ((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&(CONFIG_RAMTOP>0x100000) ) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);

-     }

+     /* Reserve a stack for each possible cpu */

+     /* the stack for ap will be put after pgtbl in 1M to CONFIG_RAMTOP range when VGA and ROM_RUN and CONFIG_RAMTOP>1M*/

+     /* TODO: workaround for the bug of GNU linker. */

+     . += ((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&(CONFIG_RAMTOP>0x100000) ) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);

      _estack = .;

         _heap = .;

         .heap . : {

@@ -117,7 +116,7 @@

      /* The ram segment

       * This is all address of the memory resident copy of coreboot.

*/

-     _ram_seg = _text;

+     _ram_seg = _text;

_eram_seg = _eheap;

      _bogus = ASSERT( ( _eram_seg < (CONFIG_RAMTOP)) , "please increase CONFIG_RAMTOP");

---

From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Myles Watson
Sent: Thursday, February 25, 2010 6:48 AM
To: coreboot
Subject: Re: [coreboot] Fam10 breakage

On Wed, Feb 24, 2010 at 3:02 PM, Myles Watson <mylesgw@gmail.com> wrote:

On Wed, Feb 24, 2010 at 2:34 PM, Myles Watson <mylesgw@gmail.com> wrote:

On Wed, Feb 24, 2010 at 2:27 PM, Myles Watson <mylesgw@gmail.com> wrote:

Rev 5132 works for me on SimNOW with 1 fam10 processor.

Current head gets stuck in an infinite loop setting fixed MTRRs.

Any clues while I'm bisecting?

So far the only difference before the failure is the location of the CBFS header:
Check CBFS header at fffeffe0 (working)
Check CBFS header at ffffff68a (broken)

That's not it, because that changes later.

Rev 5135 works Rev 5139 is broken.

Rev 5136-5138 don't build.  Rev 5136 is pretty big, and I don't see anything that's obviously related to MTRRs.

Interestingly enough, 5150 fixes it.  Then 5152 breaks it a different way.

Since the commit message from 5152 is:

     Remove nonsensical wrapper for function in
     PS/2 keyboard API. 

I guess it's probably some kind of stack corruption.  Something makes it very fragile.

Suggestions welcome.

Thanks,
Myles