more sophisticated ways for updating the atusb firmware

Werner Almesberger werner at almesberger.net
Tue May 24 19:22:16 EDT 2011


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




More information about the discussion mailing list


interactive