[coreboot] (bug in toochains?) Data in memory changes unexpectedly ininitialize_cpus
Bao, Zheng
Zheng.Bao at amd.com
Sat Feb 20 04:09:43 CET 2010
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 at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Zheng Bao
Sent: Sunday, February 14, 2010 10:12 AM
To: marcj303 at gmail.com
Cc: coreboot at 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 at gmail.com
> To: fishbaoz at hotmail.com
> CC: coreboot at coreboot.org
>
> 2010/2/12 Zheng Bao <fishbaoz at hotmail.com>:
> >
> >
> >> Date: Fri, 12 Feb 2010 16:54:43 -0700
> >> From: marcj303 at gmail.com
> >> To: Zheng.Bao at amd.com
> >> CC: coreboot at coreboot.org
> >> Subject: Re: [coreboot] Data in memory changes unexpectedly
> >> ininitialize_cpus
> >>
> >> On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <marcj303 at gmail.com>
wrote:
> >> > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <Zheng.Bao at 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
>
> --
> http://se-eng.com
________________________________
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign
up now. <https://signup.live.com/signup.aspx?id=60969>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100220/5e66715b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.tgz
Type: application/x-compressed
Size: 961 bytes
Desc: test.tgz
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20100220/5e66715b/attachment.bin>
More information about the coreboot
mailing list