[coreboot] USB debug cables and emulation
joe at settoplinux.org
Fri Jun 27 21:34:20 CEST 2008
On Fri, 27 Jun 2008 20:58:24 +0200, Peter Stuge <peter at 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
>> > 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.
> 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.
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.
More information about the coreboot