[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Ilya Yanok]

DaVinci EMAC driver has no support for running with D-Cache enabled so
disable D-Cache on all DaVinci boards with EMAC device.

Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---

I can't test it on any DaVinci boards right now but my understanding
is that currently EMAC driver can't work properly with D-Cache enabled.

 include/configs/da830evm.h          |    1 +
 include/configs/davinci_dm365evm.h  |    1 +
 include/configs/davinci_dm6467evm.h |    1 +
 include/configs/davinci_dvevm.h     |    1 +
 include/configs/davinci_schmoogie.h |    1 +
 include/configs/davinci_sffsdr.h    |    1 +
 include/configs/davinci_sonata.h    |    1 +
 include/configs/ea20.h              |    1 +
 include/configs/hawkboard.h         |    1 +
 9 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 6ac25d2..aa02c8d 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -43,6 +43,7 @@
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE		0xc1080000
+#define CONFIG_SYS_DCACHE_OFF
 
 /*
  * Memory Info
diff --git a/include/configs/davinci_dm365evm.h b/include/configs/davinci_dm365evm.h
index cb6ed24..f2171b5 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -33,6 +33,7 @@
 #define CONFIG_SYS_HZ_CLOCK		24000000	/* timer0 freq */
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SOC_DM365
+#define CONFIG_SYS_DCACHE_OFF
 
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS		1
diff --git a/include/configs/davinci_dm6467evm.h b/include/configs/davinci_dm6467evm.h
index ec1c31c..a35e850 100644
--- a/include/configs/davinci_dm6467evm.h
+++ b/include/configs/davinci_dm6467evm.h
@@ -44,6 +44,7 @@ extern unsigned int davinci_arm_clk_get(void);
 #define CONFIG_SYS_TIMERBASE		0x01c21400	/* use timer 0 */
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SOC_DM646X
+#define CONFIG_SYS_DCACHE_OFF
 
 /* EEPROM definitions for EEPROM */
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN		2
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index c052517..f9b39f6 100644
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -60,6 +60,7 @@
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SOC_DM644X
+#define CONFIG_SYS_DCACHE_OFF
 /*====================================================*/
 /* EEPROM definitions for Atmel 24C256BN SEEPROM chip */
 /* on Sonata/DV_EVM board. No EEPROM on schmoogie.    */
diff --git a/include/configs/davinci_schmoogie.h b/include/configs/davinci_schmoogie.h
index 5eaa198..cc2e540 100644
--- a/include/configs/davinci_schmoogie.h
+++ b/include/configs/davinci_schmoogie.h
@@ -35,6 +35,7 @@
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SOC_DM644X
+#define CONFIG_SYS_DCACHE_OFF
 /*=============*/
 /* Memory Info */
 /*=============*/
diff --git a/include/configs/davinci_sffsdr.h b/include/configs/davinci_sffsdr.h
index 0c65391..530ac5b 100644
--- a/include/configs/davinci_sffsdr.h
+++ b/include/configs/davinci_sffsdr.h
@@ -35,6 +35,7 @@
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SOC_DM644X
+#define CONFIG_SYS_DCACHE_OFF
 /* EEPROM definitions for Atmel 24LC64 EEPROM chip */
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN		2
 #define CONFIG_SYS_I2C_EEPROM_ADDR		0x50
diff --git a/include/configs/davinci_sonata.h b/include/configs/davinci_sonata.h
index 74530e8..f0fd389 100644
--- a/include/configs/davinci_sonata.h
+++ b/include/configs/davinci_sonata.h
@@ -60,6 +60,7 @@
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SOC_DM644X
+#define CONFIG_SYS_DCACHE_OFF
 /*====================================================*/
 /* EEPROM definitions for Atmel 24C256BN SEEPROM chip */
 /* on Sonata/DV_EVM board. No EEPROM on schmoogie.    */
diff --git a/include/configs/ea20.h b/include/configs/ea20.h
index 74fec3f..31ad338 100644
--- a/include/configs/ea20.h
+++ b/include/configs/ea20.h
@@ -48,6 +48,7 @@
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE		0xc1080000
+#define CONFIG_SYS_DCACHE_OFF
 
 /*
  * Memory Info
diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h
index 638643a..3230142 100644
--- a/include/configs/hawkboard.h
+++ b/include/configs/hawkboard.h
@@ -47,6 +47,7 @@
 #else
 #define CONFIG_SYS_TEXT_BASE		0xc1180000
 #endif
+#define CONFIG_SYS_DCACHE_OFF
 
 /*
  * Memory Info
-- 
1.7.6.4

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Andy Fleming]

On Fri, Nov 11, 2011 at 3:56 PM, Ilya Yanok <yanok@emcraft.com> wrote:
> DaVinci EMAC driver has no support for running with D-Cache enabled so
> disable D-Cache on all DaVinci boards with EMAC device.
>
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>


I think it might be better to disable DCACHE as a result of EMAC being
enabled, to make it clear in the config why that's happening.

Andy

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Tom Rini]

On Fri, Nov 11, 2011 at 3:10 PM, Andy Fleming <afleming@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 3:56 PM, Ilya Yanok <yanok@emcraft.com> wrote:
>> DaVinci EMAC driver has no support for running with D-Cache enabled so
>> disable D-Cache on all DaVinci boards with EMAC device.
>>
>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>
>
> I think it might be better to disable DCACHE as a result of EMAC being
> enabled, to make it clear in the config why that's happening.

I agree, and I was going to propose something similar.  Anecdotally
(which is all I can do atm), I had the same kind of issue a few months
back on one of these platforms.  Ben, since you've been most recently
active on the davinci side of this driver, do you object to turning
off dcache until there's flush ops for the platform?

-- 
Tom

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Ben Gardiner]

Hi Tom,

On Fri, Nov 11, 2011 at 6:53 PM, Tom Rini <tom.rini@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 3:10 PM, Andy Fleming <afleming@gmail.com> wrote:
>> On Fri, Nov 11, 2011 at 3:56 PM, Ilya Yanok <yanok@emcraft.com> wrote:
>>> DaVinci EMAC driver has no support for running with D-Cache enabled so
>>> disable D-Cache on all DaVinci boards with EMAC device.
>>>
>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>>
>>
>> I think it might be better to disable DCACHE as a result of EMAC being
>> enabled, to make it clear in the config why that's happening.
>
> I agree, and I was going to propose something similar. ?Anecdotally
> (which is all I can do atm), I had the same kind of issue a few months
> back on one of these platforms. ?Ben, since you've been most recently
> active on the davinci side of this driver, do you object to turning
> off dcache until there's flush ops for the platform?

Sounds reasonable.

Note: if conditional disabling of DCACHE is going to be added for the
boards listed in the path of this subject please remember to make
da850evm also conditional since it had its dcache disabled explicitly
in commit 'bd65d00 da850: indicate cache usage disable in config file'

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

[U-Boot] [PATCH V2] davinci: disable dcache on boards with EMAC

[Ilya Yanok]

DaVinci EMAC driver needs working {flush,invalidate}_dcache_range
functions to run with enabled D-Cache correctly. These functions are not
implemented for ARM926EJS currently so disable D-Cache on DaVinci boards
with EMAC for now.

Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
 include/configs/cam_enc_4xx.h       |    5 ++++-
 include/configs/da830evm.h          |    1 +
 include/configs/da850evm.h          |    6 +++---
 include/configs/davinci_dm365evm.h  |    4 ++++
 include/configs/davinci_dm6467evm.h |    4 ++++
 include/configs/davinci_dvevm.h     |    4 ++++
 include/configs/davinci_schmoogie.h |    4 ++++
 include/configs/davinci_sffsdr.h    |    4 ++++
 include/configs/davinci_sonata.h    |    4 ++++
 include/configs/ea20.h              |    1 +
 include/configs/hawkboard.h         |    3 +++
 11 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/include/configs/cam_enc_4xx.h b/include/configs/cam_enc_4xx.h
index a21d448..daaf545 100644
--- a/include/configs/cam_enc_4xx.h
+++ b/include/configs/cam_enc_4xx.h
@@ -70,9 +70,12 @@
 #define CONFIG_NET_RETRY_COUNT	10
 #define CONFIG_NET_MULTI
 #define CONFIG_CMD_MII
-#define CONFIG_SYS_DCACHE_OFF
 #define CONFIG_RESET_PHY_R
 
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
+
 /* I2C */
 #define CONFIG_HARD_I2C
 #define CONFIG_DRIVER_DAVINCI_I2C
diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h
index 6ac25d2..11a0b18 100644
--- a/include/configs/da830evm.h
+++ b/include/configs/da830evm.h
@@ -87,6 +87,7 @@
  * Network & Ethernet Configuration
  */
 #ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
 #define CONFIG_MII
 #define CONFIG_BOOTP_DEFAULT
 #define CONFIG_BOOTP_DNS
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 4c14370..ed1a634 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -43,9 +43,6 @@
 #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
@@ -121,6 +118,9 @@
  * Network & Ethernet Configuration
  */
 #ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_ICACHE_OFF
+#define CONFIG_SYS_DCACHE_OFF
+#define CONFIG_SYS_L2CACHE_OFF
 #define CONFIG_MII
 #define CONFIG_BOOTP_DEFAULT
 #define CONFIG_BOOTP_DNS
diff --git a/include/configs/davinci_dm365evm.h b/include/configs/davinci_dm365evm.h
index cb6ed24..9878a0a 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -64,6 +64,10 @@
 #define CONFIG_BOOTP_SEND_HOSTNAME
 #define CONFIG_NET_RETRY_COUNT	10
 
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
+
 /* I2C */
 #define CONFIG_HARD_I2C
 #define CONFIG_DRIVER_DAVINCI_I2C
diff --git a/include/configs/davinci_dm6467evm.h b/include/configs/davinci_dm6467evm.h
index ec1c31c..171d095 100644
--- a/include/configs/davinci_dm6467evm.h
+++ b/include/configs/davinci_dm6467evm.h
@@ -92,6 +92,10 @@ extern unsigned int davinci_arm_clk_get(void);
 #define CONFIG_NET_RETRY_COUNT	10
 #define CONFIG_CMD_NET
 
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
+
 /* Flash & Environment */
 #define CONFIG_SYS_NO_FLASH
 #ifdef CONFIG_SYS_USE_NAND
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index c052517..5eb8772 100644
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -108,6 +108,10 @@
 #define CONFIG_BOOTP_DNS2
 #define CONFIG_BOOTP_SEND_HOSTNAME
 #define CONFIG_NET_RETRY_COUNT	10
+
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
 /*=====================*/
 /* Flash & Environment */
 /*=====================*/
diff --git a/include/configs/davinci_schmoogie.h b/include/configs/davinci_schmoogie.h
index 5eaa198..4fa3a5c 100644
--- a/include/configs/davinci_schmoogie.h
+++ b/include/configs/davinci_schmoogie.h
@@ -75,6 +75,10 @@
 #define CONFIG_BOOTP_SEND_HOSTNAME
 #define CONFIG_NET_RETRY_COUNT	10
 #define CONFIG_OVERWRITE_ETHADDR_ONCE
+
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
 /*=====================*/
 /* Flash & Environment */
 /*=====================*/
diff --git a/include/configs/davinci_sffsdr.h b/include/configs/davinci_sffsdr.h
index 0c65391..7cbc566 100644
--- a/include/configs/davinci_sffsdr.h
+++ b/include/configs/davinci_sffsdr.h
@@ -72,6 +72,10 @@
 #define CONFIG_BOOTP_SEND_HOSTNAME
 #define CONFIG_NET_RETRY_COUNT	10
 #define CONFIG_OVERWRITE_ETHADDR_ONCE
+
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
 /* Flash & Environment */
 #undef CONFIG_ENV_IS_IN_FLASH
 #define CONFIG_SYS_NO_FLASH
diff --git a/include/configs/davinci_sonata.h b/include/configs/davinci_sonata.h
index 74530e8..631f02c 100644
--- a/include/configs/davinci_sonata.h
+++ b/include/configs/davinci_sonata.h
@@ -107,6 +107,10 @@
 #define CONFIG_BOOTP_DNS2
 #define CONFIG_BOOTP_SEND_HOSTNAME
 #define CONFIG_NET_RETRY_COUNT	10
+
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
 /*=====================*/
 /* Flash & Environment */
 /*=====================*/
diff --git a/include/configs/ea20.h b/include/configs/ea20.h
index 74fec3f..a583a2a 100644
--- a/include/configs/ea20.h
+++ b/include/configs/ea20.h
@@ -98,6 +98,7 @@
  * Network & Ethernet Configuration
  */
 #ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
 #define CONFIG_MII
 #define CONFIG_BOOTP_DEFAULT
 #define CONFIG_BOOTP_DNS
diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h
index 638643a..ff03cba 100644
--- a/include/configs/hawkboard.h
+++ b/include/configs/hawkboard.h
@@ -92,6 +92,9 @@
 #define CONFIG_BOOTP_DNS2
 #define CONFIG_BOOTP_SEND_HOSTNAME
 #define CONFIG_NET_RETRY_COUNT		10
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define CONFIG_SYS_DCACHE_OFF
+#endif
 
 /*
  * Nand Flash
-- 
1.7.6.4

[U-Boot] [PATCH V2] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Ilya Yanok,

In message <1321315795-31297-1-git-send-email-yanok@emcraft.com> you wrote:
> DaVinci EMAC driver needs working {flush,invalidate}_dcache_range
> functions to run with enabled D-Cache correctly. These functions are not
> implemented for ARM926EJS currently so disable D-Cache on DaVinci boards
> with EMAC for now.
> 
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>

NAK again, with the same reasoning as before.

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
As of 1992, they're called European Economic Community fries.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Ilya Yanok,

In message <1321048618-20616-1-git-send-email-yanok@emcraft.com> you wrote:
> DaVinci EMAC driver has no support for running with D-Cache enabled so
> disable D-Cache on all DaVinci boards with EMAC device.
> 
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
> 
> I can't test it on any DaVinci boards right now but my understanding
> is that currently EMAC driver can't work properly with D-Cache enabled.
> 
>  include/configs/da830evm.h          |    1 +
>  include/configs/davinci_dm365evm.h  |    1 +
>  include/configs/davinci_dm6467evm.h |    1 +
>  include/configs/davinci_dvevm.h     |    1 +
>  include/configs/davinci_schmoogie.h |    1 +
>  include/configs/davinci_sffsdr.h    |    1 +
>  include/configs/davinci_sonata.h    |    1 +
>  include/configs/ea20.h              |    1 +
>  include/configs/hawkboard.h         |    1 +
>  9 files changed, 9 insertions(+), 0 deletions(-)

Why do we have to permanently disable the data cache just because the
network driver is broken?  USB is also broken, and probably other
drivers as well.

But this does not man we cannot use the data cache for other things.
Actually we WANT to be able to use it, so it is counter-productive to
disable it.

It should be sufficient to switch the cache off ("dc off") before
runnign any network related commands (and you want to make sure to
switch it on again afterwards).


Please PLEASE stop disabling cache support in the config files!

Rather invest efforts in fixing the broken drivers.

Thanks.


[In case it was not clear:  This is a NAK.]

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
Die Freiheit des Menschen liegt nicht darin, dass er tun kann, was er
will, sondern darin, dass er nicht tun muss, was er nicht will.
                                             -- Jean-Jacques Rousseau

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Tom Rini]

On Sun, Nov 27, 2011 at 8:09 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Ilya Yanok,
>
> In message <1321048618-20616-1-git-send-email-yanok@emcraft.com> you wrote:
>> DaVinci EMAC driver has no support for running with D-Cache enabled so
>> disable D-Cache on all DaVinci boards with EMAC device.
>>
>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>> ---
>>
>> I can't test it on any DaVinci boards right now but my understanding
>> is that currently EMAC driver can't work properly with D-Cache enabled.
>>
>> ?include/configs/da830evm.h ? ? ? ? ?| ? ?1 +
>> ?include/configs/davinci_dm365evm.h ?| ? ?1 +
>> ?include/configs/davinci_dm6467evm.h | ? ?1 +
>> ?include/configs/davinci_dvevm.h ? ? | ? ?1 +
>> ?include/configs/davinci_schmoogie.h | ? ?1 +
>> ?include/configs/davinci_sffsdr.h ? ?| ? ?1 +
>> ?include/configs/davinci_sonata.h ? ?| ? ?1 +
>> ?include/configs/ea20.h ? ? ? ? ? ? ?| ? ?1 +
>> ?include/configs/hawkboard.h ? ? ? ? | ? ?1 +
>> ?9 files changed, 9 insertions(+), 0 deletions(-)
>
> Why do we have to permanently disable the data cache just because the
> network driver is broken? ?USB is also broken, and probably other
> drivers as well.

To be clear, the problem is that today the driver is broken (not cache
safe) and this series of patches fixes that problem.  In doing so we
expose that arm926ejs doesn't have complete cache support today.

> But this does not man we cannot use the data cache for other things.
> Actually we WANT to be able to use it, so it is counter-productive to
> disable it.

But cache support is incomplete is the problem.  None of the flushing
operations exist.

> It should be sufficient to switch the cache off ("dc off") before
> runnign any network related commands (and you want to make sure to
> switch it on again afterwards).

We can't because we can't compile the driver, once we make it cache
safe.  It's not today and at least anecdotally the driver doesn't work
today on these platforms unless you turn off dcache.

As a tangent, is pushing new network drivers that aren't cache safe OK
if we just say that you need to turn off the dcache before using?

-- 
Tom

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Tom Rini,

In message <CA+M6bXkFRqkzRtiPuLYN9Zi8ZtXCYQS+LAT4pbKD0nmb3NONdQ@mail.gmail.com> you wrote:
>
> > Why do we have to permanently disable the data cache just because the
> > network driver is broken? ?USB is also broken, and probably other
> > drivers as well.
> 
> To be clear, the problem is that today the driver is broken (not cache
> safe) and this series of patches fixes that problem.  In doing so we
> expose that arm926ejs doesn't have complete cache support today.

But the cahce support works fine for a lot of things - basicly
everything except for the broken drivers.  Why do you want to make ALL
user suffer from this, even if they don't intend to use the broken
driver(s) at all?

For example, booting from NAND is probably MUCH faster with caches on.
Why should we make this slower than necessary?

> But cache support is incomplete is the problem.  None of the flushing
> operations exist.

Then fix _THAT_.

> > It should be sufficient to switch the cache off ("dc off") before
> > runnign any network related commands (and you want to make sure to
> > switch it on again afterwards).
> 
> We can't because we can't compile the driver, once we make it cache
> safe.  It's not today and at least anecdotally the driver doesn't work
> today on these platforms unless you turn off dcache.

We cannot _compile_ the driver?  That's even worse and needs to be
fixed.

> As a tangent, is pushing new network drivers that aren't cache safe OK
> if we just say that you need to turn off the dcache before using?

No.  We should not accept any such drivers any more.


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
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Tom Rini]

On Sun, Nov 27, 2011 at 11:09 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Tom Rini,
>
> In message <CA+M6bXkFRqkzRtiPuLYN9Zi8ZtXCYQS+LAT4pbKD0nmb3NONdQ@mail.gmail.com> you wrote:
>>
>> > Why do we have to permanently disable the data cache just because the
>> > network driver is broken? ?USB is also broken, and probably other
>> > drivers as well.
>>
>> To be clear, the problem is that today the driver is broken (not cache
>> safe) and this series of patches fixes that problem. ?In doing so we
>> expose that arm926ejs doesn't have complete cache support today.
>
> But the cahce support works fine for a lot of things - basicly
> everything except for the broken drivers. ?Why do you want to make ALL
> user suffer from this, even if they don't intend to use the broken
> driver(s) at all?
>
> For example, booting from NAND is probably MUCH faster with caches on.
> Why should we make this slower than necessary?

To encourage someone with the domain knowledge to finish cache support
for the processor?

>> But cache support is incomplete is the problem. ?None of the flushing
>> operations exist.
>
> Then fix _THAT_.

OK.

>> > It should be sufficient to switch the cache off ("dc off") before
>> > runnign any network related commands (and you want to make sure to
>> > switch it on again afterwards).
>>
>> We can't because we can't compile the driver, once we make it cache
>> safe. ?It's not today and at least anecdotally the driver doesn't work
>> today on these platforms unless you turn off dcache.
>
> We cannot _compile_ the driver? ?That's even worse and needs to be
> fixed.

That's what this patch was doing, by disabling the cache so it would
build.  To be clear, today it builds but doesn't work with cache on.

>> As a tangent, is pushing new network drivers that aren't cache safe OK
>> if we just say that you need to turn off the dcache before using?
>
> No. ?We should not accept any such drivers any more.

Noted and as I suspected, thanks.

-- 
Tom

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Tom Rini,

In message <CA+M6bX=F0s3yuxZDnR+x0adi+eiE2dHW2qxZoDie_U7xSRkWMQ@mail.gmail.com> you wrote:
>
> > For example, booting from NAND is probably MUCH faster with caches on.
> > Why should we make this slower than necessary?
> 
> To encourage someone with the domain knowledge to finish cache support
> for the processor?

That would be unfair.  If you want to push for fixes, then push the
where the problems are coming from.  If it's the EMAC driver, then
let's disable the EMAC driver until it gets fixed.

Alternatively, let's add enough fixes to make it compile, and have
people switch cahces off before using the driver.

Having _everybody_ suffer fromt hat is, well, unfair.

> > We cannot _compile_ the driver?  That's even worse and needs to be
> > fixed.
> 
> That's what this patch was doing, by disabling the cache so it would
> build.  To be clear, today it builds but doesn't work with cache on.

NO, it is NOT a fix. It is a dirty workaround that makes everybody
suffer, even if he is not interested in this driver at all.

Rather disable the driver in the config files.


Hm... actually I don't understand you.  First you write: "we can't
compile the driver", then you write "it builds but doesn't work with
cache on".

Well, it it builds, then we should be able to do a "dc off" before
running the driver, and eventually it would work then?

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
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).                   - Bill Joy 6/21/85

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Tom Rini]

On Sun, Nov 27, 2011 at 11:43 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Tom Rini,
>
> In message <CA+M6bX=F0s3yuxZDnR+x0adi+eiE2dHW2qxZoDie_U7xSRkWMQ@mail.gmail.com> you wrote:
>>
>> > For example, booting from NAND is probably MUCH faster with caches on.
>> > Why should we make this slower than necessary?
>>
>> To encourage someone with the domain knowledge to finish cache support
>> for the processor?
>
> That would be unfair. ?If you want to push for fixes, then push the
> where the problems are coming from. ?If it's the EMAC driver, then
> let's disable the EMAC driver until it gets fixed.

Would this series, but with removing emac from the davinci config
files instead, be OK then?

> Alternatively, let's add enough fixes to make it compile, and have
> people switch cahces off before using the driver.

This was the first iteration, and was NAK'd by someone else (I don't
recall who right now).

>> > We cannot _compile_ the driver? ?That's even worse and needs to be
>> > fixed.
>>
>> That's what this patch was doing, by disabling the cache so it would
>> build. ?To be clear, today it builds but doesn't work with cache on.
>
> NO, it is NOT a fix. It is a dirty workaround that makes everybody
> suffer, even if he is not interested in this driver at all.
>
> Rather disable the driver in the config files.
>
>
> Hm... actually I don't understand you. ?First you write: "we can't
> compile the driver", then you write "it builds but doesn't work with
> cache on".

I was unclear, sorry.  Let me summarize:
- Today, the driver builds for davinci platforms, but anecdotal
evidence says it doesn't function without 'dc off'.
- With this series, fully, davinci builds, and works, because dcache
is off, and am35x now has ethernet, with dcache on.
- With this series, minus this single part, davinci fails to link with
this driver enabled because of missing cache functions.

-- 
Tom

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Tom Rini,

In message <CA+M6bXm-iPdXEth80UjxG=ek=6iGuK8+3H-AN+t=KdmH=a_aaQ@mail.gmail.com> you wrote:
>
> I was unclear, sorry.  Let me summarize:
> - Today, the driver builds for davinci platforms, but anecdotal
> evidence says it doesn't function without 'dc off'.
> - With this series, fully, davinci builds, and works, because dcache
> is off, and am35x now has ethernet, with dcache on.
> - With this series, minus this single part, davinci fails to link with
> this driver enabled because of missing cache functions.

I have to apologize - I havent read much U-Boot traffic in the last
few weeks, and while trying to catch up, I don;t really have a full
overview of all postings.  So I'm missing the context of what "this
series" and "this single part" means.

I think we should try and get to a state where we have AM35xx work,
with caches on (I understand this is possible with the current code
for AM35xx).

When we then have problems on DaVinci, that can be worked around by
running "dc off" before accessing the network (or USB), then this is
IMO a much better state than having DC permanently disable for all
these systems.

I don't know which patches have to be applied, or omitted, to acchive
this state, though.

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
I realize that command does have its fascination, even under  circum-
stances such as these, but I neither enjoy the idea of command nor am
I  frightened  of  it. It simply exists, and I will do whatever logi-
cally needs to be done.
	-- Spock, "The Galileo Seven", stardate 2812.7

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Ilya Yanok]

Dear Wolfgang,

On 27.11.2011 22:09, Wolfgang Denk wrote:
>> To be clear, the problem is that today the driver is broken (not cache
>> safe) and this series of patches fixes that problem.  In doing so we
>> expose that arm926ejs doesn't have complete cache support today.
> 
> But the cahce support works fine for a lot of things - basicly
> everything except for the broken drivers.  Why do you want to make ALL
> user suffer from this, even if they don't intend to use the broken
> driver(s) at all?

Please note that I've already fixed the driver itself but the patch is
still not accepted (because of this problem).

> For example, booting from NAND is probably MUCH faster with caches on.
> Why should we make this slower than necessary?
> 
>> But cache support is incomplete is the problem.  None of the flushing
>> operations exist.
> 
> Then fix _THAT_.

Hm. So I've fixed the broken driver but you aren't going to accept the
patch and say "Please go ahead and fix arm926ejs cache support also".
But it's not even the SoC type I'm working with...

>>> It should be sufficient to switch the cache off ("dc off") before
>>> runnign any network related commands (and you want to make sure to
>>> switch it on again afterwards).
>>
>> We can't because we can't compile the driver, once we make it cache
>> safe.  It's not today and at least anecdotally the driver doesn't work
>> today on these platforms unless you turn off dcache.
> 
> We cannot _compile_ the driver?  That's even worse and needs to be
> fixed.

Alternatively we can just drop the driver cache-related fix, leave the
driver broken and work with the network with "dc off" trick on AM35x also.

Do you think this will be better?

Regards, Ilya.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Ilya Yanok,

In message <4ED2835F.4010802@emcraft.com> you wrote:
> 
> > But the cahce support works fine for a lot of things - basicly
> > everything except for the broken drivers.  Why do you want to make ALL
> > user suffer from this, even if they don't intend to use the broken
> > driver(s) at all?
> 
> Please note that I've already fixed the driver itself but the patch is
> still not accepted (because of this problem).

Because of which problem?


> >> But cache support is incomplete is the problem.  None of the flushing
> >> operations exist.
> > 
> > Then fix _THAT_.
> 
> Hm. So I've fixed the broken driver but you aren't going to accept the
> patch and say "Please go ahead and fix arm926ejs cache support also".
> But it's not even the SoC type I'm working with...

I am aware of this. I don't think I rejected your driver patch.

I also did not say _you_ are supposed to add the necessary level of
cache support for all SoCs that need it.

> Alternatively we can just drop the driver cache-related fix, leave the
> driver broken and work with the network with "dc off" trick on AM35x also.
> 
> Do you think this will be better?

I think we have a number of different proposals here.  My assessment
is:

Worst:  permanently disable data chache on all boards

slightly better:  leave the driver broken and use "dc off" before
        running any network related commands

best:  fix the driver and cache support and permanently enable it.


It appears we cannot have the best solution at the moment, so we
should target for the second best one, but not for the worst one.

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
The day-to-day travails of the IBM programmer are so amusing to  most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Ilya Yanok]

Dear Wolfgang,

On 27.11.2011 22:49, Wolfgang Denk wrote:
>>> But the cahce support works fine for a lot of things - basicly
>>> everything except for the broken drivers.  Why do you want to make ALL
>>> user suffer from this, even if they don't intend to use the broken
>>> driver(s) at all?
>>
>> Please note that I've already fixed the driver itself but the patch is
>> still not accepted (because of this problem).
> 
> Because of which problem?

DaVinci building problem. After fixing the driver many DaVinci boards
failed to build because of missing cache functions.

>>>> But cache support is incomplete is the problem.  None of the flushing
>>>> operations exist.
>>>
>>> Then fix _THAT_.
>>
>> Hm. So I've fixed the broken driver but you aren't going to accept the
>> patch and say "Please go ahead and fix arm926ejs cache support also".
>> But it's not even the SoC type I'm working with...
> 
> I am aware of this. I don't think I rejected your driver patch.

Well, that wasn't you. But the series were rejected because of DaVinci
build failure. Now, with this patch rejected, the complete series is
going to be rejected again...

> I also did not say _you_ are supposed to add the necessary level of
> cache support for all SoCs that need it.

But to push my changes I have to add it, right?

Thinking once more about this... Can't we add stub implementation of
cache functions for arm926ejs? Something like this:

void flush_dcache_range(...)
{
	printf("Cache operations are not implemented, consider using 'dc off'
command or (better) implement cache support\n");
}

This will preserve status quo: we can leave D-Cache enabled on DaVinci
but user will have to disable it by hand before using network. On AM35x
network will work with caches enabled.

>> Alternatively we can just drop the driver cache-related fix, leave the
>> driver broken and work with the network with "dc off" trick on AM35x also.
>>
>> Do you think this will be better?
> 
> I think we have a number of different proposals here.  My assessment
> is:
> 
> Worst:  permanently disable data chache on all boards
> 
> slightly better:  leave the driver broken and use "dc off" before
>         running any network related commands
> 

Don't you think that adding stub implementation for cache functions on
arm926ejs and fixing the driver is better?

> best:  fix the driver and cache support and permanently enable it.

Regards, Ilya.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Ilya,

In message <4ED28DFD.7090805@emcraft.com> you wrote:
> 
> > I am aware of this. I don't think I rejected your driver patch.
> 
> Well, that wasn't you. But the series were rejected because of DaVinci
> build failure. Now, with this patch rejected, the complete series is
> going to be rejected again...

This is something I ant to avoid....

> Thinking once more about this... Can't we add stub implementation of
> cache functions for arm926ejs? Something like this:
> 
> void flush_dcache_range(...)
> {
> 	printf("Cache operations are not implemented, consider using 'dc off'
> command or (better) implement cache support\n");
> }

Yes, exactly.  And eventually also call do_dcache(...OFF...) the first
time any such function stub gets called.

> This will preserve status quo: we can leave D-Cache enabled on DaVinci
> but user will have to disable it by hand before using network. On AM35x
> network will work with caches enabled.

That would definitely be best.

> >> Alternatively we can just drop the driver cache-related fix, leave the
> >> driver broken and work with the network with "dc off" trick on AM35x also.
> >>
> >> Do you think this will be better?
> > 
> > I think we have a number of different proposals here.  My assessment
> > is:
> > 
> > Worst:  permanently disable data chache on all boards
> > 
> > slightly better:  leave the driver broken and use "dc off" before
> >         running any network related commands
> > 
> 
> Don't you think that adding stub implementation for cache functions on
> arm926ejs and fixing the driver is better?

Yes, that would be the 4th approach, listed as "much better" :-)

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
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Albert ARIBAUD]

Hi all,

Le 27/11/2011 20:36, Wolfgang Denk a ?crit :

>> Don't you think that adding stub implementation for cache functions on
>> arm926ejs and fixing the driver is better?
>
> Yes, that would be the 4th approach, listed as "much better" :-)

Better yet, have an ARM-wide, not only ARM926EJ-S, cache framework with 
a hierarchy of cache function implementations, from ARM architectures to 
Cores / SoCs or even boards.

My general idea is that:

- each ISA (ARMv4/5/4/7/etc) should provide generic implementations for 
cache handling functions to all cores, SoCs, boards that use this ISA, 
and that implementation should be used by default;

- each core / SoC should be able to easily provide specific cache 
function variants to all boards based on it, on a function granularity 
(i.e. reuse as much of the ISA cache handling code as possible);

- maybe a board should be able to easily provide specific cache 
functions as well;

- the cache API should hide L1 / L2 intricacies at the client level, 
i.e. a driver that wants to flush to memory should just call 
'cache_flush_range(address, size)' without wondering which caches the 
board provides;

- global cache enable/disable/flush (as opposed to cache range) should 
be used only in very few cases (init and exit, meaning U-Boot startup 
and jum-to-OS cases).

The system of 'overloading' between lib, ISA and SoC / Core could be 
achieved through weak symbols maybe, or a set of CONFIG variables, e.g. 
CONFIG_ARM_CACHE_FLUSH would be set to the name of the function to use 
for cache flushing, etc.

However, I have very little time ATM even to try and keep up with 
patches and pull reqs, so I simply cannot submit any code for ARM cache 
handling. Thus anyone wishing to submit code along the lines above, or 
provide an RFC if they feel there is a better approach, is more than 
welcome, and I *promise* I'll give such submissions first priority -- at 
which point I suggest making sure I am in the "To:" list of the patch 
submission mails.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Ilya Yanok]

Hi Albert,

On 28.11.2011 16:56, Albert ARIBAUD wrote:
>> Yes, that would be the 4th approach, listed as "much better" :-)
> 
> Better yet, have an ARM-wide, not only ARM926EJ-S, cache framework with
> a hierarchy of cache function implementations, from ARM architectures to
> Cores / SoCs or even boards.

Surely, that will be much-much better. Actually I think there is some
room for even more unification:
 - alignment checks are need for (almost?) any arch
 - many ARM families share the same (or very similar) CP15 register set
 - ???

Unfortunately, I don't have enough time right now to dig into this.

Regards, Ilya.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Christian Riesch]

Hi,

On Sun, Nov 27, 2011 at 5:41 PM, Tom Rini <tom.rini@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 8:09 AM, Wolfgang Denk <wd@denx.de> wrote:
>> In message <1321048618-20616-1-git-send-email-yanok@emcraft.com> you wrote:
>>> DaVinci EMAC driver has no support for running with D-Cache enabled so
>>> disable D-Cache on all DaVinci boards with EMAC device.
>>>
>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>>> ---
>>>
>>> I can't test it on any DaVinci boards right now but my understanding
>>> is that currently EMAC driver can't work properly with D-Cache enabled.

[...]

>> Why do we have to permanently disable the data cache just because the
>> network driver is broken? ?USB is also broken, and probably other
>> drivers as well.
>
> To be clear, the problem is that today the driver is broken (not cache
> safe) and this series of patches fixes that problem. ?In doing so we
> expose that arm926ejs doesn't have complete cache support today.

What do you mean by "broken"? Is it "never working" or is it "working
sometimes" or "not working under specific conditions"? I have a DA850
based board and I use the Davinci EMAC driver (CONFIG_DRIVER_TI_EMAC).
I don't have these CONFIG_SYS_xCACHE_OFF defines in my board config
file so I guess D-Cache is enabled. But Ethernet works fine, so what
am I missing here? Is D-Cache disabled somewhere else?

Regards, Christian

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Tom Rini]

On Mon, Nov 28, 2011 at 5:06 AM, Christian Riesch
<christian.riesch@omicron.at> wrote:
> Hi,
>
> On Sun, Nov 27, 2011 at 5:41 PM, Tom Rini <tom.rini@gmail.com> wrote:
>> On Sun, Nov 27, 2011 at 8:09 AM, Wolfgang Denk <wd@denx.de> wrote:
>>> In message <1321048618-20616-1-git-send-email-yanok@emcraft.com> you wrote:
>>>> DaVinci EMAC driver has no support for running with D-Cache enabled so
>>>> disable D-Cache on all DaVinci boards with EMAC device.
>>>>
>>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>>>> ---
>>>>
>>>> I can't test it on any DaVinci boards right now but my understanding
>>>> is that currently EMAC driver can't work properly with D-Cache enabled.
>
> [...]
>
>>> Why do we have to permanently disable the data cache just because the
>>> network driver is broken? ?USB is also broken, and probably other
>>> drivers as well.
>>
>> To be clear, the problem is that today the driver is broken (not cache
>> safe) and this series of patches fixes that problem. ?In doing so we
>> expose that arm926ejs doesn't have complete cache support today.
>
> What do you mean by "broken"? Is it "never working" or is it "working
> sometimes" or "not working under specific conditions"? I have a DA850
> based board and I use the Davinci EMAC driver (CONFIG_DRIVER_TI_EMAC).
> I don't have these CONFIG_SYS_xCACHE_OFF defines in my board config
> file so I guess D-Cache is enabled. But Ethernet works fine, so what
> am I missing here? Is D-Cache disabled somewhere else?

Today, right now?  I tried a dm365evm back in August on top-of-tree
and emac didn't work until I disabled caches.  I don't have day-to-day
access to that board however to confirm the current state.

-- 
Tom

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Christian Riesch]

Hi Tom,

On Mon, Nov 28, 2011 at 3:53 PM, Tom Rini <tom.rini@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 5:06 AM, Christian Riesch
> <christian.riesch@omicron.at> wrote:
>> On Sun, Nov 27, 2011 at 5:41 PM, Tom Rini <tom.rini@gmail.com> wrote:
>>> On Sun, Nov 27, 2011 at 8:09 AM, Wolfgang Denk <wd@denx.de> wrote:
>>>> In message <1321048618-20616-1-git-send-email-yanok@emcraft.com> you wrote:
>>>>> DaVinci EMAC driver has no support for running with D-Cache enabled so
>>>>> disable D-Cache on all DaVinci boards with EMAC device.
>>>>>
>>>>> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
>>>>> ---
>>>>>
>>>>> I can't test it on any DaVinci boards right now but my understanding
>>>>> is that currently EMAC driver can't work properly with D-Cache enabled.
>>
>> [...]
>>
>>>> Why do we have to permanently disable the data cache just because the
>>>> network driver is broken? ?USB is also broken, and probably other
>>>> drivers as well.
>>>
>>> To be clear, the problem is that today the driver is broken (not cache
>>> safe) and this series of patches fixes that problem. ?In doing so we
>>> expose that arm926ejs doesn't have complete cache support today.
>>
>> What do you mean by "broken"? Is it "never working" or is it "working
>> sometimes" or "not working under specific conditions"? I have a DA850
>> based board and I use the Davinci EMAC driver (CONFIG_DRIVER_TI_EMAC).
>> I don't have these CONFIG_SYS_xCACHE_OFF defines in my board config
>> file so I guess D-Cache is enabled. But Ethernet works fine, so what
>> am I missing here? Is D-Cache disabled somewhere else?
>
> Today, right now? ?I tried a dm365evm back in August on top-of-tree
> and emac didn't work until I disabled caches. ?I don't have day-to-day
> access to that board however to confirm the current state.

Yes, right now.

I did a test now with the da850evm with the current u-boot, commit
99258c34103efad3395c679256a221731d010c4b, and my recent patchset [1]
applied (all my tools currently expect this patchset, so it was easier
for me, but my patchset does not touch the emac driver).

I did a
make mrproper
make da850evm_config
make -s u-boot.ais

flashed the u-boot.ais to SPI flash and successfully tested the
Ethernet connection by loading a kernel image via tftpboot.

Then I commented out the lines
#define CONFIG_SYS_ICACHE_OFF
#define CONFIG_SYS_DCACHE_OFF
#define CONFIG_SYS_L2CACHE_OFF
re-built u-boot and tried the same, the Ethernet connection still
worked and I could still load the kernel image.

So what am I missing here?
Regards, Christian

[1] http://lists.denx.de/pipermail/u-boot/2011-November/111182.html

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Christian Riesch,

In message <CABkLOboon_r_xwZOriHBhnNRM4+jFYKVKqDVToih6CvCKxs0zA@mail.gmail.com> you wrote:
...
> Then I commented out the lines
> #define CONFIG_SYS_ICACHE_OFF
> #define CONFIG_SYS_DCACHE_OFF
> #define CONFIG_SYS_L2CACHE_OFF
> re-built u-boot and tried the same, the Ethernet connection still
> worked and I could still load the kernel image.

What does the "dc" command print in your configuration?

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
Bus error -- please leave by the rear door.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Christian Riesch]

Wolfgang,

On Mon, Nov 28, 2011 at 4:59 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Christian Riesch,
>
> In message <CABkLOboon_r_xwZOriHBhnNRM4+jFYKVKqDVToih6CvCKxs0zA@mail.gmail.com> you wrote:
> ...
>> Then I commented out the lines
>> #define CONFIG_SYS_ICACHE_OFF
>> #define CONFIG_SYS_DCACHE_OFF
>> #define CONFIG_SYS_L2CACHE_OFF
>> re-built u-boot and tried the same, the Ethernet connection still
>> worked and I could still load the kernel image.
>
> What does the "dc" command print in your configuration?

U-Boot > dc
Unknown command 'dc' - try 'help'

;-)

After rebuilding with #define CONFIG_CMD_CACHE I get

U-Boot > dc
Data writethrough) Cache is OFF

no matter whether the #define CONFIG_SYS_xxCACHE_OFF lines are in the
config file or not.

If the CONFIG_SYS_xxxCACHE_OFF lines are commented out, I can enable
d-cache with the dcache on command and then Ethernet access fails,
e.g., ping runs into timeout.

U-Boot > ping 10.0.0.5
Using DaVinci-EMAC device
host 10.0.0.5 is alive
U-Boot > dcache on
Data (writethrough) Cache is ON
U-Boot > ping 10.0.0.5
Using DaVinci-EMAC device
ping failed; host 10.0.0.5 is not alive

Regards, Christian

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Ilya Yanok]

Hi Christian,

On 28.11.2011 19:43, Christian Riesch wrote:
>>> What do you mean by "broken"? Is it "never working" or is it "working
>>> sometimes" or "not working under specific conditions"? I have a DA850
>>> based board and I use the Davinci EMAC driver (CONFIG_DRIVER_TI_EMAC).
>>> I don't have these CONFIG_SYS_xCACHE_OFF defines in my board config
>>> file so I guess D-Cache is enabled. But Ethernet works fine, so what
>>> am I missing here? Is D-Cache disabled somewhere else?
>>
>> Today, right now?  I tried a dm365evm back in August on top-of-tree
>> and emac didn't work until I disabled caches.  I don't have day-to-day
>> access to that board however to confirm the current state.
> 
> Yes, right now.

I think it's because of:

commit cba4b1809f043bf85c806e5a4e342f62bd5ded45
Author: Aneesh V <aneesh@ti.com>
Date:   Tue Aug 16 04:33:05 2011 +0000

    arm: do not force d-cache enable on all boards

    c2dd0d45540397704de9b13287417d21049d34c6 added dcache_enable()
    to board_init_r(). This enables d-cache for all ARM boards.
    As a result some of the arm boards that are not cache-ready
    are broken. Revert this change and allow platform code to
    take the decision on d-cache enabling.

    Also add some documentation for cache usage in ARM.

    Signed-off-by: Aneesh V <aneesh@ti.com>

Don't you see "WARNING: Caches not enabled" message during boot?

2Wolfgang: So caches are actually disabled on everything except OMAP...

Regards, Ilya.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Wolfgang Denk]

Dear Ilya Yanok,

In message <4ED3B09A.7060101@emcraft.com> you wrote:
> 
> Don't you see "WARNING: Caches not enabled" message during boot?
> 
> 2Wolfgang: So caches are actually disabled on everything except OMAP...

I see.  What a chaos.

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
People with narrow minds usually have broad tongues.

[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Christian Riesch]

Hi Ilya,

On Mon, Nov 28, 2011 at 5:02 PM, Ilya Yanok <yanok@emcraft.com> wrote:
> Hi Christian,
>
> On 28.11.2011 19:43, Christian Riesch wrote:
>>>> What do you mean by "broken"? Is it "never working" or is it "working
>>>> sometimes" or "not working under specific conditions"? I have a DA850
>>>> based board and I use the Davinci EMAC driver (CONFIG_DRIVER_TI_EMAC).
>>>> I don't have these CONFIG_SYS_xCACHE_OFF defines in my board config
>>>> file so I guess D-Cache is enabled. But Ethernet works fine, so what
>>>> am I missing here? Is D-Cache disabled somewhere else?
>>>
>>> Today, right now? ?I tried a dm365evm back in August on top-of-tree
>>> and emac didn't work until I disabled caches. ?I don't have day-to-day
>>> access to that board however to confirm the current state.
>>
>> Yes, right now.
>
> I think it's because of:
>
> commit cba4b1809f043bf85c806e5a4e342f62bd5ded45
> Author: Aneesh V <aneesh@ti.com>
> Date: ? Tue Aug 16 04:33:05 2011 +0000
>
> ? ?arm: do not force d-cache enable on all boards
>
> ? ?c2dd0d45540397704de9b13287417d21049d34c6 added dcache_enable()
> ? ?to board_init_r(). This enables d-cache for all ARM boards.
> ? ?As a result some of the arm boards that are not cache-ready
> ? ?are broken. Revert this change and allow platform code to
> ? ?take the decision on d-cache enabling.
>
> ? ?Also add some documentation for cache usage in ARM.
>
> ? ?Signed-off-by: Aneesh V <aneesh@ti.com>
>
> Don't you see "WARNING: Caches not enabled" message during boot?
>

Ah, yes, I see this warning, no matter whether the
CONFIG_SYS_xCACHE_OFF defines are in the config file or not.
Regards, Christian

> 2Wolfgang: So caches are actually disabled on everything except OMAP...
>
> Regards, Ilya.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot