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: [email protected]
[mailto:[email protected]] On Behalf Of Zheng Bao
Sent: Sunday, February 14, 2010 10:12 AM
To: [email protected]
Cc: [email protected]
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: [email protected]
> To: [email protected]
> CC: [email protected]
>
> 2010/2/12 Zheng Bao <[email protected]>:
> >
> >
> >> Date: Fri, 12 Feb 2010 16:54:43 -0700
> >> From: [email protected]
> >> To: [email protected]
> >> CC: [email protected]
> >> Subject: Re: [coreboot] Data in memory changes unexpectedly
> >> ininitialize_cpus
> >>
> >> On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[email protected]>
wrote:
> >> > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[email protected]>
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
>
> --
> http://se-eng.com
________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign
up now. <https://signup.live.com/signup.aspx?id=60969>
test.tgz
Description: test.tgz
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
