[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