| Message ID | 20161215112529.bkvkhtvj3ufpc6in@bogon.m.sigxcpu.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi, On 12/15/2016 12:25 PM, Guido Günther wrote: > 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? maybe this is actual the difference between dfu-util 0.7 and 0.9... I expierenced issues with dfu-util greather than 0.7, can you recheck with 0.7? I think there is some timing issue in dfu firmware part of atusb... :-/ - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Alexander, On Thu, Dec 15, 2016 at 12:38:44PM +0100, Alexander Aring wrote: > > Hi, > > On 12/15/2016 12:25 PM, Guido Günther wrote: > > 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? > > maybe this is actual the difference between dfu-util 0.7 and 0.9... > > I expierenced issues with dfu-util greather than 0.7, can you recheck > with 0.7? Version 0.7 give the same error here. Cheers, -- Guido > > I think there is some timing issue in dfu firmware part of atusb... :-/ > > - Alex > -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 15/12/16 12:25, Guido Günther wrote: > 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 ;) Sure enough. :) Just mentioned that because you flashed the 0.3 firmware file which is identical with whats on it. Happy to see someone hacking on the firmware side as well. :) >> >>> >>> # 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! Good. That will get you going. > 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? You observation is right, it performs the reset as it should. I run into that myself but its all the way down on my todo list to work out what is the problem here. Is it dfu-util? Is it the firmware? Or just some simple race? Even when working on the firmware myself I found it working well enough to plug and unplug the device when wanting to flash a new version. There is also a little userspace tool which can reset the device over libusb. Its in the git repo somewhere. For now I can take the doc patch to make it clearer. If you have an interest to work out what is going wrong and make the update working smoothly from a device already after the bootloader that would be great. Happily accepting patches to the firmware if the bug is in there. :) regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 15/12/16 12:38, Alexander Aring wrote: > > Hi, > > On 12/15/2016 12:25 PM, Guido Günther wrote: >> 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? > > maybe this is actual the difference between dfu-util 0.7 and 0.9... > > I expierenced issues with dfu-util greather than 0.7, can you recheck > with 0.7? I have been using version 0.8 for all flashing of the hundred new devices which have been produced without a single problem when flashing while the device is in the bootloader. On the other hand it never ever worked for me when doing it while the device was already in the firmware. If you are sure that it worked for you before that would be new to me. In that case it would be a regression. regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 15/12/16 18:53, Stefan Schmidt wrote: > Hello. > > On 15/12/16 12:25, Guido Günther wrote: >> 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 ;) > > > Sure enough. :) Just mentioned that because you flashed the 0.3 firmware > file which is identical with whats on it. > > Happy to see someone hacking on the firmware side as well. :) > > >>> >>>> >>>> # 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! > > Good. That will get you going. > >> 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? > > You observation is right, it performs the reset as it should. I run into > that myself but its all the way down on my todo list to work out what is > the problem here. Is it dfu-util? Is it the firmware? Or just some > simple race? > > Even when working on the firmware myself I found it working well enough > to plug and unplug the device when wanting to flash a new version. There > is also a little userspace tool which can reset the device over libusb. > Its in the git repo somewhere. > > For now I can take the doc patch to make it clearer. I thought it was for the firmware source repo, but the patch is for linux-firmware. Please submit it directly for linux-firmware and put me in CC so I can ack it. Thanks. regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 15, 2016 at 06:57:40PM +0100, Stefan Schmidt wrote: > Hello. > > On 15/12/16 12:38, Alexander Aring wrote: > > > > Hi, > > > > On 12/15/2016 12:25 PM, Guido Günther wrote: > > > 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? > > > > maybe this is actual the difference between dfu-util 0.7 and 0.9... > > > > I expierenced issues with dfu-util greather than 0.7, can you recheck > > with 0.7? > > I have been using version 0.8 for all flashing of the hundred new devices > which have been produced without a single problem when flashing while the > device is in the bootloader. On the other hand it never ever worked for me > when doing it while the device was already in the firmware. If you are sure > that it worked for you before that would be new to me. In that case it would > be a regression. I can confirm that flashing is rock stable if one starts the process while the device is in the bootloader. Thanks! -- Guido -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 12/15/2016 06:57 PM, Stefan Schmidt wrote: > Hello. > > On 15/12/16 12:38, Alexander Aring wrote: >> >> Hi, >> >> On 12/15/2016 12:25 PM, Guido Günther wrote: >>> 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? >> >> maybe this is actual the difference between dfu-util 0.7 and 0.9... >> >> I expierenced issues with dfu-util greather than 0.7, can you recheck >> with 0.7? > > I have been using version 0.8 for all flashing of the hundred new devices which have been produced without a single problem when flashing while the device is in the bootloader. On the other hand it never ever worked for me when doing it while the device was already in the firmware. If you are sure that it worked for you before that would be new to me. In that case it would be a regression. > I always flashed with dfu when the device was in firmware. The device resets and dfu-util upload the firmware.... mhh, I am not sure if I ever tested it after this patch [0]. It solved for me to use atusb in qemu above 1.6.2 but maybe has other side effects. My expierence with atusb firmware is that I never need to fiddle some right timing to call dfu-util while booting. :-/ - Alex [0] https://www.spinics.net/lists/linux-wpan/msg02032.html -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 15/12/16 20:24, Alexander Aring wrote: > > Hi, > > On 12/15/2016 06:57 PM, Stefan Schmidt wrote: >> Hello. >> >> On 15/12/16 12:38, Alexander Aring wrote: >>> >>> Hi, >>> >>> On 12/15/2016 12:25 PM, Guido Günther wrote: >>>> 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? >>> >>> maybe this is actual the difference between dfu-util 0.7 and 0.9... >>> >>> I expierenced issues with dfu-util greather than 0.7, can you recheck >>> with 0.7? >> >> I have been using version 0.8 for all flashing of the hundred new devices which have been produced without a single problem when flashing while the device is in the bootloader. On the other hand it never ever worked for me when doing it while the device was already in the firmware. If you are sure that it worked for you before that would be new to me. In that case it would be a regression. >> > > I always flashed with dfu when the device was in firmware. The device > resets and dfu-util upload the firmware.... > > mhh, I am not sure if I ever tested it after this patch [0]. > > It solved for me to use atusb in qemu above 1.6.2 but maybe has other > side effects. > > My expierence with atusb firmware is that I never need to fiddle some > right timing to call dfu-util while booting. :-/ Interesting that this worked for you while I can't remember it ever worked for me. Maybe my old patch to make it work with newer Qemu's did indeed break it. For anybody wanting to dig into this it would indeed be a good starting point. As I wrote before, for me its very much at the bottom of my todo list. regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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?= <agx@sigxcpu.org> 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