From patchwork Thu Dec 15 11:25:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Guido_G=C3=BCnther?= X-Patchwork-Id: 9475853 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 754C7607EE for ; Thu, 15 Dec 2016 11:26:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 669D028751 for ; Thu, 15 Dec 2016 11:26:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5A7A128757; Thu, 15 Dec 2016 11:26:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_TVD_MIME_EPI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BC97428751 for ; Thu, 15 Dec 2016 11:26:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751359AbcLOL0M (ORCPT ); Thu, 15 Dec 2016 06:26:12 -0500 Received: from photon.sigxcpu.org ([95.142.169.183]:47673 "EHLO photon.sigxcpu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752661AbcLOL0L (ORCPT ); Thu, 15 Dec 2016 06:26:11 -0500 Received: from honk.sigxcpu.org (localhost [127.0.0.1]) by photon.sigxcpu.org (Postfix) with ESMTPS id 5D3DB21E; Thu, 15 Dec 2016 12:26:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by honk.sigxcpu.org (Postfix) with ESMTP id 1465BFB03; Thu, 15 Dec 2016 12:26:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at honk.sigxcpu.org Received: from honk.sigxcpu.org ([127.0.0.1]) by localhost (honk.sigxcpu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YfgYaIg9L42; Thu, 15 Dec 2016 12:26:00 +0100 (CET) Received: by bogon.sigxcpu.org (Postfix, from userid 1000) id 40D9940BBF; Thu, 15 Dec 2016 12:25:29 +0100 (CET) Date: Thu, 15 Dec 2016 12:25:29 +0100 From: Guido =?iso-8859-1?Q?G=FCnther?= To: Stefan Schmidt Cc: linux-wpan@vger.kernel.org Subject: Re: Flashing firmware onto atusb Message-ID: <20161215112529.bkvkhtvj3ufpc6in@bogon.m.sigxcpu.org> References: <20161215094534.sc5awrane6eeud6f@bogon.m.sigxcpu.org> <6fb4e9b3-75f7-751c-01df-3e1551a3d619@osg.samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6fb4e9b3-75f7-751c-01df-3e1551a3d619@osg.samsung.com> User-Agent: NeoMutt/20161126 (1.7.1) Sender: linux-wpan-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wpan@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Stefan, On Thu, Dec 15, 2016 at 11:44:53AM +0100, Stefan Schmidt wrote: > Hello. > > On 15/12/16 10:45, Guido Günther wrote: > > Hi, > > I'm trying to flash firmware onto a new atusb dongle but: > > > Is this one of the dongles from the recent builds or is it an old one? > The new ones already come with version 0.3 of the firmware. :-) ...but I want to be able to flash my own in the future ;) > > > > > # lsusb | grep Qi > > Bus 001 Device 014: ID 20b7:1540 Qi Hardware ben-wpan, AT86RF230-based > > > > # dfu-util -d 20b7:1540 -D atusb-0.3.dfu > > dfu-util 0.9 > > > > Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. > > Copyright 2010-2016 Tormod Volden and Stefan Schmidt > > This program is Free Software and has ABSOLUTELY NO WARRANTY > > Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ > > > > dfu-util: Invalid DFU suffix signature > > dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! > > dfu-util: Device has DFU interface, but has no DFU functional descriptor > > Deducing device DFU version from functional descriptor length > > Opening DFU capable USB device... > > ID 20b7:1540 > > Run-time device DFU version 0100 > > Claiming USB DFU Runtime Interface... > > Determining device status: state = appIDLE, status = 0 > > Device really in Runtime Mode, send DFU detach request... > > Resetting USB... > > dfu-util: Device has DFU interface, but has no DFU functional descriptor > > Deducing device DFU version from functional descriptor length > > dfu-util: Lost device after RESET? > > # echo $? > > 74 > > > > dmesg has: > > > > # dmesg > > [ 2802.216273] usb 1-1: reset full-speed USB device number 14 using xhci_hcd > > [ 2807.496177] usb 1-1: USB disconnect, device number 14 > > [ 2807.760001] usb 1-1: new full-speed USB device number 15 using xhci_hcd > > [ 2807.901993] usb 1-1: New USB device found, idVendor=20b7, idProduct=1540 > > [ 2807.901997] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1 > > [ 2807.902000] usb 1-1: SerialNumber: 47303530353015102717 > > > > Is there anything obvious I am missing? > > Seems you tried to flash the device when already out of the bootloader mode. > Please try the above command again when inserting the dongle. The device is > in the bootloader, waiting for firmware updates, as long as the red LED is > on after insertion. That worked: # dfu-util -d 20b7:1540 -D atusb-0.3.dfu dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Opening DFU capable USB device... ID 20b7:1540 Run-time device DFU version 0101 Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuDNLOAD-IDLE, status = 8 aborting previous incomplete transfer Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 0101 Device returned transfer size 64 Copying data from PC to DFU device Download [=========================] 100% 6026 bytes Download done. state(2) = dfuIDLE, status(0) = No error condition is present Done! I was thinking about s.th. like bootloader mode in the first place but this deceived me: Device really in Runtime Mode, send DFU detach request... Resetting USB... dfu-util: Device has DFU interface, but has no DFU functional descriptor so I thought dfu-util would be able to get the device back into bootloader mode. And in fact if the device is in runtime mode already I do see a device reset (the red led turns back on) but it the fails. Is this a bug in dfu-util or expected? If so should it be documented like in the attache patch? Cheers, -- Guido From 9b4fb09336535a50752f31c2d5e649f17e76ea9b Mon Sep 17 00:00:00 2001 Message-Id: <9b4fb09336535a50752f31c2d5e649f17e76ea9b.1481801063.git.agx@sigxcpu.org> From: =?UTF-8?q?Guido=20G=C3=BCnther?= Date: Thu, 15 Dec 2016 12:23:09 +0100 Subject: [PATCH] atusb: Document that dfu-util needs to be run before device enters runtime mode --- atusb/ChangeLog | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/atusb/ChangeLog b/atusb/ChangeLog index 62b7cef..7e1d96d 100644 --- a/atusb/ChangeLog +++ b/atusb/ChangeLog @@ -7,8 +7,12 @@ ChangeLog: * Remove FCS frame check from firmware and leave it to the driver * Use extended operation mode for TX for automatic ACK handling -To flash the firmware you need dfu-util on the host: -dfu-util -d 20b7:1540 -D atusb-0.3.dfu +To flash the firmware you need dfu-util on the host. Issue + + dfu-util -d 20b7:1540 -D atusb-0.3.dfu + +right after plugging the device into the USB port while the red led is still +on. For the Atmel Raven USB dongle a full JTAG setup is needed to flash the firmware as no DFU bootloader is available there. -- 2.10.2