Data in memory changes unexpectedly in initialize_cpus

[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?


Zheng

Data in memory changes unexpectedly in initialize_cpus

[Patrick Georgi]

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

Data in memory changes unexpectedly ininitialize_cpus

[Bao, Zheng]

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Patrick Georgi
Sent: Wednesday, February 10, 2010 6:52 PM
To: [e-mail]
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

-- 
coreboot mailing list: [e-mail]
http://www.coreboot.org/mailman/listinfo/coreboot

Data in memory changes unexpectedly ininitialize_cpus

[Bao, Zheng]

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Bao, Zheng
Sent: Thursday, February 11, 2010 6:26 PM
To: Patrick Georgi; [e-mail]
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: [e-mail]
[mailto:[e-mail]] On Behalf Of Patrick Georgi
Sent: Wednesday, February 10, 2010 6:52 PM
To: [e-mail]
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

-- 
coreboot mailing list: [e-mail]
http://www.coreboot.org/mailman/listinfo/coreboot



-- 
coreboot mailing list: [e-mail]
http://www.coreboot.org/mailman/listinfo/coreboot

Data in memory changes unexpectedly ininitialize_cpus

[Marc Jones]

On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]> 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

-- 
http://se-eng.com

Data in memory changes unexpectedly ininitialize_cpus

[Marc Jones]

On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]> wrote:
> On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]> 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




-- 
http://se-eng.com

Data in memory changes unexpectedly ininitialize_cpus

[Zheng Bao]

> Date: Fri, 12 Feb 2010 16:54:43 -0700
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
>
> On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]> wrote:
> > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]> 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?
>

_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
https://signup.live.com/signup.aspx?id=60969

Data in memory changes unexpectedly ininitialize_cpus

[Marc Jones]

2010/2/12 Zheng Bao <[e-mail]>:
> > Date: Fri, 12 Feb 2010 16:54:43 -0700
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > ininitialize_cpus
> >
> > On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]> wrote:
> > > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]> 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

-- 
http://se-eng.com

Data in memory changes unexpectedly ininitialize_cpus

[Carl-Daniel Hailfinger]

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

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."

Data in memory changes unexpectedly ininitialize_cpus

[Zheng Bao]

> Date: Sat, 13 Feb 2010 11:23:49 -0700
> Subject: Re: [coreboot] Data in memory changes unexpectedly ininitialize_cpus
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
>
> 2010/2/12 Zheng Bao <[e-mail]>:
> > > Date: Fri, 12 Feb 2010 16:54:43 -0700
> > > From: [e-mail]
> > > To: [e-mail]
> > > CC: [e-mail]
> > > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > > ininitialize_cpus
> > >
> > > On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]> wrote:
> > > > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]> 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

Data in memory changes unexpectedly ininitialize_cpus

[Marc Jones]

2010/2/13 Zheng Bao <[e-mail]>:
> > Date: Sat, 13 Feb 2010 11:23:49 -0700
> > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > ininitialize_cpus
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> >
> > 2010/2/12 Zheng Bao <[e-mail]>:
> > > > Date: Fri, 12 Feb 2010 16:54:43 -0700
> > > > From: [e-mail]
> > > > To: [e-mail]
> > > > CC: [e-mail]
> > > > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > > > ininitialize_cpus
> > > >
> > > > On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]> wrote:
> > > > > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]>
> > > > > 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

-- 
http://se-eng.com

(bug in toochains?) Data in memory changes unexpectedly ininitialize_cpus

[Bao, Zheng]

> Date: Sat, 13 Feb 2010 11:23:49 -0700
> Subject: Re: [coreboot] Data in memory changes unexpectedly
> ininitialize_cpus
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
>
> 2010/2/12 Zheng Bao <[e-mail]>:
> > > Date: Fri, 12 Feb 2010 16:54:43 -0700
> > > From: [e-mail]
> > > To: [e-mail]
> > > CC: [e-mail]
> > > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > > ininitialize_cpus
> > >
> > > On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]>
>
> wrote:
> > > > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]>
> > > > 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

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Zheng Bao
Sent: Sunday, February 14, 2010 10:12 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [coreboot] Data in memory changes unexpectedly
ininitialize_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>

(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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Zheng Bao
> Sent: Sunday, February 14, 2010 10:12 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [coreboot] Data in memory changes unexpectedly
> ininitialize_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
> > Date: Sat, 13 Feb 2010 11:23:49 -0700
> > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > ininitialize_cpus
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> >
> > 2010/2/12 Zheng Bao <[e-mail]>:
> > > > Date: Fri, 12 Feb 2010 16:54:43 -0700
> > > > From: [e-mail]
> > > > To: [e-mail]
> > > > CC: [e-mail]
> > > > Subject: Re: [coreboot] Data in memory changes unexpectedly
> > > > ininitialize_cpus
> > > >
> > > > On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones <[e-mail]>
> >
> > wrote:
> > > > > On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng <[e-mail]>
> > > > > 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
>
> 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>

(bug in toolchains?) Data in memory changes unexpectedly ininitialize_cpus

[Paul Menzel]

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 [e-mail] [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

(bug in toolchains?) Data in memory changes unexpectedly ininitialize_cpus

[Bao, Zheng]

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Paul Menzel
Sent: Sunday, February 21, 2010 2:48 AM
To: [e-mail]
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 [e-mail] [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

(bug in toolchains?) Data in memory changesunexpectedly ininitialize_cpus

[Bao, Zheng]

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Bao, Zheng
Sent: Sunday, February 21, 2010 10:39 AM
To: [e-mail]
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: [e-mail]
[mailto:[e-mail]] On Behalf Of Paul Menzel
Sent: Sunday, February 21, 2010 2:48 AM
To: [e-mail]
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 [e-mail] [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


-- 
coreboot mailing list: [e-mail]
http://www.coreboot.org/mailman/listinfo/coreboot