> -----Original Message----- > From: Maximilian Thuermer [mailto:[email protected] > 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
