Re: public git l2 cache off.
Richard,
Woodruff, Richard wrote:
Beagleboard (omap3530)
I'll try the latest from here on SDP with this and see if it works.
There is also a difference in CR handling. I had submitted long
back a fix to Russell but let it get by me as I didn't have the time
to fix per his comments. I think our version was more correct then
the one in place but was still lacking a bit.
[*] It seems possible you could have an issue depending on what your
boot loader is or isn't doing for you.
U-boot (both 1.1.4 and 1.3.2) calls l2disable() before booting linux,
so linux needs to enable it. I vote for removing the l2disable() in u-
boot, but I can see that people might be stuck with broken binary
bootloaders...
Yes, this 'might' help for some users if it works. Traditionally things
usually have had some complications here at multiple levels in both hardware
and software. And yes not everyone can upgrade a boot loader. However, with
expanding boot from MMC/SD support things are getting safer.
The bit I was more worried about was the boot loader may not be invalidating
secure L2 tags correctly. The method to do this correctly is a little
different between EMU/HS and GP devices. Also these base methods changed some
between ES1 and ES2 of the chip. I hope no one is using an ES1 anymore but I'm
sure code remnants exist.
The working code variants did some work in u-boot and some in the kernel to
handle these conditions. The current balance today in working variants today
has u-boot doing more work. This probably merges with fewer conflicts with the
arm-kernel. Last I checked u-boot on Beagle was a based on an older version of
the code and probably even a wider range of versions exist in the community.
As such it's a good bet some of this is at the root of the problems you are
seeing.
On Beagle, we use ES2 GP device. From discussion on ARM kernel list
[1] we learned that it's the job of bootloader to initialize L2 cache
correctly. Thanks to Khasim we have a patch to enable L2 cache in
kernel [2], but this is only to work around "broken" bootloaders. So,
we need fixed bootloader (e.g. U-Boot) doing L2 cache initialization
correctly.
Currently, in U-Boot used for Beagle we have the following (L2) cache
handling (cleaned up for easier reading). Do you think this is
correct? Can we simply add a l2cache_enable() at the end of following
code or do we have to do/fix/change more to pass correctly configured
caches from U-Boot to kernel?
-- cut --
At U-Boot start:
l2cache_enable() for CPU_3430_ES2:
__asm__ __volatile__("mrc p15, 0, %0, c1, c0, 1":"=r" (i));
__asm__ __volatile__("orr %0, %0, #0x2":"=r"(i));
__asm__ __volatile__("mcr p15, 0, %0, c1, c0, 1":"=r" (i));
...
do U-Boot work
...
then just before kernel is called:
cleanup_before_linux():
/* turn off I/D-cache */
asm ("mrc p15, 0, %0, c1, c0, 0":"=r" (i));
i &= ~(C1_DC | C1_IC);
asm ("mcr p15, 0, %0, c1, c0, 0": :"r" (i));
/* invalidate I-cache */
mcr p15, 0, r1, c7, c5, 0 @ invalidate I cache
/* turn off L2 cache */
__asm__ __volatile__("mrc p15, 0, %0, c1, c0, 1":"=r" (i));
__asm__ __volatile__("bic %0, %0, #0x2":"=r"(i));
__asm__ __volatile__("mcr p15, 0, %0, c1, c0, 1":"=r" (i));
/* invalidate L2 cache also */
v7_flush_dcache_all(get_device_type()):
mov r7, r0 @ take a backup of device type
cmp r0, #0x3@ check if the device type is GP
moveq r12, #0x1 @ set up to invalide L2
smi:.word 0x01600070@ Call SMI monitor (smieq)
cmp r7, #0x3@ compare again in case its lost
beq finished_inval @ if GP device, inval done above
mrc p15, 1, r0, c0, c0, 1 @ read clidr
andsr3, r0, #0x700 @ extract loc from clidr
mov r3, r3, lsr #23 @ left align loc bit field
beq finished_inval @ if loc is 0, then no need to
clean
mov r10, #0 @ start clean at cache level 0
inval_loop1:
add r2, r10, r10, lsr #1@ work out 3x current cache
level
mov r1, r0, lsr r2 @ extract cache type bits from
clidr
and r1, r1, #7 @ mask of the bits for current
cache only
cmp r1, #2 @ see what cache we have at
this level
blt skip_inval @ skip if no cache, or
just i-cache
mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
isb @ isb to sych the new cssr&csidr
mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
and r2, r1, #7 @ extract the length of the
cache lines
add r2, r2, #4 @ add 4 (line length off
Re: public git l2 cache off.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 7 mei 2008, om 09:42 heeft Syed Mohammed, Khasim het volgende
geschreven:
The below patch should get you going with L2 Cache enabled on GIT
kernel, tested on Beagle board.
Unscientific benchmark:
mplayer -nosound -vo null -quiet -benchmark -loop 12
matrixbench_normdivx_vbrmp3.avi | grep BENCHMARK
kernel without l2 cache, at 381MHz:
BENCHMARKs: VC: 193.856s VO: 0.153s A: 0.000s Sys: 2.718s =
196.727s
kernel with l2 cache at 500MHz:
BENCHMARKs: VC: 56.150s VO: 0.133s A: 0.000s Sys: 1.043s =
57.327s
mplayer is 2.7 times faster :)
Regards,
Khasim
--- ../my_linux_omap/arch/arm/mm/Kconfig2008-05-06
16:37:17.0 +0530
+++ arch/arm/mm/Kconfig 2008-05-07 12:40:05.0 +0530
@@ -659,6 +659,20 @@ config CPU_DCACHE_SIZE
If your SoC is configured to have a different size, define
the value
here with proper conditions.
+choice
+ prompt "L2 Cache Size"
+ depends on ARCH_OMAP34XX
+
+config CPU_LOCKDOWN_TO_64K_L2
+ bool "Lock down L2 Cache to 64K"
+
+config CPU_LOCKDOWN_TO_128K_L2
+ bool "Lock down L2 Cache to 128K"
+
+config CPU_LOCKDOWN_TO_256K_L2
+ bool "Lock down L2 Cache to 256K"
+endchoice
+
config CPU_DCACHE_WRITETHROUGH
bool "Force write through D-cache"
depends on (CPU_ARM740T || CPU_ARM920T || CPU_ARM922T ||
CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E ||
CPU_ARM1020) && !CPU_DCACHE_DISABLE
@@ -674,6 +688,12 @@ config CPU_CACHE_ROUND_ROBIN
Say Y here to use the predictable round-robin cache
replacement
policy. Unless you specifically require this or are
unsure, say N.
+config CPU_L2CACHE_DISABLE
+ bool "Disable level 2 cache"
+ depends on CPU_V7
+ help
+ Say Y here to disable the level 2 cache. If unsure, say N.
+
config CPU_BPREDICT_DISABLE
bool "Disable branch prediction"
depends on CPU_ARM1020 || CPU_V6 || CPU_XSC3 || CPU_V7
--- ../my_linux_omap/arch/arm/mm/proc-v7.S 2008-04-27
00:13:57.0 +0530
+++ arch/arm/mm/proc-v7.S 2008-05-07 12:22:29.0 +0530
@@ -182,11 +182,72 @@ __v7_setup:
mov r10, #0x1f @ domains 0, 1 =
manager
mcr p15, 0, r10, c3, c0, 0 @ load domain access
register
#endif
+#if defined(CONFIG_ARCH_OMAP3)
+ @ L2 cache is enabled in the aux control register
+ mrc p15, 0, r0, c1, c0, 1
+ orr r0, r0, #0x11 @ speculative+no-alais
protection
+#ifdef CONFIG_CPU_L2CACHE_DISABLE
+ bic r0, r0, #0x2@ disable L2 Cache.
+#else
+ orr r0, r0, #0x2@ enaable L2 Cache.
+#endif
+
+/* On 3430 ES2.0 ZeBu and silicon, Aux Ctrl Reg can be written
outside
+ * Secure mode also
+ */
+ mcr p15, 0, r0, c1, c0, 1
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#ifdef CONFIG_CPU_LOCKDOWN_TO_64K_L2
+ mov r10, #0xfc
+ mcr p15, 1, r10, c9, c0, 0
+#endif
+
+#ifdef CONFIG_CPU_LOCKDOWN_TO_128K_L2
+ mov r10, #0xf0
+ mcr p15, 1, r10, c9, c0, 0
+#endif
+
+#ifdef CONFIG_CPU_LOCKDOWN_TO_256K_L2
+ mov r10, #0x00
+ mcr p15, 1, r10, c9, c0, 0
+#endif
+#endif
+
adr r5, v7_crval
ldmia r5, {r5, r6}
- mrc p15, 0, r0, c1, c0, 0 @ read control
register
- bic r0, r0, r5 @ clear bits them
- orr r0, r0, r6 @ set them
+ mrc p15, 0, r0, c1, c0, 0 @ read control register
+ bic r0, r0, r5 @ clear bits them
+ orr r0, r0, r6 @ set them
+ mov pc, lr @ return to head.S:__ret
+
+ /*
+* TAT N EV FH R
+* .EFR M.EE .UI. ..A. .RVI Z... B... .CAM
+* 0xxx x0xx 11x0 01x1 0xxx x000 0111 1xxx < forced typical
+* rrr rr r rr r r rrr r < always
read only
+* .000 ..00 ..0. ..0. .011 1... .101 < we want
+*/
+ .type v7_crval, #object
+v7_crval:
+ crval clear=0x7322f006, mmuset=0x3805, ucset=0x1804
+#else
+
+#ifndef CONFIG_CPU_L2CACHE_DISABLE
+ @ L2 cache configuration in the L2 aux control register
+ mrc p15, 1, r10, c9, c0, 2
+ bic r10, r10, #(1 << 16)@ L2 outer cache
+ mcr p15, 1, r10, c9, c0, 2
+ @ L2 cache is enabled in the aux control register
+ mrc p15, 0, r10, c1, c0, 1
+ orr r10, r10, #2
+ mcr p15, 0, r10, c1, c0, 1
+#endif
+ mrc p15, 0, r0, c1, c0, 0 @ read control
register
+ ldr r10, cr1_clear @ get mask for bits
to clear
+ bic r0, r0, r10 @ clear bits them
+ ldr r10, cr1_set@ get mask for bits
to set
+ orr r0, r0, r10 @ set them
mov pc, lr
RE: public git l2 cache off.
The below patch should get you going with L2 Cache enabled on GIT kernel,
tested on Beagle board.
Regards,
Khasim
--- ../my_linux_omap/arch/arm/mm/Kconfig2008-05-06 16:37:17.0
+0530
+++ arch/arm/mm/Kconfig 2008-05-07 12:40:05.0 +0530
@@ -659,6 +659,20 @@ config CPU_DCACHE_SIZE
If your SoC is configured to have a different size, define the value
here with proper conditions.
+choice
+ prompt "L2 Cache Size"
+ depends on ARCH_OMAP34XX
+
+config CPU_LOCKDOWN_TO_64K_L2
+ bool "Lock down L2 Cache to 64K"
+
+config CPU_LOCKDOWN_TO_128K_L2
+ bool "Lock down L2 Cache to 128K"
+
+config CPU_LOCKDOWN_TO_256K_L2
+ bool "Lock down L2 Cache to 256K"
+endchoice
+
config CPU_DCACHE_WRITETHROUGH
bool "Force write through D-cache"
depends on (CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T ||
CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020) && !CPU_DCACHE_DISABLE
@@ -674,6 +688,12 @@ config CPU_CACHE_ROUND_ROBIN
Say Y here to use the predictable round-robin cache replacement
policy. Unless you specifically require this or are unsure, say N.
+config CPU_L2CACHE_DISABLE
+ bool "Disable level 2 cache"
+ depends on CPU_V7
+ help
+ Say Y here to disable the level 2 cache. If unsure, say N.
+
config CPU_BPREDICT_DISABLE
bool "Disable branch prediction"
depends on CPU_ARM1020 || CPU_V6 || CPU_XSC3 || CPU_V7
--- ../my_linux_omap/arch/arm/mm/proc-v7.S 2008-04-27 00:13:57.0
+0530
+++ arch/arm/mm/proc-v7.S 2008-05-07 12:22:29.0 +0530
@@ -182,11 +182,72 @@ __v7_setup:
mov r10, #0x1f @ domains 0, 1 = manager
mcr p15, 0, r10, c3, c0, 0 @ load domain access register
#endif
+#if defined(CONFIG_ARCH_OMAP3)
+ @ L2 cache is enabled in the aux control register
+ mrc p15, 0, r0, c1, c0, 1
+ orr r0, r0, #0x11 @ speculative+no-alais protection
+#ifdef CONFIG_CPU_L2CACHE_DISABLE
+ bic r0, r0, #0x2@ disable L2 Cache.
+#else
+ orr r0, r0, #0x2@ enaable L2 Cache.
+#endif
+
+/* On 3430 ES2.0 ZeBu and silicon, Aux Ctrl Reg can be written outside
+ * Secure mode also
+ */
+ mcr p15, 0, r0, c1, c0, 1
+
+#ifdef CONFIG_ARCH_OMAP34XX
+#ifdef CONFIG_CPU_LOCKDOWN_TO_64K_L2
+ mov r10, #0xfc
+ mcr p15, 1, r10, c9, c0, 0
+#endif
+
+#ifdef CONFIG_CPU_LOCKDOWN_TO_128K_L2
+ mov r10, #0xf0
+ mcr p15, 1, r10, c9, c0, 0
+#endif
+
+#ifdef CONFIG_CPU_LOCKDOWN_TO_256K_L2
+ mov r10, #0x00
+ mcr p15, 1, r10, c9, c0, 0
+#endif
+#endif
+
adr r5, v7_crval
ldmia r5, {r5, r6}
- mrc p15, 0, r0, c1, c0, 0 @ read control register
- bic r0, r0, r5 @ clear bits them
- orr r0, r0, r6 @ set them
+ mrc p15, 0, r0, c1, c0, 0 @ read control register
+ bic r0, r0, r5 @ clear bits them
+ orr r0, r0, r6 @ set them
+ mov pc, lr @ return to head.S:__ret
+
+ /*
+* TAT N EV FH R
+* .EFR M.EE .UI. ..A. .RVI Z... B... .CAM
+* 0xxx x0xx 11x0 01x1 0xxx x000 0111 1xxx < forced typical
+* rrr rr r rr r r rrr r < always read only
+* .000 ..00 ..0. ..0. .011 1... .101 < we want
+*/
+ .type v7_crval, #object
+v7_crval:
+ crval clear=0x7322f006, mmuset=0x3805, ucset=0x1804
+#else
+
+#ifndef CONFIG_CPU_L2CACHE_DISABLE
+ @ L2 cache configuration in the L2 aux control register
+ mrc p15, 1, r10, c9, c0, 2
+ bic r10, r10, #(1 << 16)@ L2 outer cache
+ mcr p15, 1, r10, c9, c0, 2
+ @ L2 cache is enabled in the aux control register
+ mrc p15, 0, r10, c1, c0, 1
+ orr r10, r10, #2
+ mcr p15, 0, r10, c1, c0, 1
+#endif
+ mrc p15, 0, r0, c1, c0, 0 @ read control register
+ ldr r10, cr1_clear @ get mask for bits to clear
+ bic r0, r0, r10 @ clear bits them
+ ldr r10, cr1_set@ get mask for bits to set
+ orr r0, r0, r10 @ set them
mov pc, lr @ return to head.S:__ret
/*
@@ -195,9 +256,13 @@ __v7_setup:
* rrrx xxx0 0101 x111 < forced
* 0 110 0011 1.00 .111 1101 < we want
*/
- .type v7_crval, #object
-v7_crval:
- crval clear=0x0120c302, mmuset=0x00c0387d, ucset=0x00c0187c
+ .type cr1_clear, #object
+ .type cr1_set, #object
+cr1_clear:
+ .word 0x0120c302
+cr1_set:
+ .word 0x00c0387d
+#endif
__v7_setup_stack:
.space 4 * 11
Re: public git l2 cache off.
* Koen Kooi <[EMAIL PROTECTED]> [080506 10:02]: > > Op 6 mei 2008, om 18:51 heeft Woodruff, Richard het volgende geschreven: > >> Beagleboard (omap3530) > >> > >>> I'll try the latest from here on SDP with this and see if it works. > >>> There is also a difference in CR handling. I had submitted long > >>> back a fix to Russell but let it get by me as I didn't have the time > >>> to fix per his comments. I think our version was more correct then > >>> the one in place but was still lacking a bit. > >>> > >>> [*] It seems possible you could have an issue depending on what your > >>> boot loader is or isn't doing for you. > >> > >> U-boot (both 1.1.4 and 1.3.2) calls l2disable() before booting linux, > >> so linux needs to enable it. I vote for removing the l2disable() in > >> u- > >> boot, but I can see that people might be stuck with broken binary > >> bootloaders... > > > > Yes, this 'might' help for some users if it works. Traditionally > > things usually have had some complications here at multiple levels > > in both hardware and software. And yes not everyone can upgrade a > > boot loader. However, with expanding boot from MMC/SD support > > things are getting safer. > > > > The bit I was more worried about was the boot loader may not be > > invalidating secure L2 tags correctly. The method to do this > > correctly is a little different between EMU/HS and GP devices. Also > > these base methods changed some between ES1 and ES2 of the chip. I > > hope no one is using an ES1 anymore but I'm sure code remnants exist. > > > > The working code variants did some work in u-boot and some in the > > kernel to handle these conditions. The current balance today in > > working variants today has u-boot doing more work. This probably > > merges with fewer conflicts with the arm-kernel. Last I checked u- > > boot on Beagle was a based on an older version of the code and > > probably even a wider range of versions exist in the community. As > > such it's a good bet some of this is at the root of the problems you > > are seeing. > > I'm currently using the u-boot Jason built (1.3.2 + beagle patches) > which disables l2 cache before boot and I switch between 2.6.22-wtbu > (which enables L2) and git HEAD (which doesn't enable L2). Sounds like the bootloader should configure L2 cache and just leave the C bit off for kernel looking at the "Cortex-A8 L2 cache handling at startup?" thread on linux-arm-kernel. I guess the L2 configuration is implementation specific and cannot be read from the ARM registers. Regards, Tony > > regards, > > Koen > > > > > > > > It is important to keep x-loader/u-boot/kernel somewhat in sync for > > some of these kinds of issues until the development process has > > settled down and code matured. > > > > L2 cache is a huge performance boost on an OMAP3 so it's good to get > > it. Also you really haven't validated your software if you're > > running with it off. > > > > Regards, > > Richard W. > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux- > > omap" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: public git l2 cache off.
Woodruff, Richard wrote: Enabling L2 cache was removed from proc-v7.S since was cortex specific instead of armv7 specific and u-boot explicitly turns of L2 before booting into linux. I made a reverse patch, but my omap3 board doesn't boot if I use it: Our 2.6.24 kernel does something close and boots fine on OMAP3-SDP and Labrador boards. Which platform did you try on? I think we are talking about BeagleBoard here. Dirk I'll try the latest from here on SDP with this and see if it works. There is also a difference in CR handling. I had submitted long back a fix to Russell but let it get by me as I didn't have the time to fix per his comments. I think our version was more correct then the one in place but was still lacking a bit. [*] It seems possible you could have an issue depending on what your boot loader is or isn't doing for you. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: public git l2 cache off.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 6 mei 2008, om 18:51 heeft Woodruff, Richard het volgende geschreven: Beagleboard (omap3530) I'll try the latest from here on SDP with this and see if it works. There is also a difference in CR handling. I had submitted long back a fix to Russell but let it get by me as I didn't have the time to fix per his comments. I think our version was more correct then the one in place but was still lacking a bit. [*] It seems possible you could have an issue depending on what your boot loader is or isn't doing for you. U-boot (both 1.1.4 and 1.3.2) calls l2disable() before booting linux, so linux needs to enable it. I vote for removing the l2disable() in u- boot, but I can see that people might be stuck with broken binary bootloaders... Yes, this 'might' help for some users if it works. Traditionally things usually have had some complications here at multiple levels in both hardware and software. And yes not everyone can upgrade a boot loader. However, with expanding boot from MMC/SD support things are getting safer. The bit I was more worried about was the boot loader may not be invalidating secure L2 tags correctly. The method to do this correctly is a little different between EMU/HS and GP devices. Also these base methods changed some between ES1 and ES2 of the chip. I hope no one is using an ES1 anymore but I'm sure code remnants exist. The working code variants did some work in u-boot and some in the kernel to handle these conditions. The current balance today in working variants today has u-boot doing more work. This probably merges with fewer conflicts with the arm-kernel. Last I checked u- boot on Beagle was a based on an older version of the code and probably even a wider range of versions exist in the community. As such it's a good bet some of this is at the root of the problems you are seeing. I'm currently using the u-boot Jason built (1.3.2 + beagle patches) which disables l2 cache before boot and I switch between 2.6.22-wtbu (which enables L2) and git HEAD (which doesn't enable L2). regards, Koen It is important to keep x-loader/u-boot/kernel somewhat in sync for some of these kinds of issues until the development process has settled down and code matured. L2 cache is a huge performance boost on an OMAP3 so it's good to get it. Also you really haven't validated your software if you're running with it off. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux- omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFIII79MkyGM64RGpERAtvQAJ48vSb7R+zcqdSvVZVNE2Gi1mCAoACglzMo 3N3Xt8DeBWfdyZ8DmCfc4OY= =lEih -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: public git l2 cache off.
> Beagleboard (omap3530) > > > I'll try the latest from here on SDP with this and see if it works. > > There is also a difference in CR handling. I had submitted long > > back a fix to Russell but let it get by me as I didn't have the time > > to fix per his comments. I think our version was more correct then > > the one in place but was still lacking a bit. > > > > [*] It seems possible you could have an issue depending on what your > > boot loader is or isn't doing for you. > > U-boot (both 1.1.4 and 1.3.2) calls l2disable() before booting linux, > so linux needs to enable it. I vote for removing the l2disable() in u- > boot, but I can see that people might be stuck with broken binary > bootloaders... Yes, this 'might' help for some users if it works. Traditionally things usually have had some complications here at multiple levels in both hardware and software. And yes not everyone can upgrade a boot loader. However, with expanding boot from MMC/SD support things are getting safer. The bit I was more worried about was the boot loader may not be invalidating secure L2 tags correctly. The method to do this correctly is a little different between EMU/HS and GP devices. Also these base methods changed some between ES1 and ES2 of the chip. I hope no one is using an ES1 anymore but I'm sure code remnants exist. The working code variants did some work in u-boot and some in the kernel to handle these conditions. The current balance today in working variants today has u-boot doing more work. This probably merges with fewer conflicts with the arm-kernel. Last I checked u-boot on Beagle was a based on an older version of the code and probably even a wider range of versions exist in the community. As such it's a good bet some of this is at the root of the problems you are seeing. It is important to keep x-loader/u-boot/kernel somewhat in sync for some of these kinds of issues until the development process has settled down and code matured. L2 cache is a huge performance boost on an OMAP3 so it's good to get it. Also you really haven't validated your software if you're running with it off. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: public git l2 cache off.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 6 mei 2008, om 17:06 heeft Woodruff, Richard het volgende geschreven: Enabling L2 cache was removed from proc-v7.S since was cortex specific instead of armv7 specific and u-boot explicitly turns of L2 before booting into linux. I made a reverse patch, but my omap3 board doesn't boot if I use it: Our 2.6.24 kernel does something close and boots fine on OMAP3-SDP and Labrador boards. Which platform did you try on? Beagleboard (omap3530) I'll try the latest from here on SDP with this and see if it works. There is also a difference in CR handling. I had submitted long back a fix to Russell but let it get by me as I didn't have the time to fix per his comments. I think our version was more correct then the one in place but was still lacking a bit. [*] It seems possible you could have an issue depending on what your boot loader is or isn't doing for you. U-boot (both 1.1.4 and 1.3.2) calls l2disable() before booting linux, so linux needs to enable it. I vote for removing the l2disable() in u- boot, but I can see that people might be stuck with broken binary bootloaders... regards, Koen Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux- omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFIIIU6MkyGM64RGpERAskVAJ9v+zkGPPVi5E2Icb+LHPpoX9rdYgCeOQde zo4KEu3uL8kZliQFQ4YESWE= =mmNw -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: public git l2 cache off.
> Enabling L2 cache was removed from proc-v7.S since was cortex specific > instead of armv7 specific and u-boot explicitly turns of L2 before > booting into linux. I made a reverse patch, but my omap3 board doesn't > boot if I use it: Our 2.6.24 kernel does something close and boots fine on OMAP3-SDP and Labrador boards. Which platform did you try on? I'll try the latest from here on SDP with this and see if it works. There is also a difference in CR handling. I had submitted long back a fix to Russell but let it get by me as I didn't have the time to fix per his comments. I think our version was more correct then the one in place but was still lacking a bit. [*] It seems possible you could have an issue depending on what your boot loader is or isn't doing for you. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: public git l2 cache off.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 6 mei 2008, om 07:38 heeft Koen Kooi het volgende geschreven: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Op 6 mei 2008, om 01:27 heeft Woodruff, Richard het volgende geschreven: Hi, Looks like a tweak from the ARM or TI tree may be needed. Builds of recent pulls of the OMAP3 kernel show L2 cache is disabled. This really has a huge performance impact. I don't have time right now to suggest a patch but may look some time this week. TI internal kernels do have it enabled. A stop in Lauterbach and a look at the L2EN bit in AUX control register will show it is not correct. Enabling L2 cache was removed from proc-v7.S since was cortex specific instead of armv7 specific For reference: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7092fc38ee770251aed361572bf6bed05fcf3ee2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFIIAGMMkyGM64RGpERAgh0AJ9lAmo66yaPu6Yxhp7yeW4S5pvaKwCgppYv jUZY8KpVn0AuQDdhjN2gfBg= =fH+z -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: public git l2 cache off.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Op 6 mei 2008, om 01:27 heeft Woodruff, Richard het volgende geschreven:
Hi,
Looks like a tweak from the ARM or TI tree may be needed. Builds of
recent pulls of the OMAP3 kernel show L2 cache is disabled. This
really has a huge performance impact.
I don't have time right now to suggest a patch but may look some
time this week. TI internal kernels do have it enabled.
A stop in Lauterbach and a look at the L2EN bit in AUX control
register will show it is not correct.
Enabling L2 cache was removed from proc-v7.S since was cortex specific
instead of armv7 specific and u-boot explicitly turns of L2 before
booting into linux. I made a reverse patch, but my omap3 board doesn't
boot if I use it:
- --- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -665,6 +665,12 @@ config CPU_CACHE_ROUND_ROBIN
Say Y here to use the predictable round-robin cache
replacement
policy. Unless you specifically require this or are
unsure, say N.
+config CPU_L2CACHE_DISABLE
+ bool "Disable level 2 cache"
+ depends on CPU_V7
+ help
+ Say Y here to disable the level 2 cache. If unsure, say N.
+
config CPU_BPREDICT_DISABLE
bool "Disable branch prediction"
depends on CPU_ARM1020 || CPU_V6 || CPU_XSC3 || CPU_V7
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index a1d7331..432ddab 100644
- --- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -181,6 +181,16 @@ __v7_setup:
mcr p15, 0, r4, c2, c0, 1 @ load TTB1
mov r10, #0x1f @ domains 0, 1 =
manager
mcr p15, 0, r10, c3, c0, 0 @ load domain access
register
+#ifndef CONFIG_CPU_L2CACHE_DISABLE
+ @ L2 cache configuration in the L2 aux control register
+ mrc p15, 1, r10, c9, c0, 2
+ bic r10, r10, #(1 << 16)@ L2 outer cache
+ mcr p15, 1, r10, c9, c0, 2
+ @ L2 cache is enabled in the aux control register
+ mrc p15, 0, r10, c1, c0, 1
+ orr r10, r10, #2
+ mcr p15, 0, r10, c1, c0, 1
+#endif
#endif
adr r5, v7_crval
ldmia r5, {r5, r6}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFIH+71MkyGM64RGpERAu1EAKCLF8Id735bHUovuZzn56koZw/YywCfb31G
KiN6OiMd1EkOBPa76Ogo+zs=
=R9mv
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
