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