Hello, Marc > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Marc Jones > Sent: Thursday, January 19, 2012 2:28 AM > To: Wolfgang Kamp - datakamp > Cc: [email protected] > Subject: Re: [coreboot] Issue with CIMX/SB800 PCIe Port Initialization > > On Wed, Jan 18, 2012 at 8:11 AM, Wolfgang Kamp - datakamp > <[email protected]> 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:[email protected]] > > Gesendet: Mittwoch, 18. Januar 2012 08:49 > > An: She, Kerry; Marc Jones; Wolfgang Kamp - datakamp > > Cc: [email protected]; chia, kenneth > > Betreff: Re: [coreboot] Issue with CIMX/SB800 PCIe Port Initialization > > > > Hello Marc and Wolfgang > > > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] > >> On Behalf Of She, Kerry > >> Sent: Tuesday, January 17, 2012 4:07 PM > >> To: Marc Jones; Wolfgang Kamp - datakamp > >> Cc: [email protected] > >> Subject: Re: [coreboot] Issue with CIMX/SB800 PCIe Port Initialization > >> > >> Hello Walfqang, > >> > >> > -----Original Message----- > >> > From: [email protected] [mailto:coreboot- > >> [email protected]] > >> > On Behalf Of Marc Jones > >> > Sent: Tuesday, January 17, 2012 3:23 AM > >> > To: Wolfgang Kamp - datakamp > >> > Cc: [email protected] > >> > Subject: Re: [coreboot] Issue with CIMX/SB800 PCIe Port > >> > Initialization > >> > > >> > On Mon, Jan 16, 2012 at 10:18 AM, Wolfgang Kamp - datakamp > >> > <[email protected]> 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: [email protected] > > http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > http://se-eng.com > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
