Patchwork fam10/newconfig on supermicro h8dme - early hang

> Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that
> conditional
> on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed
> that.
> 
> Should this go into the tree?
> 
> --- northbridge/amd/amdfam10/northbridge.c (revision 4978)
> +++ northbridge/amd/amdfam10/northbridge.c (working copy)
> @@ -31,10 +31,10 @@
> 
>  #include <cpu/x86/lapic.h>
> 
> -#if CONFIG_LOGICAL_CPUS==1
>  #include <cpu/amd/quadcore.h>
>  #include <pc80/mc146818rtc.h>
> -#endif
> 
>  #include "chip.h"
>  #include "root_complex/chip.h"

I like just moving the endif to protect nb_cfg_54, if it would work.  It
compiles for me.

 	//    still be 0)
@@ -1243,6 +1242,7 @@
 	//    and differ d0 and e0 single core
 
 	nb_cfg_54 = read_nb_cfg_54();
+#endif
 
 #if CONFIG_CBB
 	dev_mc = dev_find_slot(0, PCI_DEVFN(CONFIG_CDB, 0)); //0x00


> 
> > > and by adding a return at the very beginning of start_other_cores in
> > >
> > >   cpu/amd/quadcore/quadcore.c
> > >
> > > which gets me a bit further, but not much. It hangs in the
> > > mcp55_early_pcie_setup function in
> > >
> > >   southbridge/nvidia/mcp55/mcp55_early_setup_car.c
> > >
> > > Log attached. Anything else I should try?
> >
> > If inl and outl are hanging, I would dump the routing registers and read
> the
> > device's IDs to see what's going wrong.  I'm not very familiar with how
> the
> > fam10 code works, but dumping the routing registers should be mostly cut
> and
> > paste from the k8/util.c code.
> 
> Right. I've done that - log attached. I'm dumping with
> 
>     showallroutes(BIOS_DEBUG, PCI_DEV(0, 0x18, 1));
> 
> I'm not sure what to make of the dump though (attached).
MMIO(b8)0000000000-31a4f2ffff, ->(0,1), , , CPU disable 0, Lock 0, Non
posted 0

This is broken, but I'm not sure if it's the dump or the register value.  It
shouldn't affect the IO, though.  That register looked fine.  It seems like
IO is broken for you not to be able to start the other processors or
complete the mcp55 init.

You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower
bits are what you expect.  The ones I'd look at are the default link (bits
11,3,2), disable routing bit (bit 0).

The default link should be 2.  The disable routing bit can tell you if it's
important that the routing registers are messed up.

Thanks,
Myles

On Tue, Dec 22, 2009 at 04:11:06PM -0700, Myles Watson wrote:
> > Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that
> > conditional
> > on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed
> > that.
> > 
> > Should this go into the tree?
> > 
> > --- northbridge/amd/amdfam10/northbridge.c (revision 4978)
> > +++ northbridge/amd/amdfam10/northbridge.c (working copy)
> > @@ -31,10 +31,10 @@
> > 
> >  #include <cpu/x86/lapic.h>
> > 
> > -#if CONFIG_LOGICAL_CPUS==1
> >  #include <cpu/amd/quadcore.h>
> >  #include <pc80/mc146818rtc.h>
> > -#endif
> > 
> >  #include "chip.h"
> >  #include "root_complex/chip.h"
> 
> I like just moving the endif to protect nb_cfg_54, if it would work.  It
> compiles for me.
> 
> --- northbridge/amd/amdfam10/northbridge.c (revision 4978)
> +++ northbridge/amd/amdfam10/northbridge.c (working copy)
> @@ -1235,7 +1235,6 @@
>  	disable_siblings = !CONFIG_LOGICAL_CPUS;
>  #if CONFIG_LOGICAL_CPUS == 1
>  	get_option(&disable_siblings, "quad_core");
> -#endif
>  
>  	// for pre_e0, nb_cfg_54 can not be set, ( even set, when you read
> it
>  	//    still be 0)
> @@ -1243,6 +1242,7 @@
>  	//    and differ d0 and e0 single core
>  
>  	nb_cfg_54 = read_nb_cfg_54();
> +#endif
>  
>  #if CONFIG_CBB
>  	dev_mc = dev_find_slot(0, PCI_DEVFN(CONFIG_CDB, 0)); //0x00

OK - with that patch it builds and boots, and the output looks similar (but
not identical. See

  http://ward.vandewege.net/coreboot/h8dme/fam10/minicom-20091222af-ram-on-both-cpus.cap

The only difference is this

-MMIO(b8)0000000000-31a4f2ffff, ->(0,1), , , CPU disable 0, Lock 0, Non
posted 0
+MMIO(b8)0000000000-31a6b2ffff, ->(0,1), , , CPU disable 0, Lock 0, Non
posted 1

which may be entirely unrelated?

I'll look at that other register tomorrow.

Thanks!
Ward.

On Tue, Dec 22, 2009 at 04:11:06PM -0700, Myles Watson wrote:
> This is broken, but I'm not sure if it's the dump or the register value.  It
> shouldn't affect the IO, though.  That register looked fine.  It seems like
> IO is broken for you not to be able to start the other processors or
> complete the mcp55 init.
> 
> You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower
> bits are what you expect.  The ones I'd look at are the default link (bits
> 11,3,2), disable routing bit (bit 0).
> 
> The default link should be 2.  The disable routing bit can tell you if it's
> important that the routing registers are messed up.

Hrm. If I'm reading that right with this code

  u32 xxx = pci_read_config32(PCI_DEV(0, 0x18, 0), 0x6c);
  printk_debug("0x%04x\n",xxx);

then what comes out does not look very good:

  0xf870

which is

  1111100001110000

So the default link is 0, and the Routing Table Disable bit is set to zero.

You mentioned bit 11 - that seems to be marked as 'reserved' in the BKDG for
fam10?

Thanks,
Ward.

> > This is broken, but I'm not sure if it's the dump or the register value.
> It
> > shouldn't affect the IO, though.  That register looked fine.  It seems
> like
> > IO is broken for you not to be able to start the other processors or
> > complete the mcp55 init.
> >
> > You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower
> > bits are what you expect.  The ones I'd look at are the default link
> (bits
> > 11,3,2), disable routing bit (bit 0).
> >
> > The default link should be 2.  The disable routing bit can tell you if
> it's
> > important that the routing registers are messed up.
> 
> Hrm. If I'm reading that right with this code
> 
>   u32 xxx = pci_read_config32(PCI_DEV(0, 0x18, 0), 0x6c);
>   printk_debug("0x%04x\n",xxx);
That looks right.

> then what comes out does not look very good:
> 
>   0xf870
> 
> which is
> 
>   1111100001110000
That looks pretty broken.  Bits 12-15 are reserved according to the BKDG I
have.  Maybe you should try printing those values earlier?  I don't know
what's going on to get such strange values.
 
> So the default link is 0, and the Routing Table Disable bit is set to
> zero.
> 
> You mentioned bit 11 - that seems to be marked as 'reserved' in the BKDG
> for fam10?
In the version I have it's marked as read only.

Thanks,
Myles