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. I can think of the following ways to avoid this problem: 1) Simply override DFU suffix checking in dfu-util in this case. 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. 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. 4) Just give up on PID checking by dfu-util and use a wildcard in the DFU suffix. 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. 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". Comments ? - Werner _______________________________________________ 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
