[coreboot] Data in memory changes unexpectedly ininitialize_cpus

[Marc Jones]

2010/2/13 Zheng Bao <fishbaoz at hotmail.com>:
>
>
>> 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.

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