I have narrowed my problem to a small test
project. It is quite easy for you to do a quick test.
Please check the test.map, and you will find
the sizes of stackbbbb and stackaaa are different. But
the only difference in the coreboot_ram.ld is CONFIG_MAX_CPU
in stackbbbb and a constant in stackaaaa. Can you guys build
the project on your machine to see if you can get the same
result with me? Do you think it is bug in binutils?
Coreboot_ram.ld:
/* INCLUDE ldoptions */
/* ENTRY(_start) */
SECTIONS
{
CONFIG_STACK_SIZE = 0x00000002 ;
CONFIG_MAX_CPU = 2;
. = 0x100000 ;
_stackbbbb = . ;
.stackbbbb . : {
. = ((CONFIG_STACK_SIZE) * CONFIG_MAX_CPU);
}
_estackbbbb = . ;
_text = . ;
.text . : {
*(.text) ;
}
_etext = . ;
/*. = ALIGN(0x10000);*/
. = 0x400000 ;
_stackaaaa = . ;
.stackaaaa . : {
. = ((CONFIG_STACK_SIZE) * 2);
}
_estackaaaa = . ;
.data : {
_data = . ;
*(.data) ;
_edata = . ;
}
/DISCARD/ : {
*(.comment)
*(.note)
*(.note.*)
}
}
My test.map:
00000002 A CONFIG_MAX_CPU
00000002 A CONFIG_STACK_SIZE
00100000 A _stackbbbb
00100004 A _estackbbbb
00100004 A _text
00100004 t test
00100016 T main
0010002c A _etext
00400000 A _stackaaaa
00c00004 A _estackaaaa
00c00004 B _data
00c00004 B _edata
________________________________
From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Zheng Bao Sent: Sunday, February 14, 2010 10:12 AM To: marcj303@gmail.com Cc: coreboot@coreboot.org Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
Date: Sat, 13 Feb 2010 11:23:49 -0700 Subject: Re: [coreboot] Data in memory changes unexpectedly
ininitialize_cpus
From: marcj303@gmail.com To: fishbaoz@hotmail.com CC: coreboot@coreboot.org
2010/2/12 Zheng Bao fishbaoz@hotmail.com:
Date: Fri, 12 Feb 2010 16:54:43 -0700 From: marcj303@gmail.com To: Zheng.Bao@amd.com CC: coreboot@coreboot.org Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones marcj303@gmail.com
wrote:
On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng Zheng.Bao@amd.com
wrote:
I kept on finding the problem. Now it is narrowed down to the
line 108,
src/arch/i386/coreboot_ram.ld. It is very, very, very, very
confused.
My CONFIG_RAMBASE should be 0x200000, which is more than
0x100000, but
the location counter "." is CONFIG_STACK_SIZE. Even if I
manually set
". = CONFIG_STACK_SIZE * 2 ;", I can not get the correct size.
But if I
set ". = 0x2000 * 2 ;", or ". = CONFIG_STACK_SIZE << 1", it is
right. I
kinda doubt the compiler and linker.
Can you try it on your building machine? Just try the Serengeti_cheetah_fam10 and don't need the hardware. Just check
the
build/coreboot_ram.map to see if the _estack - _stack is
multiple of
CONFIG_STACK_SIZE. That problem should happen on all the fam10
board if
it is built on my building machine.
Is this due to the hard coded values in lapic_cpu_init. I don't
really
understand the comment or what it is doing. I would expect the AP stacks to be setup based on estack as well.
// for all APs, let use stack after pgtbl, 20480 is the pgtbl
size for
every cpu stack_end = 0x100000+(20480 + CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS
-
(CONFIG_STACK_SIZE*index);
This is what I get in my map file. It seems reasonable.
00230000 A _stack 00238000 A _estack 00238000 A _heap 002f8000 A _eheap 002f8000 A _eram_seg 01000000 A CONFIG_RAMTOP
what is the CONFIG_STACK_SIZE in your map file?
00008000 A CONFIG_STACK_SIZE
This is not right.
I buillt svn head of serengeti_cheetah_fam10.
Marc
________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now. https://signup.live.com/signup.aspx?id=60969