Patchwork [U-Boot,1/5] da830: disable cache usage due to coherency issues

login
register
mail settings
Submitter nagabhushana.netagunte@ti.com
Date Aug. 30, 2011, 12:15 p.m.
Message ID <1314706560-12773-2-git-send-email-nagabhushana.netagunte@ti.com>
Download mbox | patch
Permalink /patch/112273/
State Superseded
Headers show

Comments

nagabhushana.netagunte@ti.com - Aug. 30, 2011, 12:15 p.m.
From: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>

there are cache coherency issues when using the DAVINCI Ethernet driver,
hence caches cant be used for da830 u-boot. As per new cache management
framework,if the caches are not used in u-boot, it needs to be explicitly
indicated through macros in config file. CACHE disable is  indicated by
the following macro definitions in config file,

1. CONFIG_SYS_ICACHE_OFF
2. CONFIG_SYS_DCACHE_OFF
3. CONFIG_SYS_L2CACHE_OFF

Signed-off-by: Nagabhushana Netagunte <nagabhushana.netagunte@ti.com>
---
 include/configs/da830evm.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Mike Frysinger - Aug. 30, 2011, 3:15 p.m.
On Tuesday, August 30, 2011 08:15:56 nagabhushana.netagunte@ti.com wrote:
> there are cache coherency issues when using the DAVINCI Ethernet driver,
> hence caches cant be used for da830 u-boot.

why not fix the davinci eth driver ?
-mike
nagabhushana.netagunte@ti.com - Aug. 31, 2011, 5:40 a.m.
Mike,

We will address cache coherency issues soon after these patches.
Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 

Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.

Regards,
Nag

On Tue, Aug 30, 2011 at 20:45:58, Mike Frysinger wrote:
> On Tuesday, August 30, 2011 08:15:56 nagabhushana.netagunte@ti.com wrote:
> > there are cache coherency issues when using the DAVINCI Ethernet 
> > driver, hence caches cant be used for da830 u-boot.
> 
> why not fix the davinci eth driver ?
> -mike
>
Nick Thompson - Aug. 31, 2011, 9:39 a.m.
On 31/08/11 06:40, Netagunte, Nagabhushana wrote:
> Mike,
>
> We will address cache coherency issues soon after these patches.
> Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 
>
> Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.
>
> Regards,
> Nag
>

Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel.

On the other hand tftp and kernel CRC checking are much faster with cache enabled.

Nick.
Mike Frysinger - Aug. 31, 2011, 2:35 p.m.
On Wednesday, August 31, 2011 01:40:26 Netagunte, Nagabhushana wrote:
> We will address cache coherency issues soon after these patches.
> Earlier also, chache was disabled. Only due to new cache management
> Framework which was added recently, it is explicitly needed to be
> indicated to turn off cache.
> 
> Since fixing the cache coherency issues with EMAC will take some time, I
> want this patch to go in mainline so that issue doesn't crop up for People
> who use u-boot.

please add something like this to your emac driver then:
#ifndef CONFIG_SYS_DCACHE_OFF
# error "this driver sucks: define CONFIG_SYS_DCACHE_OFF until it is fixed"
#endif
-mike
nagabhushana.netagunte@ti.com - Sept. 14, 2011, 5:54 a.m.
Nick,

I am seeing this issue on da830/da850/dm36x/dm644x.

I agree that u-boot will be faster with cache enabled. And also, TI wants it to be enabled soon. Since so many patches are lined u, we don't up-streaming them to get hampered because of this issue. So, we are trying to push this 
Patch. We are committed come up with appropriate patch to fix the EMAC and coherency issue. 

Meanwhile, we are trying to gather info about earlier patch/changes which disabled cache so that community understands the known issue.

Also, one more engineer observed the issue with EMAC, I will send his mail to you. 

Regards,
Nag
On Wed, Aug 31, 2011 at 15:09:35, Nick Thompson wrote:
> On 31/08/11 06:40, Netagunte, Nagabhushana wrote:
> > Mike,
> >
> > We will address cache coherency issues soon after these patches.
> > Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 
> >
> > Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.
> >
> > Regards,
> > Nag
> >
> 
> Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel.
> 
> On the other hand tftp and kernel CRC checking are much faster with cache enabled.
> 
> Nick.
>
Nick Thompson - Sept. 14, 2011, 11:07 a.m.
On 14/09/11 06:54, Netagunte, Nagabhushana wrote:
> Nick,
>
> I am seeing this issue on da830/da850/dm36x/dm644x.

Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss.

The v1.0 and v1.1 parts do have a d-cache errata, so we only get to use the d-cache in write through mode. This would mean that TCP packet data writes by the processor would never have a coherency problem. Reads could still have an issue, but I think the explanation provided so far referred to TCP packet sending...?

This vintage of da830 will always have to use write trough mode, so there should be no issue...?

> I agree that u-boot will be faster with cache enabled. And also, TI wants it to be enabled soon. Since so many patches are lined u, we don't up-streaming them to get hampered because of this issue. So, we are trying to push this 
> Patch. We are committed come up with appropriate patch to fix the EMAC and coherency issue. 
>
> Meanwhile, we are trying to gather info about earlier patch/changes which disabled cache so that community understands the known issue.

Boot time is critical to us. I can't ship without cache enabled. I can use my own _config.h of course to work around it I think, but I don't understand why you think there is an issue to fix on da830 yet. With a working d-cache I can imagine such a problem though.

> Also, one more engineer observed the issue with EMAC, I will send his mail to you. 
>
> Regards,
> Nag
> On Wed, Aug 31, 2011 at 15:09:35, Nick Thompson wrote:
>> On 31/08/11 06:40, Netagunte, Nagabhushana wrote:
>>> Mike,
>>>
>>> We will address cache coherency issues soon after these patches.
>>> Earlier also, chache was disabled. Only due to new cache management Framework which was added recently, it is explicitly needed to be indicated to turn off cache. 
>>>
>>> Since fixing the cache coherency issues with EMAC will take some time, I want this patch to go in mainline so that issue doesn't crop up for People who use u-boot.
>>>
>>> Regards,
>>> Nag
>>>
>> Which device(s) does this occur on? I have a lot of OMAP-L137 (EVM and custom) boards with cache enabled and no problems tftp'ing the kernel.
>>
>> On the other hand tftp and kernel CRC checking are much faster with cache enabled.
>>
>> Nick.
>>
Tom Rini - Sept. 14, 2011, 2:05 p.m.
On Wed, Sep 14, 2011 at 4:07 AM, Nick Thompson <nick.thompson@ge.com> wrote:
> On 14/09/11 06:54, Netagunte, Nagabhushana wrote:
>> Nick,
>>
>> I am seeing this issue on da830/da850/dm36x/dm644x.
>
> Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss.

Note that when there is a problem, there's no network activity.  I'd
seen this on a dm365evm, but don't have the board handy (nor did I
note the exact rev of the one I had at the time, sadly).
nagabhushana.netagunte@ti.com - Sept. 14, 2011, 2:17 p.m.
Tom,

Thanks! I had a conversation with engineer who came up with new cache management framework. Looks like he has provided patch which fixes this
Issue which got exposed because of his patches. I will test this patch 
Tomorrow and confirm. Most probably, we don't need this patch.

Regards,
Nag

On Wed, Sep 14, 2011 at 19:35:47, Tom Rini wrote:
> On Wed, Sep 14, 2011 at 4:07 AM, Nick Thompson <nick.thompson@ge.com> wrote:
> > On 14/09/11 06:54, Netagunte, Nagabhushana wrote:
> >> Nick,
> >>
> >> I am seeing this issue on da830/da850/dm36x/dm644x.
> >
> > Strange that I have seen no issue with da830 (OMAP-L137 v1.0 & v1.1 - don't have any v2.0 yet) when tftp'ing the kernel. I do get very occasional errors, but have put this down to network packet loss.
> 
> Note that when there is a problem, there's no network activity.  I'd seen this on a dm365evm, but don't have the board handy (nor did I note the exact rev of the one I had at the time, sadly).
> 
> --
> Tom
>

Patch

diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index bcf8ee0..da7d528 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -42,6 +42,9 @@ 
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE		0xc1080000
+#define CONFIG_SYS_ICACHE_OFF
+#define CONFIG_SYS_DCACHE_OFF
+#define CONFIG_SYS_L2CACHE_OFF
 
 /*
  * Memory Info