Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=, In message <4d3eac1a.5030...@arcor.de> you wrote: > > | HEAD(1)| HEAD(1)| HEAD(2)| HEAD(2)| > | | +patch | | +patch | > -----------------------+--------+--------+--------+--------+ > Reset to prompt | 438ms | 330ms | 228ms | 120ms | > | | | | | > TFTP a 3MB img | 4782ms | 3428ms | 3245ms | 2820ms | > | | | | | > FATLOAD USB a 3MB img* | 8515ms | 8510ms | ------ | ------ | > | | | | | > BOOTM LZO img in RAM | 3473ms | 3168ms | 592ms | 592ms | > where CRC is | 615ms | 615ms | 54ms | 54ms | > uncompress | 2460ms | 2462ms | 450ms | 451ms | > final boot_elf | 376ms | 68ms | 65ms | 65ms | > | | | | | > BOOTM LZO img in FLASH | 3207ms | 2902ms | 1050ms | 1050ms | > where CRC is | 600ms | 600ms | 135ms | 135ms | > uncompress | 2209ms | 2211ms | 828ms | 828ms | > final boot_elf | 376ms | 68ms | 65ms | 65ms | > > (1) No dcache > (2) dcache enabled in board_init > *Does not work when dcache is on > > I think we can see that there seems to be no negativ impact of theses > patches when only execution speed is taken into consideration. The gain > is noticable when caching is not used or not activated. For pure RAM to > RAM copy when caching is activated the patch didn't change anything. > > Here are some additional numbers for copying a 1.4MB image from NOR to RAM: > > HEAD : 134ms > HEAD + patch : 72ms > HEAD + dcache : 120ms > HEAD + dcache + patch : 70ms
This is pretty much interesting information for developers who have to decide if they want to accept the increased memory footprint. Can you please add this to the commit message? > Would it be an option to use the CONFIG entries CONFIG_USE_ARCH_MEMCPY > and CONFIG_USE_ARCH_MEMSET to enable that feature? If that is OK I can Makes sense to me. > send a new version of the patch. The only problem I see with this > approach is that there are architectures which already have their own > implementations which are then not affected by these config options. If you are aware of any, it might make sense to put the respective maintainers on Cc: to trigger them to adapt / clean up their code. Thanks. 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 Its always easier short term to pee in the pond than install a toilet - it's just not a good long term plan. - Alan Cox in <20100101145701.6432e...@lxorguk.ukuu.org.uk> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot