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: [email protected] [mailto:[email protected]] On Behalf Of Myles Watson Sent: Sunday, February 28, 2010 12:41 PM To: Zheng Bao Cc: [email protected] Subject: Re: [coreboot] [patch] RE: Fam10 breakage 2010/2/27 Zheng Bao <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
