[U-Boot] MPC8555 pci issue
Scott Wood
scottwood at freescale.com
Tue Jan 8 21:02:52 CET 2013
On 01/03/2013 07:03:49 AM, Ashok Kumar Kacham wrote:
>
> Dear Wolfgang Denk
>
> > Dear "Ashok Kumar Kacham",
> >
> > In message
> <0969b5bdd1b15922721db142831c3b02.squirrel at mail.bel.co.in> you
> > wrote:
> >>
> >> Hi all,
> >>
> >> we have a pci-to-usb controller(32bit,33MHZ,PCI1 controller, IDSEL
> 18)
> >> on
> >> pci bus, we disabled PCI and tried to read the configuration
> data(vendor
> >> and
> >> device id) of the usb controller by giving following commands.
> >> (0xe0000000 is the CCSR base address)
What happens if you don't disable PCI?
> same thing is working in one of our MPC8540 based board, where we are
> able
> to read the vendor id and device id of the pci device properly.
With PCI disabled?
Are you sure you have the right IDSEL? Do you have PCI errors disabled
so that you'll get 0xffffffff rather than a machine check if nothing
responds?
Oh, and there's this comment in arch/powerpc/cpu/mpc85xx/pci.c:
#if defined(CONFIG_MPC8555CDS) || defined(CONFIG_MPC8541CDS)
/*
* This is a SW workaround for an apparent HW problem
* in the PCI controller on the MPC85555/41 CDS boards.
* The first config cycle must be to a valid, known
* device on the PCI bus in order to trick the PCI
* controller state machine into a known valid state.
* Without this, the first config cycle has the chance
* of hanging the controller permanently, just leaving
* it in a semi-working state, or leaving it working.
*
* Pick on the Tundra, Device 17, to get it right.
*/
{
u8 header_type;
pci_hose_read_config_byte(hose,
PCI_BDF(0,BRIDGE_ID,0),
PCI_HEADER_TYPE,
&header_type);
}
#endif
-Scott
More information about the U-Boot
mailing list