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

[Lukasz Majewski]

Hi Wolfgang,

> Dear Lukasz,
> 
> In message <20140515154334.626923b4 at 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