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...
They say that PLX is still processing orders for them as well.
-Bari
Bari Ari wrote:
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...
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
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.
Ronald G Minnich wrote:
Bari Ari wrote:
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...
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
Denis Dowling wrote:
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.
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
* Bari Ari bari@onelabs.com [060722 06:57]:
Denis Dowling wrote: 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?
copyright c 2006, patent pending
So we're shot if we continue to talk about this? ;-)
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [060722 06:57]:
Denis Dowling wrote: 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
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [060722 06:57]:
Denis Dowling wrote: 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: http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html
-Bari
Ronald G Minnich wrote:
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
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.
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 Smith wrote:
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
On 7/22/06, Bari Ari bari@onelabs.com wrote:
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.
On Sat, Jul 22, 2006 at 09:15:02PM -0500, Richard Smith wrote:
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
* Richard Smith smithbone@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
On 7/23/06, Stefan Reinauer stepan@coresystems.de wrote:
- Richard Smith smithbone@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:
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.
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.
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.
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/
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.
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
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
Stefan Reinauer wrote:
- Richard Smith smithbone@gmail.com [060723 04:15]:
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"
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
let's bring our demo USB systems to linuxbios summit. I'm serious.
thanks
ron
-
Bari Ari -
Denis Dowling -
Peter Stuge -
Richard Smith -
Ronald G Minnich -
Stefan Reinauer