more sophisticated ways for updating the atusb firmware

Stefan Schmidt stefan at datenfreihafen.org
Wed May 25 02:53:42 EDT 2011


Hello.

On Tue, 2011-05-24 at 20:22, Werner Almesberger wrote:
> 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.

Indeed.

> >> 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.

Specs are often not written with elegance in mind. ;) I see your
point. Having a more flexible solution there might have helped.

> > 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 ?

Yes.

> > 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.

I agree with you on the importance of the worst case handling. Nothing
to argue about. It need to have a solution that covers all cases. We
have actually two here already just need to settle for one. :P

What I'm arguing about is to force the "awkward" way to all user by
default. Finding the different solutions would not be a hard problem
either as you would only need to add somehing like a --force option to
dfu-util.

In the end it is really your call. You are going to be in charge of
the bootloader parts and at leats in the beginning of the firmware
releases needing to match and having something ready for the worst
case. I might be a bit biased wrt dfu-util as well. :)

> > 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 ...

As I said, I'm with you on being prepared for the worst case. It will
come anyway. I'm just more into not designing for the worst case by
default. :)

BTW, the first pieces for dfu suffix parsing in dfu-util are falling
into place right now. The missing pieces and a small tool to generate
the suffix for a given file should come over the next weeks as well.

regards
Stefan Schmidt




More information about the discussion mailing list


interactive