[coreboot] (bug in toochains?) Data in memory changes unexpectedly ininitialize_cpus

[Matthias Wenzel]

Same here:
only this irrelevant diff
$ diff test.map.orig test.map
8c8
< 0010002c A _etext
---
> 0010003e A _etext


$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)


best,

matthias



Bao, Zheng wrote:
> 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> 
> 
> 
>