[LinuxBIOS] USB Host to Host Debug Dongle/Cable

[Stefan Reinauer]

* Richard Smith <smithbone at gmail.com> [060723 04:15]:
> I see having the target send control packets with the serial bytes in
> them.  Are any of our debug prints greater than say 50 characters or
> so?  Max control packet is 64 bytes and both sides must support that
> since they are hosts.
 
Wait., USB2 Debug Mode has a maximum packet size of 8 bytes (64 _bits_)
Which is why it does not need RAM to operate:

Some general restrictions and operational differences result from the use
of the debug port rather than the standard host controller interface.
The main operational difference is packet/transfer size. The debug port
has a maximum packet size of eight bytes. Since this is smaller than the
USB2 High Speed control endpoint packet size of sixty-four bytes, this
also means that control transfers have a maximum transfer size of eight
bytes as well. Because of this limitation, the debug port driver cannot
use standard means to enumerate and configure debug devices.

> I see having the target just spit OUTs with the debug data in them.
 
Do you have a sample implementation?

> The debug host computer would need to put the USB bridge into some
> sort of raw mode where you would just read the packets and dump them
> to the screen.  Perhaps we could make some sort of software serial
> device driver that could be opened by minicom or some other terminal
> software.

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?)

> What concerns me is a topic that Stefan already brought up.  Talking
> to the USB bridge on the target.  AFAICT you have to have ram working
> to use an [OUE]HCI controller.

This applies to OHCI and UHCI. The "Debug mode" is a special operating
mode that needs support from the used EHCI controller. The EHCI
controllers used in the Intel ICH-x chips (for x>=5) support this, at
least. Presumably most others do so as well (AMD8111 has no working EHCI
at all iirc)

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)

> How are we going to do that when RAM is not up?
 
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.

> 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.

> Stefan mentioned that a simple pci serial port adapter wouldn't really
> work since you have to go through the serial bus to find it.
 
And this was a wild guess. These adapters are available for below 10$.
Whoever can try this, please do. I would assume that this needs some
special initialization sequence at least as they are not connected via
the SuperIO chip, or are they? 

> What about making a PCI card that ignored spec and always positively
> decoded port 80 or 90 or what ever we picked.  Then you could stick it
> in and data would come out whenever outs to that port happened.

a port 80 card "with a memory" or a serial interface on the other side?
Sounds good. And works on all machines that have slots. This way port80
codes would not have a distinct meaning but be bytes written to 
the console

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"

> I like Bari's idea of a DIMM module that sat on the SMbus. Thats cool.
>  Getting the SMbus to work sometimes is a pain though.

yes. port 80 monitoring would be easier.

> If most new motherboards comming out now don't have serial ports on
> them then how are the mfg's debugging the boards?  JTAG?  If so then I
> think we better start learning how to do JTAG.  Of course the mfgs may
> drop the jtag interface on a production run.

The problem as far as I can tell is that JTAG needs an extensive per
system adaption on the client side that is usually only available for
windows. Benefit is that we can single step, reflash and read memory and
a console with the same cable for less than 100$ (the software is where
the money is here.

The de facto standard open source tools are available here:
http://openwince.sourceforge.net/jtag/

but: they have not been updated since 2003 

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/