Heiko,

I was comparing time just by timing it manually. How did you instrument u-boot to display the time?

As for the small versus large file, I did the same test for 1MB of data using nand read and saw a x4 performance advantage. I also did a test on mmc with 100 MB file and saw no performance increase. Looks like file size doesn't matter.

So does that mean that MMC file loading will not benefit from dcache enabled? Can anybody explain this?

Thanks.

On Thu, Oct 7, 2010 at 1:14 AM, Heiko Schocher hs@denx.de wrote:

Hello Chris,

chris chriss wrote:

...

I'm trying to test the cache on my beagle with a snapshot from the git

tree

...

today. I tried it out by loading a file from the mmc with dcache off and then dcache on. I didn't see any difference in speed. After reading

this

...

commit (http://git.denx.de/?p=u-boot.git;a=commit;h=95c6f6d), I expected

to

...

see a performance improvement.

Here a log which actual reloacte code from Albert Aribaud and my fix patch for the beagle on the beagle board:

170.880 U-Boot 2010.09-00102-g456a0da-dirty (Oct 05 2010 - 14:41:10) 170.880 170.920 OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz 170.920 OMAP3 Beagle board + LPDDR/NAND 170.960 I2C: ready 170.960 DRAM: 128 MiB 171.000 NAND: 256 MiB 174.000 In: serial 174.000 Out: serial 174.000 Err: serial 174.000 Beagle Rev C1/C2/C3 174.360 Die ID #00b000030000000004013f8a1700900c 175.200 Hit any key to stop autoboot: 0 175.440 OMAP3 beagleboard.org # 178.280 OMAP3 beagleboard.org # ica off 178.280 Instruction Cache is OFF 180.480 OMAP3 beagleboard.org # dca off 180.480 Data (writethrough) Cache is OFF 183.520 OMAP3 beagleboard.org # echo start ; nand read 80800000 0 7000000 ; echo stop 0.000 start 0.000 0.000 NAND read: device 0 offset 0x0, size 0x7000000 114.040 NAND read from offset 0 failed -74 114.040 117440512 bytes read: ERROR 114.040 stop 135.880 OMAP3 beagleboard.org # ica on 135.880 Instruction Cache is ON 138.280 OMAP3 beagleboard.org # echo start ; nand read 80800000 0 7000000 ; echo stop 0.000 start 0.000 0.000 NAND read: device 0 offset 0x0, size 0x7000000 95.120 NAND read from offset 0 failed -74 95.120 117440512 bytes read: ERROR 95.120 stop 160.880 OMAP3 beagleboard.org # dca on 160.880 Data (writethrough) Cache is ON 164.600 OMAP3 beagleboard.org # ica on 164.600 Instruction Cache is ON 166.080 OMAP3 beagleboard.org # echo start ; nand read 80800000 0 7000000 ; echo stop 0.000 start 0.000 0.000 NAND read: device 0 offset 0x0, size 0x7000000 26.680 NAND read from offset 0 failed -74 26.680 117440512 bytes read: ERROR 26.680 stop

...

This is a capture of how I tested it...

<capture>

OMAP3 beagleboard.org # mmc init 1 mmc1 is available OMAP3 beagleboard.org # dcache Data (writethrough) Cache is OFF OMAP3 beagleboard.org # fatload mmc 0:1 0x80000000 uImage.bin reading uImage.bin

3852836 bytes read OMAP3 beagleboard.org # dcache on Data (writethrough) Cache is ON OMAP3 beagleboard.org # fatload mmc 0:1 0x80000000 uImage.bin reading uImage.bin

3852836 bytes read OMAP3 beagleboard.org #

</capture>

How did you measured the time between start an end?

Maybe uImage.bin is a little bit to small for seeing some effect?

bye, Heiko

Thanks for the replies. I didn't realize that the MMC module was operating in 1-bit mode inside U-boot. I'll concentrate on looking at that. Has anybody done any work to try and get 4-bit mode working for OMAP3 in U-boot?

Thanks, Chris

On Thu, Oct 7, 2010 at 1:04 PM, Wolfgang Denk wd@denx.de wrote:

Dear chris c,

In message <AANLkTi=usuEyf4YuUVWrrLu80bMRFpRF+BThEix2bFNg@mail.gmail.comusuEyf4YuUVWrrLu80bMRFpRF%2BBThEix2bFNg@mail.gmail.com> you wrote:

...

I was comparing time just by timing it manually. How did you instrument u-boot to display the time?

That's no instrumentation of U-Boot, but just timestamping the output on the serial console. See for example ftp://ftp.denx.de/pub/tools/time_log

...

As for the small versus large file, I did the same test for 1MB of data using nand read and saw a x4 performance advantage. I also did a test on mmc with 100 MB file and saw no performance increase. Looks like file

size

...

doesn't matter.

So does that mean that MMC file loading will not benefit from dcache enabled? Can anybody explain this?

It depends on where the time is actually spent. If you have a slow (say, bit-banging) MMC driver and a low-performance CPU then the transfer from MMC might simply not depend as much on caches. It is wrong to check just a simple use case. Try a number of different operations, like umcompressing a large image in RAM or from NOR to RAM, or downloading over the net, or ...

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@denx.de "Remember, Information is not knowledge; Knowledge is not Wisdom; Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is not music; Music is the best." - Frank Zappa