From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 28 10:39:54 2003 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 E09BB16A4BF for ; Thu, 28 Aug 2003 10:39:53 -0700 (PDT) Received: from purge.bash.sh (purge.bash.sh [193.178.223.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1B2843FCB for ; Thu, 28 Aug 2003 10:39:52 -0700 (PDT) (envelope-from stu@ipng.org.uk) Received: from acbcb75e.ipt.aol.com ([172.188.183.94] helo=stu.ipng.org.uk) by purge.bash.sh with asmtp (Exim 4.20 #2 ) id 19sQkP-0000JC-35; Thu, 28 Aug 2003 18:39:49 +0100 Received: from baal.stu ([192.168.2.2] helo=icecold.stu) by stu.ipng.org.uk with esmtp (Exim 4.10) id 19sQlt-000K76-00; Thu, 28 Aug 2003 18:41:21 +0100 Received: from icecold.stu (localhost [127.0.0.1]) by icecold.stu (8.12.7/8.12.7) with ESMTP id h7SHdeCo006521; Thu, 28 Aug 2003 18:39:40 +0100 (BST) (envelope-from stu@ipng.org.uk) Received: (from stu@localhost) by icecold.stu (8.12.7/8.12.7/Submit) id h7SHdXmN006520; Thu, 28 Aug 2003 18:39:33 +0100 (BST) X-Authentication-Warning: icecold.stu: stu set sender to stu@ipng.org.uk using -f Date: Thu, 28 Aug 2003 18:39:33 +0100 From: Stuart Walsh To: "Daan Vreeken [PA4DAN]" Message-ID: <20030828173932.GA6368@icecold.stu> References: <20030828132653.GD817@icecold.stu> <200308281915.44317.Danovitsch@Vitsch.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200308281915.44317.Danovitsch@Vitsch.net> User-Agent: Mutt/1.5.4i X-SA-Exim-Mail-From: stu@ipng.org.uk Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.3 required=7.5 tests=EMAIL_ATTRIBUTION,FORGED_RCVD_TRAIL,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SA-Exim-Version: 3.0 (built Tue Jul 1 14:25:23 BST 2003) X-SA-Exim-Scanned: Yes cc: FreeBSD-Hackers@FreeBSD.org Subject: Re: Atmel USB Wireless devices 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: Thu, 28 Aug 2003 17:39:54 -0000 On Thu Aug 28, 07:15P +0200, Daan Vreeken [PA4DAN] wrote: > 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 > have a working driver for them. At this moment it's still a "beta" which can > only do ad-hoc mode, but it works. Ok, that saves some duplicated effort :) > > 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 > 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); > That bit works fine. > After that the atmel processor will start communicating again. But it's > 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 reset > with a call to : > usbd_set_address(sc->atuwi_udev,my_old_address); This fails with another IOERROR > > The story gets more complex since the descriptors of the device have changed > by the reset. (first it only had a control endpoint, now it also has 2 bulk > endpoints). Somehow you'll have to reload the new descriptor to please the > kernel. > I have come very far in this process, but I am doing something wrong with > releasing the old descriptors... So at this moment I use a trick to reset the > device. > After uploading the internal firmware I unplug the USB connector just far > enough for the data-lines to disconnect, but without disconnecting the > power-lines. After plugging the device back in the kernel recognizes it again > and uploads the external firmware. > Hopefully I can look into this when I can talk to the device a bit better :) > I'll come back to this thread tomorrow and post some links to my code, but I > have to run now. Thanks for the info.. I'll wait to see your code and see where I'm going wrong. Regards, Stuart