Hello On Fri, 2011-05-20 at 14:00, Werner Almesberger wrote: > Stefan Schmidt wrote: > > Are you actually using two different PIDs for normal operation and DFU > > mode? > > I'm looking into this right now. There seems to be an interesting > conflict between "emergency unbricking" and the use of the > product ID (PID): > > - the device always present an idProduct of either APP_PID or > DFU_PID, where APP_PID != DFU_PID, as recommended in section 2, > page 8, of revision 1.1. of the DFU specification. > > - let's assume the DFU file suffix contains a non-wildcard PID. > According to appendix B, page 41, this would be APP_PID. > > - in the case of a "bricked" application, we could not rely on > the application to even enumerate. We would therefore have to > force entry into DFU mode via some other means. In the case of > atusb, this is the 2 seconds timeout. > > - now, if the device has already been put into DFU mode, it would > present DFU_PID instead of APP_PID. dfu-util should therefore > refuse to update the firmware.
Yup, good analysis. Thats actually what can happen if your application firmware is completely broken. I will always allow dfu-util to flash the fimrware neverless the PID, VID, BCD or whatever mismatch. It will do so by default to be a safe default for the user but it will always will have a commandline switch to force the download and completely ingnoring the dfu suffix informations. :) > I can think of the following ways to avoid this problem: > > 1) Simply override DFU suffix checking in dfu-util in this case. Will be available. > 2) Make dfu-util consider an alternate PID as valid, too. Hackish > to automate given that section 2, page 8, leaves the relation > between APP_PID and DFU_PID open. > > However, if the alternative PID could be provided manually > this would be a safer override than just disabling suffic > checking entirely. And what about the wrong VID or BCD? Vendors are known to screw up a lot and maybe you are also interested to bring this nice monitor mode firmware on this cheap usb stick instead of buying the premium usb stick with the same hw but different VID. A case I just made up from my mind but I think we need a way to ignore bits form the suffix instead of only the PID. Maybe there will be different override levels but one for override all will be there as well. > 3) Have two sets of firmware files, one with APP_PID, the other > with DFU_PID, and let the user jump through that extra hoop. Thats an option you as a vendor have. Not sure if it gets more confusing and is even needed if the switch to force the download is available in dfu-util. Anyway, thats up to you guys if you want to provide them. > 4) Just give up on PID checking by dfu-util and use a wildcard > in the DFU suffix. In all cases where the firmware is good that would be step backwards I think. And that should be considered the normal case. Broken firmware files that don't even enumerate are a developer problem. The CRC check should safe the user for broken donwloads as well. > 5) Make the boot loader present APP_PID until asked to switch to > DFU mode. This way, it would comply with the formal > requirements of the DFU spec, but this would of course bring > the driver selection problem right back. Personally I would avoid this. > 6) Remove any DFU-related knowledge (besides having an APP_PID > which differs from DFU_PID) from the application. You would > therefore have to use an application-specific means to make > the device run the boot loader, and only then would it > advertize DFU capabilities. > > Interestingly, this is similar to what I have right now, with > the involvement of atrf-reset. The difference is that I use a > single PID, while we ought to use two or three of them: > APP_PID, and either a unified DFU_PID, or, following the DFU > spec by the letter, a DFU_PID for the boot loader in > "application mode" and another DFU_PID for the boot loader in > "DFU mode". Well, I would not trying to force you using different IDs for DFU and runtime mode. I just think its a good idea,conform to the spec and convinient to have it all done by dfu-util with the need of different tools. Its not a violation neither to not have this and dfu-util will still work with the same ID. Up to you I would say as you are writing the bootloader here. > Comments ? Some as you can see. :) I see you case and I see the problem that comes out of it and I think we should be able to handle it (be it with our reset method and the one PID or with the method I mentioned above). But we should also be clear that the case is very rare and we should not try to over-engineer for just this case. The _normal_ case should be a user flashing the device with a _verified_ firmware file that will enumerate on the bus. regards Stefan Schmidt _______________________________________________ Qi Hardware Discussion List Mail to list (members only): discussion@lists.en.qi-hardware.com Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
