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@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@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@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