Hello. This really comes as surprise to me as I'm working on exactly the same at the moment. I just realised that I only mentioned it here inside the fastboot patches thread.
I started from the old patches Harald Welte wrote for u-boot during his work for OpenMoko. I worked with him during this time at OpenMoko and I'm the current maintainer of dfu-util. (Just as background). You seem to have started from scratch with this DFU implementation instead of using the older but available patches. Was there a specific reason for this? I found it not that complicated to update them on a current u-boot and adjust it accordingly. I have it working here with a beagleboard. Was about to send them out next week but you have been a small tick faster here. :) >From a quick look I see some stuff missing in your implementation that is working in mine so there is some ground for working together on this. The main question is which of both implementation to use to build up from. I will give you some feedback on the design high level aspects further below. A complete review of the code and testing on the beagleboard will hopefully happen over the next days. Testing might be problematic as you flashing part is forced to be rewritten for every board here it seems. Need to investigate further before I can really comment on this. More comment inline. On Wed, 2011-11-02 at 11:00, Andrzej Pietrasiewicz wrote: > http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf Have you fully implemented 1.1? With the detahc logic inside the device implementation? > The aim of DFU is to allow transferring data to/from selected areas of > interest within a compliant device. In the DFU nomenclature the host->device > direction is called download and the device->host direction is called > upload. The areas are defined by the compliant device. In the DFU > nomenclature the area of interest within the device is called an altsetting. > The device is connected to the host through USB. On the host side compliant > software must be used to initiate the data transfer. Example piece of such > software is dfu-util package from the OpenMoko project: > > http://wiki.openmoko.org/wiki/Dfu-util. Better to use the official homepage here: http://dfu-util.gnumonks.org/ It misses some examples but has the current informations while the wiki is outdated. > The DFU implementation on the device side remains in one of the two modes: > the Run-Time mode and the DFU mode. The USB descriptor sets exported by > the device depend on which mode is in force. While in DFU mode the device > exports the descriptors corresponding to each available altsetting. An > example dfu-util session when the device is in the DFU mode looks similar > to this: > > # dfu-util -l > dfu-util - (C) 2007-2008 by OpenMoko Inc. > This program is Free Software and has ABSOLUTELY NO WARRANTY > > Found DFU: [0x0525:0xffff] devnum=46, cfg=0, intf=0, alt=0, name="bootldr" > Found DFU: [0x0525:0xffff] devnum=46, cfg=0, intf=0, alt=1, name="kernel" Just curious. What version of dfu-util your are using for your tests? I released 0.5 earlier today. > This u-boot implementation introduces a parameter-less dfu command. > After the user finishes with dfu they can Ctrl-C to return to u-boot main > menu. Hmm, that sounds like you only implemented the DFU mode but not the run-time mode yet? No addtional DFU descripto in the normal run-time operation mode like usbtty? If yes this is a real limitation as the update would only be possible when the user has serial access to start the dfu command and then flash the device. While the original purpose of DFU was to make updating USB device easy enough for end-users as well. The implementation from OpenMoko i forward ported and cleanup has this functionality and it works well enough. Did so on the Freerunner from OM already. In the end I would like to see different options available: 1) Entering DFU mode directly when a button is pressed on startup. An update mode if you want to call it like this. 2) Normal startup, but with DFU descripton to allow dfu-util detaching and entering the DFU mode for flashing. 3) Starting dfu mode form the command line as you did implement it. > The implementation is split into two parts: the dfu gadget implementation > and a "flashing backend", the interface between the two being the > struct flash_entity. The "flashing backend"'s implementation is > board-specific and is implemented on the Goni target. What is your reasoning behind this split? I have it working here with the normal nand_flashing routines taking care of bad blocks, etc. I agree that there are several aspects that are board specific. Partions can be read out dynamically and the alt setting generated though. Soemthing what bothers me is the different underlaying medias that can be flashed. Right now I only cover nand, but eMMC, USB and other are valid as well. That is not covered in my implementation at all right now. To make it clear, I'm happy to see somebody else working on this as well as my primary goal is to have good DFU support in U-Boot here not if my implementation is merged or yours. I will clean up my patches a bit more and send them in the next days. Also will go through your code to understand what and how you are doing things. From there we can go and decide how we merge our work and bring it into U-Boot mainline. Comment from Scott for nand and Remy for USB related parts will be helpful here. Looking forward to work with you on this until we have good DFU support in U-Boot. regards Stefan Schmidt _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
