[U-Boot] [PATCH 16/20] Roll crc32 into hash infrastructure
Simon Glass
sjg at chromium.org
Mon Feb 18 18:06:01 CET 2013
Hi Wolfgang,
On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Tom,
>
> In message <51216721.1010603 at ti.com> you wrote:
>>
>> There's another thread I don't have yet (and I don't have this one in
>> gmail yet even). But, I am OK with custodians using their repos, but
>> not the master branch, for unrelated but otherwise good patches. I'm
>> also fine with patchwork bundles. I suppose we could use the staging
>> repository for these changes instead.
>
> What I mostly object about there is that these patches would go into
> mainline basicly unreviewed, as patch submission and pull request is
> all done from a single person, with no other feedback on the patches
> at all. And this affects a lot of common code...
>
> Actually, I see this change when pulling u-boot-x86.git/master:
>
> -> bloat-o-meter u-boot-before u-boot
What board is this please?
Some specific notes here - I think it boils down to moving crc32 into
the hash framework. This adds some overhead, but has a few benefits.
> add/remove: 9/0 grow/shrink: 3/14 up/down: 1006/-560 (446)
> function old new delta
> hash_command - 424 +424
This is the generic hashing command. What is happening here is that
the crc32 command is getting a few more features, more like sha1sum.
However, this might not be desriable - and in fact this patch changes
the behaviour of the CRC storage and verify to support using an
environment variable, and requiring * before the argument when an
address is required! That needs to be fixed, at least.
The intent is to try to unify the hashing/crc features into a single
framework. If you enable only crc32 and nothing else then this has
quite a cost (0.5KB at present). I think I can reduce this code by
making the full features of hash.c only available when something more
than just crc32 is enabled. However, it might involve some #ifdefs...
> strncasecmp - 156 +156
> simple_itoa - 104 +104
> crc32_wd_buf - 76 +76
> setenv_hex - 68 +68
> setenv_ulong - 52 +52
> strcasecmp - 36 +36
> do_mem_loopw 304 328 +24
> static.local - 22 +22
> do_mem_loop 268 288 +20
> hash_algo - 16 +16
> do_mem_cmp 332 340 +8
> do_mem_mw 224 220 -4
> set_working_fdt_addr 72 52 -20
> load_serial_ymodem 300 280 -20
> load_serial 512 492 -20
> index_partitions 200 180 -20
> do_load_serial_bin 1844 1824 -20
> do_load 468 448 -20
> do_jffs2_fsload 320 300 -20
> do_imgextract 636 592 -44
> NetLoop 832 788 -44
> do_mem_cp 312 252 -60
> do_bootm 1244 1180 -64
> do_mem_crc 188 88 -100
> do_mem_mtest 1436 1332 -104
>
>
> So there are changes all over the place, including a growth of the
> memory footprint. I think this needs at least minimal review.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Time is an illusion perpetrated by the manufacturers of space.
More information about the U-Boot
mailing list