From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 7 02:03:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1442216A4CE for ; Wed, 7 Jan 2004 02:03:49 -0800 (PST) Received: from Vitsch.net (b74143.upc-b.chello.nl [212.83.74.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8814A43D45 for ; Wed, 7 Jan 2004 02:03:45 -0800 (PST) (envelope-from Danovitsch@Vitsch.net) Received: from FreeBSD.Danovitsch.LAN (b83007.upc-b.chello.nl [212.83.83.7]) by Vitsch.net (8.12.3p2/8.11.3) with ESMTP id i07A38Xe089362; Wed, 7 Jan 2004 11:03:18 +0100 (CET) (envelope-from Danovitsch@Vitsch.net) Content-Type: text/plain; charset="iso-8859-1" From: "Daan Vreeken [PA4DAN]" To: ticso@cicely.de Date: Wed, 7 Jan 2004 11:04:37 +0100 User-Agent: KMail/1.4.3 References: <3FFA04A8.30601@evilrealms.net> <200401071734.05764.doconnor@gsoft.com.au> <20040107080720.GH45569@cicely12.cicely.de> In-Reply-To: <20040107080720.GH45569@cicely12.cicely.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200401071104.37461.Danovitsch@Vitsch.net> cc: Bernd Walter cc: FreeBSD-hackers@FreeBSD.org Subject: Re: USB stack / configuration 0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 10:03:49 -0000 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