Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jan 2004 22:24:59 +1030
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net>, ticso@cicely.de
Cc:        FreeBSD-hackers@FreeBSD.org
Subject:   Re: USB stack / configuration 0
Message-ID:  <200401072224.59350.doconnor@gsoft.com.au>
In-Reply-To: <200401071104.37461.Danovitsch@Vitsch.net>
References:  <3FFA04A8.30601@evilrealms.net> <20040107080720.GH45569@cicely12.cicely.de> <200401071104.37461.Danovitsch@Vitsch.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 07 January 2004 20:34, Daan Vreeken [PA4DAN] wrote:
> > 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 :)

Yeah.. well there are plenty of dumb things about USB :)

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

Interesting way of making it :)
The device I have uses a Ti chip which has USB primitives and powers up with 
DFU only support, and then needs a reset to start executing the new code from 
RAM.

> 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?

Ooh yes please :)

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

I thought Josef Karthauser <joe@FreeBSD.org> was doing some USB work, but I am 
not certain. I can test some stuff - I have a variety of USB 1 and 2 hardware 
(USB1 scanner, USB2 card reader, USB1 Pocket PC cradle *hiss* :), mouse, USB2 
HD enclosure, USB1 printer and dongle..)

I updated by laptop to 5.x recently so that should make this more relevant :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401072224.59350.doconnor>