[U-Boot] Testing Data Cache for armv7 (beagleboard)

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[chris chriss]

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.


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>

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[Reinhard Meyer]

Dear chris chriss,
> 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.

Maybe you should try a comparable test scenario to that of loading a
really large file from a fast storage medium like NAND instead a small
file from a slow, serial, probably SPI driven medium...

Reinhard

> <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>

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[Heiko Schocher]

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

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[chris c]

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
>

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[Wolfgang Denk]

Dear chris c,

In message <AANLkTi=usuEyf4YuUVWrrLu80bMRFpRF+BThEix2bFNg@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 at 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

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[chris c]

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 at mail.gmail.com<usuEyf4YuUVWrrLu80bMRFpRF%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 at 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
>

[U-Boot] Testing Data Cache for armv7 (beagleboard)

[Ghorai, Sukumar]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of chris c
> Sent: Tuesday, October 12, 2010 6:55 AM
> To: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Testing Data Cache for armv7 (beagleboard)
> 
> 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?

[Ghorai] can you give a test using this patch series? This uses the generic mmc/sd driver for beagle board. And mmc/sd card will work at 4-bit, 48Mhz.
http://www.mail-archive.com/u-boot at lists.denx.de/msg38690.html

> 
> 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.com<usuEyf4YuUVW
> rrLu80bMRFpRF%2BBThEix2bFNg at 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 at 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
> >