-----Original Message----- From: Maximilian Thuermer [mailto:Maximilian.Thuermer@ziti.uni- heidelberg.de] Sent: Wednesday, November 04, 2009 4:53 AM To: Myles Watson Subject: failing fam10 code in coreboot
Myles,
sorry it took so long to get back to you. I checked revs 4787 and 4788 and attached the significant parts of the logs. You were right with the assumption that the problem first occured in rev 4788. I also attached the coreboot_ram.map files. Hope this helps tracking down the bug...
Best regards,
Maximilian
Myles Watson wrote:
I did a fresh svn co the other day and tried building and running a Tyan S2912_fam10 system. With older sources (rev 4729) everything worked just fine, with the newest checkout the booting process stops at setting MTRR registers or a little later (depending on the compiler used: 3.4.6 builds faster code and gets further than 4.3.3, both Ubuntu fashion). I tried tracking down the problem and it appeared to me as if the switch from CONFIG_LB_MEM_TOPK to CONFIG_RAMTOP
It's possible. Could you try Rev 4787 & 4788 to make sure, then send me
the
logs from both? I'm also interested in the coreboot_ram.map files.
That's really weird. It looks like memory corruption, because CONFIG_RAMTOP (the top of memory that coreboot_ram can use) shouldn't affect the variable MTRR setup for the top of real RAM.
I'm surprised that there was a difference in the coreboot_ram.map file too. I don't see how the changes affected the length of the stack!
Which toolchain did you use to build these two? Are you using Kconfig or ./buildtarget?
Can you try making the stack a lot bigger and seeing if that helps?
CONFIG_STACK_SIZE is now 8K, but try 64K. (0x10000)
I can't see why CONFIG_RAMTOP is 16M. Your coreboot_ram.map file says you could fit under 2M. That might not be true with a 64K stack, but for sure 4M.
Thanks, Myles