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

-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot



-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot