USB stack / configuration 0

[Daan Vreeken [PA4DAN]]

On Wednesday 07 January 2004 09:07, Bernd Walter wrote:
> On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote:
> > On Wednesday 07 January 2004 17:08, Bernd Walter wrote:
> > > > I don't think it IS a dumb device, there is a USB spec called DFU
> > > > which covers it and the hosts job is to do the reenumeration.
> > >
> > > Sparing a transistor to offload the work to the host were its also
> > > way more complex to do is dump.
> > > If this is part of the Spec, then the spec is dump too.
> > Err yes, this IS USB we're talking about here :)
> Reead your spec - it's not part of USB itself.
As long as there are a lot of usefull devices that use the DFU spec, to me it 
seems no more than logicle to implement it in FreeBSD, no matter how dumb the 
system may sound :)

> > > usbd_reset_port should do from the USB point of view, but this doesn't
> > > trigger Free BSD to do a reconfiguration of the device, which is
> > > required after reset.
> > > Maybe the following will do instead:
> > > usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE)
> > > delay(USB_PORT_POWERUP_DELAY);
> > > usbd_set_port_feature(dev, port, UHF_PORT_ENABLE)
> > > dev and port is that from the hub.
> > Except that would remove power to the port I think..
> AFAIK power is independend, but I'm not 100% shure.
I have written a driver for Atmel USB WLAN adapters for FreeBSD recently (and 
still am). The device also needs it's firmware to be uploaded via the DFU 
interface. The first time the device is plugged in, an internal ROM mask is 
mapped into code-space of the processor which provides it with only a very 
basic "USB stack" that can do enumeration and DFU. Via DFU the host uploads 
the firmware into RAM. At the end of the upload the host asks the device to 
"manifest" the firmware.
For the device this means having to switch the ROM image with the RAM image 
which is impossible while running in the specific processor. Thus the 
processor tells it's core to map RAM into code-space and resets itself. After 
that the device will apear again with address = 0.
The host then needs to set the address, re-read the device descriptor (it has 
changes, the device now offers endpoints etc), attach a driver.

Btw, a reset can be sent down to a usb device from within a driver with this 
line of code :

  usb_port_status_t       stat;

  usbd_reset_port(sc->atuwi_udev->myhub,
    sc->atuwi_udev->powersrc->portno, &stat);

For my device driver I have made a small change to the USB Stack and I have 
introduced the return code "USB_ATTACH_NEED_RESET" for drivers to tell the 
USB Stack thee device needs to be re-enumerated. The stack then automatically 
re-assigns the device it's address, and re-probes for drivers. This way even 
two seperate drivers could be made : one with the firmware and one with the 
real driver.
Is anyone interrested in a patch maybe?

btw2: I have submitted a couple of patches in 2003 (one of witch is almost a 
year old at this moment), but none of the got comments / commited. Is anyone 
really working on USB code development / debugging lately? I want to see ALL 
USB devices working with FreeBSD and am willing to devote my spare-time to 
achieving this.

grtz,
Daan