It doesn't matter whether it is a huge stack. The _estack - _stack should be MAX_CPUS * STACK_SIZE. The MAX_CPU could be set as 4, and STACK_SIZE could be 0x2000. So the stack is only 0x8000. Is it huge? But checking my coreboot_ram.map, _estack - _stack is only ONE STACK_SIZE. But the loader has no idea about that. The stack will overlap other section of data. I believe many other build machine will produce the same result with me.
I have tried compiling with the reference cross compiler from util/crossgcc, and it make no difference.
Zheng
________________________________________ From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Myles Watson Sent: Sunday, February 28, 2010 12:41 PM To: Zheng Bao Cc: coreboot@coreboot.org Subject: Re: [coreboot] [patch] RE: Fam10 breakage
2010/2/27 Zheng Bao fishbaoz@hotmail.com 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? 002284a0 A _ebss 002284a0 A _end 00230000 A _stack 00530000 A _estack 00530000 A _heap 005f0000 A _eheap 005f0000 A _eram_seg
So it worked for me.
I think we should just get rid of the complexity. I don't think there are any boards with lots of APs and huge stack needs that start below 1M, so the check that is breaking for you doesn't help anyone.
Thanks, Myles