I am debugging the fam10+RS780+SB700. Now I am facing a problem which troubles me for quite a long time. It came up since CBFS play its role. The data in memory changes unexpectedly. The printk_debug can not help to narrow down the point where the writing happens.
So I set the memory address which changes during booting as a breakpoint trigger. Anyone writes data to this address will cause a breakpoint. But unfortunately nothing can be captured. So I had to set breakpoint in the whole process to narrow down. Now I narrow down to the initialize_cpus in src/cpu/x86/lapic/. The functions called in initialize_cpus are static which can not find a symbol in the coreboot.map. I need to disassemble the binary to find out why. Before that, I need to guess what on earth happens.
It seems to have something to do with the SMP. It seems that other cores write data into the memory which is not belong to them. Do you think it can happen?
Zheng
Am 10.02.2010 11:24, schrieb Bao, Zheng:
I am debugging the fam10+RS780+SB700. Now I am facing a problem which troubles me for quite a long time. It came up since CBFS play its role. The data in memory changes unexpectedly. The printk_debug can not help to narrow down the point where the writing happens.
So I set the memory address which changes during booting as a breakpoint trigger. Anyone writes data to this address will cause a breakpoint. But unfortunately nothing can be captured. So I had to set breakpoint in the whole process to narrow down. Now I narrow down to the initialize_cpus in src/cpu/x86/lapic/. The functions called in initialize_cpus are static which can not find a symbol in the coreboot.map. I need to disassemble the binary to find out why. Before that, I need to guess what on earth happens.
It seems to have something to do with the SMP. It seems that other cores write data into the memory which is not belong to them. Do you think it can happen?
Can you narrow down a bit what kind of data is overwritten there?
The only thing related to SMP that I can think of is stacks and CBFS loading. For both it might (but should not) happen that multiple cores try to do the same thing and overwrite each other's data.
Stacks seem fine in AMD code (from a short look), you could try to look what the APs so once they are started. cbfs might happen early, and we need to change things there, eg. have the BSP decompress the AP code once, before starting the APs, instead of the APs, which would require locking to not stumble over each other.
Patrick
I finally find out why. Your suggestion is quite usefull. The stack size is not set correctly. Each core should get 0x2000 bytes as its own stack. But the whole stack size is only 0x2000. So the stacks for AP overlap with the BSS/DATA of the BSP. I will find a solution. Now I can have a relaxed Chinese New Year. Oops.
Zheng
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Wednesday, February 10, 2010 6:52 PM To: coreboot@coreboot.org Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
Am 10.02.2010 11:24, schrieb Bao, Zheng:
I am debugging the fam10+RS780+SB700. Now I am facing a problem which troubles me for quite a long time. It came up since CBFS play its
role.
The data in memory changes unexpectedly. The printk_debug can not help to narrow down the point where the writing happens.
So I set the memory address which changes during booting as a
breakpoint
trigger. Anyone writes data to this address will cause a breakpoint.
But
unfortunately nothing can be captured. So I had to set breakpoint in
the
whole process to narrow down. Now I narrow down to the initialize_cpus in src/cpu/x86/lapic/. The functions called in initialize_cpus are static which can not find a symbol in the coreboot.map. I need to disassemble the binary to find out why. Before that, I need to guess what on earth happens.
It seems to have something to do with the SMP. It seems that other
cores
write data into the memory which is not belong to them. Do you think
it
can happen?
Can you narrow down a bit what kind of data is overwritten there?
The only thing related to SMP that I can think of is stacks and CBFS loading. For both it might (but should not) happen that multiple cores try to do the same thing and overwrite each other's data.
Stacks seem fine in AMD code (from a short look), you could try to look what the APs so once they are started. cbfs might happen early, and we need to change things there, eg. have the BSP decompress the AP code once, before starting the APs, instead of the APs, which would require locking to not stumble over each other.
Patrick
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.
Zheng
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Bao, Zheng Sent: Thursday, February 11, 2010 6:26 PM To: Patrick Georgi; coreboot@coreboot.org Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
I finally find out why. Your suggestion is quite usefull. The stack size is not set correctly. Each core should get 0x2000 bytes as its own stack. But the whole stack size is only 0x2000. So the stacks for AP overlap with the BSS/DATA of the BSP. I will find a solution. Now I can have a relaxed Chinese New Year. Oops.
Zheng
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Patrick Georgi Sent: Wednesday, February 10, 2010 6:52 PM To: coreboot@coreboot.org Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
Am 10.02.2010 11:24, schrieb Bao, Zheng:
I am debugging the fam10+RS780+SB700. Now I am facing a problem which troubles me for quite a long time. It came up since CBFS play its
role.
The data in memory changes unexpectedly. The printk_debug can not help to narrow down the point where the writing happens.
So I set the memory address which changes during booting as a
breakpoint
trigger. Anyone writes data to this address will cause a breakpoint.
But
unfortunately nothing can be captured. So I had to set breakpoint in
the
whole process to narrow down. Now I narrow down to the initialize_cpus in src/cpu/x86/lapic/. The functions called in initialize_cpus are static which can not find a symbol in the coreboot.map. I need to disassemble the binary to find out why. Before that, I need to guess what on earth happens.
It seems to have something to do with the SMP. It seems that other
cores
write data into the memory which is not belong to them. Do you think
it
can happen?
Can you narrow down a bit what kind of data is overwritten there?
The only thing related to SMP that I can think of is stacks and CBFS loading. For both it might (but should not) happen that multiple cores try to do the same thing and overwrite each other's data.
Stacks seem fine in AMD code (from a short look), you could try to look what the APs so once they are started. cbfs might happen early, and we need to change things there, eg. have the BSP decompress the AP code once, before starting the APs, instead of the APs, which would require locking to not stumble over each other.
Patrick
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);
Marc
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
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?
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
_________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969
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
I buillt svn head of serengeti_cheetah_fam10.
Marc
Zheng,
can you try if the RS780 code works with a uniprocessor K8 (not Fam10) CPU? Maybe that gives us a better baseline for testing.
Regards, Carl-Daniel
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. https://signup.live.com/signup.aspx?id=60969
2010/2/13 Zheng Bao fishbaoz@hotmail.com:
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.
OK, I changed the stack size in the platform Kconfig to match newconfig setting. The results are:
00002000 A CONFIG_STACK_SIZE
0022a000 A _stack 0022c000 A _estack 0022c000 A _heap 002ec000 A _eheap 002ec000 A _eram_seg 01000000 A CONFIG_RAMTOP
I sent a the patch to the ist in a new thread.
Marc
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
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@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
Am Samstag, den 20.02.2010, 11:09 +0800 schrieb Bao, Zheng:
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?
I get the same results on my system.
$ diff test.map.orig test.map $ grep _stack* test.map 00100000 A _stackbbbb 00400000 A _stackaaaa
$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-2' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-2)
$ ld -v GNU ld (GNU Binutils for Debian) 2.20
What version do you use?
Do you think it is bug in binutils?
I do not know. Is someone subscribed to bug-binutils@gnu.org [1] and can ask there with a reference to this thread [2]?
[…]
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.
Is AMD using Hotmail?
Thanks,
Paul
[1] http://www.gnu.org/software/binutils/ [2] http://www.coreboot.org/pipermail/coreboot/2010-February/055903.html
My gcc and binutils is in FC11 distribution:
[/home/baozheng]$ gcc -v Using built-in specs. Target: i586-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i586 --build=i586-redhat-linux Thread model: posix gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC)
[/home/baozheng]$ ld -v GNU ld version 2.19.51.0.2-17.fc11 2009020
I just had vocation at home and sent mail by hotmail.
Zheng
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Paul Menzel Sent: Sunday, February 21, 2010 2:48 AM To: coreboot@coreboot.org Subject: Re: [coreboot] (bug in toolchains?) Data in memory changes unexpectedly ininitialize_cpus
Am Samstag, den 20.02.2010, 11:09 +0800 schrieb Bao, Zheng:
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?
I get the same results on my system.
$ diff test.map.orig test.map $ grep _stack* test.map 00100000 A _stackbbbb 00400000 A _stackaaaa
$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-2' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-2)
$ ld -v GNU ld (GNU Binutils for Debian) 2.20
What version do you use?
Do you think it is bug in binutils?
I do not know. Is someone subscribed to bug-binutils@gnu.org [1] and can ask there with a reference to this thread [2]?
[...]
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now.
Is AMD using Hotmail?
Thanks,
Paul
[1] http://www.gnu.org/software/binutils/ [2] http://www.coreboot.org/pipermail/coreboot/2010-February/055903.html
Assuming it is a real bug, it really hurts my fam10 board and my feeling. Even if it is submitted as a bug, it needs quite a long time to reach our every building machine. So I think we need a workaround patch. I will do it if more than 5 guys agree with me.
Zheng
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Bao, Zheng Sent: Sunday, February 21, 2010 10:39 AM To: coreboot@coreboot.org Subject: Re: [coreboot] (bug in toolchains?) Data in memory changesunexpectedly ininitialize_cpus
My gcc and binutils is in FC11 distribution:
[/home/baozheng]$ gcc -v Using built-in specs. Target: i586-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i586 --build=i586-redhat-linux Thread model: posix gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC)
[/home/baozheng]$ ld -v GNU ld version 2.19.51.0.2-17.fc11 2009020
I just had vocation at home and sent mail by hotmail.
Zheng
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Paul Menzel Sent: Sunday, February 21, 2010 2:48 AM To: coreboot@coreboot.org Subject: Re: [coreboot] (bug in toolchains?) Data in memory changes unexpectedly ininitialize_cpus
Am Samstag, den 20.02.2010, 11:09 +0800 schrieb Bao, Zheng:
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?
I get the same results on my system.
$ diff test.map.orig test.map $ grep _stack* test.map 00100000 A _stackbbbb 00400000 A _stackaaaa
$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-2' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-2)
$ ld -v GNU ld (GNU Binutils for Debian) 2.20
What version do you use?
Do you think it is bug in binutils?
I do not know. Is someone subscribed to bug-binutils@gnu.org [1] and can ask there with a reference to this thread [2]?
[...]
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now.
Is AMD using Hotmail?
Thanks,
Paul
[1] http://www.gnu.org/software/binutils/ [2] http://www.coreboot.org/pipermail/coreboot/2010-February/055903.html
-
Bao, Zheng -
Carl-Daniel Hailfinger -
Marc Jones -
Matthias Wenzel -
Patrick Georgi -
Paul Menzel -
Zheng Bao