[coreboot] [patch] RE: Fam10 breakage

Bao, Zheng Zheng.Bao at amd.com
Fri Feb 26 03:48:57 CET 2010


It is about the bug in the gnu linker. It seems to be ridiculous.

It can be tested by a small program.

 

In the ld script, if the expression is located in a section, like

   .stack . : {

        EXPRESSION;

   }

the symbol and constant can not be in the expression at the same time,

like:

      . = CONFIG_STACK_SIZE * 2;

or:

      CONFIG_RAMBASE<0x100000 ? xxxxx : yyyyy;

 

This bug leads to the fact that we can not allocate enough space of

stack for each core. Then the data in the memory will be covered by AP

stack which doesnt know anything.

 

That is the fact I can find. It is a bug in the linker. But we can not

fix each linker on coreboot developer, not to mention the fact I have

no idea how to submit the bug. The bug will be fixed in the

future. But when the fixed linker will come into our machine? So I

believe we need the workaround patch to avoid this problem.

 

Signed-off-by: Zheng Bao <zheng.bao at amd.com>

 

 

Index: src/arch/i386/coreboot_ram.ld

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

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

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

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

      _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. When the bug is
fixed

+     * on almost every machine, Please change it back */

+     . += ((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 . : {

 

 

 

________________________________

From: Myles Watson [mailto:mylesgw at gmail.com] 
Sent: Thursday, February 25, 2010 11:11 PM
To: Bao, Zheng; Timothy Pearson
Cc: coreboot
Subject: Re: [coreboot] Fam10 breakage

 

 

On Wed, Feb 24, 2010 at 6:46 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:

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

It fixes it for me, and fixes the APIC enumeration problem that Timothy
Pearson was seeing.  I hadn't seen it before, but now that it's fixed I
see a line like this:

Unknown device path type: 0

So the device tree was getting corrupted.

I'd like to understand better why it fixes it.

Zheng:
Could you commit the whitespace changes and then submit the patch to
make it clearer?

Thanks,
Myles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100226/a91ce0f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workaround_gnu_linker_bug.patch
Type: application/octet-stream
Size: 2070 bytes
Desc: workaround_gnu_linker_bug.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100226/a91ce0f5/attachment.obj>


More information about the coreboot mailing list