Hi,
I'm not officially back yet, but here's a question I don't want to forget: Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe. Can I emulate such a cable with the Geode USB target mode?
Regards, Carl-Daniel
On Thu, 26 Jun 2008 15:57:39 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi,
I'm not officially back yet, but here's a question I don't want to
forget:
Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe. Can I emulate such a cable with the Geode USB target mode?
Yeh I think the NET20DC is way to expensive anyways, unless your in a mass production environment.
I read somewhere you could make one, but I don't know how difficult that would be. I was always wondering if you could just use two USB -> Serial adapters with a null modem cable in the middle???
Joseph Smith wrote:
Yeh I think the NET20DC is way to expensive anyways, unless your in a mass production environment.
It's 83$ at semiconductorstore. That's actually not bad for such special equipment.
I read somewhere you could make one, but I don't know how difficult that would be. I was always wondering if you could just use two USB -> Serial adapters with a null modem cable in the middle??
Nope, won't work. You need a USB device that explicitly understands USB debug mode. In this mode you don't have to set up the BARs (ie no memory required) to talk USB.
Stefan
I read somewhere you could make one, but I don't know how difficult that would be. I was always wondering if you could just use two USB -> Serial adapters with a null modem cable in the middle??
Nope, won't work. You need a USB device that explicitly understands USB debug mode. In this mode you don't have to set up the BARs (ie no memory required) to talk USB.
This guy was able to get it working with one USB -> Serial adapter (reversed) on an iMac (with ICH7) using Solaris as the host:
http://blogs.sun.com/szhou/entry/solaris_on_efi_imac
On Thu, 26 Jun 2008 12:48:25 -0400, Joseph Smith joe@settoplinux.org wrote:
I read somewhere you could make one, but I don't know how difficult
that
would be. I was always wondering if you could just use two USB ->
Serial
adapters with a null modem cable in the middle??
Nope, won't work. You need a USB device that explicitly understands USB debug mode. In this mode you don't have to set up the BARs (ie no memory required) to talk USB.
This guy was able to get it working with one USB -> Serial adapter (reversed) on an iMac (with ICH7) using Solaris as the host:
I have to say, the more I think about this, it would be really cool to setup coreboot to do the same:-)
On 26.06.2008 18:48, Joseph Smith wrote:
I read somewhere you could make one, but I don't know how difficult that would be. I was always wondering if you could just use two USB -> Serial adapters with a null modem cable in the middle??
Nope, won't work. You need a USB device that explicitly understands USB debug mode. In this mode you don't have to set up the BARs (ie no memory required) to talk USB.
This guy was able to get it working with one USB -> Serial adapter (reversed) on an iMac (with ICH7) using Solaris as the host:
The blog entry explicitly states that it didn't work.
Regards, Carl-Daniel
On Thu, 26 Jun 2008 19:06:08 +0200, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 26.06.2008 18:48, Joseph Smith wrote:
I read somewhere you could make one, but I don't know how difficult
that
would be. I was always wondering if you could just use two USB ->
Serial
adapters with a null modem cable in the middle??
Nope, won't work. You need a USB device that explicitly understands USB debug mode. In this mode you don't have to set up the BARs (ie no
memory
required) to talk USB.
This guy was able to get it working with one USB -> Serial adapter (reversed) on an iMac (with ICH7) using Solaris as the host:
The blog entry explicitly states that it didn't work.
Than you did not read all of it. At the end"I was finally able to get console output on the iMac"
Joseph Smith schrieb:
Than you did not read all of it. At the end"I was finally able to get console output on the iMac"
Yes, by using the default USB controller in polled mode (ie. no IRQ handling). The USB debug port is a different facility.
Regards, Patrick
Joseph Smith wrote:
The blog entry explicitly states that it didn't work.
Than you did not read all of it. At the end"I was finally able to get console output on the iMac"
With the downside that you need a full blown USB stack around for that.
cite: Although the device doesn't work early in boot, I can still boot the system up if the kernel "just worked".
So it starts working some time after a kernel is running. I am sure that's pretty good for what it does, but it does not replace the DC20, unfortunately
Joseph Smith wrote:
The blog entry explicitly states that it didn't work.
Than you did not read all of it. At the end"I was finally able to get console output on the iMac"
Stefan Reinauer wrote:
With the downside that you need a full blown USB stack around for that.
What about something less than a full USB stack similar to Porus?
So it starts working some time after a kernel is running. I am sure that's pretty good for what it does, but it does not replace the DC20, unfortunately
Of course a JTAG device might be better. On the other hand, a NET20DC ($83) is a real bargain compared to an American Arium ECM-50 or for XDP JTAG, the ECM-XDP3.
http://www.coreboot.org/JTAG/BSDL_Guide probably should be updated.
The Intel and Arium links at the bottom of this page are no longer valid.
Here's a Geode JTAG tool that may be useful to list on coreboot's JTAG/BSDL Guide:
http://www.fs2.com/geodetools.html
http://www.fs2.com/pdfs/SNAV-GX.pdf
Back to USB Debug Port:
Here's an old USB Debug Port presentation that may be useful to those new to the concept:
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
Is the NET20DC really the only USB Debug Device available? I tried searching for others, but didn't find any.
Sincerely,
Ken Fuchs
P.S. Stefan, are you having e-mail filter problems?
What about something less than a full USB stack similar to Porus?
Wow Ken, this is a very interesting API. Possible canidate for LegacyBIOS???
Here's an old USB Debug Port presentation that may be useful to those new to the concept:
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
This is a great explination, if no one objects, I will add this to the wiki.
Is the NET20DC really the only USB Debug Device available?
Yes. There should be an cheaper alternative....
Here's an old USB Debug Port presentation that may be useful to those new to the concept:
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
Is the NET20DC really the only USB Debug Device available? I tried searching for others, but didn't find any.
I think the design might become easier if you just create the debug part of the device and use the serial side of a plain usbserial device as direct interface.
Actually I suggested something along those lines already in the wiki page. :)
Well it looks like in the pdf presentation above they have a Serial->USB debugger. It looks like a development board though because there are a bunch of unnecessary stuff on it. I'm thinking a Serial->USB debugger is the way to go to keep the costs down, and it gives the terminal PC (serial end) more flexability. If one wanted to have it USB on both ends they could always use a USB->Serial adapter for the terminal PC (serial end). Also, this way there would be no need for any kind of a special driver for windows/linux, it would just show up as a serial communications device. Any suggestions, questions, comments?
On Thu, Jul 3, 2008 at 8:45 AM, Joseph Smith joe@settoplinux.org wrote:
Well it looks like in the pdf presentation above they have a Serial->USB debugger. It looks like a development board though because there are a bunch of unnecessary stuff on it. I'm thinking a Serial->USB debugger is the way to go to keep the costs down, and it gives the terminal PC (serial end) more flexability. If one wanted to have it USB on both ends they could always use a USB->Serial adapter for the terminal PC (serial end). Also, this way there would be no need for any kind of a special driver for windows/linux, it would just show up as a serial communications device. Any suggestions, questions, comments?
I think I am still a bit confused about your goal.
A Net20DC is ~$90 right now.
You aren't going to be able to take some off-the-shelf USB-Serial adapter and make it into a debug device. Those adapters use fixed-function USB-Serial ICs that are cheap and small. You can't re-program the firmware to make them into debug devices. If you buy a development kit with an appropriate IC and allows you to develop the firmware, you will easily be at $90 or above.
To make a replacement, you need: Net2272 (or equivalent, Cypress, etc) ~$10 "host side" interface chip ~$5 ($5 for serial, USB would be ~10 instead) Connectors, SEEP, passives, etc $10 PCB $20
So, $50 *cost* (and the above numbers are very best-case). Then you need to assemble and test your board, develop the firmware for the USB debug Device, and possibly the firmware for the host-side interface. (Please don't try and argue less than $20 for a PCB, for your quantities, that is what it will be)
Even if you consider all of your time "free", you still are comparing $50 to $90.
If you could sell a USB debug cable for $20, it would make sense. If the Net20DC was $200, it would make sense. Otherwise, I am not so sure. Am I missing something?
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Tom Sylla Sent: Thursday, July 03, 2008 10:56 AM To: Joseph Smith Cc: stepan@coresystems.de; Ken.Fuchs@bench.com; c- d.hailfinger.devel.2006@gmx.net; coreboot@coreboot.org Subject: Re: [coreboot] USB debug cables and emulation
On Thu, Jul 3, 2008 at 8:45 AM, Joseph Smith joe@settoplinux.org wrote:
Well it looks like in the pdf presentation above they have a Serial->USB debugger. It looks like a development board though because there are a bunch of unnecessary stuff on it. I'm thinking a Serial->USB debugger is the way to go to keep the costs down, and it gives the terminal PC
(serial
end) more flexability. If one wanted to have it USB on both ends they
could
always use a USB->Serial adapter for the terminal PC (serial end). Also, this way there would be no need for any kind of a special driver for windows/linux, it would just show up as a serial communications device.
Any
suggestions, questions, comments?
I think I am still a bit confused about your goal.
A Net20DC is ~$90 right now.
You aren't going to be able to take some off-the-shelf USB-Serial adapter and make it into a debug device. Those adapters use fixed-function USB-Serial ICs that are cheap and small. You can't re-program the firmware to make them into debug devices. If you buy a development kit with an appropriate IC and allows you to develop the firmware, you will easily be at $90 or above.
To make a replacement, you need: Net2272 (or equivalent, Cypress, etc) ~$10 "host side" interface chip ~$5 ($5 for serial, USB would be ~10 instead) Connectors, SEEP, passives, etc $10 PCB $20
So, $50 *cost* (and the above numbers are very best-case). Then you need to assemble and test your board, develop the firmware for the USB debug Device, and possibly the firmware for the host-side interface. (Please don't try and argue less than $20 for a PCB, for your quantities, that is what it will be)
Even if you consider all of your time "free", you still are comparing $50 to $90.
If you could sell a USB debug cable for $20, it would make sense. If the Net20DC was $200, it would make sense. Otherwise, I am not so sure. Am I missing something?
I guess you don't get it. I am not doing it to mass produce and sell at a lower cost. I don't really care about any kind of profit. I'm simply doing it for a "HOWTO build your own USB 2.0 Debugger For Around 20 Dollars". $20 Dollars for a PCB??? I am going to use a generic PCB you can pick up at radio shack for 2 dollars. If I have to get some of the components at a larger volume to get a cheaper price and re-sell them to interested parties so they get a cheaper price I will. This is more for educational, learning, and teaching purposes. Everything is not about money you know (or not) :-(
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Thu, Jul 03, 2008 at 08:45:15AM -0400, Joseph Smith wrote:
I'm thinking a Serial->USB debugger is the way to go
Ok. Keep in mind that the serial port will probably not be able to handle full speed data from the debugged target. I'm not sure what the transfer overhead is, but I expect the debug device to be able to shuffle quite a bit of data even though each transfer is only 8 bytes max.
to keep the costs down
As Tom pointed out, this is not a good argument. Serial will only be simpler to implement, not lower cost to any degree that matters.
Any suggestions, questions, comments?
You might want to look into the speed thing. I believe the best way to do so is to run tests on the NET20DC.
On Thu, Jul 03, 2008 at 12:28:47PM -0400, Joseph Smith wrote:
$20 Dollars for a PCB??? I am going to use a generic PCB you can pick up at radio shack for 2 dollars.
That will not work. There are no standalone USB 2 high-speed function controllers that are usable with those PCBs. You will have to design a PCB, or buy a devkit.
This is more for educational, learning, and teaching purposes. Everything is not about money you know (or not) :-(
Manufacturing electronics is VERY expensive, and I think the concern is that you will either be spending ridiculous $$ or be forced to shut down the project before finish, and that either would be a high price for whatever knowledge has been gained.
USB Debug Devices aren't the best target for learning USB in general because the devices need to do some tricks here and there, and thus require high end function controllers that can perform.
//Peter
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Thursday, July 03, 2008 1:19 PM To: coreboot@coreboot.org Subject: Re: [coreboot] USB debug cables and emulation
On Thu, Jul 03, 2008 at 08:45:15AM -0400, Joseph Smith wrote:
I'm thinking a Serial->USB debugger is the way to go
Ok. Keep in mind that the serial port will probably not be able to handle full speed data from the debugged target. I'm not sure what the transfer overhead is, but I expect the debug device to be able to shuffle quite a bit of data even though each transfer is only 8 bytes max.
to keep the costs down
As Tom pointed out, this is not a good argument. Serial will only be simpler to implement, not lower cost to any degree that matters.
Any suggestions, questions, comments?
You might want to look into the speed thing. I believe the best way to do so is to run tests on the NET20DC.
On Thu, Jul 03, 2008 at 12:28:47PM -0400, Joseph Smith wrote:
$20 Dollars for a PCB??? I am going to use a generic PCB you can pick up at radio shack for 2 dollars.
That will not work. There are no standalone USB 2 high-speed function controllers that are usable with those PCBs. You will have to design a PCB, or buy a devkit.
This is more for educational, learning, and teaching purposes. Everything is not about money you know (or not) :-(
Manufacturing electronics is VERY expensive, and I think the concern is that you will either be spending ridiculous $$ or be forced to shut down the project before finish, and that either would be a high price for whatever knowledge has been gained.
USB Debug Devices aren't the best target for learning USB in general because the devices need to do some tricks here and there, and thus require high end function controllers that can perform.
So everyone is just telling me I should give up???
I wonder how many times OLPC herd that???
Ok then I will just give up and go buy a Net20DC :-(
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On 03.07.2008 21:42, Joseph Smith wrote:
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Thursday, July 03, 2008 1:19 PM To: coreboot@coreboot.org Subject: Re: [coreboot] USB debug cables and emulation
On Thu, Jul 03, 2008 at 08:45:15AM -0400, Joseph Smith wrote:
I'm thinking a Serial->USB debugger is the way to go
Ok. Keep in mind that the serial port will probably not be able to handle full speed data from the debugged target. I'm not sure what the transfer overhead is, but I expect the debug device to be able to shuffle quite a bit of data even though each transfer is only 8 bytes max.
to keep the costs down
As Tom pointed out, this is not a good argument. Serial will only be simpler to implement, not lower cost to any degree that matters.
Any suggestions, questions, comments?
You might want to look into the speed thing. I believe the best way to do so is to run tests on the NET20DC.
On Thu, Jul 03, 2008 at 12:28:47PM -0400, Joseph Smith wrote:
$20 Dollars for a PCB??? I am going to use a generic PCB you can pick up at radio shack for 2 dollars.
That will not work. There are no standalone USB 2 high-speed function controllers that are usable with those PCBs. You will have to design a PCB, or buy a devkit.
This is more for educational, learning, and teaching purposes. Everything is not about money you know (or not) :-(
Manufacturing electronics is VERY expensive, and I think the concern is that you will either be spending ridiculous $$ or be forced to shut down the project before finish, and that either would be a high price for whatever knowledge has been gained.
USB Debug Devices aren't the best target for learning USB in general because the devices need to do some tricks here and there, and thus require high end function controllers that can perform.
As luck has it, the USB chips used in the NET20DC are also present in other devices.
So everyone is just telling me I should give up???
Well, I think it would be really cool to have an affordable USB debug device. Unfortunately, I am not so skilled when it comes to designing hardware, so I won't be able to help. Together with shipping, the NET20DC is >$140 anywhere in Europe. That's pretty much outside my budget.
I wonder how many times OLPC herd that???
Ok then I will just give up and go buy a Net20DC :-(
If you can get schematics and photos and a dump of the ROM of a NET20DC, you should be able to find out rather quickly whether this is doable. In theory, having a Geode/CS5536 board should enable you to abuse one of the USB host ports as device port and create USB debug functionality purely in software. No idea whether the hardware is that flexible, though.
Regards, Carl-Daniel
On Thu, Jul 03, 2008 at 03:42:05PM -0400, Joseph Smith wrote:
Manufacturing electronics is VERY expensive, and I think the concern is that you will either be spending ridiculous $$ or be forced to shut down the project before finish, and that either would be a high price for whatever knowledge has been gained.
USB Debug Devices aren't the best target for learning USB in general because the devices need to do some tricks here and there, and thus require high end function controllers that can perform.
So everyone is just telling me I should give up???
I'm not. :) If you want to spend a lot of time learning about USB I am all for it! Once you've gotten your first device to work and know all the twisty passages of the device firmware, it will be alot easier to adapt it so that it's a debug device instead.
I wonder how many times OLPC herd that???
Probably many! They persisted, and I bet they did not have the same motivation as you; education of self and hack credits.
Ok then I will just give up and go buy a Net20DC :-(
You will not be able to DIY for lower cost, and I say it will take half a year or more to finish because USB is so complex.
If the goal is to further use of the Debug Port in any fashion, I do recommend grabbing a NET20DC, getting it to work somehow somewhere maybe write some code for talking to it that is missing or buggy, and documenting the process so others can make use of the device too.
If the goal is to educate yourself about USB and make a very narrow hack then I say go for it, just be prepared for the effort. Except time you'll either have to use an existing USB2 device controller devkit, or design your own PCB and purchase lots of chips. Either way, it is not so easy to reproduce your effort for another DIY:er. Finally you could then fall back to the other purpose, to use your DIY:ed device in order to help with debug target software for communicating with a debugger host through the debug device, but by then maybe someone has already used the NET20DC to do that.
So - comes down to why you want to do it. :)
//Peter
So - comes down to why you want to do it. :)
Well, I wanted to take this as a opportunity to learn the in's and out's of USB especially USB 2.0 (EHCI). If I make a cool debugging device along the way, then great :-) But I get the point, It will probably end up costing me an arm and a leg to do it. The NET 2270 USB2.0 Development Kit is $995.00..... :-(
Also I really want to learn USB for coreboot payload purposes. Did anyone realize with all these different payloads we have none of them support USB completely?? Filo is the only one that supports OHCI but that is it. I want to learn about USB so I can get some USB support for legacy USB devices (keyboards/mouse) as well as support for booting USB drives. This non-USB situation is and always has been disturbing to me :-0 In a certain way it puts coreboot behind the times...
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Joseph Smith wrote:
Also I really want to learn USB for coreboot payload purposes. Did anyone realize with all these different payloads we have none of them support USB completely?? Filo is the only one that supports OHCI but that is it. I want to learn about USB so I can get some USB support for legacy USB devices (keyboards/mouse) as well as support for booting USB drives. This non-USB situation is and always has been disturbing to me :-0 In a certain way it puts coreboot behind the times...
We're pretty far with the UHCI stack in GRUB2. If you are looking for a USB project to jump on, we can certainly use help ;-)
Initial keyboard support is there. MSC support is there, UHCI is there.
Missing: Fixes, Testing, OHCI, EHCI, Fixes, Fixes, Testing...
Maybe we can pack it into libpayload instead of GRUB2 too, so we can make it available to more payloads?
On Fri, 04 Jul 2008 01:21:19 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Also I really want to learn USB for coreboot payload purposes. Did
anyone
realize with all these different payloads we have none of them support
USB
completely?? Filo is the only one that supports OHCI but that is it. I
want
to learn about USB so I can get some USB support for legacy USB devices (keyboards/mouse) as well as support for booting USB drives. This
non-USB
situation is and always has been disturbing to me :-0 In a certain way it puts coreboot behind the times...
We're pretty far with the UHCI stack in GRUB2. If you are looking for a USB project to jump on, we can certainly use help ;-)
Initial keyboard support is there. MSC support is there, UHCI is there.
Missing: Fixes, Testing, OHCI, EHCI, Fixes, Fixes, Testing...
Maybe we can pack it into libpayload instead of GRUB2 too, so we can make it available to more payloads?
Stefan, I would love to help out. I offered my services to Patrick a while ago, with no response. What can I do?
Joseph Smith schrieb:
We're pretty far with the UHCI stack in GRUB2. If you are looking for a USB project to jump on, we can certainly use help ;-)
Initial keyboard support is there. MSC support is there, UHCI is there.
Missing: Fixes, Testing, OHCI, EHCI, Fixes, Fixes, Testing...
Maybe we can pack it into libpayload instead of GRUB2 too, so we can make it available to more payloads?
It's clean code with no imports (though I got some clues from other sources, esp. as far as workarounds for chipset bugs are concerned, but it should be safe), so it's not bound to a license, and apart from grub_strcpy here and grub_uint32_t there, which can be sanitized easily, and some trivial pci controller detection logic, it's not very grub2 specific either. I merely develop it inside the grub2 tree because that's the most convenient for now.
Stefan, I would love to help out. I offered my services to Patrick a while ago, with no response. What can I do?
Oops, sorry! You seem to be only starting into USB now, but so did I when I started writing this code (which probably shows at places). I quickly collected a TODO:
For UHCI: - testing and fixes, lots of it - make more clever (eg. bulk transfer with >1 packet/ms, which might be done next week already) - fix some abstractions (eg. bulk transfer is at the wrong place currently) - improve interrupt transfer handling
For OHCI: - create driver (most of UHCI doesn't apply here, because the chip is more clever. "fix some abstractions" definitely helps, though)
For EHCI: - figure out how to gain control over a device from the USB1 controller (that will somehow interact with the USB1 driver) - PING/DATA2 protocol, microframes support - extend HUB driver, so it handles USB1 devices on a USB2 hub
USB devices: - the keyboard driver is rather rudimentary - mouse doesn't exist - mass storage only likes few devices (high priority for me) - hub driver doesn't have proper device power management yet
Get the code to run, figure out the design (sorry, no documentation yet - but ask me. The code can only become better that way), play with it, fix it for your hardware, ask questions, send/commit patches, ...
On my personal TODO (after this %!$# northbridge works for me) is most of the UHCI stuff, and mass storage. Everything else is pretty much free for grabs (but it might be good to tell me so I don't step on your toes). OHCI and mouse are definitely not on my list for the short term, other usb device drivers also aren't. I also don't mind patches to any part of the code :-)
Regards, Patrick Georgi
-----Original Message----- From: coreboot-bounces+joe=settoplinux.org@coreboot.org [mailto:coreboot- bounces+joe=settoplinux.org@coreboot.org] On Behalf Of Patrick Georgi Sent: Thursday, July 03, 2008 9:44 PM To: Joseph Smith Cc: Stefan Reinauer; coreboot@coreboot.org Subject: Re: [coreboot] USB debug cables and emulation
Joseph Smith schrieb:
We're pretty far with the UHCI stack in GRUB2. If you are looking for a USB project to jump on, we can certainly use help ;-)
Initial keyboard support is there. MSC support is there, UHCI is there.
Missing: Fixes, Testing, OHCI, EHCI, Fixes, Fixes, Testing...
Maybe we can pack it into libpayload instead of GRUB2 too, so we can make it available to more payloads?
It's clean code with no imports (though I got some clues from other sources, esp. as far as workarounds for chipset bugs are concerned, but it should be safe), so it's not bound to a license, and apart from grub_strcpy here and grub_uint32_t there, which can be sanitized easily, and some trivial pci controller detection logic, it's not very grub2 specific either. I merely develop it inside the grub2 tree because that's the most convenient for now.
Stefan, I would love to help out. I offered my services to Patrick a
while
ago, with no response. What can I do?
Oops, sorry! You seem to be only starting into USB now, but so did I when I started writing this code (which probably shows at places). I quickly collected a TODO:
For UHCI:
- testing and fixes, lots of it
- make more clever (eg. bulk transfer with >1 packet/ms, which might be
done next week already)
- fix some abstractions (eg. bulk transfer is at the wrong place
currently)
- improve interrupt transfer handling
For OHCI:
- create driver (most of UHCI doesn't apply here, because the chip is
more clever. "fix some abstractions" definitely helps, though)
For EHCI:
- figure out how to gain control over a device from the USB1 controller
(that will somehow interact with the USB1 driver)
- PING/DATA2 protocol, microframes support
- extend HUB driver, so it handles USB1 devices on a USB2 hub
USB devices:
- the keyboard driver is rather rudimentary
- mouse doesn't exist
- mass storage only likes few devices (high priority for me)
- hub driver doesn't have proper device power management yet
Get the code to run, figure out the design (sorry, no documentation yet
- but ask me. The code can only become better that way), play with it,
fix it for your hardware, ask questions, send/commit patches, ...
On my personal TODO (after this %!$# northbridge works for me) is most of the UHCI stuff, and mass storage. Everything else is pretty much free for grabs (but it might be good to tell me so I don't step on your toes). OHCI and mouse are definitely not on my list for the short term, other usb device drivers also aren't. I also don't mind patches to any part of the code :-)
Great. I am going to be on vacation next week. I am about half way through reading the USB 2.0 specification (http://www.usb.org/developers/docs/), and I will try to finish by next week and dive right in when I get back :-)
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Joseph Smith wrote:
Great. I am going to be on vacation next week. I am about half way through reading the USB 2.0 specification (http://www.usb.org/developers/docs/), and I will try to finish by next week and dive right in when I get back :-)
Take a look at the microchip PIC devices as an inexpensive alternative for a USB debug device. PIC24FJ128 series is ~$5 and should do the job.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1...
They give you all the source to a USB stack and the device supports custom modes as well as device, Host, and OTG.
Some versions have 4 uarts in addition to the USB 2.0 controller if you wanted to do USB --> Serial.
-Bari
On Tue, 08 Jul 2008 08:31:12 -0500, bari bari@onelabs.com wrote:
Joseph Smith wrote:
Great. I am going to be on vacation next week. I am about half way
through
reading the USB 2.0 specification (http://www.usb.org/developers/docs/),
and
I will try to finish by next week and dive right in when I get back :-)
Take a look at the microchip PIC devices as an inexpensive alternative for a USB debug device. PIC24FJ128 series is ~$5 and should do the job.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1...
They give you all the source to a USB stack and the device supports custom modes as well as device, Host, and OTG.
Some versions have 4 uarts in addition to the USB 2.0 controller if you wanted to do USB --> Serial.
-Bari
Thanks Bari, I will look into this :-)
On Fri, Jul 04, 2008 at 03:44:18AM +0200, Patrick Georgi wrote:
For UHCI:
..
For OHCI:
..
For EHCI:
- figure out how to gain control over a device from the USB1
controller (that will somehow interact with the USB1 driver)
Some comments, hopefully helpful:
USB1 devices on the EHCI root hub do not appear on the EHCI controller.
All EHCI controllers must also have one "companion" USB1 host controller per physical USB 2.0 port if they want to be backwards comatible so that USB1 devices can be connected to the root hub.
When a USB1 device is connected to a root hub port, the device appears on that port's companion HC PCI device instead of on the EHCI PCI device.
- PING/DATA2 protocol, microframes support
- extend HUB driver, so it handles USB1 devices on a USB2 hub
Look into USB 2.0 spec chapter 11.14 re Transaction Translators. USB2 hubs that support USB1 downstream devices have this split mode where a USB 2 transfer is used to start the USB1 transfer, and at a later time, another USB 2 transfer is used to complete the USB1 transfer.
USB devices:
- the keyboard driver is rather rudimentary
- mouse doesn't exist
I would recommend starting with the keyboard or mouse device drivers.
The only issue is that the HID Class can be a bit difficult to understand.
//Peter
Others have pretty much replied with what I was trying to point out, but here are a couple more comments:
On Thu, Jul 3, 2008 at 12:28 PM, Joseph Smith joe@settoplinux.org wrote:
I guess you don't get it. I am not doing it to mass produce and sell at a lower cost. I don't really care about any kind of profit. I'm simply doing it for a "HOWTO build your own USB 2.0 Debugger For Around 20 Dollars". $20 Dollars for a PCB??? I am going to use a generic PCB you can pick up at radio shack for 2 dollars. If I have to get some of the components at a larger volume to get a cheaper price and re-sell them to interested parties so they get a cheaper price I will. This is more for educational, learning, and teaching purposes. Everything is not about money you know (or not) :-(
I am not at all talking about greed, I am talking about practicality. You said you want to create instructions to build a $20 USB debug cable. I am saying that I don't think that is possible, and at *best*, you will be closer to the $50 number in the end. I am just hoping you realize that before you spend a lot of time and effort on it.
What sort of volume discounts are you expecting? The number I said for the 2272 *was* for high quantity. I see 1 for $11, 100 for $9.73, and 500 for $9.45. Still pretty high. If there are other USB device ICs of the *same caliber* that are much cheaper, I would be very interested to know about them.
If your goal is to learn USB, great, you'll learn a lot from doing something like that. Just expect that the kits or instructions you may offer in the end will get pretty close to the price of the Net20DC (at least in the US). Maybe you could create a cheaper solution for people outside the US, but expect that you will need to spin a PCB, and supply them to whoever might want to do it.
On Thu, Jun 26, 2008 at 03:57:39PM +0200, Carl-Daniel Hailfinger wrote:
Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe.
My experience is different. I bought mine from semiconductorstore.com http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083
They have it in stock, accept credit card payment and are quick to ship.
Can I emulate such a cable with the Geode USB target mode?
Possibly. Debug Class devices have some limitations that the Geode target will not be optimized for, but it might work, assuming of course the Geode USB is up an running already - ie. it's not a good plan to use this for bringing up the same Geode board itself, but it could be possible to use a Geode as debug device and send out ethernet on the other end for example.
Only one port on the Geode can be the target port, I don't know if the alix boards bring out that port. And a driver has to be written.
On Thu, Jun 26, 2008 at 10:28:09AM -0400, Joseph Smith wrote:
Yeh I think the NET20DC is way to expensive anyways, unless your in a mass production environment.
I don't find US$ 83 so bad actually. Granted, there's import duties too, but still not too bad considering the hours of development that would go into creating my own device.
I read somewhere you could make one, but I don't know how difficult that would be.
In theory sure! It is a USB device, but it is special in several ways, narrowing the possible development kits and USB chips that can be used a bit. (In particular, it must do high-speed communication.)
I was always wondering if you could just use two USB -> Serial adapters with a null modem cable in the middle???
No, you can not. More info on: http://www.coreboot.org/EHCI_Debug_Port
//Peter
Carl-Daniel Hailfinger wrote:
Hi,
I'm not officially back yet, but here's a question I don't want to forget: Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe. Can I emulate such a cable with the Geode USB target mode?
Regards, Carl-Daniel
We discussed this on the list a couple of years ago. These may be options, maybe not:
USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm
The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/
USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html
PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/
-Bari
On Thu, 26 Jun 2008 12:54:04 -0500, bari bari@onelabs.com wrote:
Carl-Daniel Hailfinger wrote:
Hi,
I'm not officially back yet, but here's a question I don't want to
forget:
Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe. Can I emulate such a cable with the Geode USB target mode?
Regards, Carl-Daniel
We discussed this on the list a couple of years ago. These may be options, maybe not:
USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm
The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/
USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html
PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/
-Bari
Hmm, hardware wise, what is the difference between these and the NET20DC?
On Thu, Jun 26, 2008 at 03:29:00PM -0400, Joseph Smith wrote:
USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm
The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/
USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html
PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/
None of these cables work.
Hmm, hardware wise, what is the difference between these and the NET20DC?
The above are typically Communication Device Class functions, while the NET20DC is a Debug Class funcion.
Please read the Debug Class specification which is linked from the wiki page. That spec is easy to grok if you already know USB. :)
//Peter
On Thu, 26 Jun 2008 21:36:04 +0200, Peter Stuge peter@stuge.se wrote:
On Thu, Jun 26, 2008 at 03:29:00PM -0400, Joseph Smith wrote:
USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm
The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/
USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html
PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/
None of these cables work.
Hmm, hardware wise, what is the difference between these and the NET20DC?
The above are typically Communication Device Class functions, while the NET20DC is a Debug Class funcion.
That's the software side right? I'm wondering about physical hardware?
Please read the Debug Class specification which is linked from the wiki page. That spec is easy to grok if you already know USB. :)
Maybe that's my problem, I know some about USB (thanks to coreboot), but not a whole lot. If I did, I would already have UHCI and EHCI working in filo :-)
On Thu, 26 Jun 2008 12:54:04 -0500, bari bari@onelabs.com wrote:
Carl-Daniel Hailfinger wrote:
Hi,
I'm not officially back yet, but here's a question I don't want to
forget:
Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe. Can I emulate such a cable with the Geode USB target mode?
Regards, Carl-Daniel
We discussed this on the list a couple of years ago. These may be options, maybe not:
USB 2.0 Host-to-Host Cable http://www.pccasegear.com/prod3972.htm
The USB 2.0 LINK & NETWORK CABLE http://www.linkusb.com/
USB 2.0 Host-to-Host Cable http://www.datapro.net/products/UL2.html
PCLinq2 (PL-2501) Hi-Speed USB Bridge Cable http://www.usbfiletransfer.com/
Well, as some of you may know I am a bit of a hardware hacker. That's what brought me to coreboot in the first place. As soon as my budget will allow it I am going to get a NET20DC, pop open the little box, and exploit the hardware. I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars. I'm also going to get one of the Host-to-Host Cables mentioned above (you can find them on eBay for less than 10 dollars) and see how hard it would be to convert one. Once I start this little side project, is it ok to setup a wiki page on coreboot, or could there be liability issues? Otherwise I will just post a discrete page on my site.
On Fri, Jun 27, 2008 at 10:28:07AM -0400, Joseph Smith wrote:
Well, as some of you may know I am a bit of a hardware hacker. That's what brought me to coreboot in the first place.
That does not get you too far when it comes to USB, which has several layers of protocol. Please do look into the USB spec: http://www.usb.org/developers/docs/
As soon as my budget will allow it I am going to get a NET20DC, pop open the little box, and exploit the hardware.
You will find two PLX Technology NET 2270 chips and a microcontroller (I'm not sure which micro it was, maybe Ubicom SX) responsible for configuration and data flow control in the NET 2270s.
http://www.plxtech.com/products/net2000/
I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars.
In which quantity?
I'm also going to get one of the Host-to-Host Cables mentioned above (you can find them on eBay for less than 10 dollars) and see how hard it would be to convert one.
This will not be a hardware exercise. I imagine the CDC cables are constructed similar to the NET20DC, but the microcontroller software within will be quite different.
So, you will have to reverse engineer the microcontroller software, and re-engineering a software that does what the NET20DC does.
Assuming of course that the USB chips in the cheapo CDC cables are as flexible as NET 2270 - which I doubt.
Once I start this little side project, is it ok to setup a wiki page on coreboot, or could there be liability issues? Otherwise I will just post a discrete page on my site.
You will be learning a lot about USB - which I think is a great idea! I like USB a lot. I strongly recommend reading the USB spec. It is a few hundred pages, but you can skim some parts. It is really required reading. I think USB is well-designed and far too few know it well - so go for it! :)
All I'm saying is don't expect it to be about hardware.
//Peter
On Fri, 27 Jun 2008 17:04:29 +0200, Peter Stuge peter@stuge.se wrote:
On Fri, Jun 27, 2008 at 10:28:07AM -0400, Joseph Smith wrote:
Well, as some of you may know I am a bit of a hardware hacker. That's what brought me to coreboot in the first place.
That does not get you too far when it comes to USB, which has several layers of protocol. Please do look into the USB spec: http://www.usb.org/developers/docs/
Thanks for the tip Peter, I will do some reading.
As soon as my budget will allow it I am going to get a NET20DC, pop open the little box, and exploit the hardware.
You will find two PLX Technology NET 2270 chips and a microcontroller (I'm not sure which micro it was, maybe Ubicom SX) responsible for configuration and data flow control in the NET 2270s.
Is the datasheet publicly available?
I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars.
In which quantity?
Maybe when I figure it out, I will buy a big batch and sell them cheaper to those interested:-)
I'm also going to get one of the Host-to-Host Cables mentioned above (you can find them on eBay for less than 10 dollars) and see how hard it would be to convert one.
This will not be a hardware exercise. I imagine the CDC cables are constructed similar to the NET20DC, but the microcontroller software within will be quite different.
So, you will have to reverse engineer the microcontroller software, and re-engineering a software that does what the NET20DC does.
So is there some kind of memory device with the "microcontroller software"? Like a eprom or eeprom??
Assuming of course that the USB chips in the cheapo CDC cables are as flexible as NET 2270 - which I doubt.
Once I start this little side project, is it ok to setup a wiki page on coreboot, or could there be liability issues? Otherwise I will just post a discrete page on my site.
You will be learning a lot about USB - which I think is a great idea!
Good, than maybe this little side project will work out great for everyone. Maybe I will learn so much about USB I will be able contribute else where; like filo, GRUB2, and LegacyBIOS :-)
I like USB a lot. I strongly recommend reading the USB spec. It is a few hundred pages, but you can skim some parts. It is really required reading. I think USB is well-designed and far too few know it well - so go for it! :)
Also, another question about this topic. I read somewhere someone was working on a Linux Kernel driver for the NET20DC for the host PC. Did this ever implimented? Can you use the NET20DC in linux on a host PC? If so, how does it work?
On Fri, Jun 27, 2008 at 01:15:32PM -0400, Joseph Smith wrote:
You will find two PLX Technology NET 2270 chips and a microcontroller (I'm not sure which micro it was, maybe Ubicom SX) responsible for configuration and data flow control in the NET 2270s.
Is the datasheet publicly available?
Yes, but you have to register on their web site.
I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars.
In which quantity?
Maybe when I figure it out, I will buy a big batch and sell them cheaper to those interested:-)
Even if you have to buy 1000 pcs?
So, you will have to reverse engineer the microcontroller software, and re-engineering a software that does what the NET20DC does.
So is there some kind of memory device with the "microcontroller software"? Like a eprom or eeprom??
I expect it to be stored in internal memory in the microcontroller package. I'll open my device up if I can find it to check if I remember correctly about the Ubicom.
You will be learning a lot about USB - which I think is a great idea!
Good, than maybe this little side project will work out great for everyone. Maybe I will learn so much about USB I will be able contribute else where; like filo, GRUB2, and LegacyBIOS :-)
USB has strict distinction between hosts and devices. This is a fundamental design decision detailed pretty well in the spec.
In order to create your own Debug Class device you need to learn a lot about devices and almost nothing about hosts.
When writing a USB stack for the host one needs to learn everything about the Host Controller and almost nothing about devices.
Also, another question about this topic. I read somewhere someone was working on a Linux Kernel driver for the NET20DC for the host PC. Did this ever implimented? Can you use the NET20DC in linux on a host PC?
Yes.
If so, how does it work?
USB serial port. CONFIG_USB_SERIAL_DEBUG enables the driver.
//Peter
On Fri, 27 Jun 2008 19:34:10 +0200, Peter Stuge peter@stuge.se wrote:
On Fri, Jun 27, 2008 at 01:15:32PM -0400, Joseph Smith wrote:
You will find two PLX Technology NET 2270 chips and a microcontroller (I'm not sure which micro it was, maybe Ubicom SX) responsible for configuration and data flow control in the NET 2270s.
Is the datasheet publicly available?
Yes, but you have to register on their web site.
Ok, thanks.
I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars.
In which quantity?
Maybe when I figure it out, I will buy a big batch and sell them cheaper to those interested:-)
Even if you have to buy 1000 pcs?
Sure if I have enough people interested.
So, you will have to reverse engineer the microcontroller software, and re-engineering a software that does what the NET20DC does.
So is there some kind of memory device with the "microcontroller software"? Like a eprom or eeprom??
I expect it to be stored in internal memory in the microcontroller package. I'll open my device up if I can find it to check if I remember correctly about the Ubicom.
Thanks that would help a lot. What would be really great, is if you could open it up and send me some high res pics of both sides of the board. If you did that I may not need to buy one.
You will be learning a lot about USB - which I think is a great idea!
Good, than maybe this little side project will work out great for everyone. Maybe I will learn so much about USB I will be able contribute else where; like filo, GRUB2, and LegacyBIOS :-)
USB has strict distinction between hosts and devices. This is a fundamental design decision detailed pretty well in the spec.
In order to create your own Debug Class device you need to learn a lot about devices and almost nothing about hosts.
When writing a USB stack for the host one needs to learn everything about the Host Controller and almost nothing about devices.
Thanks for the tip. I would like to write it in C, my assembly is not so good. Possible??
Also, another question about this topic. I read somewhere someone was working on a Linux Kernel driver for the NET20DC for the host PC. Did this ever implimented? Can you use the NET20DC in linux on a host PC?
Yes.
Cool
If so, how does it work?
USB serial port. CONFIG_USB_SERIAL_DEBUG enables the driver.
So if this is enabled in in the kernel, what kind of device does it show up as in the serial terminal emulator?
On Fri, Jun 27, 2008 at 02:17:01PM -0400, Joseph Smith wrote:
I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars.
In which quantity?
Maybe when I figure it out, I will buy a big batch and sell them cheaper to those interested:-)
Even if you have to buy 1000 pcs?
Sure if I have enough people interested.
Right. I think it is really easy to buy components for a debug class device for less than USD 20, but you do need quite a big volume. That translates to keeping big stock. Which is expensive. You will also want to get paid at least a little for your invested time. (I would estimate five-six months*160h to implement a debug device for someone new to USB, and that is probably a bit optimistic.)
I'll open my device up if I can find it to check if I remember correctly about the Ubicom.
Thanks that would help a lot.
To be honest, I don't think it would help at all, but I appreciate the curiosity and will be glad to provide photos when I find my device! :)
If you did that I may not need to buy one.
If you want to design a new debug class design from scratch you definately do not need to reverse engineer the NET20DC. The hardware design is trivial.
You "just" need to learn a lot about USB.
USB has strict distinction between hosts and devices. This is a fundamental design decision detailed pretty well in the spec.
In order to create your own Debug Class device you need to learn a lot about devices and almost nothing about hosts.
When writing a USB stack for the host one needs to learn everything about the Host Controller and almost nothing about devices.
Thanks for the tip. I would like to write it in C, my assembly is not so good. Possible??
I'm a little unsure what you mean here. There are C compilers for many microcontrollers, so if you are designing a new device, you can just pick something that seems to fit your choice of USB interface chip and make sure there's a C compiler for it.
I am already assuming you are familiar with some definitions per the USB spec, maybe I should clarify a bit. The USB host is the PC, which has a root hub with one or more ports. USB devices, or functions, are what connect to these ports.
Creating a debug class compliant device does not involve the host, except when you want to test it.
If so, how does it work?
USB serial port. CONFIG_USB_SERIAL_DEBUG enables the driver.
So if this is enabled in in the kernel, what kind of device does it show up as in the serial terminal emulator?
I don't understand. A serial terminal emulator doesn't really know about devices.
You get one /dev/ttyUSBx serial port. Bytes sent out on the EHCI Debug Port on the system being debugged will be coming in on that serial port on the debugger host, and vice versa.
//Peter
On Fri, 27 Jun 2008 20:58:24 +0200, Peter Stuge peter@stuge.se wrote:
On Fri, Jun 27, 2008 at 02:17:01PM -0400, Joseph Smith wrote:
I'll bet anyone all the electrical components inside that little box can be purchased for less than 20 dollars.
In which quantity?
Maybe when I figure it out, I will buy a big batch and sell them cheaper to those interested:-)
Even if you have to buy 1000 pcs?
Sure if I have enough people interested.
Right. I think it is really easy to buy components for a debug class device for less than USD 20, but you do need quite a big volume. That translates to keeping big stock. Which is expensive. You will also want to get paid at least a little for your invested time. (I would estimate five-six months*160h to implement a debug device for someone new to USB, and that is probably a bit optimistic.)
I don't really care about getting paid. That is what my job is for :-) I don't mind putting a big volume on the CC just as long as It can sell them and make my money back.
I'll open my device up if I can find it to check if I remember correctly about the Ubicom.
Thanks that would help a lot.
To be honest, I don't think it would help at all, but I appreciate the curiosity and will be glad to provide photos when I find my device! :)
Photos, will help it will show me if there are little caps, resisters, diodes, etc between chips.
If you did that I may not need to buy one.
If you want to design a new debug class design from scratch you definately do not need to reverse engineer the NET20DC. The hardware design is trivial.
You "just" need to learn a lot about USB.
Ok, sounds good. I am pretty good at self teaching when I put my mind to it.
USB has strict distinction between hosts and devices. This is a fundamental design decision detailed pretty well in the spec.
In order to create your own Debug Class device you need to learn a lot about devices and almost nothing about hosts.
When writing a USB stack for the host one needs to learn everything about the Host Controller and almost nothing about devices.
Thanks for the tip. I would like to write it in C, my assembly is not so good. Possible??
I'm a little unsure what you mean here. There are C compilers for many microcontrollers, so if you are designing a new device, you can just pick something that seems to fit your choice of USB interface chip and make sure there's a C compiler for it.
Nevermind, you just answered that question.
I am already assuming you are familiar with some definitions per the USB spec, maybe I should clarify a bit. The USB host is the PC, which has a root hub with one or more ports. USB devices, or functions, are what connect to these ports.
Right.
Creating a debug class compliant device does not involve the host, except when you want to test it.
Right.
If so, how does it work?
USB serial port. CONFIG_USB_SERIAL_DEBUG enables the driver.
So if this is enabled in in the kernel, what kind of device does it show up as in the serial terminal emulator?
I don't understand. A serial terminal emulator doesn't really know about devices.
Yes it does, the emulator needs to know what port/device to connect to (ex. /dev/ttyS0, /dev/ttyS1, /dev/ttyUSB0, etc)
You get one /dev/ttyUSBx serial port. Bytes sent out on the EHCI Debug Port on the system being debugged will be coming in on that serial port on the debugger host, and vice versa.
Ok, that makes sense, I have a USB-> Serial adapter for my laptop that comes up as /dev/ttyUSB0. So Linux signifys the USB debugger as a USB serial device(/dev/ttyUSBx). If so that answers that question.
On 27.06.2008 21:34, Joseph Smith wrote:
On Fri, 27 Jun 2008 20:58:24 +0200, Peter Stuge peter@stuge.se wrote:
Creating a debug class compliant device does not involve the host, except when you want to test it.
Right.
I think the design might become easier if you just create the debug part of the device and use the serial side of a plain usbserial device as direct interface. And Peter will hate the statement above.
Regards, Carl-Daniel
On Fri, Jun 27, 2008 at 03:34:20PM -0400, Joseph Smith wrote:
I'll open my device up if I can find it to check if I remember correctly about the Ubicom.
Thanks that would help a lot.
To be honest, I don't think it would help at all, but I appreciate the curiosity and will be glad to provide photos when I find my device! :)
Photos, will help it will show me if there are little caps, resisters, diodes, etc between chips.
Sure, there will be some passives to glue the three major blocks together.
USB serial port. CONFIG_USB_SERIAL_DEBUG enables the driver.
So if this is enabled in in the kernel, what kind of device does it show up as in the serial terminal emulator?
I don't understand. A serial terminal emulator doesn't really know about devices.
Yes it does, the emulator needs to know what port/device to connect to (ex. /dev/ttyS0, /dev/ttyS1, /dev/ttyUSB0, etc)
Oh that kind of device! :)
You get one /dev/ttyUSBx serial port. Bytes sent out on the EHCI Debug Port on the system being debugged will be coming in on that serial port on the debugger host, and vice versa.
Ok, that makes sense, I have a USB-> Serial adapter for my laptop that comes up as /dev/ttyUSB0. So Linux signifys the USB debugger as a USB serial device(/dev/ttyUSBx). If so that answers that question.
Right!
Note that the NET20DC isn't any kind of debugger, it can be thought of as a special type of proxy for USB transfers.
On Fri, Jun 27, 2008 at 09:43:50PM +0200, Carl-Daniel Hailfinger wrote:
I think the design might become easier if you just create the debug part of the device and use the serial side of a plain usbserial device as direct interface.
Actually I suggested something along those lines already in the wiki page. :)
But if someone is learning enough to make their own debug class device, it will be mostly a copypaste exercise to include a USB interface also for the other end.
And Peter will hate the statement above.
:) Mh, not so bad.
Looking at the economics of this project again, it requires the price to go down another $20, to make room for a USB-serial converter. (Though that has more uses, so maybe one could reduce that figure.)
//Peter
-
bari -
Carl-Daniel Hailfinger -
Joseph Smith -
Ken.Fuchs＠bench.com -
Patrick Georgi -
Peter Stuge -
Stefan Reinauer -
Tom Sylla