Re: uticom(4)

["Jonathan A. Kollasch" <jakllsch%kollasch.net@localhost>]

On Fri, Feb 05, 2010 at 12:13:01AM +0200, Yorick Hardy wrote:
> I think uticom(4) is now ready for comment.
> 
> The source for uticom(4) is available at
> 
>  ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom20100204.tar.bz2
> 
> (extract in src/) and the additional changes to src at
> 
>  ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom.diff
> 
> This is not a port of OpenBSD uticom(4), nor of the Linux driver.
> This driver uses different firmware from the OpenBSD and Linux drivers.

*NICE*, our own firmware, and sufficent docs (and compilers) to modify
it are public it looks like.

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

> 
> The driver uses a header file (src/sys/dev/microcode/uticom/tusb3410fw.h)
> for the firmware.  The firmware is about 5KB. firmload(9) will be used if
> UTICOM_TUSB3410FW_H is undefined in src/sys/dev/usb/uticom.h (line 68).

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

> 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).

        Jonathan Kollasch