Re: uticom(4)

[Yorick Hardy <yorickhardy%gmail.com@localhost>]

On 2010-02-06, Jonathan A. Kollasch wrote:
> *NICE*, our own firmware, and sufficent docs (and compilers) to modify
> it are public it looks like.

Yes, you need pkgsrc/devel/sdcc and pkgsrc-wip/srecord
(GPL v2 and v3 respectively). Documentation is available
from the Texas Instruments website, and hopefully the
comments in the firmware sources are descriptive enough.

For the firware blob:
cd /usr/src/sys/dev/microcode/uticom && make tusb3410fw

For the firmware header file:
cd /usr/src/sys/dev/microcode/uticom && make tusb3410fw.h

> Where do i get one of these devices?
> (Says the person with 5+ uplcom(4)s he doesn't use.)

I got it bundled with a Huawei ETS 2258. But this cable
seems odd, it caused an old US-Robotics modem send and
receive LEDs to be constantly on.

I did not find any other examples except for connecting
to cellular phones and the evaluation board.

> There's not much point in putting the firmware in the kernel
> by default until we have console-on-ucom(4) support.

I did not figure out how to delay firmware load if the device
is already connected on boot, then the filesystem is not yet
available for firmload(9). Can anyone point me in the right
direction?

> > I encountered a problem with uhci_open (probably also ehci). uhci_open
> > sets nexttoggle to zero (src/sys/dev/usb/uhci.c line 3186) on every
> > pipe open. However, the device endpoint toggle will not reset to zero.
> > Since ucomopen seems to open the pipes for the bulk endpoints, this means
> > the device bulk endpoint toggle may differ from the pipe's nexttoggle
> > on every open.
> > 
> > I worked around the problem by clearing the halt feature on the bulk
> > endpoints which resets the data toggle to zero, but this should not
> > be necessary.
> 
> Oh, that must be the problem I was having with my AVRISP mkII.
> It should be fixed where appropriate (in the host
> controller driver).

I will look into it. I am surprised that no problems were encountered
before. I would have guessed that every instance of ucom(4) on uhci/ehci
would have problems.

-- 
Kind regards,

Yorick Hardy