[coreboot] Fam10 breakage

[Bao, Zheng]

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 at coreboot.org
[mailto:coreboot-bounces at 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 at gmail.com> wrote:

 

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

 

On Wed, Feb 24, 2010 at 2:27 PM, Myles Watson <mylesgw at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100225/a4e08afc/attachment.html>