* Ronald G Minnich rminnich@lanl.gov [060703 22:45]:
yes, but ... that's how it goes. Very few people want to see linuxbios anyway.
We do. But after our job is done, it should not be visible, indeed.
Many years ago I did an experiment, and was able to set things up so that linuxbios log buffer was picked up by the kernel, so you could do a dmesg and see linuxbios messages. I think this might be useful to revive.
Do you have a pointer on this one? It indeed sounds very useful.
I just don't see us putting a fully capable usb stack into linuxbios, it will not work as well as the linux usb stack.
Not a USB stack. That would be crap, and it would not work.
Eric pointed this out and I did not even notice what he was saying:
EHCI has a workaround method called the "USB2 Debug port for legacy free machines"
This debug port can be used by simple inb/outb sequences, not more complex than serial io.
According to this document
http://www.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf
what you need is a debug device, which mostly looks like a usb style null modem cable. No idea where to get this hardware though.
* Stefan Reinauer stepan@coresystems.de [060707 15:25]:
Eric pointed this out and I did not even notice what he was saying:
EHCI has a workaround method called the "USB2 Debug port for legacy free machines"
This debug port can be used by simple inb/outb sequences, not more complex than serial io.
According to this document
http://www.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf
what you need is a debug device, which mostly looks like a usb style null modem cable. No idea where to get this hardware though.
D'uh - it reads any usb 2 to usb 2 data link cable can be used for this purpose. Such cables are available for ~ 10$
Also: This is at least supported by the ICH4 and newer Intel EHCI controllers. I wonder whether AMD or others support it as well?
Stefan
Stefan Reinauer wrote:
Also: This is at least supported by the ICH4 and newer Intel EHCI controllers. I wonder whether AMD or others support it as well?
ALI and nVidia are also mentioned as supporting the optional EHCI Debug Device in this patch:
http://lkml.org/lkml/2005/1/8/93
John
On Fri, 2006-07-07 at 16:18 +0200, Stefan Reinauer wrote:
- Stefan Reinauer stepan@coresystems.de [060707 15:25]:
Eric pointed this out and I did not even notice what he was saying:
EHCI has a workaround method called the "USB2 Debug port for legacy free machines"
This debug port can be used by simple inb/outb sequences, not more complex than serial io.
According to this document
http://www.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdf
what you need is a debug device, which mostly looks like a usb style null modem cable. No idea where to get this hardware though.
D'uh - it reads any usb 2 to usb 2 data link cable can be used for this purpose. Such cables are available for ~ 10$
What's on the other end of the cable? Just the usual USB port? What software we need (minicom)?
Ollie
This is a nice idea.
On Fri, Jul 07, 2006 at 04:18:25PM +0200, Stefan Reinauer wrote:
what you need is a debug device, which mostly looks like a usb style null modem cable. No idea where to get this hardware though.
D'uh - it reads any usb 2 to usb 2 data link cable can be used for this purpose. Such cables are available for ~ 10$
Where did you read this?
I doubt they will work, unless the manufacturers were exceedingly clever and actually implemented the DEBUG_MODE feature in the device..
I agree with your first observation that this will be a special device, because of the DEBUG_MODE feature described in the spec as well as the 8 byte limits on transfer size.
On Fri, Jul 07, 2006 at 09:21:57AM -0600, ollie wrote:
What's on the other end of the cable? Just the usual USB port? What software we need (minicom)?
The spec only deals with the end of the debug device that connects to the target system. I guess implementors are free to choose whatever USB interface they wish to expose to the host ("remote" in the spec) system as long as it has one max 8-byte bulk in endpoint and one max 8-byte bulk out endpoint.
I'm not sure if this requirement is compatible with the CDC spec that USB-serial adapters implement, but it would indeed be very handy if minicom+the kernel USB-serial driver could be used with the host end of the debug device.
It's quite possible that the device requires a special application, but in any case such an application would be trivial to hack up. I think the hard part is to find or make the hardware. Or maybe not so hard if you have a proven USB2 HS platform and are comfortable with tweaking USB descriptors. All I have handy is USB2 FS. :(
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [060707 19:52]:
This is a nice idea.
On Fri, Jul 07, 2006 at 04:18:25PM +0200, Stefan Reinauer wrote:
what you need is a debug device, which mostly looks like a usb style null modem cable. No idea where to get this hardware though.
D'uh - it reads any usb 2 to usb 2 data link cable can be used for this purpose. Such cables are available for ~ 10$
Where did you read this?
I doubt they will work, unless the manufacturers were exceedingly clever and actually implemented the DEBUG_MODE feature in the device..
You are right. The cable would need to implement the DEBUG_MODE feature.
I read over page 5 of http://www.intel.com/technology/magazine/computing/it09021.pdf and it actually says so.
The question is now: what devices/cables can be used for this purpose. Or is it maybe trivial to build such a device yourself in a low quantity?
I'm not sure if this requirement is compatible with the CDC spec that USB-serial adapters implement, but it would indeed be very handy if minicom+the kernel USB-serial driver could be used with the host end of the debug device.
That would indeed be great!
It's quite possible that the device requires a special application, but in any case such an application would be trivial to hack up.
Or just a small dummy serial driver so minicom or whatever could be used.
I think the hard part is to find or make the hardware. Or maybe not so hard if you have a proven USB2 HS platform and are comfortable with tweaking USB descriptors. All I have handy is USB2 FS. :(
The idea is probably to get a cost effective solution, otherwise a lot of volunteers might get locked out of joining the project.
Stefan
Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@cdy.org [060707 19:52]:
This is a nice idea.
On Fri, Jul 07, 2006 at 04:18:25PM +0200, Stefan Reinauer wrote:
what you need is a debug device, which mostly looks like a usb style null modem cable. No idea where to get this hardware though.
D'uh - it reads any usb 2 to usb 2 data link cable can be used for this purpose. Such cables are available for ~ 10$
Where did you read this?
I doubt they will work, unless the manufacturers were exceedingly clever and actually implemented the DEBUG_MODE feature in the device..
You are right. The cable would need to implement the DEBUG_MODE feature.
I read over page 5 of http://www.intel.com/technology/magazine/computing/it09021.pdf and it actually says so.
The question is now: what devices/cables can be used for this purpose. Or is it maybe trivial to build such a device yourself in a low quantity?
I'm not sure if this requirement is compatible with the CDC spec that USB-serial adapters implement, but it would indeed be very handy if minicom+the kernel USB-serial driver could be used with the host end of the debug device.
That would indeed be great!
It's quite possible that the device requires a special application, but in any case such an application would be trivial to hack up.
Or just a small dummy serial driver so minicom or whatever could be used.
I think the hard part is to find or make the hardware. Or maybe not so hard if you have a proven USB2 HS platform and are comfortable with tweaking USB descriptors. All I have handy is USB2 FS. :(
The idea is probably to get a cost effective solution, otherwise a lot of volunteers might get locked out of joining the project.
Stefan
Let me know what it actually needs (if it needs to be custom) and I'll see about manufacturing them in low volumes (100's, k's) for cheap.
-Bari
Bari Ari wrote:
Let me know what it actually needs (if it needs to be custom) and I'll see about manufacturing them in low volumes (100's, k's) for cheap.
WinDBG has recently added support for USB2 debugging support. I haven't seen it explicitly stated by Microsoft anywhere, but it seems to use the "debug port" defined by EHCI. Here is a post:
http://www.osronline.com/article.cfm?id=456
The debug cable mentioned can be purchased from Mouser for $75:
http://www.mouser.com/index.cfm?handler=displayproduct&lstdispproductid=...
or here for 80:
http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20...
A little more info here:
http://advdbg.com/blogs/advdbg_system/articles/64.aspx
For debug targets with their own *device* controller, you may not even need the dongle.
On Fri, Jul 07, 2006 at 03:48:42PM -0600, Tom Sylla wrote:
The debug cable mentioned can be purchased from Mouser for $75:
http://www.mouser.com/index.cfm?handler=displayproduct&lstdispproductid=...
or here for 80:
http://shop.semiconductorstore.com/iwwida.pvx?;item?item_no=NET20DC%20%20%20...
Perfect.
For debug targets with their own *device* controller, you may not even need the dongle.
No, but that also means that the debugging code will differ between firmware implementations. A NET20DC or other debug device implementing the spec has the benefit of a standardized simple interface on both ends.
//Peter
Tom Sylla wrote:
Bari Ari wrote:
Let me know what it actually needs (if it needs to be custom) and I'll see about manufacturing them in low volumes (100's, k's) for cheap.
WinDBG has recently added support for USB2 debugging support. I haven't seen it explicitly stated by Microsoft anywhere, but it seems to use the "debug port" defined by EHCI. Here is a post:
http://www.osronline.com/article.cfm?id=456
The debug cable mentioned can be purchased from Mouser for $75:
The orphaned page at PLX on the USB debug cable is at: http://www.plxtech.com/products/NET2000/NET20DC/default.asp
The NET20DC's don't seem to be in stock anywhere. I wonder if they are out of production since the page is active yet orphaned on their website. The search function on the PLX website also returns nothing on the NET20DC.
-Bari
-
Bari Ari -
John DeGood -
ollie -
Peter Stuge -
Stefan Reinauer -
Tom Sylla