Hi Wolfgang, On Mon, Feb 18, 2013 at 3:35 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Tom, > > In message <51216721.1010...@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: w...@denx.de > Time is an illusion perpetrated by the manufacturers of space. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot