Discussion:
USB Host to Host Debug Dongle/Cable
(too old to reply)
Bari Ari
2006-07-21 20:35:44 UTC
Permalink
SemiconductorStore.com has several of the the USB debug cables currently
in stock for $80:

http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM


They say that PLX is still processing orders for them as well.

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Ronald G Minnich
2006-07-21 21:14:45 UTC
Permalink
Post by Bari Ari
SemiconductorStore.com has several of the the USB debug cables currently
http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM
They say that PLX is still processing orders for them as well.
yes, but ... depending on obsolete hardware for future debug strategy is
not a good plan.

ron
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Denis Dowling
2006-07-21 23:28:10 UTC
Permalink
There are a couple of other "ports" on a PC that could be used for
initial debugging. I have used a spare IDE channel as a general 8 bit IO
port. In fact you can address up to 8 different ports per channel. A
simple outb(b, 0x170) gets reflected on the port. This is dead easy to
interface with. Connect a logic analyser or a small circuit and then
just write to the port. Does not help if the IDE sits out on the PCI bus
though.

Another thought would be to tap the SMBus signals. These are routed to
all memory DIMMS. With some careful soldering you can tap the signals
off the DIMM to a logic analyser. The code can then just write to an
unised i2c address.

Regards,
Denis.
Post by Ronald G Minnich
Post by Bari Ari
SemiconductorStore.com has several of the the USB debug cables currently
http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20%20%20%20%20%201?comp=SYM
They say that PLX is still processing orders for them as well.
yes, but ... depending on obsolete hardware for future debug strategy is
not a good plan.
ron
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Bari Ari
2006-07-22 04:57:23 UTC
Permalink
Post by Denis Dowling
There are a couple of other "ports" on a PC that could be used for
initial debugging. I have used a spare IDE channel as a general 8 bit IO
port. In fact you can address up to 8 different ports per channel. A
simple outb(b, 0x170) gets reflected on the port. This is dead easy to
interface with. Connect a logic analyser or a small circuit and then
just write to the port. Does not help if the IDE sits out on the PCI bus
though.
The problem here is that IDE is going the way of the serial port as
well. Maybe a SATA debug module is a way to go. I could spin a simple
FPGA based card for output.
Post by Denis Dowling
Another thought would be to tap the SMBus signals. These are routed to
all memory DIMMS. With some careful soldering you can tap the signals
off the DIMM to a logic analyser. The code can then just write to an
unised i2c address
A debug card could also be designed the same form factor as a memory
dimm. It could be placed into an unused memory slot to debug via the
SMbus. This is easier than the SATA method to build.

copyright c 2006, patent pending

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Stefan Reinauer
2006-07-22 06:03:22 UTC
Permalink
Post by Bari Ari
A debug card could also be designed the same form factor as a memory
dimm. It could be placed into an unused memory slot to debug via the
SMbus. This is easier than the SATA method to build.
Instead of just building a "post card", could such a card hold
a serial port or something?
Post by Bari Ari
copyright c 2006, patent pending
So we're shot if we continue to talk about this? ;-)
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: ***@coresystems.de • http://www.coresystems.de/
--
linuxbios mailing list
***@linuxbios.org
Bari Ari
2006-07-23 02:42:30 UTC
Permalink
Post by Stefan Reinauer
Post by Bari Ari
A debug card could also be designed the same form factor as a memory
dimm. It could be placed into an unused memory slot to debug via the
SMbus. This is easier than the SATA method to build.
Instead of just building a "post card", could such a card hold
a serial port or something?
Good idea! With the right level control a SMbus to USB or serial
adapter could be used with the SMbus lines cabled to a module with the
same mechanicals as a dimm or sodimm module with contacts for the SMbus.

I2C Bus to USB or serial adapters
http://www.mcc-us.com/catalog.htm#I2C%20Bus%20Host%20Adapters

I2C/SPI Host Adapter
http://www.totalphase.com/products/aardvark/

I2C Bus to USB or serial adapters
http://www.telos.info/products/

QBridge-I2C-USB
http://www.qprotos.com/index.html

SMBus Specs:
http://www.smbus.org/specs/

SMbus info:
http://www.interfacebus.com/Design_Connector_Smbus.html

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Bari Ari
2006-07-23 03:13:02 UTC
Permalink
Post by Stefan Reinauer
Post by Bari Ari
A debug card could also be designed the same form factor as a memory
dimm. It could be placed into an unused memory slot to debug via the
SMbus. This is easier than the SATA method to build.
Instead of just building a "post card", could such a card hold
a serial port or something?
This adapter even has Linux tools:
USB-I2C/SPI/GPIO Interface Adapter
http://www.diolan.com/i2c/u2c12.html

with a probe like this that slides into the dimm socket:
Loading Image...
http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Bari Ari
2006-07-22 04:48:05 UTC
Permalink
Post by Ronald G Minnich
yes, but ... depending on obsolete hardware for future debug strategy
is not a good plan.
I'm still checking with PLX. If it's no longer produced, I may build
some. There is not much to them. Just a USB Host to Host bridge.

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Richard Smith
2006-07-23 02:15:02 UTC
Permalink
Post by Ronald G Minnich
yes, but ... depending on obsolete hardware for future debug strategy is
not a good plan.
I've been looking over the spec sheets and I think the larger problem
is not the external hardware or even the USB stack.

We have a somewhat unique situation in that its a Host-to-Host
connection and we control both sides of the cable. At the bottom rung
USB is just a special packet of data with some preable and a checksum.
Nothing says we have to do things the "USB" way.

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.

I see having the target just spit OUTs with the debug data in them.

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.

None of that really concerns me. Its fuzzy but I see a path.

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. You set up the base address on a 4k
RAM boundary, then the frame counter, then stuff the data your want to
send in ram and hit the go bit.

How are we going to do that when RAM is not up?

Can CAR make that work? I don't know a lot about CAR but something
tells me the USB bridge can't fetch from inside the cache.

So even if USB can be made to fly I don't think it will serve our needs.

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.

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.

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.

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.

Its a tough issue. But one we are going to have to solve.
--
Richard A. Smith
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Richard Smith
2006-07-23 02:56:31 UTC
Permalink
Post by Richard Smith
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.
Ooops looks like that was Denis's idea. Sorry Denis.
--
Richard A. Smith
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Bari Ari
2006-07-23 03:42:44 UTC
Permalink
Post by Richard Smith
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.
Its a tough issue. But one we are going to have to solve.
The chipset dev boards come with serial ports and several other debug
connectors. The dev boards don't easily get into public hands though.

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Richard Smith
2006-07-23 03:51:43 UTC
Permalink
Post by Bari Ari
The chipset dev boards come with serial ports and several other debug
connectors. The dev boards don't easily get into public hands though.
Thats what I was gussing was the answer but hoping otherwise.
By the time we get them the mfgs consider all the debugging done.
--
Richard A. Smith
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Peter Stuge
2006-07-23 05:54:32 UTC
Permalink
Post by Richard Smith
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. You set up the base
address on a 4k RAM boundary, then the frame counter, then stuff
the data your want to send in ram and hit the go bit.
Isn't the PCI register space and BAR contents decoded by the EHCI
controller to hardware registers?

"Only" PCI bus access is required for the EHCI debug mode if I
understand correctly, I don't even think it has to be completely
configured on the PCI bus. Appendix C of the EHCI 1.0 spec covers
the debug port.
http://www.intel.com/technology/usb/download/ehci-r10.pdf

While it seems that the connected device must be a Debug Class device
it would be quite possible to make a device compliant with the Debug
Class spec only on the target side and then have a regular serial
port on the other (host/remote) end.

I think a simple-as-possible circuit for a USB2 high-speed device
with a serial port is all that is needed.

Note that the debug port is an optional implementation feature of the
EHCI spec. Intel ICH6 implements it. Check your system with:

# lspci -vs $(lspci|grep EHCI|cut -f1 -d' ')
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI])
Subsystem: IBM Unknown device 0566
Flags: bus master, medium devsel, latency 0, IRQ 5
Memory at b0000000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port

The last line is the winner.

I just added a EHCI Debug Port wiki page to collect whatever we come
up with in this thread, and primed it with some of this info.
http://wiki.linuxbios.org/index.php/EHCI_Debug_Port


//Peter
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Stefan Reinauer
2006-07-23 12:42:00 UTC
Permalink
Post by Richard Smith
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.
Post by Richard Smith
I see having the target just spit OUTs with the debug data in them.
Do you have a sample implementation?
Post by Richard Smith
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?)
Post by Richard Smith
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)
Post by Richard Smith
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.
Post by Richard Smith
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.
Post by Richard Smith
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?
Post by Richard Smith
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"
Post by Richard Smith
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.
Post by Richard Smith
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: ***@coresystems.de • http://www.coresystems.de/
--
linuxbios mailing list
***@linuxbios.org
http://www.o
Richard Smith
2006-07-23 16:23:57 UTC
Permalink
Post by Stefan Reinauer
Post by Richard Smith
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_)
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.
Post by Stefan Reinauer
Post by Richard Smith
I see having the target just spit OUTs with the debug data in them.
Do you have a sample implementation?
No.. Its just a guess from the work I've done with my embedded USB
stack I have on another product. 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.

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.
Post by Stefan Reinauer
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.
Post by Stefan Reinauer
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.
http://openwince.sourceforge.net/jtag/
They still work though. I have a parallel port wiggler interface
thats a copy of an Altera byteblaster. I had to make a small patch
(posted to OLPC) to fix up the compile but after that I was able to
dump a scan chain on one of my Altera boards just fine.

Not that that helps much. Since like you said all the magic is in
knowing what to send down to the part.
--
Richard A. Smith
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Bari Ari
2006-07-23 17:15:56 UTC
Permalink
Post by Stefan Reinauer
Post by Richard Smith
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?
Post by Richard Smith
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"
PCIe is the direction in the PC world. PCI will still be around for
years mainly for MIPS/ARM SOC based network devices, routers, bridges etc.

PCIe Serial Cards
http://www.serialgear.com/PCI-Express-Cards.html

One-port (9-pin) serial (16550 UART) x1 PCI Express card
http://www.siig.com/product.asp?pid=1020&catid=14

I haven't come across a PCIe Minicard to serial adapter yet.

-Bari
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Ronald G Minnich
2006-07-23 19:07:06 UTC
Permalink
let's bring our demo USB systems to linuxbios summit. I'm serious.

thanks

ron
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Peter Stuge
2006-07-23 22:12:44 UTC
Permalink
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.
Post by Richard Smith
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.
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.
Post by Richard Smith
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
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Richard Smith
2006-07-24 04:50:32 UTC
Permalink
Post by Richard Smith
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.
PCI: 1033:00e0
00:13.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Compaq Computer Corporation Unknown device 0056
Flags: bus master, medium devsel, latency 132, IRQ 11
Memory at f0018c00 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

PCI: 1106:3104
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
(prog-if 20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at dfffff00 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
--
Richard A. Smith
--
linuxbios mailing list
***@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Continue reading on narkive:
Loading...