* [U-Boot] Testing Data Cache for armv7 (beagleboard)
@ 2010-10-06 23:31 chris chriss
2010-10-07 0:56 ` Reinhard Meyer
2010-10-07 6:14 ` Heiko Schocher
0 siblings, 2 replies; 7+ messages in thread
From: chris chriss @ 2010-10-06 23:31 UTC (permalink / raw
To: u-boot
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
2010-10-06 23:31 [U-Boot] Testing Data Cache for armv7 (beagleboard) chris chriss
@ 2010-10-07 0:56 ` Reinhard Meyer
2010-10-07 6:14 ` Heiko Schocher
1 sibling, 0 replies; 7+ messages in thread
From: Reinhard Meyer @ 2010-10-07 0:56 UTC (permalink / raw
To: u-boot
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
2010-10-06 23:31 [U-Boot] Testing Data Cache for armv7 (beagleboard) chris chriss
2010-10-07 0:56 ` Reinhard Meyer
@ 2010-10-07 6:14 ` Heiko Schocher
2010-10-07 16:57 ` chris c
1 sibling, 1 reply; 7+ messages in thread
From: Heiko Schocher @ 2010-10-07 6:14 UTC (permalink / raw
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
2010-10-07 6:14 ` Heiko Schocher
@ 2010-10-07 16:57 ` chris c
2010-10-07 18:04 ` Wolfgang Denk
0 siblings, 1 reply; 7+ messages in thread
From: chris c @ 2010-10-07 16:57 UTC (permalink / raw
To: u-boot
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
2010-10-07 16:57 ` chris c
@ 2010-10-07 18:04 ` Wolfgang Denk
2010-10-12 1:25 ` chris c
0 siblings, 1 reply; 7+ messages in thread
From: Wolfgang Denk @ 2010-10-07 18:04 UTC (permalink / raw
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
2010-10-07 18:04 ` Wolfgang Denk
@ 2010-10-12 1:25 ` chris c
0 siblings, 0 replies; 7+ messages in thread
From: chris c @ 2010-10-12 1:25 UTC (permalink / raw
To: u-boot
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
[not found] <8f0047be822f419132f5f2df38bc14b5@mail.gmail.com>
@ 2010-10-13 18:45 ` Ghorai, Sukumar
0 siblings, 0 replies; 7+ messages in thread
From: Ghorai, Sukumar @ 2010-10-13 18:45 UTC (permalink / raw
To: u-boot
> -----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
> >
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-10-13 18:45 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-06 23:31 [U-Boot] Testing Data Cache for armv7 (beagleboard) chris chriss
2010-10-07 0:56 ` Reinhard Meyer
2010-10-07 6:14 ` Heiko Schocher
2010-10-07 16:57 ` chris c
2010-10-07 18:04 ` Wolfgang Denk
2010-10-12 1:25 ` chris c
[not found] <8f0047be822f419132f5f2df38bc14b5@mail.gmail.com>
2010-10-13 18:45 ` Ghorai, Sukumar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.