| Message ID | 1314706560-12773-2-git-send-email-nagabhushana.netagunte@ti.com |
|---|---|
| State | Superseded |
| Headers | show |
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
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 >
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.
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
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. >
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. >>
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, 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 >
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