On Wed, May 05, 2010 at 04:26:15PM -0400, Myles Watson wrote:
On Wed, May 5, 2010 at 2:06 PM, Joe Korty joe.korty@ccur.comwrote:
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