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>