On Sun, Jul 23, 2006 at 02:42:00PM +0200, Stefan Reinauer wrote:
the debug port driver cannot use standard means to enumerate and configure debug devices.
Right. It only supports a single debug class device. And hardware handles the enumeration and configuration in the target.
Does the [host] end point really have to be in a special mode (debug mode as well?)
Not at all. The debug class spec only sets requirements for the device edge connected to the target (aka remote) system.
The downside of this is, like the SuperIO sequence needed to make serial output working you probably need a (somewhat) southbridge specific sequence to enable this debug mode. (somewhat would mean: probably one per vendor/generation)
Actually no. How to find the debug port registers in the EHCI PCI configuration space is standardized by the EHCI spec.
Not at all. USB 1.x chipsets are out of this scope. All we can look at is 8byte bursts that are written to the USB2 debug registers in PCI space. This is the whole delicacy of USB2 debug mode as far as I understand it.
Yep. Maybe even 1 byte packets would be best.
So even if USB can be made to fly I don't think it will serve our needs.
I believe with above it should do the job.
Me too.
It seems to be on the horizon that there is not "1 final solution" to this problem but rather "the most simple or cheapest solution for this or that purpose"
Options are nice. Especially since the debug port is optional.
On Sun, Jul 23, 2006 at 11:23:57AM -0500, Richard Smith wrote:
I should have clarified. I was discounting the debug port (because its optional) until its shown that its a common feature on 2.0 Bridges.
Neither of the the bridges on my laptop (NEC) or my desktop (VIA) show a debug implementation.
Please add PCI ids and chip names on http://wiki.linuxbios.org/index.php/EHCI_Debug_Port or send me a quick message so I can do it.
The interface there is _much_ simpler all I have is a data FIFO and a few bits to tell me its done. If I stuff data into the FIFO and hit write then out it goes.
The debug port works the same way. A few bytes control/status and 8 bytes data buffer.
I was looking at the specs to see what it would take to do something similar with a (OUE)HCI but I stopped going much further when I saw that I would need working RAM.
Only EHCI.
Yes, this would definitely be the preferred method. The question is: Does the end point really have to be in a special mode (debug mode as well?)
I was thinking you might need to bypass some of the timeouts and such.
All timing is handled by EHCI hardware. All the "debug port driver" has to do is to touch the registers and away the transactions go.
//Peter