On Wed, May 05, 2010 at 04:26:15PM -0400, Myles Watson wrote: > On Wed, May 5, 2010 at 2:06 PM, Joe Korty <[email protected]>wrote: >> Naturally I am having troubles. I suspect that as a newbie I am probably >> doing something stupid. But then I've heard that mb manufacturers like >> to change things around without notice, so maybe I'm doing things right >> and what was once a supported mb, no longer is.
> It looks like you're doing things right. It's dying really early, though. >> When booting coreboot, nothing happens for about 45 seconds. >> Then the fans speed up to high and some messages start appearing >> on the serial line. These messages print rather slowly (maybe >> 1 second/message). They are: >> >> coreboot-4.0-r5521M Wed May 5 10:53:42 EDT 2010 starting... >> *sysinfo range: [000cf000,000cf730] >> bsp_apicid=00 >> Enabling routing table for node 00 done. >> Enabling SMP settings >> (0,1) link=00 > You could try an earlier revision. I can't think of what would slow > it down that much. >> I put some printk's in setup_smb2, the crashing routine. They show >> that setup_temp_row is called by setup_smb2 but never returns. > Since it takes so long to get there, I think you'll have better luck > trying to figure out what's wrong before that. >> fgrep 'Video ROM' /proc/iomem >> # displays "000c0000-000cafff : Video ROM" >> sudo dd if=/dev/mem of=/tmp/vgabios.bin bs=4k skip=$((0xc0)) count=$((0xb)) >> >> # --- figure out the Video ROM's PCI Vendor,Device ID >> # --- I _think_ the numbers I want are the second set shown, ie "15d9:1611". > > You want the first set. The second set is Supermicro's board ID. Hi Myles, Thanks for the pointers. I'm going to try some earlier releases of coreboot and if I can find one that lacks the slowdown. If that fails I am going to have to figure out how to debug the earliest stages of coreboot, when nothing is visible and little can be saved. Joe -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
