Date: Wed, 7 Jan 2004 11:04:37 +0100 From: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net> To: ticso@cicely.de Cc: FreeBSD-hackers@FreeBSD.org Subject: Re: USB stack / configuration 0 Message-ID: <200401071104.37461.Danovitsch@Vitsch.net> In-Reply-To: <20040107080720.GH45569@cicely12.cicely.de> References: <3FFA04A8.30601@evilrealms.net> <200401071734.05764.doconnor@gsoft.com.au> <20040107080720.GH45569@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 m=
e it=20
seems no more than logicle to implement it in FreeBSD, no matter how dumb=
the=20
system may sound :)
> > > usbd_reset_port should do from the USB point of view, but this does=
n'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=20
still am). The device also needs it's firmware to be uploaded via the DFU=
=20
interface. The first time the device is plugged in, an internal ROM mask =
is=20
mapped into code-space of the processor which provides it with only a ver=
y=20
basic "USB stack" that can do enumeration and DFU. Via DFU the host uploa=
ds=20
the firmware into RAM. At the end of the upload the host asks the device =
to=20
"manifest" the firmware.
For the device this means having to switch the ROM image with the RAM ima=
ge=20
which is impossible while running in the specific processor. Thus the=20
processor tells it's core to map RAM into code-space and resets itself. A=
fter=20
that the device will apear again with address =3D 0.
The host then needs to set the address, re-read the device descriptor (it=
has=20
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 t=
his=20
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 ha=
ve=20
introduced the return code "USB_ATTACH_NEED_RESET" for drivers to tell th=
e=20
USB Stack thee device needs to be re-enumerated. The stack then automatic=
ally=20
re-assigns the device it's address, and re-probes for drivers. This way e=
ven=20
two seperate drivers could be made : one with the firmware and one with t=
he=20
real driver.
Is anyone interrested in a patch maybe?
btw2: I have submitted a couple of patches in 2003 (one of witch is almos=
t a=20
year old at this moment), but none of the got comments / commited. Is any=
one=20
really working on USB code development / debugging lately? I want to see =
ALL=20
USB devices working with FreeBSD and am willing to devote my spare-time t=
o=20
achieving this.
grtz,
Daan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401071104.37461.Danovitsch>