[coreboot] failing fam10 code in coreboot
mylesgw at gmail.com
Wed Nov 4 19:53:17 CET 2009
> -----Original Message-----
> From: Maximilian Thuermer [mailto:Maximilian.Thuermer at ziti.uni-
> Sent: Wednesday, November 04, 2009 4:53 AM
> To: Myles Watson
> Subject: failing fam10 code in coreboot
> 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,
> 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
> > 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
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
More information about the coreboot