Stefan Schmidt wrote: > And what about the wrong VID or BCD? Ah, sure. I mentioned only the PID, because this is the problem at hand. But you'd of course want to generalize the solution.
>> 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'm still trying to wrap my head around the concept of that wildcard :-) I could imagine wonderful uses for a mask+value pair or maybe a list, but that all-or-nothing wildcard looks horribly clunky to me. > 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). Okay, so if I implement the regular DFU mechanism, the user would just use the override/force option in this case ? > But we should also be clear that the case is very rare and we should > not try to over-engineer for just this case. I find the worst case important because solving this also solves all less severe cases of firmware troubles. In fact, one could even go as far as not advertizing the other cases very much, because just doing things the "awkward" way is still a lot more efficient than first figuring out how to correctly choose which approach to use, and then perhaps to pick the more efficient option. > The _normal_ case should > be a user flashing the device with a _verified_ firmware file that > will enumerate on the bus. This could be tricky. E.g., if the firmware checks some variable but persistent state before enumerating or accepting DFU commands, and there's a fatal bug in one branch, even a perfectly intact firmware image could cause trouble. Of course, proper QA should find such things, but ... Thanks, - 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
