Have you tried compiling with the reference cross compiler from util/ crossgcc?
Stefan
On 28.02.2010, at 04:52, Zheng Bao fishbaoz@hotmail.com wrote:
Unfortunately, it doesn't fix my problem here. It is the coreboot_ram.map of serengeti_cheetah_fam10 built on my machine. The _estack is not what we expect. Myles, what is the result at you machine?
00000030 A CONFIG_MAX_CPUS ............... 00002000 A CONFIG_STACK_SIZE ............... 00228550 A _ebss 00228550 A _end 0022a000 A _stack 0022c000 A _estack 0022c000 A _heap 002ec000 A _eheap 002ec000 A _eram_seg 01000000 A CONFIG_RAMTOP 04000000 A CONFIG_AGP_APERTURE_SIZE fff80000 A CONFIG_XIP_ROM_BASE ffff0000 A CONFIG_ROMBASE
Zheng
Date: Fri, 26 Feb 2010 13:32:49 -0700 From: mylesgw@gmail.com To: patrick@georgi-clan.de CC: coreboot@coreboot.org Subject: Re: [coreboot] [patch] RE: Fam10 breakage
On Fri, Feb 26, 2010 at 1:24 PM, Patrick Georgi <patrick@georgi-clan.de
wrote:
Am 26.02.2010 16:35, schrieb Myles Watson:
For me, the only change that needs to be made is:
. = ((CONFIG_CONSOLE_VGA ||CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&
(CONFIG_RAMTOP>0x100000)
) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);
. += ((CONFIG_CONSOLE_VGA ||CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x100000)&&
(CONFIG_RAMTOP>0x100000)
) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);
Removing the .stack construct makes no difference.
I like the idea of minimizing the change.
Sounds good, and should be stable (unless that's part of the bug Zheng Bao is experiencing).
I'd say, commit this (as it fixes things for you). If it's not enough, we can do the full change. Great.
Acked-by: Patrick Georgi patrick.georgi@coresystems.de Rev 5166.
Thanks, Myles
Hotmail: Trusted email with powerful SPAM protection. Sign up now.
coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot