* 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