L2 cache stability workaround for 4460 ES1.0
Subsystems (3)
Hi Santosh,
I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream.
http://www.digipedia.pl/usenet/thread/18885/8437/#post8496
The problem is that we have to keep porting this patch each time we update the kernel.
Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found?
It seems the patch at least makes the kernel usable on ES1.0.
regards,
-roger
Quoted 1 line
From
68ab20c60335eef5aceb9c5f978b8d6ef4b11d9bMon Sep 17 00:00:00 2001
From: Santosh Shilimkar <[email protected]>
Date: Tue, 27 Mar 2012 11:20:09 -0400
Subject: [PATCH 1/3] OMAP4460: L2X0: work-around for stability.
OMAP4460 ES1.0 seems to suffer from stability with L2 cache enabled. The root-cause analysis is ongoing but in meantime this chabe is to enable a software WA with L2 cache enabled build. The WA consist of locking certain cache ways based on their positions on the physical memory layout.
Downside of this WA is that effective L2 cache size will be 512 KB instead of 1 MB.
clalancette: Changed so that the workaround is only activated for ES1.0, and not ES1.1.
--- arch/arm/include/asm/hardware/cache-l2x0.h | 5 +++++ arch/arm/mach-omap2/omap4-common.c | 18 ++++++++++++++++++ 2 files changed, 23 insertions(+), 0 deletions(-)
arch/arm/include/asm/hardware/cache-l2x0.h +5 -0
@@ -56,6 +56,11 @@#define L2X0_LOCKDOWN_STRIDE 0x08#define L2X0_ADDR_FILTER_START 0xC00#define L2X0_ADDR_FILTER_END 0xC04 +#define L2X0_LOCKDOWN_WAY_D0 0x900 +#define L2X0_LOCKDOWN_WAY_D1 0x908 +#define L2X0_LOCKDOWN_WAY_I0 0x904 +#define L2X0_LOCKDOWN_WAY_I1 0x90C +#define L2X0_TEST_OPERATION 0xF00#define L2X0_LINE_DATA 0xF10#define L2X0_LINE_TAG 0xF30
arch/arm/mach-omap2/omap4-common.c +18 -0
@@ -129,6 +129,7 @@ static void omap4_l2x0_set_debug(unsigned long val)static int __init omap_l2_cache_init (void ) {u32 aux_ctrl =0 ; +u32 lockdown =0 ;/* * To avoid code running on other OMAPs in
@@ -164,6 +165,23 @@ static int __init omap_l2_cache_init(void)if (omap_rev () !=OMAP4430_REV_ES1_0 )omap_smc1 (0x109 , aux_ctrl); +/* +* WA for OMAP4460 ES1.0 L2 cache corruption issue. +* Lock-down specific L2 cache ways which makes effective +* L2 size as 512 KB instead of 1 MB +* +* The L2 cache in the ES1.1 doesn't have this issue, so only enable +* the workaround for ES1.0. +*/ +if (omap_rev () ==OMAP4460_REV_ES1_0 ) { +printk (KERN_INFO "OMAP4460 ES1.0 detected, enabling L2 cache stability workaround\n" ); + lockdown =0xa5a5 ; +writel_relaxed (lockdown, l2cache_base +L2X0_LOCKDOWN_WAY_D0 ); +writel_relaxed (lockdown, l2cache_base +L2X0_LOCKDOWN_WAY_D1 ); +writel_relaxed (lockdown, l2cache_base +L2X0_LOCKDOWN_WAY_I0 ); +writel_relaxed (lockdown, l2cache_base +L2X0_LOCKDOWN_WAY_I1 ); + } +/* Enable PL310 L2 Cache controller */ omap_smc1 (0x102 ,0x1 );
Signature · 1 line
1.7.9.1
Quoted 5 lines · Roger Quadros
Hi Santosh,
I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream.
Quoted 8 lines
http://www.digipedia.pl/usenet/thread/18885/8437/#post8496
The problem is that we have to keep porting this patch each time we update the kernel.
Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found?
Yes and fixed in OMAP4460 ES1.2.
Quoted 2 lines
It seems the patch at least makes the kernel usable on ES1.0.
I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0
Regards
Santosh
Quoted 8 lines · Santosh
Quoted 7 lines · Roger Quadros
Hi Santosh,
I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream.
Quoted 7 lines
Quoted 6 lines
The problem is that we have to keep porting this patch each time we update the kernel.
Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found?
Yes and fixed in OMAP4460 ES1.2.
Did you mean ES1.1?
Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690
Quoted 7 lines
Quoted 3 lines
It seems the patch at least makes the kernel usable on ES1.0.
I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0
Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix.
What do you say?
regards,
-roger
Quoted 12 lines · Roger Quadros
Quoted 11 lines · Santosh
Quoted 10 lines · Roger Quadros
Hi Santosh,
I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream.
http://www.digipedia.pl/usenet/thread/18885/8437/#post8496
The problem is that we have to keep porting this patch each time we update the kernel.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found?
Yes and fixed in OMAP4460 ES1.2.
Did you mean ES1.1?
yep. Sorry for the typo.
Quoted 10 lines
Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690
Quoted 7 lines
Quoted 3 lines
It seems the patch at least makes the kernel usable on ES1.0.
I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0
Quoted 6 lines
Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix.
What do you say?
My request is to get rid of ES1.0 board because the WA just not completely correct. Don't feel patching kernel for silicon which is not suppose to be used nether has complete WA to support it.
Regards
Santosh
Quoted 36 lines · Santosh
Quoted 12 lines · Roger Quadros
Quoted 11 lines · Santosh
Quoted 10 lines · Roger Quadros
Hi Santosh,
I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream.
http://www.digipedia.pl/usenet/thread/18885/8437/#post8496
The problem is that we have to keep porting this patch each time we update the kernel.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found?
Yes and fixed in OMAP4460 ES1.2.
Did you mean ES1.1?
yep. Sorry for the typo.
Quoted 14 lines
Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690
Quoted 7 lines
Quoted 3 lines
It seems the patch at least makes the kernel usable on ES1.0.
I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0
Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix.
Quoted 7 lines
Quoted 2 lines
What do you say?
My request is to get rid of ES1.0 board because the WA just not completely correct. Don't feel patching kernel for silicon which is not suppose to be used nether has complete WA to support it.
OK Santosh. seems like cache is broken bad on ES1.0.
Is it possible to disable the cache for ES1.0 and print a warning message about it?
regards,
-roger
Quoted 44 lines · Roger Quadros
Quoted 36 lines · Santosh
Quoted 12 lines · Roger Quadros
Quoted 11 lines · Santosh
Quoted 10 lines · Roger Quadros
Hi Santosh,
I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream.
http://www.digipedia.pl/usenet/thread/18885/8437/#post8496
The problem is that we have to keep porting this patch each time we update the kernel.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found?
Yes and fixed in OMAP4460 ES1.2.
Did you mean ES1.1?
yep. Sorry for the typo.
Quoted 14 lines
Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690
Quoted 7 lines
Quoted 3 lines
It seems the patch at least makes the kernel usable on ES1.0.
I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0
Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix.
Quoted 7 lines
Quoted 2 lines
What do you say?
My request is to get rid of ES1.0 board because the WA just not completely correct. Don't feel patching kernel for silicon which is not suppose to be used nether has complete WA to support it.
Quoted 5 lines
OK Santosh. seems like cache is broken bad on ES1.0.
Is it possible to disable the cache for ES1.0 and print a warning message about it?
Let's not add that support. See there are very few boards in TI where ES1.0 is used so I suggest those users keep using whatever works for them. Disable or the partial WA.
Regards
Santosh