From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Mon, 19 May 2014 16:02:40 +0200 Subject: [U-Boot] [PATCH v3] dfu: Introduction of the "dfu_hash_algo" env variable for checksum method setting In-Reply-To: <20140516105858.56a457bc@amdc2363> References: <1399295786-30652-1-git-send-email-l.majewski@samsung.com> <1399552067-31208-1-git-send-email-l.majewski@samsung.com> <20140509042745.A040938043A@gemini.denx.de> <20140509085203.31133238@amdc2363> <20140509083154.2B66038060C@gemini.denx.de> <20140512144512.GC22182@bill-the-cat> <20140515090904.32f1d13d@amdc2363> <20140515111943.CAFC138047D@gemini.denx.de> <20140515154334.626923b4@amdc2363> <20140516105858.56a457bc@amdc2363> Message-ID: <537A0F00.5040608@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Lukasz, Am 16.05.2014 10:58, schrieb Lukasz Majewski: > Hi Wolfgang, Tom, > >> Hi Wolfgang, >> >>> Dear Lukasz, >>> >>> In message<20140515090904.32f1d13d@amdc2363> you wrote: >>>> >>>>>> What I complained about is the change in behaviour. I asked >>>>>> to make the existing behaviour the default, so unaware users >>>>>> will not be affected. Only if you intentionally want some >>>>>> other behaviour you can then enable this by setting the env >>>>>> variable. >>>>> >>>>> Well, looking at mainline usage of DFU, Lukasz is speaking for >>>>> about half of the users / implementors. Since Denx is working >>>>> with the other half, can you shed some light on actual use vs >>>>> theoretical possibilities? >>>> >>>> I don't want to urge anybody on making any conclusion here :-), >>>> but I would be very grateful if we could come up with an >>>> agreement. >>>> >>>> As I've stated previously, my opinion is similar to the one >>>> presented by Tom in this message. >>>> >>>> For me it would be best to not calculate any checksum on default >>>> and only enable it when needed. >>> >>> I asked Heiko to run some actual tests on the boards where he has to >>> maintain DFU for. For a 288 MiB image he did not measure any >>> difference - with your patch applied, both with and without CRC >>> enabled, we would get the same (slow) 1:54 minutes download time. >> >> As I've spoken with Heiko, am33xx uses NAND memory. I deal with eMMC. >> Moreover, the size of "chunks" are different - 1 MiB and 32 MiB. >> >> I must double check for the rationale for chunk size of 32 MiB at >> Trats/Trats2 boards. I suspect, that eMMC write performance depend >> on that. >> >> I will perform some performance tests with 1 MiB chunk size and share >> the result. > > Unfortunately the 32 MiB is fixed for our platform. since lthor uses it > by default. > >> >>> >>> 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. >> >> 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). >> >>> 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). > > Regarding L2 - our platform requires SMC calls to enable and manage L2 > cache. In my opinion support for this in u-boot is an overkill. > > > Can we conclude this whole discussion? The main point was if we should > keep calculating and displaying crc32 as default for DFU transfers. > > I'm for the option to NOT display and calculate it by default (PATCH > v3). I talked with the siemens board customer, they also do not check/use the displayed value from U-Boot ... So, for me it is OK to not display this value ... but we should add to DFU such a check ... or? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany