[coreboot] Issue with CIMX/SB800 PCIe Port Initialization

[She, Kerry]

Hello, Marc

> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of Marc Jones
> Sent: Thursday, January 19, 2012 2:28 AM
> To: Wolfgang Kamp - datakamp
> Cc: coreboot at coreboot.org
> Subject: Re: [coreboot] Issue with CIMX/SB800 PCIe Port Initialization
> 
> On Wed, Jan 18, 2012 at 8:11 AM, Wolfgang Kamp - datakamp
> <wmkamp at datakamp.de> wrote:
> > Hello Kerry, hello Marc,
> >
> > sounds good but solves not my problem. The enumeration of the SB800 GPP
> ports works fine with Linux.
> > But coreboot fails because the SB GPP ports are not yet initialized
> when coreboot probes them.
> > The function sbPcieGppEarlyInit will be executed after coreboot PCI
> probing of the SB GPP ports.
> > You can see that in late.c.
> > I put that function now in the right place in the case (0x15<<0 | 0)
> statement so probing succeeds.
> > And my Intel LAN GB82574 will be enumerated as I can see in the log.
> > But if I do that coreboot hangs in tables.c with postcode 0x9c and I
> can't imagine why.
> > I need the correct enumeration in coreboot because the Intel LAN chip
> tools only works under DOS.
> >
> > Wolfgang
> >
> 
> Kerry,
> 
> I agree with Wolfgang. I think that the sb800 has an issue.
> 
> >> > The sb900 wrapper appears to fix this issue with cimx setup in early
> init.
Yes, sb900 put the sb_before_pci_init wrapper call at romstage.
The problem is we can't get the configuration information from devicetree.cb in this way,
all the configuration option is defined in a header file.


> The device isn't visible in late init. The coreboot chip device scan
> will disable the device when it isn't found. The configuration needs
> to be set in early init like the sb900. Do you agree?
I think this is a compromise choice, we can unhide/hide the gpp device according to the devicetree.cb setting in sb800 dev_enable(), and then call the cimx function.


BTW. We using this way in the RD890 wrapper.
Thanks

Kerry

> Marc
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: She, Kerry [mailto:Kerry.She at amd.com]
> > Gesendet: Mittwoch, 18. Januar 2012 08:49
> > An: She, Kerry; Marc Jones; Wolfgang Kamp - datakamp
> > Cc: coreboot at coreboot.org; chia, kenneth
> > Betreff: Re: [coreboot] Issue with CIMX/SB800 PCIe Port Initialization
> >
> > Hello Marc and Wolfgang
> >
> >> -----Original Message-----
> >> From: coreboot-bounces at coreboot.org
> >> [mailto:coreboot-bounces at coreboot.org]
> >> On Behalf Of She, Kerry
> >> Sent: Tuesday, January 17, 2012 4:07 PM
> >> To: Marc Jones; Wolfgang Kamp - datakamp
> >> Cc: coreboot at coreboot.org
> >> Subject: Re: [coreboot] Issue with CIMX/SB800 PCIe Port Initialization
> >>
> >> Hello Walfqang,
> >>
> >> > -----Original Message-----
> >> > From: coreboot-bounces at coreboot.org [mailto:coreboot-
> >> bounces at coreboot.org]
> >> > On Behalf Of Marc Jones
> >> > Sent: Tuesday, January 17, 2012 3:23 AM
> >> > To: Wolfgang Kamp - datakamp
> >> > Cc: coreboot at coreboot.org
> >> > Subject: Re: [coreboot] Issue with CIMX/SB800 PCIe Port
> >> > Initialization
> >> >
> >> > On Mon, Jan 16, 2012 at 10:18 AM, Wolfgang Kamp - datakamp
> >> > <wmkamp at datakamp.de> wrote:
> >> > > Hello,
> >> > >
> >> > >
> >> > >
> >> > > I found a problem with the PCI enumeration of the PCIe Ports in
> >> > > the CIMX/SB800 Southbridge for the INAGUA platform.
> >> > >
> >> > > The .../southbridge/amd/cimx/sb800/late.c routine calls the
> >> > > function sb_Before_PCI_Init after
> >> > >
> >> > > case (0x16 >>3) | 2. This means when the PCI Express ports (0x15
> >> > > <<3)
> >> |
> >> > 0
> >> > > are probed in the routine ../devices/pci_device.c function
> >> > >
> >> > > pci_probe_dev they are not yet initialized. The probing fails and
> >> also
> >> > > devices behind the bridge are not recognized.
> >> > >
> >> > > Behind the PCIe bridge I have an Intel 82574 LAN chip.
> >> > >
> >> > > But if I move the call to sb_Before_PCI_Init behind case  (0x15
> >> > > <<3)
> >> |
> >> > 0 the
> >> > > enumeration succeed but coreboot crashes later into nothing. The
> >> > > Sage Debugger fails.
> >> > >
> >> > > I can't imagine why.
> >> > >
> >> > >
> >> > >
> >> > > Marc have you any idea?
> >> >
> >> > This looks like a problem in the sb800 cimx wrapper logic. Cimx
> >> > doesn't treat the devices separately. it lumps all the configuration
> >> > and enables together, making the coreboot chipset device enable
> >> > callback fail to enable the device, so it gets disabled. The sb900
> >> > wrapper appears to fix this issue with cimx setup in early init. You
> >> > may want to try porting those changes to the sb800.
> >> >
> >> > I don't know why it fails later, but I assume it is due to the
> >> > missing config since you moved the call earlier in the process. You
> >> > could try calling it multiple times. I'm not sure how it handles
> that, though.
> >> >
> >> > Kerry,
> >> > Do you have any comments?
> >> If the enumeration fail, I suggest you should check the PCIE deassert
> >> GPIO setting.
> >> Thanks
> >
> > I found the recent amd/inagua code in the git tree is not boot on my
> platform and more.
> > I made an update to make my platform works now.
> > The missing mainboard specific GPIO setting also added back, So the
> sb800 GPP enumeration works now.
> >
> > Please reference following link and the attachment.
> > http://review.coreboot.org/#change,542
> > http://review.coreboot.org/#change,543
> > http://review.coreboot.org/#change,544
> > http://review.coreboot.org/#change,545
> > http://review.coreboot.org/#change,546
> >
> > Thanks
> > Kerry
> >
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> 
> 
> 
> --
> http://se-eng.com
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot