<br><br><div class="gmail_quote">On Fri, Feb 26, 2010 at 5:56 AM, Patrick Georgi <span dir="ltr"><<a href="mailto:patrick@georgi-clan.de">patrick@georgi-clan.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am 26.02.2010 03:48, schrieb Bao, Zheng:<br>
<div class="im">> This bug leads to the fact that we can not allocate enough space of<br>
> stack for each core. Then the data in the memory will be covered by AP<br>
> stack which doesnt know anything.<br>
><br>
> That is the fact I can find. It is a bug in the linker. But we can not<br>
> fix each linker on coreboot developer, not to mention the fact I have<br>
> no idea how to submit the bug. The bug will be fixed in the<br>
> future. But when the fixed linker will come into our machine? So I<br>
> believe we need the workaround patch to avoid this problem.<br>
</div>Just to make sure what the patch does: It simply removes the separate<br>
section and reserves an area at the same place, of the same size, just<br>
in a way that works with the linker?<br></blockquote><div>I would like to double check this before it gets committed.  I only tried it once, and the difference was very large.  3M of stack doesn't seem right.<br><br>
diff -urN 5152/coreboot_ram.map build/coreboot_ram.map<br>--- 5152/coreboot_ram.map    2010-02-24 16:05:19.000000000 -0700<br>+++ build/coreboot_ram.map    2010-02-25 08:11:33.000000000 -0700<br>
@@ -924,10 +924,10 @@<br> 002284a0 A _ebss<br> 002284a0 A _end<br> 00230000 A _stack<br>-00240000 A _estack<br>-00240000 A _heap<br>-00300000 A _eheap<br>-00300000 A _eram_seg<br>+00530000 A _estack<br>+00530000 A _heap<br>

+005f0000 A _eheap<br>+005f0000 A _eram_seg<br> 01000000 A CONFIG_RAMTOP<br> 04000000 A CONFIG_AGP_APERTURE_SIZE<br> fff80000 A CONFIG_XIP_ROM_BASE <br><br>Thanks,<br>Myles<br></div><div> </div></div><br>