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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
