Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

 Myles,
 
 I'm not sure what you mean by: Change the hard coded values. Where
 should I change them?
Send me the latest output and I'll send you a patch to test.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

Here's a patch that will either work or help us figure out what's going
wrong.

Signed-off-by: Myles Watson myle...@gmail.com

Thanks,
Myles
Index: svn/src/mainboard/arima/hdama/mptable.c
===
--- svn.orig/src/mainboard/arima/hdama/mptable.c
+++ svn/src/mainboard/arima/hdama/mptable.c
@@ -327,16 +327,21 @@ void reboot_if_hotswap(void)
 	int reset;
 	int i;
 
+	unsigned char bus_chain_0 = node_link_to_bus(0, 0);
 	reset = 0;
 	printk_debug(Looking for bad PCIX MHz input\n);
-	dev = dev_find_slot(1, PCI_DEVFN(0x02,0));
+	dev = dev_find_slot(bus_chain_0, PCI_DEVFN(0x02,0));
+	if (!dev)
+		printk_debug(Couldn't find %02x:02.0 \n, bus_chain_0);
 	data = pci_read_config32(dev, 0xa0);
 	if(!(((data16)0x03)==0x03)) {
 		reset=1;
 		printk_debug(Bad PCIX MHz - Reset\n);
 	}
 	printk_debug(Looking for bad Hot Swap Enable\n);
-	dev = dev_find_slot(1, PCI_DEVFN(0x01,0));
+	dev = dev_find_slot(bus_chain_0, PCI_DEVFN(0x01,0));
+	if (!dev)
+		printk_debug(Couldn't find %02x:01.0 \n, bus_chain_0);
 	data = pci_read_config32(dev, 0x48);
 	if(data  0x0c) {
 		reset=1;
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Nov 4, 2009 at 2:48 PM, Hugh Greenberg h...@lanl.gov wrote:

 Attached is the latest output.  I don't see the errors anymore.  I just
 tried booting Linux with the latest rom and it booted.

Great!  So is everything finally working, or are you still fighting sporadic
hangs?

We should commit the fixes so they don't get lost.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Myles,

Everything seems to be working well.  I had one sporadic hang while 
testing at what looked to be at the same place as the initial first 
hang.  That was the only instance since I moved to gcc 3.4. We were 
testing so many things that I don't remember the exact scenario.   I'm 
satisfied though.  If I see it happening again, I'll try to capture it 
and send it to you.


You deserve a medal for this.  Thanks a lot.

--
Hugh Greenberg




Myles Watson wrote:



On Wed, Nov 4, 2009 at 2:48 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Attached is the latest output.  I don't see the errors anymore.  I
just tried booting Linux with the latest rom and it booted.

Great!  So is everything finally working, or are you still fighting 
sporadic hangs?


We should commit the fixes so they don't get lost.

Thanks,
Myles



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Nov 4, 2009 at 4:23 PM, Hugh Greenberg h...@lanl.gov wrote:

 Myles,

 Everything seems to be working well.  I had one sporadic hang while testing
 at what looked to be at the same place as the initial first hang.  That was
 the only instance since I moved to gcc 3.4. We were testing so many things
 that I don't remember the exact scenario.   I'm satisfied though.  If I see
 it happening again, I'll try to capture it and send it to you.

Sounds good.  I'd be interested in whether or not it hangs with the newer
gcc still, too.  Since everything else is working, it would be nice to know
if that's really an issue.


 You deserve a medal for this.  Thanks a lot.

No problem.  Would you mind sending svn diff from your working tree so I can
make a patch?  I've lost track of which patches you're using.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Attached is the output from svn diff.   I'll test it with gcc 4.4 and 
let you know if it hangs or not.


--
Hugh Greenberg



Myles Watson wrote:



On Wed, Nov 4, 2009 at 4:23 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Myles,

Everything seems to be working well.  I had one sporadic hang
while testing at what looked to be at the same place as the
initial first hang.  That was the only instance since I moved to
gcc 3.4. We were testing so many things that I don't remember the
exact scenario.   I'm satisfied though.  If I see it happening
again, I'll try to capture it and send it to you.

Sounds good.  I'd be interested in whether or not it hangs with the 
newer gcc still, too.  Since everything else is working, it would be 
nice to know if that's really an issue.
 


You deserve a medal for this.  Thanks a lot.

No problem.  Would you mind sending svn diff from your working tree so 
I can make a patch?  I've lost track of which patches you're using.


Thanks,
Myles

Index: src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
===
--- src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c	(revision 4887)
+++ src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c	(working copy)
@@ -50,6 +50,7 @@
 #include southbridge/amd/amd8111/amd8111_early_smbus.c
 #include northbridge/amd/amdk8/raminit.h
 #include cpu/amd/model_fxx/apic_timer.c
+#include northbridge/amd/amdk8/util.c
 #endif
 
 
@@ -393,6 +394,7 @@
 	dump_pci_device_index_wait(PCI_DEV(0, 0x19, 2), 0x98);
 #endif
 
+	showallroutes(BIOS_DEBUG, PCI_DEV(0, 0x18, 1));
 post_cache_as_ram(); // bsp swtich stack to ram and copy sysinfo ram now
 
 }
Index: src/mainboard/arima/hdama/Kconfig
===
--- src/mainboard/arima/hdama/Kconfig	(revision 4887)
+++ src/mainboard/arima/hdama/Kconfig	(working copy)
@@ -73,7 +73,7 @@
 
 config SB_HT_CHAIN_ON_BUS0
 	int
-	default 0
+	default 1
 	depends on BOARD_ARIMA_HDAMA
 
 config HT_CHAIN_END_UNITID_BASE
Index: src/mainboard/arima/hdama/mptable.c
===
--- src/mainboard/arima/hdama/mptable.c	(revision 4887)
+++ src/mainboard/arima/hdama/mptable.c	(working copy)
@@ -65,7 +65,7 @@
 
 	dev = dev_find_slot(0, PCI_DEVFN(0x18, 1));
 	if (!dev) {
-		return 0;
+		return 0xff;
 	}
 	for(reg = 0xE0; reg  0xF0; reg += 0x04) {
 		uint32_t config_map;
@@ -89,7 +89,7 @@
 			return bus_base;
 		}
 	}
-	return 0;
+	return 0xff;
 }
 
 unsigned max_apicid(void)
@@ -152,9 +152,9 @@
 
 		/* HT chain 0 */
 		bus_chain_0 = node_link_to_bus(0, 0);
-		if (bus_chain_0 == 0) {
+		if (bus_chain_0 == 0xff) {
 			printk_debug(ERROR - cound not find bus for node 0 chain 0, using defaults\n);
-			bus_chain_0 = 1;
+			bus_chain_0 = 0;
 		}
 
 		/* 8111 */
@@ -165,7 +165,7 @@
 			bus_isa++;
 		}
 		else {
-			printk_debug(ERROR - could not find PCI 1:03.0, using defaults\n);
+			printk_debug(ERROR - could not find PCI %02x:03.0, using defaults\n, bus_chain_0);
 
 			bus_8111_1 = 4;
 			bus_isa = 5;
@@ -177,7 +177,7 @@
 
 		}
 		else {
-			printk_debug(ERROR - could not find PCI 1:01.0, using defaults\n);
+			printk_debug(ERROR - could not find PCI %02x:01.0, using defaults\n, bus_chain_0);
 
 			bus_8131_1 = 2;
 		}
@@ -188,7 +188,7 @@
 
 		}
 		else {
-			printk_debug(ERROR - could not find PCI 1:02.0, using defaults\n);
+			printk_debug(ERROR - could not find PCI %02x:02.0, using defaults\n, bus_chain_0);
 
 			bus_8131_2 = 3;
 		}
@@ -327,16 +327,21 @@
 	int reset;
 	int i;
 
+	unsigned char bus_chain_0 = node_link_to_bus(0, 0);
 	reset = 0;
 	printk_debug(Looking for bad PCIX MHz input\n);
-	dev = dev_find_slot(1, PCI_DEVFN(0x02,0));
+	dev = dev_find_slot(bus_chain_0, PCI_DEVFN(0x02,0));
+	if (!dev)
+		printk_debug(Couldn't find %02x:02.0 \n, bus_chain_0);
 	data = pci_read_config32(dev, 0xa0);
 	if(!(((data16)0x03)==0x03)) {
 		reset=1;
 		printk_debug(Bad PCIX MHz - Reset\n);
 	}
 	printk_debug(Looking for bad Hot Swap Enable\n);
-	dev = dev_find_slot(1, PCI_DEVFN(0x01,0));
+	dev = dev_find_slot(bus_chain_0, PCI_DEVFN(0x01,0));
+	if (!dev)
+		printk_debug(Couldn't find %02x:01.0 \n, bus_chain_0);
 	data = pci_read_config32(dev, 0x48);
 	if(data  0x0c) {
 		reset=1;
Index: src/mainboard/arima/hdama/cache_as_ram_auto.c
===
--- src/mainboard/arima/hdama/cache_as_ram_auto.c	(revision 4887)
+++ src/mainboard/arima/hdama/cache_as_ram_auto.c	(working copy)
@@ -19,6 +19,7 @@
 #include southbridge/amd/amd8111/amd8111_early_smbus.c
 #include northbridge/amd/amdk8/raminit.h
 #include cpu/amd/model_fxx/apic_timer.c
+#include northbridge/amd/amdk8/util.c
 #include lib/delay.c
 
 #include cpu/x86/lapic/boot_cpu.c
@@ -213,5 +214,6 @@
 
 	sdram_initialize(nodes, ctrl);
 
+	showallroutes(BIOS_DEBUG, PCI_DEV(0, 0x18, 1));
 	post_cache_as_ram();
 }
Index: 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Yes, it is still hanging occasionally with a newer gcc.  I thought I put 
all the debug stuff back in, but I apparently didn't get it all.   Below 
is the output.  I will put the remaining debug statements back in for 
this hang again and send the output.


coreboot-2.3 Wed Nov  4 16:40:23 MST 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x0, freq=0x4, needs_reset=0x1
dev2 old_freq=0x0, freq=0x4, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
ht reset -


coreboot-2.3 Wed Nov  4 16:40:23 MST 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x4, freq=0x4, needs_reset=0x0
dev2 old_freq=0x4, freq=0x4, needs_reset=0x0
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0010 kB
Lower RAM end at 0x0010 kB
Ram2.01
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3

--
Hugh Greenberg




Myles Watson wrote:



On Wed, Nov 4, 2009 at 4:23 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Myles,

Everything seems to be working well.  I had one sporadic hang
while testing at what looked to be at the same place as the
initial first hang.  That was the only instance since I moved to
gcc 3.4. We were testing so many things that I don't remember the
exact scenario.   I'm satisfied though.  If I see it happening
again, I'll try to capture it and send it to you.

Sounds good.  I'd be interested in whether or not it hangs with the 
newer gcc still, too.  Since everything else is working, it would be 
nice to know if that's really an issue.
 


You deserve a medal for this.  Thanks a lot.

No problem.  Would you mind sending svn diff from your working tree so 
I can make a patch?  I've lost track of which patches you're using.


Thanks,
Myles



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

 Yes, it is still hanging occasionally with a newer gcc.  
Too bad.  Occasionally like 1-in-3?  I don't have any idea what the compiler
would have to do with non-deterministic hangs.

 I thought I put
 all the debug stuff back in, but I apparently didn't get it all.   Below
 is the output.  I will put the remaining debug statements back in for
 this hang again and send the output.
OK.  The other thing to find out is if you still need the Forcing Type 1
hack.  Everything else is nearly trivial since it only affects your board,
and you've tested it.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Sometimes it takes a very long time to reproduce.   It is very random.  
I just tried about 30 times and I was not able to reproduce it.  Ok, I 
will see if I still need that.


--
Hugh Greenberg
Los Alamos National Laboratory, CCS-1
Email: h...@lanl.gov
Phone: (505) 665-6471



Myles Watson wrote:
Yes, it is still hanging occasionally with a newer gcc.  


Too bad.  Occasionally like 1-in-3?  I don't have any idea what the compiler
would have to do with non-deterministic hangs.

  

I thought I put
all the debug stuff back in, but I apparently didn't get it all.   Below
is the output.  I will put the remaining debug statements back in for
this hang again and send the output.


OK.  The other thing to find out is if you still need the Forcing Type 1
hack.  Everything else is nearly trivial since it only affects your board,
and you've tested it.

Thanks,
Myles

  


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

It doesn't seem like I need the forcing type 1 hack anymore.

I reproduced the hang with some of the debugging statements back in. I 
hope that is all you need. Here is the output:


coreboot-2.3 Wed Nov 4 17:28:13 MST 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x0, freq=0x4, needs_reset=0x1
dev2 old_freq=0x0, freq=0x4, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
ht reset -


coreboot-2.3 Wed Nov 4 17:28:13 MST 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x4, freq=0x4, needs_reset=0x0
dev2 old_freq=0x4, freq=0x4, needs_reset=0x0
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0010 kB
Lower RAM end at 0x0010 kB
Ram2.01
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3
Before starting clocks: Before memreset:

--
Hugh Greenberg




Myles Watson wrote:
Yes, it is still hanging occasionally with a newer gcc.  


Too bad.  Occasionally like 1-in-3?  I don't have any idea what the compiler
would have to do with non-deterministic hangs.

  

I thought I put
all the debug stuff back in, but I apparently didn't get it all.   Below
is the output.  I will put the remaining debug statements back in for
this hang again and send the output.


OK.  The other thing to find out is if you still need the Forcing Type 1
hack.  Everything else is nearly trivial since it only affects your board,
and you've tested it.

Thanks,
Myles

  


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Myles,

I'm not sure what you mean by: Change the hard coded values. Where 
should I change them?


--
Hugh Greenberg


Myles Watson wrote:

Setting it to 1 or 2 gives what looks like the same output.  It causes
coreboot to fail with the following error:


I guess I shouldn't have committed it until it worked, but 0 was the wrong
value.

  

Initializing CBMEM area to 0x3fff (65536 bytes)
Adding CBMEM entry as no. 1
Moving GDT to 3fff0200...ok
High Tables Base is 3fff.
Copying Interrupt Routing Table to 0x000f... done.
Adding CBMEM entry as no. 2
Copying Interrupt Routing Table to 0x3fff0400... done.
PIRQ table: 176 bytes.
Looking for bad PCIX MHz input


That message comes from mainboard/arima/hdama/mptable.c

The bus numbers are hard-coded.  The easiest thing to do would be to:

1. Choose 1 or 2 for that config value
2. Find the bus and device numbers in the output
3. Change the hard coded values

Thanks,
Myles

  


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Myles,

Setting it to 1 or 2 gives what looks like the same output.  It causes 
coreboot to fail with the following error:


Initializing CBMEM area to 0x3fff (65536 bytes)
Adding CBMEM entry as no. 1
Moving GDT to 3fff0200...ok
High Tables Base is 3fff.
Copying Interrupt Routing Table to 0x000f... done.
Adding CBMEM entry as no. 2
Copying Interrupt Routing Table to 0x3fff0400... done.
PIRQ table: 176 bytes.
Looking for bad PCIX MHz input
get_pbus: dev is NULL!

--
Hugh Greenberg


Myles Watson wrote:
It turns out that SB_HT_CHAIN_ON_BUS_0 was set incorrectly.  I should 
have had you test if it should have been 2, but at least setting it to 
1 should let SeaBIOS find your devices.


Thanks,
Myles


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

 Setting it to 1 or 2 gives what looks like the same output.  It causes
 coreboot to fail with the following error:
I guess I shouldn't have committed it until it worked, but 0 was the wrong
value.

 Initializing CBMEM area to 0x3fff (65536 bytes)
 Adding CBMEM entry as no. 1
 Moving GDT to 3fff0200...ok
 High Tables Base is 3fff.
 Copying Interrupt Routing Table to 0x000f... done.
 Adding CBMEM entry as no. 2
 Copying Interrupt Routing Table to 0x3fff0400... done.
 PIRQ table: 176 bytes.
 Looking for bad PCIX MHz input
That message comes from mainboard/arima/hdama/mptable.c

The bus numbers are hard-coded.  The easiest thing to do would be to:

1. Choose 1 or 2 for that config value
2. Find the bus and device numbers in the output
3. Change the hard coded values

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

It turns out that SB_HT_CHAIN_ON_BUS_0 was set incorrectly.  I should have
had you test if it should have been 2, but at least setting it to 1 should
let SeaBIOS find your devices.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

It's really strange that SeaBIOS can't find your devices.  Could you try
this patch?  I'm wondering what your PCI routing table looks like.  I
revived some of Ron's debug code from v3.

Thanks,
Myles
Index: svn/src/northbridge/amd/amdk8/Makefile.inc
===
--- svn.orig/src/northbridge/amd/amdk8/Makefile.inc
+++ svn/src/northbridge/amd/amdk8/Makefile.inc
@@ -2,6 +2,7 @@ driver-y += northbridge.o
 driver-y += misc_control.o
 obj-y += get_sblk_pci1234.o
 obj-$(CONFIG_GENERATE_ACPI_TABLES) += amdk8_acpi.o
+obj-y += util.o
 
 # Not sure what to do with these yet. How did raminit_test even work?
 # Should be a target in -y form.
Index: svn/src/northbridge/amd/amdk8/northbridge.c
===
--- svn.orig/src/northbridge/amd/amdk8/northbridge.c
+++ svn/src/northbridge/amd/amdk8/northbridge.c
@@ -575,6 +575,7 @@ static void mcf0_control_init(struct dev
 #if 0
 	printk_debug(NB: Function 0 Misc Control.. );
 #endif
+	showallroutes(BIOS_DEBUG, dev_find_slot(0, PCI_DEVFN(0x18,1)));
 #if 0
 	printk_debug(done.\n);
 #endif
@@ -1075,6 +1076,7 @@ static void amdk8_domain_set_resources(d
 	}
 	assign_resources(dev-link[0]);
 
+	showallroutes(BIOS_DEBUG, dev_find_slot(0, PCI_DEVFN(0x18,1)));
 }
 
 static unsigned int amdk8_domain_scan_bus(device_t dev, unsigned int max)
Index: svn/src/northbridge/amd/amdk8/util.c
===
--- /dev/null
+++ svn/src/northbridge/amd/amdk8/util.c
@@ -0,0 +1,277 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2008 Vincent Legoll vincent.leg...@gmail.com
+ * Copyright (C) 2008 Ronald G. Minnich rminn...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+/*
+ * K8 northbridge utilities (dump routing registers).
+ * Designed to be called at any time.
+ */
+#ifndef __ROMCC__
+#include console/console.h
+#include string.h
+#include device/pci.h
+#include cpu/amd/amdk8_sysconf.h
+#include device/pci_ops.h
+#include amdk8.h
+#endif
+
+/* Function 1 */
+/* the DRAM, MMIO,and PCIIO routing are 64-bit registers, hence the ending at
+ * 0x78, 0xb8, and 0xd8
+ */
+#define DRAM_ROUTE_START	0x40
+#define DRAM_ROUTE_END		0x78
+#define MMIO_ROUTE_START	0x80
+#define MMIO_ROUTE_END		0xb8
+#define PCIIO_ROUTE_START	0xc0
+#define PCIIO_ROUTE_END		0xd8
+#define CONFIG_ROUTE_START	0xe0
+#define CONFIG_ROUTE_END	0xec
+
+#define PCI_IO_BASE0		0xc0
+#define PCI_IO_BASE1		0xc8
+#define PCI_IO_BASE2		0xd0
+#define PCI_IO_BASE3		0xd8
+#define PCI_IO_BASE_VGA_EN	(1  4)
+#define PCI_IO_BASE_NO_ISA	(1  5)
+
+#define BITS(r, shift, mask) (((rshift)mask))
+
+/**
+ * Return R if the register has read-enable bit set.
+ */
+static const char *re(u32 i);
+static const char *re(u32 i)
+{
+	return ((i  1) ? R : );
+}
+
+/**
+ * Return W if the register has write-enable bit set.
+ */
+static const char *we(u32 i);
+static const char *we(u32 i)
+{
+	return ((i  1) ? W : );
+}
+
+/**
+ * Return a string containing the interleave settings.
+ */
+static const char *ileave(u32 base);
+static const char *ileave(u32 base)
+{
+	switch ((base  8)  7) {
+	case 0:
+		return No interleave;
+	case 1:
+		return 2 nodes;
+	case 3:
+		return 4 nodes;
+	case 7:
+		return 8 nodes;
+	default:
+		return Reserved;
+	}
+}
+
+/**
+ * Return the node number.
+ * For one case (config registers) these are not the right bit fields.
+ */
+static int node(u32 reg);
+static int node(u32 reg)
+{
+	return BITS(reg, 0, 0x7);
+}
+
+/**
+ * Return the link number.
+ * For one case (config registers) these are not the right bit fields.
+ */
+static int link(u32 reg);
+static int link(u32 reg)
+{
+	return BITS(reg, 4, 0x3);
+}
+
+/**
+ * Print the DRAM routing info for one base/limit pair.
+ *
+ * Show base, limit, dest node, dest link on that node, read and write
+ * enable, and interleave information.
+ *
+ * @param level Printing level
+ * @param which Register number
+ * @param base Base register
+ * @param lim Limit register
+ */
+static void showdram(int level, u8 which, u32 base, u32 lim)
+{
+	do_printk(level, DRAM(%02x)%010llx-%010llx, -(%d), %s, %s, %s, %d\n,
+	   which, (((u64) base  0x)  8),
+	   (((u64) lim  0x)  8) + 0xff,
+	   node(lim), re(base), we(base), ileave(base), (lim  8)  3);
+}
+

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Fri, Oct 30, 2009 at 5:07 PM, Hugh Greenberg h...@lanl.gov wrote:

 Attached is the output.  I tried your idea with changing PCI_ROOT and it
 worked.  You can see gpxe booting in the output.


CONFIG(e0)01-04 -(0,0),R W (bus numbers)

That's not good.  That means If you get a config space read or write for
bus 1-4, send it down link 0 of node 0.

Unfortunately, it left out bus 0, which is why you only see the CPUs.  It
also explains why you can't see bus 2 unless you specifically point it out
to SeaBIOS.

I guess we need to look at the code that sets that.  It worked fine for
SimNOW...

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

I was using gcc 4.3.  Without the patches, I still see a problem even 
with gcc 3.4.  With the patches and gcc 3.4, things seem to be better so 
far.  Thanks.


--
Hugh Greenberg




Ward Vandewege wrote:

On Thu, Oct 22, 2009 at 09:16:14AM -0600, Myles Watson wrote:
  

RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3
Before starting clocks: Before memreset: cpu is pre_c0
after first udelay
  

OK.  So the timer worked for the first udelay...

Does it only freeze when you have both CPUs enabled?  Have you tried it with
the no_smp patch again?  I'm grasping at straws.



This is starting to sound like all the weirdness I was seeing when working on
the h8dmr fam10 port a few months ago.

Are you sure it hangs? I thought so at first as well, but it turned out that
things were running extremely slowly when compiling with gcc 4.3 (32 bit). If
I waited 5 minutes or so eventually the board would boot.

Can you reproduce a hang when changing CONSOLE_LOGLEVEL ? In my case the
board would just hang if I lowered the default loglevel to something less
than 8.

I never did figure out what was going on there. Ron thought perhaps there was
a cache issue. I put a file in the tree with the issues I ran into

  src/mainboard/supermicro/h8dmr_fam10/README

I haven't been able to revisit yet as that particular box is in production.

What toolchain are you using? 


Thanks,
Ward.

  


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

The script didn't help.  Seabios just doesn't see the rom.  Is this a 
seabios problem?  I didn't have this problem for the tyan s2881.  Here 
is the output again:


PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x
Incorrect Expansion ROM Header Signature 
Devices initialized
Show all devs...After init.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: : enabled 1, 5 resources
PCI: 00:18.0: enabled 1, 4 resources
PCI: 01:01.0: enabled 1, 3 resources
PCI: 01:01.1: enabled 1, 1 resources
PCI: 01:02.0: enabled 0, 0 resources
PCI: 01:02.1: enabled 1, 1 resources
PCI: 01:03.0: enabled 1, 3 resources
PCI: 04:00.0: enabled 1, 1 resources
PCI: 04:00.1: enabled 1, 1 resources
PCI: 04:00.2: enabled 0, 0 resources
PCI: 04:01.0: enabled 0, 0 resources
PCI: 04:06.0: enabled 1, 4 resources
PCI: 01:04.0: enabled 1, 3 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 0, 3 resources
PNP: 002e.2: enabled 0, 4 resources
PNP: 002e.3: enabled 1, 2 resources
PNP: 002e.4: enabled 0, 2 resources
PNP: 002e.5: enabled 0, 1 resources
PNP: 002e.6: enabled 1, 3 resources
PNP: 002e.7: enabled 0, 2 resources
PNP: 002e.8: enabled 0, 2 resources
PNP: 002e.9: enabled 0, 2 resources
PNP: 002e.a: enabled 0, 2 resources
PCI: 01:04.1: enabled 1, 1 resources
PCI: 01:04.2: enabled 1, 1 resources
PCI: 01:04.3: enabled 1, 1 resources
I2C: 01:70: enabled 1, 0 resources
I2C: 00:2c: enabled 1, 0 resources
I2C: 01:50: enabled 1, 0 resources
I2C: 01:51: enabled 1, 0 resources
I2C: 01:52: enabled 1, 0 resources
I2C: 01:53: enabled 1, 0 resources
I2C: 01:54: enabled 1, 0 resources
I2C: 01:55: enabled 1, 0 resources
I2C: 01:56: enabled 1, 0 resources
I2C: 01:57: enabled 1, 0 resources
PCI: 01:04.5: enabled 0, 0 resources
PCI: 01:04.6: enabled 1, 2 resources
PCI: 00:18.1: enabled 1, 0 resources
PCI: 00:18.2: enabled 1, 0 resources
PCI: 00:18.3: enabled 1, 1 resources
PCI: 00:19.0: enabled 1, 0 resources
PCI: 00:19.1: enabled 1, 0 resources
PCI: 00:19.2: enabled 1, 0 resources
PCI: 00:19.3: enabled 1, 0 resources
APIC: 01: enabled 1, 0 resources
PCI: 02:03.0: enabled 1, 2 resources
PCI: 02:04.0: enabled 1, 2 resources
Initializing CBMEM area to 0x3fff (65536 bytes)
Adding CBMEM entry as no. 1
Moving GDT to 3fff0200...ok
High Tables Base is 3fff.
Copying Interrupt Routing Table to 0x000f... done.
Adding CBMEM entry as no. 2
Copying Interrupt Routing Table to 0x3fff0400... done.
PIRQ table: 176 bytes.
Looking for bad PCIX MHz input
Looking for bad Hot Swap Enable
OK 133MHz  Hot Swap is off
Wrote the mp table end at: 000f0410 - 000f0614
Adding CBMEM entry as no. 3
Looking for bad PCIX MHz input
Looking for bad Hot Swap Enable
OK 133MHz  Hot Swap is off
Wrote the mp table end at: 3fff1410 - 3fff1614
MP table: 532 bytes.
Adding CBMEM entry as no. 4
Writing high table forward entry at 0x0500
Wrote coreboot table at: 0500 - 0518  checksum 9bdf
New low_table_end: 0x0518
Now going to write high coreboot table at 0x3fff2400
rom_table_end = 0x3fff2400
Adjust low_table_end from 0x0518 to 0x1000
Adjust rom_table_end from 0x3fff2400 to 0x4000
Adding high table area
Wrote coreboot table at: 3fff2400 - 3fff2ca4  checksum b5b9
coreboot table: 2212 bytes.
0. FREE SPACE 3fff4400 bc00
1. GDT3fff0200 0200
2. IRQ TABLE  3fff0400 1000
3. SMP TABLE  3fff1400 1000
4. COREBOOT   3fff2400 2000
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
CBFS: follow chain: fff8 + 38 + a590 + align - fff8a600
Check fallback/payload
Got a payload
Loading segment from rom address 0xfff8a638
 data (compression=1)
malloc Enter, size 36, free_mem_ptr 00160ce4
malloc 00160ce4
 New segment dstaddr 0xf memsize 0x1 srcaddr 0xfff8a670 
filesize 0x7350
 (cleaned up) New segment addr 0xf size 0x1 offset 0xfff8a670 
filesize0

Loading segment from rom address 0xfff8a654
 Entry Point 0x000fc4f3
Loading Segment: addr: 0x000f memsz: 0x0001 
filesz: 0x00

lb: [0x0010, 0x00164000)
Post relocation: addr: 0x000f memsz: 0x0001 
filesz: 0x00

using LZMA
[ 0x000f, 0010, 0x0010) - 
fff8a670

dest f, end 10, bouncebuffer 7ff38000
Loaded segments
Jumping to boot code at fc4f3
entry= 0x000fc4f3
lb_start = 0x0010
lb_size  = 0x00064000
adjust   = 0x7fe9c000
buffer   = 0x7ff38000
elf_boot_notes = 0x00113a20
adjusted_boot_notes = 0x7ffafa20
Start bios (version 0.4.2-20090908_202836-morn.localdomain)
CPU Mhz=1804
Found mainboard Arima HDAMA
Found CBFS header at 0xfffeffe0
Ram Size=0x8000
Found 2 cpu(s)
Scan for VGA option rom
Got ps2 nak (status=51); continuing
ps2_recvbyte timeout
Found 0 lpt ports
Found 1 serial ports
Copying PIR from 0x3fff0400 to 0x000fdc50
Copying MPTABLE from 0x3fff1400/3fff1410 to 0x000fda30
SMBIOS 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Thu, Oct 29, 2009 at 12:21 PM, Hugh Greenberg h...@lanl.gov wrote:

 The script didn't help.  Seabios just doesn't see the rom.  Is this a
 seabios problem?  I didn't have this problem for the tyan s2881.  Here is
 the output again:



 Found mainboard Arima HDAMA
 Found CBFS header at 0xfffeffe0
 Ram Size=0x8000
 Found 2 cpu(s)
 Scan for VGA option rom

Here's a snippet from mine:

Scan for VGA option rom
Attempting to init PCI bdf 02:00.0 (dev/ven 014110de)
Searching CBFS for prefix pci10de,0141.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file
...
Much later
...
Scan for option roms
Attempting to init PCI bdf 00:00.0 (dev/ven 005e10de)
Searching CBFS for prefix pci10de,005e.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file
Attempting to map option rom on dev 00:00.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:01.0 (dev/ven 005110de)
Searching CBFS for prefix pci10de,0051.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file

Is your debug level = 6 for SeaBIOS?  It looks like you do.

Do you have CONFIG_OPTION_ROMS_DEPLOYED set to 0?

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

I was using the pre-built one mentioned in the wiki: 
http://www.coreboot.org/SeaBIOS .  I don't know what the debug option is 
set to.  This worked for me for the tyan s2881, so I assume that the 
correct options are set.  I tried compiling my own and I had that option 
set along with the others mentioned in the wiki, but I also had the same 
problem.  I can try compiling my own again and making sure the debug 
option is set to 6.


--
Hugh Greenberg




Myles Watson wrote:



On Thu, Oct 29, 2009 at 12:21 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


The script didn't help.  Seabios just doesn't see the rom.  Is
this a seabios problem?  I didn't have this problem for the tyan
s2881.  Here is the output again:

 


Found mainboard Arima HDAMA
Found CBFS header at 0xfffeffe0
Ram Size=0x8000
Found 2 cpu(s)
Scan for VGA option rom

Here's a snippet from mine:
 
Scan for VGA option rom

Attempting to init PCI bdf 02:00.0 (dev/ven 014110de)
Searching CBFS for prefix pci10de,0141.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file
...
Much later
...
Scan for option roms
Attempting to init PCI bdf 00:00.0 (dev/ven 005e10de)
Searching CBFS for prefix pci10de,005e.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file
Attempting to map option rom on dev 00:00.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:01.0 (dev/ven 005110de)
Searching CBFS for prefix pci10de,0051.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file

Is your debug level = 6 for SeaBIOS?  It looks like you do.

Do you have CONFIG_OPTION_ROMS_DEPLOYED set to 0?

Thanks,
Myles


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Here is the relevant output with the debug option set to 6:

Searching CBFS for prefix floppyimg/
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Scan for option roms
Attempting to init PCI bdf 00:18.0 (dev/ven 11001022)
Searching CBFS for prefix pci1022,1100.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:18.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:18.1 (dev/ven 11011022)
Searching CBFS for prefix pci1022,1101.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:18.1
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:18.2 (dev/ven 11021022)
Searching CBFS for prefix pci1022,1102.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:18.2
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:18.3 (dev/ven 11031022)
Searching CBFS for prefix pci1022,1103.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:18.3
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:19.0 (dev/ven 11001022)
Searching CBFS for prefix pci1022,1100.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:19.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:19.1 (dev/ven 11011022)
Searching CBFS for prefix pci1022,1101.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom

Los Alamos National Laboratory, CCS-1
Email: h...@lanl.gov
Phone: (505) 665-6471

Found CBFS file
Attempting to map option rom on dev 00:19.1
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:19.2 (dev/ven 11021022)
Searching CBFS for prefix pci1022,1102.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:19.2
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:19.3 (dev/ven 11031022)
Searching CBFS for prefix pci1022,1103.rom
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Attempting to map option rom on dev 00:19.3
Option rom sizing returned 0 0
Searching CBFS for prefix genroms/
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
Press F12 for boot menu.

finalize PMM
malloc finalize
zone 0: 7c00-0009 used=0 (0%)
zone 1: 000a-000a used=0 (0%)
zone 2: 000fd440-000fdc40 used=752 (36%)
zone 3: 4000-7fff used=128 (0%)
zone 4: 7fff-8000 used=2048 (3%)
Returned 61440 bytes of ZoneHigh
e820 map has 7 items:
 0:  - 0009f400 = 1
 1: 0009f400 - 000a = 2
 2: 000f - 0010 = 2
 3: 0010 - 3fff = 1
 4: 3fff - 4000 = 2
 5: 4000 - 7000 = 1
 6: 7000 - 8000 = 2
Jump to int19
enter handle_19:
 NULL
Booting from Floppy...
fail handle_legacy_disk:801(1):
  a=0201  b=  c=0001  d= ds= es=07c0 ss=
 si= di= bp= sp=7b00 cs=f000 ip=efc4  f=0202
Boot failed: could not read the boot disk

enter handle_18:
 NULL
Booting from CD-Rom...
Boot failed: Could not read from CDROM (code 0001)
enter handle_18:
 NULL
Booting from Hard Disk...
fail handle_legacy_disk:801(1):
  a=0201  b=  c=0001  d=0080 ds= es=07c0 ss=
 si= di= bp= sp=7b00 cs=f000 ip=efc4  f=0202
Boot failed: could not read the boot disk

enter handle_18:
 NULL
Booting from CBFS...
Searching CBFS for prefix img/
Found CBFS file fallback/coreboot_ram
Found CBFS file fallback/payload
Found CBFS file pci14e4,16a6.rom
Found CBFS file
enter handle_18:
 NULL
No bootable device.


It seems though that seabios does not detect my network cards.  I tried 
then adding the rom as pci1022,1101.rom, and gpxe will load, but it 
won't detect my network devices.  Any suggestions?  Thanks.


--
Hugh Greenberg



Myles Watson wrote:



On Thu, Oct 29, 2009 at 12:21 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


The script didn't help.  Seabios just doesn't see the rom.  Is
this a seabios problem?  I didn't have this problem for the tyan
s2881.  Here is the output again:

 


Found mainboard Arima HDAMA
Found CBFS header at 0xfffeffe0
Ram Size=0x8000
Found 2 cpu(s)
Scan for VGA option rom

Here's a snippet 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Thu, Oct 29, 2009 at 2:31 PM, Hugh Greenberg h...@lanl.gov wrote:

 Here is the relevant output with the debug option set to 6:

 Searching CBFS for prefix floppyimg/

 Found CBFS file fallback/coreboot_ram
 Found CBFS file fallback/payload
 Found CBFS file pci14e4,16a6.rom
 Found CBFS file
 Scan for option roms
 Attempting to init PCI bdf 00:18.0 (dev/ven 11001022)

...

 Attempting to init PCI bdf 00:18.1 (dev/ven 11011022)

...

 Attempting to init PCI bdf 00:18.2 (dev/ven 11021022)

Attempting to init PCI bdf 00:18.3 (dev/ven 11031022)
 Attempting to init PCI bdf 00:19.0 (dev/ven 11001022)
 Attempting to init PCI bdf 00:19.1 (dev/ven 11011022)
 Attempting to init PCI bdf 00:19.2 (dev/ven 11021022)
 Attempting to init PCI bdf 00:19.3 (dev/ven 11031022)

It's only seeing your CPUs.  I was looking for Attempting to init... lines
with other devices.

02:03.0 (from your Coreboot log this looks like one of your NICs)

Maybe you can cheat and set CONFIG_PCI_ROOT1 to 2.  I don't know why it's
not finding your devices.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

Would you try this patch?

I'm having problems where PCI config writes aren't working correctly, and
I'm wondering if you are too.

Thanks,
Myles
Index: sysconfig/src/arch/i386/lib/pci_ops_auto.c
===
--- sysconfig.orig/src/arch/i386/lib/pci_ops_auto.c
+++ sysconfig/src/arch/i386/lib/pci_ops_auto.c
@@ -45,6 +45,9 @@ const struct pci_bus_operations *pci_che
 {
 	unsigned int tmp;
 
+	printk_debug(%s\n, __func__);
+	printk_debug(PCI: Forcing configuration type 1\n);
+	return pci_cf8_conf1;
 	/*
 	 * Check if configuration type 1 works.
 	 */
Index: sysconfig/src/devices/pci_device.c
===
--- sysconfig.orig/src/devices/pci_device.c
+++ sysconfig/src/devices/pci_device.c
@@ -479,6 +479,11 @@ static void pci_set_resource(struct devi
 		return;
 	}
 
+	/* If this resource is fixed don't worry about it. */
+	if (resource-flags  IORESOURCE_FIXED) {
+		return;
+	}
+
 	/* If I have already stored this resource don't worry about it. */
 	if (resource-flags  IORESOURCE_STORED) {
 		return;
@@ -525,7 +530,7 @@ static void pci_set_resource(struct devi
 	}
 
 	if (!(resource-flags  IORESOURCE_PCI_BRIDGE)) {
-		unsigned long base_lo, base_hi;
+		u32 base_lo, base_hi;
 		/* Some chipsets allow us to set/clear the I/O bit
 		 * (e.g. VIA 82c686a). So set it to be safe.
 		 */
@@ -535,6 +540,19 @@ static void pci_set_resource(struct devi
 			base_lo |= PCI_BASE_ADDRESS_SPACE_IO;
 		}
 		pci_write_config32(dev, resource-index, base_lo);
+		{
+			u32 regval = pci_read_config32(dev, resource-index);
+			if (regval != base_lo) {
+			report_resource_stored(dev, resource, first try);
+			printk_debug(Second write regval %x base_lo %x\n,
+ regval, base_lo);
+			pci_write_config32(dev, resource-index, base_lo);
+			regval = pci_read_config32(dev, resource-index);
+if (regval != base_lo)
+			printk_debug(Second failure regval %x base_lo %x\n,
+ regval, base_lo);
+			}
+		}
 		if (resource-flags  IORESOURCE_PCI64) {
 			pci_write_config32(dev, resource-index + 4, base_hi);
 		}
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

 Attached is the output after applying this patch.
Thanks.  Yours looks good, so I'll have to dig deeper to see why I've got
those problems.

Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

It froze again.  Here is some of the output:

SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0010 kB
Lower RAM end at 0x0010 kB
Ram2.01
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3
Before starting clocks: Before memreset: cpu is pre_c0
after first udelay

--
Hugh Greenberg


Myles Watson wrote:

While I was just trying to get seabios to boot gpxe, coreboot hung at
the same spot.  It seems to happen randomly now, not every time it boots
like before.


Too bad.

I guess put all the debugging back in and see if it still hangs randomly,
and if it is exactly the same spot.

Thanks,
Myles

  


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Ward Vandewege]

On Thu, Oct 22, 2009 at 09:16:14AM -0600, Myles Watson wrote:
  RAM end at 0x0020 kB
  Lower RAM end at 0x0020 kB
  Ram3
  Before starting clocks: Before memreset: cpu is pre_c0
  after first udelay
 
 OK.  So the timer worked for the first udelay...
 
 Does it only freeze when you have both CPUs enabled?  Have you tried it with
 the no_smp patch again?  I'm grasping at straws.

This is starting to sound like all the weirdness I was seeing when working on
the h8dmr fam10 port a few months ago.

Are you sure it hangs? I thought so at first as well, but it turned out that
things were running extremely slowly when compiling with gcc 4.3 (32 bit). If
I waited 5 minutes or so eventually the board would boot.

Can you reproduce a hang when changing CONSOLE_LOGLEVEL ? In my case the
board would just hang if I lowered the default loglevel to something less
than 8.

I never did figure out what was going on there. Ron thought perhaps there was
a cache issue. I put a file in the tree with the issues I ran into

  src/mainboard/supermicro/h8dmr_fam10/README

I haven't been able to revisit yet as that particular box is in production.

What toolchain are you using? 

Thanks,
Ward.

-- 
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Please disregard my last message.  I mean do you want me to apply the 
patch without any of the changes to apic_timer.c ?


Myles Watson wrote:

Below is the output with the no_smp patch and the previous patch.  Is
there another problem since the payload is not being loaded?


There's definitely some problem.  It hangs before the devices are enumerated
:(
 
  

coreboot-2.3 Tue Oct 20 16:46:25 MDT 2009 starting...
Enabling routing table for node 00 done.
Enabling UP settings
Disabling read/write/fill probes for UP... done.
Ram2.00
Enabling dual channel memory
coreboot-2.3 Tue Oct 20 16:46:25 MDT 2009 booting...
POST: 0x40
Enumerating buses...
Show all devs...Before Device Enumeration.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: : enabled 1, 0 resources
PCI: 00:18.0: enabled 1, 0 resources


...
  

PCI: 00:1e.0, bad id 0x
PCI: 00:1f.0, bad id 0x
POST: 0x25


This is another strange place to hang.  I don't understand why it would hang
here.  It's probably time to put a few print statements around there and see
if we can get it to go a little farther.

Have you tried it with the init call, but not the timeout?  It would be nice
if we could say that bug was squashed and we could move on.  If init wasn't
the problem, we should probably figure out why you can't get to the lapic
before we move on.

Thanks,
Myles

  




--
Hugh Greenberg
Los Alamos National Laboratory, CCS-1
Email: h...@lanl.gov
Phone: (505) 665-6471


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

It seems like the changes to apic_timer.c were not needed as it is still 
getting to the same spot without them:


coreboot-2.3 Wed Oct 21 08:50:27 MDT 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x0, freq=0x4, needs_reset=0x1
dev2 old_freq=0x0, freq=0x4, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
ht reset -


coreboot-2.3 Wed Oct 21 08:50:27 MDT 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x4, freq=0x4, needs_reset=0x0
dev2 old_freq=0x4, freq=0x4, needs_reset=0x0
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0010 kB
Lower RAM end at 0x0010 kB
Ram2.01
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3
Before starting clocks: Before memreset: cpu is pre_c0
after first udelay
after second udelay
Before controllers loop: ECC enabled
ECC enabled
Before 2nd controllers loop: Initializing memory: done
Initializing memory: done
Before hole: Ram4
v_esp=000ced88
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now
Clearing initial memory region: Done
Jumping to image.
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
Stage: load fallback/coreboot_ram @ 1048576/409600 bytes, enter @ 10
Stage: done loading.
Jumping to image.
POST: 0x80
POST: 0x39
coreboot-2.3 Wed Oct 21 08:51:08 MDT 2009 booting...
POST: 0x40
Enumerating buses...
Show all devs...Before Device Enumeration.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: : enabled 1, 0 resources
PCI: 00:18.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:01.0: enabled 1, 0 resources
PCI: 00:01.1: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:00.2: enabled 0, 0 resources
PCI: 00:01.0: enabled 0, 0 resources
PCI: 00:06.0: enabled 1, 0 resources
PCI: 00:01.0: enabled 1, 0 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 0, 2 resources
PNP: 002e.2: enabled 0, 2 resources
PNP: 002e.3: enabled 1, 2 resources
PNP: 002e.4: enabled 0, 0 resources
PNP: 002e.5: enabled 0, 0 resources
PNP: 002e.6: enabled 1, 3 resources
PNP: 002e.7: enabled 0, 0 resources
PNP: 002e.8: enabled 0, 0 resources
PNP: 002e.9: enabled 0, 0 resources
PNP: 002e.a: enabled 0, 0 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

 -Original Message-
 From: Hugh Greenberg [mailto:h...@lanl.gov]
 Sent: Wednesday, October 21, 2009 8:58 AM
 To: Myles Watson; coreboot@coreboot.org
 Subject: Re: [Fwd: Re: [Fwd: Re: [coreboot] [Fwd: Re: arima hdama
 problem]]]
 
 It seems like the changes to apic_timer.c were not needed as it is still
 getting to the same spot without them:
Good.

 PCI: 00:1f.0, bad id 0x
 POST: 0x25
I would add a print statement in src/devices/pci_device.c:

/* For all children that implement scan_bus() (i.e. bridges)
 * scan the bus behind that child.
 */
for (child = bus-children; child; child = child-sibling) {
/* Put a print statement here that prints out the child that's being
scanned. */
printk_debug(scan bus of %s\n, dev_path(child));
max = scan_bus(child, max);
}

I'm away from my machine right now, so I don't have a patch.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Here is the output after adding the print statement:

coreboot-2.3 Wed Oct 21 09:25:50 MDT 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x0, freq=0x4, needs_reset=0x1
dev2 old_freq=0x0, freq=0x4, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
ht reset -


coreboot-2.3 Wed Oct 21 09:25:50 MDT 2009 starting...
Enabling routing table for node 00 done.
Enabling SMP settings
(0,1) link=01
(1,0) link=01
setup_remote_node: done
Renaming current temporary node to 01 done.
Enabling routing table for node 01 done.
02 nodes initialized.
coherent_ht_finalize
done
started ap apicid:
SBLink=00
NC node|link=00
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x35
freq_cap1=0x35, freq_cap2=0x15
dev1 old_freq=0x4, freq=0x4, needs_reset=0x0
dev2 old_freq=0x4, freq=0x4, needs_reset=0x0
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
entering ht_optimize_link
pos=0xd2, unfiltered freq_cap=0x35
pos=0xce, unfiltered freq_cap=0x1
pos=0xce, filtered freq_cap=0x1
freq_cap1=0x15, freq_cap2=0x1
dev1 old_freq=0x0, freq=0x0, needs_reset=0x0
dev2 old_freq=0x0, freq=0x0, needs_reset=0x0
width_cap1=0x0, width_cap2=0x0
dev1 input ln_width1=0x3, ln_width2=0x3
dev1 input width=0x0
dev1 output ln_width1=0x3, ln_width2=0x3
dev1 input|output width=0x0
old dev1 input|output width=0x0
dev2 input|output width=0x0
old dev2 input|output width=0x0
SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0010 kB
Lower RAM end at 0x0010 kB
Ram2.01
Enabling dual channel memory
Registered
166Mhz
RAM end at 0x0020 kB
Lower RAM end at 0x0020 kB
Ram3
Before starting clocks: Before memreset: cpu is pre_c0
after first udelay
after second udelay
Before controllers loop: ECC enabled
ECC enabled
Before 2nd controllers loop: Initializing memory: done
Initializing memory: done
Before hole: Ram4
v_esp=000ced88
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now
Clearing initial memory region: Done
Jumping to image.
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/coreboot_ram
Stage: load fallback/coreboot_ram @ 1048576/409600 bytes, enter @ 10
Stage: done loading.
Jumping to image.
POST: 0x80
POST: 0x39
coreboot-2.3 Wed Oct 21 09:25:50 MDT 2009 booting...
POST: 0x40
Enumerating buses...
Show all devs...Before Device Enumeration.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: : enabled 1, 0 resources
PCI: 00:18.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:01.0: enabled 1, 0 resources
PCI: 00:01.1: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:00.2: enabled 0, 0 resources
PCI: 00:01.0: enabled 0, 0 resources
PCI: 00:06.0: enabled 1, 0 resources
PCI: 00:01.0: enabled 1, 0 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 0, 2 resources
PNP: 002e.2: enabled 0, 2 resources
PNP: 002e.3: enabled 1, 2 resources
PNP: 002e.4: enabled 0, 0 resources
PNP: 002e.5: enabled 0, 0 resources
PNP: 002e.6: enabled 1, 3 resources
PNP: 002e.7: enabled 0, 0 resources
PNP: 002e.8: enabled 0, 0 resources
PNP: 002e.9: enabled 0, 0 resources
PNP: 002e.a: enabled 0, 0 resources
PCI: 00:01.1: enabled 1, 0 resources
PCI: 00:01.2: 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Oct 21, 2009 at 9:31 AM, Hugh Greenberg h...@lanl.gov wrote:


 PCI: 00:1f.0, bad id 0x
 POST: 0x25
 scan bus of PCI: 00:18.0

While we're doing this part only the last few lines (or the new lines since
the last time) really matter.

It looks like it gets stuck in scan_bus.  Try adding print statements
1. after scan_bus just in case.
2. inside scan_bus in src/devices/device.c

Print out which functions are being called and we'll narrow this down.

When I get back to the lab I can start comparing to SimNOW again.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Attached is a patch that contains the extra debug statements I added.  
Below is the new output:


before scan bus of PCI: 00:18.0
In scan bus of PCI: 00:18.0

--
Hugh Greenberg

Myles Watson wrote:



On Wed, Oct 21, 2009 at 9:31 AM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:



PCI: 00:1f.0, bad id 0x
POST: 0x25
scan bus of PCI: 00:18.0

While we're doing this part only the last few lines (or the new lines 
since the last time) really matter.


It looks like it gets stuck in scan_bus.  Try adding print statements
1. after scan_bus just in case.
2. inside scan_bus in src/devices/device.c

Print out which functions are being called and we'll narrow this down.

When I get back to the lab I can start comparing to SimNOW again.

Thanks,
Myles
diff -urN -x .svn coreboot-v2.orig/src/devices/device.c coreboot-v2/src/devices/device.c
--- coreboot-v2.orig/src/devices/device.c	2009-10-21 10:14:54.0 -0600
+++ coreboot-v2/src/devices/device.c	2009-10-21 10:13:29.0 -0600
@@ -847,14 +847,20 @@
 	do_scan_bus = 1;
 	while (do_scan_bus) {
 		int link;
+		printk_debug(In scan bus of %s\n, dev_path(busdev));
 		new_max = busdev-ops-scan_bus(busdev, max);
 		do_scan_bus = 0;
 		for (link = 0; link  busdev-links; link++) {
 			if (busdev-link[link].reset_needed) {
+			printk_debug(Reset needed for link device: %s\n, 
+	 dev_path(busdev-link[link].dev));
+
 if (reset_bus(busdev-link[link])) {
 	do_scan_bus = 1;
 } else {
 	busdev-bus-reset_needed = 1;
+	printk_debug(Setting reset_needed for %s to 1\n, 
+		 dev_path(busdev));
 }
 			}
 		}
diff -urN -x .svn coreboot-v2.orig/src/devices/pci_device.c coreboot-v2/src/devices/pci_device.c
--- coreboot-v2.orig/src/devices/pci_device.c	2009-10-21 10:14:54.0 -0600
+++ coreboot-v2/src/devices/pci_device.c	2009-10-21 10:10:22.0 -0600
@@ -1081,7 +1081,9 @@
 	 * scan the bus behind that child.
 	 */
 	for (child = bus-children; child; child = child-sibling) {
+		printk_debug(before scan bus of %s\n, dev_path(child));
 		max = scan_bus(child, max);
+	printk_debug(after scan bus of %s\n, dev_path(child));
 	}
 
 	/* We've scanned the bus and so we know all about what's on the other
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Oct 21, 2009 at 10:32 AM, Hugh Greenberg h...@lanl.gov wrote:

 Attached is a patch that contains the extra debug statements I added.
  Below is the new output:

 before scan bus of PCI: 00:18.0
 In scan bus of PCI: 00:18.0

OK.  This next patch prints the location of scan_bus and puts some prints in
amdk8_scan_chain(s).

Thanks,
Myles
Index: svn/src/devices/device.c
===
--- svn.orig/src/devices/device.c
+++ svn/src/devices/device.c
@@ -847,14 +847,21 @@ unsigned int scan_bus(struct device *bus
 	do_scan_bus = 1;
 	while (do_scan_bus) {
 		int link;
+		printk_debug(In scan bus of %s\n, dev_path(busdev));
+		printk_debug(scan_bus() = %p\n, busdev-ops-scan_bus);
 		new_max = busdev-ops-scan_bus(busdev, max);
 		do_scan_bus = 0;
 		for (link = 0; link  busdev-links; link++) {
 			if (busdev-link[link].reset_needed) {
+			printk_debug(Reset needed for link device: %s\n,
+	 dev_path(busdev-link[link].dev));
+
 if (reset_bus(busdev-link[link])) {
 	do_scan_bus = 1;
 } else {
 	busdev-bus-reset_needed = 1;
+	printk_debug(Setting reset_needed for %s to 1\n,
+		 dev_path(busdev));
 }
 			}
 		}
Index: svn/src/devices/pci_device.c
===
--- svn.orig/src/devices/pci_device.c
+++ svn/src/devices/pci_device.c
@@ -1081,7 +1081,9 @@ unsigned int pci_scan_bus(struct bus *bu
 	 * scan the bus behind that child.
 	 */
 	for (child = bus-children; child; child = child-sibling) {
+		printk_debug(before scan bus of %s\n, dev_path(child));
 		max = scan_bus(child, max);
+	printk_debug(after scan bus of %s\n, dev_path(child));
 	}
 
 	/* We've scanned the bus and so we know all about what's on the other
Index: svn/src/northbridge/amd/amdk8/northbridge.c
===
--- svn.orig/src/northbridge/amd/amdk8/northbridge.c
+++ svn/src/northbridge/amd/amdk8/northbridge.c
@@ -93,19 +93,29 @@ static unsigned int amdk8_scan_chain(dev
 		unsigned min_bus;
 		unsigned max_devfn;
 
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
+
 		dev-link[link].cap = 0x80 + (link *0x20);
+		if (pci_read_config32(dev, dev-link[link].cap + 0x18) 
+		ConnectionPending)
+			printk_debug(%s: connection pending %s link %d\n,
+  __func__, dev_path(dev), link);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(link_type  ConnectionPending);
 		if (!(link_type  LinkConnected)) {
 			return max;
 		}
+		printk_debug(connected\n);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(!(link_type  InitComplete));
+		printk_debug(Init Complete\n);
 		if (!(link_type  NonCoherent)) {
 			return max;
 		}
+		printk_debug(non coherent\n);
 		/* See if there is an available configuration space mapping
 		 * register in function 1.
 		 */
@@ -199,6 +209,7 @@ static unsigned int amdk8_scan_chain(dev
 		else
 			max_devfn = (0x1f3) | 7;
 
+		printk_debug(scan chain\n);
 		max = hypertransport_scan_chain(dev-link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
 		/* We know the number of busses behind this bridge.  Set the
@@ -237,6 +248,8 @@ static unsigned int amdk8_scan_chains(de
 	unsigned offset_unitid = 0;
 	nodeid = amdk8_nodeid(dev);
 
+	printk_debug(%s: %s, node %d\n, __func__,
+		 dev_path(dev), nodeid);
 	if(nodeid==0) {
 		sblink = (pci_read_config32(dev, 0x64)8)  3;
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
@@ -248,6 +261,8 @@ static unsigned int amdk8_scan_chains(de
 	}
 
 	for(link = 0; link  dev-links; link++) {
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
 		if( (nodeid == 0)  (sblink == link) ) continue; //already done
 #endif
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Below is the end of the output.  I have no idea what coreboot_ram.map 
should look like, so I've attached that file.


before scan bus of PCI: 00:18.0
In scan bus of PCI: 00:18.0
scan_bus() = 0010131c
amdk8_scan_chains: PCI: 00:18.0, node 0
amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
connected
Init Complete
non coherent
scan chain

--
Hugh Greenberg


Myles Watson wrote:



On Wed, Oct 21, 2009 at 11:03 AM, Myles Watson myle...@gmail.com 
mailto:myle...@gmail.com wrote:




On Wed, Oct 21, 2009 at 10:32 AM, Hugh Greenberg h...@lanl.gov
mailto:h...@lanl.gov wrote:

Attached is a patch that contains the extra debug statements I
added.  Below is the new output:

before scan bus of PCI: 00:18.0
In scan bus of PCI: 00:18.0

OK.  This next patch prints the location of scan_bus

I forgot to say that you can look in build/coreboot_ram.map to see if 
the value matches what you expect.


Thanks,
Myles

 A CONFIG_ACPI_SSDTX_NUM
 A CONFIG_APIC_ID_OFFSET
 A CONFIG_AP_IN_SIPI_WAIT
 A CONFIG_COMPRESSED_PAYLOAD_NRV2B
 A CONFIG_CONSOLE_SERIAL_19200
 A CONFIG_CONSOLE_SERIAL_38400
 A CONFIG_CONSOLE_SERIAL_57600
 A CONFIG_CONSOLE_SERIAL_9600
 A CONFIG_CONSOLE_SERIAL_COM2
 A CONFIG_CONSOLE_SERIAL_COM3
 A CONFIG_CONSOLE_SERIAL_COM4
 A CONFIG_CONSOLE_VGA
 A CONFIG_CONSOLE_VGA_MULTI
 A CONFIG_CONSOLE_VGA_ONBOARD_AT_FIRST
 A CONFIG_COREBOOT_ROMSIZE_KB_1024
 A CONFIG_COREBOOT_ROMSIZE_KB_128
 A CONFIG_COREBOOT_ROMSIZE_KB_2048
 A CONFIG_COREBOOT_ROMSIZE_KB_256
 A CONFIG_COREBOOT_ROMSIZE_KB_4096
 A CONFIG_CPU_SOCKET_TYPE
 A CONFIG_DEBUG
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_0
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_1
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_2
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_3
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_4
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_5
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6
 A CONFIG_DEFAULT_CONSOLE_LOGLEVEL_7
 A CONFIG_EXPERT
 A CONFIG_HAVE_ACPI_RESUME
 A CONFIG_HAVE_FAILOVER_BOOT
 A CONFIG_HAVE_MAINBOARD_RESOURCES
 A CONFIG_HAVE_SMI_HANDLER
 A CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC
 A CONFIG_HW_MEM_HOLE_SIZEK
 A CONFIG_K8_REV_F_SUPPORT
 A CONFIG_LIFT_BSP_APIC_ID
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_0
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_1
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_2
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_3
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_4
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_5
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_6
 A CONFIG_MAXIMUM_CONSOLE_LOGLEVEL_7
 A CONFIG_MMCONF_SUPPORT
 A CONFIG_MMCONF_SUPPORT_DEFAULT
 A CONFIG_MULTIBOOT
 A CONFIG_PAYLOAD_NONE
 A CONFIG_PCI_64BIT_PREF_MEM
 A CONFIG_PCI_BUS_SEGN_BITS
 A CONFIG_PCI_IO_CFG_EXT
 A CONFIG_PCI_OPTION_ROM_RUN_X86EMU
 A CONFIG_PCI_OPTION_ROM_RUN_YABEL
 A CONFIG_PIRQ_ROUTE
 A CONFIG_SB_HT_CHAIN_ON_BUS0
 A CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2
 A CONFIG_UDELAY_IO
 A CONFIG_UDELAY_LAPIC
 A CONFIG_UDELAY_TSC
 A CONFIG_USBDEBUG_DIRECT
 A CONFIG_USE_FAILOVER_IMAGE
 A CONFIG_USE_INIT
 A CONFIG_USE_OPTION_TABLE
 A CONFIG_USE_WATCHDOG_ON_BOOT
 A CONFIG_VENDOR_ABIT
 A CONFIG_VENDOR_ADVANTECH
 A CONFIG_VENDOR_AMD
 A CONFIG_VENDOR_ARTEC_GROUP
 A CONFIG_VENDOR_ASI
 A CONFIG_VENDOR_ASUS
 A CONFIG_VENDOR_A_TREND
 A CONFIG_VENDOR_AXUS
 A CONFIG_VENDOR_AZZA
 A CONFIG_VENDOR_BCOM
 A CONFIG_VENDOR_BIOSTAR
 A CONFIG_VENDOR_BROADCOM
 A CONFIG_VENDOR_COMPAQ
 A CONFIG_VENDOR_DELL
 A CONFIG_VENDOR_DIGITAL_LOGIC
 A CONFIG_VENDOR_EAGLELION
 A CONFIG_VENDOR_EMULATION
 A CONFIG_VENDOR_GIGABYTE
 A CONFIG_VENDOR_HP
 A CONFIG_VENDOR_IBM
 A CONFIG_VENDOR_IEI
 A CONFIG_VENDOR_INTEL
 A CONFIG_VENDOR_IWILL
 A CONFIG_VENDOR_JETWAY
 A CONFIG_VENDOR_KONTRON
 A CONFIG_VENDOR_LIPPERT
 A CONFIG_VENDOR_MITAC
 A CONFIG_VENDOR_MSI
 A CONFIG_VENDOR_NEC
 A CONFIG_VENDOR_NEWISYS
 A CONFIG_VENDOR_NVIDIA
 A CONFIG_VENDOR_OLPC
 A CONFIG_VENDOR_PC_ENGINES
 A CONFIG_VENDOR_RCA
 A CONFIG_VENDOR_SOYO
 A CONFIG_VENDOR_SUNW
 A CONFIG_VENDOR_SUPERMICRO
 A CONFIG_VENDOR_TECHNEXION
 A CONFIG_VENDOR_TECHNOLOGIC
 A CONFIG_VENDOR_TELEVIDEO
 A CONFIG_VENDOR_THOMSON
 A CONFIG_VENDOR_TYAN
 A CONFIG_VENDOR_VIA
 A CONFIG_VGA
 A CONFIG_VGA_BIOS
 A 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Oct 21, 2009 at 11:37 AM, Hugh Greenberg h...@lanl.gov wrote:

 Below is the end of the output.  I have no idea what coreboot_ram.map
 should look like, so I've attached that file.

Thanks.  That was just in case amdk8_scan_chains wasn't being called, so we
could see why.  0010131c matches the value for amdk8_scan_chains, and it got
called, so we're good.


 before scan bus of PCI: 00:18.0
 In scan bus of PCI: 00:18.0
 scan_bus() = 0010131c
 amdk8_scan_chains: PCI: 00:18.0, node 0
 amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
 amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
 connected
 Init Complete
 non coherent
 scan chain


Here's the next step.  I took out a few of the print statements that we got
past.

Thanks,
Myles
Index: svn/src/devices/pci_device.c
===
--- svn.orig/src/devices/pci_device.c
+++ svn/src/devices/pci_device.c
@@ -1081,7 +1081,9 @@ unsigned int pci_scan_bus(struct bus *bu
 	 * scan the bus behind that child.
 	 */
 	for (child = bus-children; child; child = child-sibling) {
+		printk_debug(before scan bus of %s\n, dev_path(child));
 		max = scan_bus(child, max);
+printk_debug(after scan bus of %s\n, dev_path(child));
 	}
 
 	/* We've scanned the bus and so we know all about what's on the other
Index: svn/src/northbridge/amd/amdk8/northbridge.c
===
--- svn.orig/src/northbridge/amd/amdk8/northbridge.c
+++ svn/src/northbridge/amd/amdk8/northbridge.c
@@ -93,19 +93,29 @@ static unsigned int amdk8_scan_chain(dev
 		unsigned min_bus;
 		unsigned max_devfn;
 
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
+
 		dev-link[link].cap = 0x80 + (link *0x20);
+		if (pci_read_config32(dev, dev-link[link].cap + 0x18) 
+		ConnectionPending)
+			printk_debug(%s: connection pending %s link %d\n,
+  __func__, dev_path(dev), link);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(link_type  ConnectionPending);
 		if (!(link_type  LinkConnected)) {
 			return max;
 		}
+		printk_debug(connected\n);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(!(link_type  InitComplete));
+		printk_debug(Init Complete\n);
 		if (!(link_type  NonCoherent)) {
 			return max;
 		}
+		printk_debug(non coherent\n);
 		/* See if there is an available configuration space mapping
 		 * register in function 1.
 		 */
@@ -199,6 +209,7 @@ static unsigned int amdk8_scan_chain(dev
 		else
 			max_devfn = (0x1f3) | 7;
 
+		printk_debug(scan chain\n);
 		max = hypertransport_scan_chain(dev-link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
 		/* We know the number of busses behind this bridge.  Set the
@@ -237,6 +248,8 @@ static unsigned int amdk8_scan_chains(de
 	unsigned offset_unitid = 0;
 	nodeid = amdk8_nodeid(dev);
 
+	printk_debug(%s: %s, node %d\n, __func__,
+		 dev_path(dev), nodeid);
 	if(nodeid==0) {
 		sblink = (pci_read_config32(dev, 0x64)8)  3;
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
@@ -248,6 +261,8 @@ static unsigned int amdk8_scan_chains(de
 	}
 
 	for(link = 0; link  dev-links; link++) {
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
 		if( (nodeid == 0)  (sblink == link) ) continue; //already done
 #endif
Index: svn/src/devices/hypertransport.c
===
--- svn.orig/src/devices/hypertransport.c
+++ svn/src/devices/hypertransport.c
@@ -299,6 +299,11 @@ static void ht_collapse_early_enumeratio
 	prev.freq_off = PCI_HT_CAP_HOST_FREQ;
 	prev.freq_cap_off = PCI_HT_CAP_HOST_FREQ_CAP;
 
+	printk_debug(%s: %s children %s offset_unitid %d\n, __func__,
+		 dev_path(bus-dev), dev_path(bus-children), offset_unitid);
+	printk_debug(%s: ctrl = %x\n, __func__,
+		 pci_read_config16(prev.dev, prev.pos + prev.ctrl_off));
+
 	/* Wait until the link initialization is complete */
 	do {
 		ctrl = pci_read_config16(prev.dev, prev.pos + prev.ctrl_off);
@@ -401,6 +406,8 @@ unsigned int hypertransport_scan_chain(s
 	/* Restore the hypertransport chain to it's unitialized state */
 	ht_collapse_early_enumeration(bus, offset_unitid);
 
+	printk_debug(%s: %s children %s offset_unitid %d\n, __func__,
+		 dev_path(bus-dev), dev_path(bus-children), offset_unitid);
 	/* See which static device nodes I have */
 	old_devices = bus-children;
 	bus-children = 0;
@@ -449,10 +456,13 @@ unsigned int hypertransport_scan_chain(s
 			}
 		} while((ctrl  (1  5)) == 0);
 		
+		printk_debug(%s: link OK\n, __func__);
 
 		/* Get and setup the device_structure */
 		dev = ht_scan_get_devs(old_devices);
 
+		printk_debug(%s: dev = %s\n, dev_path(dev));
+		printk_debug(%s: old_devs = %s\n, dev_path(old_devices));
 		/* See if a device is present and setup the
 		 * device structure.
 		 */
-- 
coreboot mailing list: 

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Here is the new output:

before scan bus of PCI: 00:18.0
amdk8_scan_chains: PCI: 00:18.0, node 0
amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
connected
Init Complete
non coherent
scan chain
ht_collapse_early_enumeration: PCI: 00:18.0 children PCI: 00:18.0 
offset_unitid0

ht_collapse_early_enumeration: ctrl = 20

--
Hugh Greenberg



Myles Watson wrote:



On Wed, Oct 21, 2009 at 11:37 AM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Below is the end of the output.  I have no idea what
coreboot_ram.map should look like, so I've attached that file.

Thanks.  That was just in case amdk8_scan_chains wasn't being called, 
so we could see why.  0010131c matches the value for 
amdk8_scan_chains, and it got called, so we're good.
 


before scan bus of PCI: 00:18.0
In scan bus of PCI: 00:18.0
scan_bus() = 0010131c
amdk8_scan_chains: PCI: 00:18.0, node 0
amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
connected
Init Complete
non coherent
scan chain


Here's the next step.  I took out a few of the print statements that 
we got past.


Thanks,
Myles



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Oct 21, 2009 at 12:23 PM, Hugh Greenberg h...@lanl.gov wrote:

 Here is the new output:

 before scan bus of PCI: 00:18.0
 amdk8_scan_chains: PCI: 00:18.0, node 0
 amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
 amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
 connected
 Init Complete
 non coherent
 scan chain
 ht_collapse_early_enumeration: PCI: 00:18.0 children PCI: 00:18.0
 offset_unitid0
 ht_collapse_early_enumeration: ctrl = 20

And here's the next.

Thanks,
Myles
Index: svn/src/devices/pci_device.c
===
--- svn.orig/src/devices/pci_device.c
+++ svn/src/devices/pci_device.c
@@ -1081,7 +1081,9 @@ unsigned int pci_scan_bus(struct bus *bu
 	 * scan the bus behind that child.
 	 */
 	for (child = bus-children; child; child = child-sibling) {
+		printk_debug(before scan bus of %s\n, dev_path(child));
 		max = scan_bus(child, max);
+printk_debug(after scan bus of %s\n, dev_path(child));
 	}
 
 	/* We've scanned the bus and so we know all about what's on the other
Index: svn/src/northbridge/amd/amdk8/northbridge.c
===
--- svn.orig/src/northbridge/amd/amdk8/northbridge.c
+++ svn/src/northbridge/amd/amdk8/northbridge.c
@@ -93,19 +93,29 @@ static unsigned int amdk8_scan_chain(dev
 		unsigned min_bus;
 		unsigned max_devfn;
 
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
+
 		dev-link[link].cap = 0x80 + (link *0x20);
+		if (pci_read_config32(dev, dev-link[link].cap + 0x18) 
+		ConnectionPending)
+			printk_debug(%s: connection pending %s link %d\n,
+  __func__, dev_path(dev), link);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(link_type  ConnectionPending);
 		if (!(link_type  LinkConnected)) {
 			return max;
 		}
+		printk_debug(connected\n);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(!(link_type  InitComplete));
+		printk_debug(Init Complete\n);
 		if (!(link_type  NonCoherent)) {
 			return max;
 		}
+		printk_debug(non coherent\n);
 		/* See if there is an available configuration space mapping
 		 * register in function 1.
 		 */
@@ -199,6 +209,7 @@ static unsigned int amdk8_scan_chain(dev
 		else
 			max_devfn = (0x1f3) | 7;
 
+		printk_debug(scan chain\n);
 		max = hypertransport_scan_chain(dev-link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
 		/* We know the number of busses behind this bridge.  Set the
@@ -237,6 +248,8 @@ static unsigned int amdk8_scan_chains(de
 	unsigned offset_unitid = 0;
 	nodeid = amdk8_nodeid(dev);
 
+	printk_debug(%s: %s, node %d\n, __func__,
+		 dev_path(dev), nodeid);
 	if(nodeid==0) {
 		sblink = (pci_read_config32(dev, 0x64)8)  3;
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
@@ -248,6 +261,8 @@ static unsigned int amdk8_scan_chains(de
 	}
 
 	for(link = 0; link  dev-links; link++) {
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
 		if( (nodeid == 0)  (sblink == link) ) continue; //already done
 #endif
Index: svn/src/devices/hypertransport.c
===
--- svn.orig/src/devices/hypertransport.c
+++ svn/src/devices/hypertransport.c
@@ -299,6 +299,11 @@ static void ht_collapse_early_enumeratio
 	prev.freq_off = PCI_HT_CAP_HOST_FREQ;
 	prev.freq_cap_off = PCI_HT_CAP_HOST_FREQ_CAP;
 
+	printk_debug(%s: %s children %s offset_unitid %d\n, __func__,
+		 dev_path(bus-dev), dev_path(bus-children), offset_unitid);
+	printk_debug(%s: ctrl = %x\n, __func__,
+		 pci_read_config16(prev.dev, prev.pos + prev.ctrl_off));
+
 	/* Wait until the link initialization is complete */
 	do {
 		ctrl = pci_read_config16(prev.dev, prev.pos + prev.ctrl_off);
@@ -332,6 +337,7 @@ static void ht_collapse_early_enumeratio
 }
 #endif
 
+	printk_debug(Check collapse state\n);
 /* Check if is already collapsed */
 if((!offset_unitid)|| (offset_unitid  (!((CONFIG_HT_CHAIN_END_UNITID_BASE == 0)  (CONFIG_HT_CHAIN_END_UNITID_BASE CONFIG_HT_CHAIN_UNITID_BASE) {
 struct device dummy;
@@ -339,7 +345,9 @@ static void ht_collapse_early_enumeratio
 dummy.bus  = bus;
 dummy.path.type= DEVICE_PATH_PCI;
 dummy.path.pci.devfn = PCI_DEVFN(0, 0);
+		printk_debug(Check collapse state pci_read\n);
 id = pci_read_config32(dummy, PCI_VENDOR_ID);
+		printk_debug(Check collapse state after pci_read\n);
 if ( ! ( (id == 0x) || (id == 0x) ||
 (id == 0x) || (id == 0x) ) ) {
  return;
@@ -349,6 +357,7 @@ static void ht_collapse_early_enumeratio
 	/* Spin through the devices and collapse any early
 	 * hypertransport enumeration.
 	 */
+	printk_debug(Collapsing devs\n);
 	

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Here is the output:

before scan bus of PCI: 00:18.0
amdk8_scan_chains: PCI: 00:18.0, node 0
amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
connected
Init Complete
non coherent
scan chain
ht_collapse_early_enumeration: PCI: 00:18.0 children PCI: 00:18.0 
offset_unitid0

ht_collapse_early_enumeration: ctrl = 20
Check collapse state
Check collapse state pci_read
pci_remember_direct: pci_bus_fallback_ops=
pci_check_direct

--
Hugh Greenberg




Myles Watson wrote:



On Wed, Oct 21, 2009 at 12:23 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Here is the new output:


before scan bus of PCI: 00:18.0
amdk8_scan_chains: PCI: 00:18.0, node 0
amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
connected
Init Complete
non coherent
scan chain
ht_collapse_early_enumeration: PCI: 00:18.0 children PCI: 00:18.0
offset_unitid0
ht_collapse_early_enumeration: ctrl = 20

And here's the next.

Thanks,
Myles



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Oct 21, 2009 at 2:21 PM, Hugh Greenberg h...@lanl.gov wrote:

 Here is the output:

 before scan bus of PCI: 00:18.0
 amdk8_scan_chains: PCI: 00:18.0, node 0
 amdk8_scan_chains: PCI: 00:18.0, node 0, link 0
 amdk8_scan_chain: PCI: 00:18.0, node 0, link 0
 connected
 Init Complete
 non coherent
 scan chain
 ht_collapse_early_enumeration: PCI: 00:18.0 children PCI: 00:18.0
 offset_unitid0
 ht_collapse_early_enumeration: ctrl = 20
 Check collapse state
 Check collapse state pci_read
 pci_remember_direct: pci_bus_fallback_ops=
 pci_check_direct

It looks like it's dying in pci_check_direct.  Hopefully we're getting
close.  Here's another patch.

Thanks,
Myles
Index: svn/src/devices/pci_device.c
===
--- svn.orig/src/devices/pci_device.c
+++ svn/src/devices/pci_device.c
@@ -1081,7 +1081,9 @@ unsigned int pci_scan_bus(struct bus *bu
 	 * scan the bus behind that child.
 	 */
 	for (child = bus-children; child; child = child-sibling) {
+		printk_debug(before scan bus of %s\n, dev_path(child));
 		max = scan_bus(child, max);
+printk_debug(after scan bus of %s\n, dev_path(child));
 	}
 
 	/* We've scanned the bus and so we know all about what's on the other
Index: svn/src/northbridge/amd/amdk8/northbridge.c
===
--- svn.orig/src/northbridge/amd/amdk8/northbridge.c
+++ svn/src/northbridge/amd/amdk8/northbridge.c
@@ -93,19 +93,29 @@ static unsigned int amdk8_scan_chain(dev
 		unsigned min_bus;
 		unsigned max_devfn;
 
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
+
 		dev-link[link].cap = 0x80 + (link *0x20);
+		if (pci_read_config32(dev, dev-link[link].cap + 0x18) 
+		ConnectionPending)
+			printk_debug(%s: connection pending %s link %d\n,
+  __func__, dev_path(dev), link);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(link_type  ConnectionPending);
 		if (!(link_type  LinkConnected)) {
 			return max;
 		}
+		printk_debug(connected\n);
 		do {
 			link_type = pci_read_config32(dev, dev-link[link].cap + 0x18);
 		} while(!(link_type  InitComplete));
+		printk_debug(Init Complete\n);
 		if (!(link_type  NonCoherent)) {
 			return max;
 		}
+		printk_debug(non coherent\n);
 		/* See if there is an available configuration space mapping
 		 * register in function 1.
 		 */
@@ -199,6 +209,7 @@ static unsigned int amdk8_scan_chain(dev
 		else
 			max_devfn = (0x1f3) | 7;
 
+		printk_debug(scan chain\n);
 		max = hypertransport_scan_chain(dev-link[link], 0, max_devfn, max, ht_unitid_base, offset_unitid);
 
 		/* We know the number of busses behind this bridge.  Set the
@@ -237,6 +248,8 @@ static unsigned int amdk8_scan_chains(de
 	unsigned offset_unitid = 0;
 	nodeid = amdk8_nodeid(dev);
 
+	printk_debug(%s: %s, node %d\n, __func__,
+		 dev_path(dev), nodeid);
 	if(nodeid==0) {
 		sblink = (pci_read_config32(dev, 0x64)8)  3;
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
@@ -248,6 +261,8 @@ static unsigned int amdk8_scan_chains(de
 	}
 
 	for(link = 0; link  dev-links; link++) {
+		printk_debug(%s: %s, node %d, link %d\n, __func__,
+			 dev_path(dev), nodeid, link);
 #if CONFIG_SB_HT_CHAIN_ON_BUS0  0
 		if( (nodeid == 0)  (sblink == link) ) continue; //already done
 #endif
Index: svn/src/devices/hypertransport.c
===
--- svn.orig/src/devices/hypertransport.c
+++ svn/src/devices/hypertransport.c
@@ -299,6 +299,11 @@ static void ht_collapse_early_enumeratio
 	prev.freq_off = PCI_HT_CAP_HOST_FREQ;
 	prev.freq_cap_off = PCI_HT_CAP_HOST_FREQ_CAP;
 
+	printk_debug(%s: %s children %s offset_unitid %d\n, __func__,
+		 dev_path(bus-dev), dev_path(bus-children), offset_unitid);
+	printk_debug(%s: ctrl = %x\n, __func__,
+		 pci_read_config16(prev.dev, prev.pos + prev.ctrl_off));
+
 	/* Wait until the link initialization is complete */
 	do {
 		ctrl = pci_read_config16(prev.dev, prev.pos + prev.ctrl_off);
@@ -332,6 +337,7 @@ static void ht_collapse_early_enumeratio
 }
 #endif
 
+	printk_debug(Check collapse state\n);
 /* Check if is already collapsed */
 if((!offset_unitid)|| (offset_unitid  (!((CONFIG_HT_CHAIN_END_UNITID_BASE == 0)  (CONFIG_HT_CHAIN_END_UNITID_BASE CONFIG_HT_CHAIN_UNITID_BASE) {
 struct device dummy;
@@ -339,7 +345,9 @@ static void ht_collapse_early_enumeratio
 dummy.bus  = bus;
 dummy.path.type= DEVICE_PATH_PCI;
 dummy.path.pci.devfn = PCI_DEVFN(0, 0);
+		printk_debug(Check collapse state pci_read\n);
 id = pci_read_config32(dummy, PCI_VENDOR_ID);
+		printk_debug(Check collapse state after pci_read\n);
 if ( ! ( (id == 0x) || (id == 0x) ||
 (id == 0x) || (id == 0x) ) ) {
  return;

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

On Wed, Oct 21, 2009 at 3:03 PM, Hugh Greenberg h...@lanl.gov wrote:

 Alight!  It booted and loaded seabios.  Attached is the entire output.

Great.  So the two problems were init_timer and pci_check_direct, right?

I've attached the two patches.

Signed-off-by: Myles Watson myle...@gmail.com


  One thing though, it failed to load gpxe.  The only thing related to this
 that looks like an error is:

 File pci14e4,16a6.rom is of type 6300 instead oftype 30
 and this
 PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x
 Incorrect Expansion ROM Header Signature 

This should be OK because you don't want it to run before Coreboot is
through.  I think SeaBIOS should run it, right?

I don't know anything about gpxe.  I'm assuming you followed the
instructions here:
http://www.coreboot.org/SeaBIOS#Adding_gpxe_support

Did you try pushing f12 to see the boot menu?

Thanks,
Myles
Index: svn/src/arch/i386/lib/pci_ops_auto.c
===
--- svn.orig/src/arch/i386/lib/pci_ops_auto.c
+++ svn/src/arch/i386/lib/pci_ops_auto.c
@@ -47,6 +47,9 @@ const struct pci_bus_operations *pci_che
 {
 	unsigned int tmp;
 
+	printk_debug(%s\n, __func__);
+	printk_debug(PCI: Forcing configuration type 1\n);
+	return pci_cf8_conf1;
 	/*
 	 * Check if configuration type 1 works.
 	 */
Index: svn/src/mainboard/arima/hdama/cache_as_ram_auto.c
===
--- svn.orig/src/mainboard/arima/hdama/cache_as_ram_auto.c
+++ svn/src/mainboard/arima/hdama/cache_as_ram_auto.c
@@ -157,33 +157,22 @@ void cache_as_ram_main(unsigned long bis
 
 void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
 {
-	static const struct mem_controller cpu[] = {
-		{
-			.node_id = 0,
-			.f0 = PCI_DEV(0, 0x18, 0),
-			.f1 = PCI_DEV(0, 0x18, 1),
-			.f2 = PCI_DEV(0, 0x18, 2),
-			.f3 = PCI_DEV(0, 0x18, 3),
-			.channel0 = { (0xa3)|0, (0xa3)|2, 0, 0 },
-			.channel1 = { (0xa3)|1, (0xa3)|3, 0, 0 },
-		},
+	static const uint16_t spd_addr [] = {
+		(0xa3)|0, (0xa3)|2, 0, 0,
+		(0xa3)|1, (0xa3)|3, 0, 0,
 #if CONFIG_MAX_PHYSICAL_CPUS  1
-		{
-			.node_id = 1,
-			.f0 = PCI_DEV(0, 0x19, 0),
-			.f1 = PCI_DEV(0, 0x19, 1),
-			.f2 = PCI_DEV(0, 0x19, 2),
-			.f3 = PCI_DEV(0, 0x19, 3),
-			.channel0 = { (0xa3)|4, (0xa3)|6, 0, 0 },
-			.channel1 = { (0xa3)|5, (0xa3)|7, 0, 0 },
-		},
+		(0xa3)|4, (0xa3)|6, 0, 0,
+		(0xa3)|5, (0xa3)|7, 0, 0,
 #endif
 	};
 
 int needs_reset;
+	unsigned bsp_apicid = 0;
+	struct mem_controller ctrl[8];
+	unsigned nodes;
 
 if (bist == 0) {
-		init_cpus(cpu_init_detectedx);
+		bsp_apicid = init_cpus(cpu_init_detectedx);
 }
 
 	pc87360_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
@@ -200,7 +189,10 @@ void real_main(unsigned long bist, unsig
 #if CONFIG_LOGICAL_CPUS==1
 // It is said that we should start core1 after all core0 launched
 start_other_cores();
+	wait_all_other_cores_started(bsp_apicid);
 #endif
+	init_timer();  /* This is needed to be able to call udelay() */
+
 // automatically set that for you, but you might meet tight space
 needs_reset |= ht_setup_chains_x();
 
@@ -209,11 +201,17 @@ void real_main(unsigned long bist, unsig
	soft_reset();
	}
 
+	allow_all_aps_stop(bsp_apicid);
+
+	nodes = get_nodes();
+
+	fill_mem_ctrl(nodes, ctrl, spd_addr);
+
 	enable_smbus();
 
 	memreset_setup();
-	sdram_initialize(ARRAY_SIZE(cpu), cpu);
 
-	post_cache_as_ram();
+	sdram_initialize(nodes, ctrl);
 
+	post_cache_as_ram();
 }
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

Yeah, those two patches solved the problem.  Thank you very much for 
your help with this.  I followed those directions, but still no luck. 
I'll keep working at it.


--
Hugh Greenberg


Myles Watson wrote:



On Wed, Oct 21, 2009 at 3:03 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Alight!  It booted and loaded seabios.  Attached is the entire
output. 


Great.  So the two problems were init_timer and pci_check_direct, right?

I've attached the two patches.

Signed-off-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com
 


 One thing though, it failed to load gpxe.  The only thing related
to this that looks like an error is:

File pci14e4,16a6.rom is of type 6300 instead oftype 30
and this
PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x
Incorrect Expansion ROM Header Signature 

This should be OK because you don't want it to run before Coreboot is 
through.  I think SeaBIOS should run it, right?
 
I don't know anything about gpxe.  I'm assuming you followed the 
instructions here:

http://www.coreboot.org/SeaBIOS#Adding_gpxe_support

Did you try pushing f12 to see the boot menu?

Thanks,
Myles



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

While I was just trying to get seabios to boot gpxe, coreboot hung at 
the same spot.  It seems to happen randomly now, not every time it boots 
like before.


--
Hugh Greenberg




Myles Watson wrote:



On Wed, Oct 21, 2009 at 3:03 PM, Hugh Greenberg h...@lanl.gov 
mailto:h...@lanl.gov wrote:


Alight!  It booted and loaded seabios.  Attached is the entire
output. 


Great.  So the two problems were init_timer and pci_check_direct, right?

I've attached the two patches.

Signed-off-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com
 


 One thing though, it failed to load gpxe.  The only thing related
to this that looks like an error is:

File pci14e4,16a6.rom is of type 6300 instead oftype 30
and this
PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x
Incorrect Expansion ROM Header Signature 

This should be OK because you don't want it to run before Coreboot is 
through.  I think SeaBIOS should run it, right?
 
I don't know anything about gpxe.  I'm assuming you followed the 
instructions here:

http://www.coreboot.org/SeaBIOS#Adding_gpxe_support

Did you try pushing f12 to see the boot menu?

Thanks,
Myles



--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Myles Watson]

 While I was just trying to get seabios to boot gpxe, coreboot hung at
 the same spot.  It seems to happen randomly now, not every time it boots
 like before.
Too bad.

I guess put all the debugging back in and see if it still hangs randomly,
and if it is exactly the same spot.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Hugh Greenberg]

I'm having a hard time reproducing it now. I'll post something when/if I 
have the output with the debug info.


--
Hugh Greenberg




Myles Watson wrote:

While I was just trying to get seabios to boot gpxe, coreboot hung at
the same spot.  It seems to happen randomly now, not every time it boots
like before.


Too bad.

I guess put all the debugging back in and see if it still hangs randomly,
and if it is exactly the same spot.

Thanks,
Myles

  


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Peter Stuge]

Hugh Greenberg wrote:
 File pci14e4,16a6.rom is of type 6300 instead oftype 30
 and this
 PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x
 Incorrect Expansion ROM Header Signature 

 I got this file from gpxe's rom O matic.  I tried getting a new one
 just in case and got the same error.

IIRC this is a known problem (by us) but there hasn't been much
effort in getting it fixed with GPXE. There is a script in the
SeaBIOS source tree which can fix up checksums, maybe you can try
using that - and if it works send a hint to GPXE?


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

[Kevin O'Connor]

On Wed, Oct 21, 2009 at 03:03:44PM -0600, Hugh Greenberg wrote:
 Alight!  It booted and loaded seabios.  Attached is the entire output.   
 One thing though, it failed to load gpxe.  The only thing related to  
 this that looks like an error is:

 File pci14e4,16a6.rom is of type 6300 instead oftype 30
 and this
 PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x
 Incorrect Expansion ROM Header Signature 

 I got this file from gpxe's rom O matic.  I tried getting a new one just  
 in case and got the same error.

Please compile SeaBIOS with the debug level set to 8 (#define
CONFIG_DEBUG_LEVEL 8 in src/config.h) and then resend the full output.

-Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot