more sophisticated ways for updating the atusb firmware

Stefan Schmidt stefan at datenfreihafen.org
Mon May 23 14:07:20 EDT 2011


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




More information about the discussion mailing list


interactive