Date: Thu, 28 Aug 2003 19:15:44 +0200 From: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net> To: Stuart Walsh <stu@ipng.org.uk> Cc: FreeBSD-Hackers@FreeBSD.org Subject: Re: Atmel USB Wireless devices Message-ID: <200308281915.44317.Danovitsch@Vitsch.net> In-Reply-To: <20030828132653.GD817@icecold.stu> References: <20030828132653.GD817@icecold.stu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 28 August 2003 15:26, Stuart Walsh wrote: > Hi, > > Firstly, it would be interesting to know if anyone else is working on > support for these devices before I get too far into it :) Yes, I have bought a bunch of them about a month ago, and at this moment = I=20 have a working driver for them. At this moment it's still a "beta" which = can=20 only do ad-hoc mode, but it works. > I've started working on support for the above devices and have had some > limited success so far. The device requires two sets of firmware to be > uploaded for it to work and I have managed to upload the first firmware > but it doesnt seem to want to boot. Any attempts to read the device > after uploading firmware result in error code 13(IOERROR). The Linux > driver calls usb_reset_device() after uploading the firmware but I can'= t > seem to find an equivelant in FreeBSD. The problem is that the device really dies after uploading the internal=20 firmware. It really needs a reset before it will communicate again. A usb-hub can send a reset signal down it's ports with a call to : usbd_reset_port(sc->atuwi_udev->myhub,sc->atuwi_udev->powersrc->portno,&T= ); After that the atmel processor will start communicating again. But it's=20 usb-address will be set to 0 (as always after a reset). So you will have to (re)set it's address back to what it was before the r= eset=20 with a call to : usbd_set_address(sc->atuwi_udev,my_old_address); The story gets more complex since the descriptors of the device have chan= ged=20 by the reset. (first it only had a control endpoint, now it also has 2 bu= lk=20 endpoints). Somehow you'll have to reload the new descriptor to please th= e=20 kernel. I have come very far in this process, but I am doing something wrong with= =20 releasing the old descriptors... So at this moment I use a trick to reset= the=20 device. After uploading the internal firmware I unplug the USB connector just far= =20 enough for the data-lines to disconnect, but without disconnecting the=20 power-lines. After plugging the device back in the kernel recognizes it a= gain=20 and uploads the external firmware. I'll come back to this thread tomorrow and post some links to my code, bu= t I=20 have to run now. grtz, Daan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308281915.44317.Danovitsch>