[coreboot] failing fam10 code in coreboot

Myles Watson mylesgw at gmail.com
Wed Nov 4 19:53:17 CET 2009

> From: Maximilian Thuermer [mailto:Maximilian.Thuermer at 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

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 mailing list