[U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting

Lukasz Majewski
2014-05-16T06:08:58Z

Hi Wolfgang,

> Dear Lukasz,
>
> In message <20140515154334.626923b4@amdc2363> you wrote:
> >
> > > This reinforces my speculation that you are actually addressing
> > > the wrong problem. Instead of adding new code and environment
> > > variables and making the system even more complex, we should just
> > > leave everything as is,
> >
> > During working on this patch I've replaced the crc32() method with
> > the call to hash_method(), which IMHO is welcome.
>
> Yes, indeed this is highly welcome. Thanks a lot for that!
>
> > I also don't personally like the crc32, hence I like the choice
> > which this patch gives me to use other algorithm (for which I've
> > got HW support on my platform - e.g. MD5).
>
> Well, is this really useful? dfu-utils provides only CRC caculation,
> so where would you get the reference value for any other checksum
> metod from?

I was rather thinking about a test setup with my target connected via
serial console to HOST machine. Then I could compare the CRC32/MD5/SHA1
just after sending the data.

For my target it is better to use MD5 or SHA1 since support for them is
provided via the specialized, embedded crypto IP.

>
> > > and you should try to find out why the CRC
> > > calculation is so low for you. Checking if caches are enabled is
> > > probably among the things that should be done first.
> >
> > L1 is enabled. L2 has been disabled on purpose (power consumption
> > reduction).
>
> This certainly contributes to slow code execution.
>
> > Please note that the last revision of DFU is from 2004. I've
> > contacted Greg KH (one of the original authors) and he replied that
> > no new attempt to revise the standard was made.
>
> This may just mean that users were just happy with the current
> situation.

It is hard to say.

> It's definitely better than if changed had been proposed
> but rejected.

True.

>
> > The best however, would be to revise the standard to include such
> > functionality to it. In the same time I'm fully aware that this is
> > very unlikely to happen.
>
> Why do you think it is unlikely?

I don't have the experience with preparing USB standards, but I assume
that it is somewhat hard to revise the standard after 10 years.

> Of course, it would require that
> someone comes up with such a proposal in the first place. But you
> sound as if you were certain a proposal had no chance for being
> considered.

No, this is not what I meant.

> I may be naive, but should we not at least try before
> giving up?

Unfortunately my time budget is limited and I feel like this has lower
priority than fixing/solving current DFU problems.

>
> Best regards,
>
> Wolfgang Denk
>

--
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group