We have actually determined the problem with our board... and it was much simplier than expected.
a) some initialization code was doing the wrong thing to some configuration space registers b) the root 8548 PCI registers were being overwritten by some process that disabled memory accesses for this bus.... I now have it working very nicely...except for a small problem that I am trying to solve right now... Tom Ps: to answer your question about the 48MHZ Clock - the EXT2 register (0xe0 offset) in the PCI configuration space for the EHCI host controller has a bit selection for 30MHZ vs. 48Mhz. There is an app note about this (can't seem to find the notation that indicates this specific part will 'freeze' if this is NOT set before starting memory accesses... I've added a quirk for this in our custom BSP to make sure this is set correctly... -----Original Message----- From: David Brownell [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 6:08 PM To: Morrison, Tom Cc: linux-usb@vger.kernel.org Subject: Re: Problem with NEC PCI USB 72010 (linux 2.6.23.8) On Wednesday 16 January 2008, Morrison, Tom wrote: > Hi, > > I tried to look through archives - and I did not see the exact problem > that I am experiencing in there (although there might be some very > similar ones): Summarizing: both EHCI and OHCI controllers got fatal error IRQs. Those are the type of errors that *typically* indicate DMA problems, like talking to invalid DMA addresses. OHCI gets that as soon as it tries to start ... EHCI gets it on the first request it submits. How do they get invalid addresses? Sometimes it's hardware problems. Sometimes their dma descriptors get overwritten by other drivers, or management of the DMA mappings is broken on that system. And the "restart OHCI" logic seems to need a way to stop restarting when it keeps getting errors... Since OHCI fails so quickly, that might be the best place to start. There's an internal "verbose" debug option; turn it on by hand, along with CONFIG_USB_DEBUG, and you'll get more info when the module loads. Some of it should become informative. > Also, this is my first post to the linux-usb groups and I tried to read > all the FAQs and hopefully I have all the information required to at > least give me some suggestions as to where to look next Thank you! :) However you omitted relevant CONFIG_* data for EHCI + OHCI. There were some endianness options for EHCI that could maybe kick in there. If so, make sure the EHCI is treated as little-endian. Likewise with OHCI. (They're both on PCI, so the OS should view them as little endian.) > OK, the details: > > CPU: MPC8548E (with PCI1 & PCI Express support) So -- PowerPC? Big Endian? > USB Chip (per subject line): > - NEC 720101 > - Port 1 connected to external USB connector > - Ports 2-5 are not connected to anything & are > 'logically disconnected" in hub driver. What do you mean by that? Custom patch? The OHCI driver has a mechanism whereby it can be told that the "real" number of ports is less than what the hardware says ... to cope with cases where e.g. port 1 is bonded out but not port 2. Maybe EHCI should have something similar. > EHCI Driver > > Kernel: linux-2.6.23.8 (with one quirk found for this chip - > to select 48MHZ clock (it hung otherwise)). Again, what do you mean by that? Another custom patch? I don't recall any clock selection options. Normally I'd expect a discrete crystal dedicated to that controller. But it'd also be practical to have an external clockgen chip that needs to be told to feed 48 MHz to that chip. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
