[U-Boot] [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org --- include/configs/palmld.h | 3 +++ include/configs/palmtc.h | 3 +++ include/configs/zipitz2.h | 3 +++ 3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/configs/palmld.h b/include/configs/palmld.h index c5dd494..3f9802c 100644 --- a/include/configs/palmld.h +++ b/include/configs/palmld.h @@ -28,6 +28,9 @@ #define CONFIG_CPU_PXA27X 1 /* Marvell PXA270 CPU */ #define CONFIG_PALMLD 1 /* Palm LifeDrive board */
+/* we will never enable dcache, because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF + /* * Environment settings */ diff --git a/include/configs/palmtc.h b/include/configs/palmtc.h index 9c948c5..64771e7 100644 --- a/include/configs/palmtc.h +++ b/include/configs/palmtc.h @@ -30,6 +30,9 @@ #define CONFIG_CPU_PXA25X 1 /* Intel PXA255 CPU */ #define CONFIG_PALMTC 1 /* Palm Tungsten|C board */
+/* we will never enable dcache, because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF + /* * Environment settings */ diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h index bf6394a..b92f70b 100644 --- a/include/configs/zipitz2.h +++ b/include/configs/zipitz2.h @@ -41,6 +41,9 @@ #define CONFIG_ENV_ADDR 0x40000 #define CONFIG_ENV_SIZE 0x20000
+/* we will never enable dcache, because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF + #define CONFIG_SYS_MALLOC_LEN (128*1024) #define CONFIG_ARCH_CPU_INIT
Dear Simon Glass,
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org
Is that needed? Why not fix PXA by defining stub cache routines ?
include/configs/palmld.h | 3 +++ include/configs/palmtc.h | 3 +++ include/configs/zipitz2.h | 3 +++ 3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/configs/palmld.h b/include/configs/palmld.h index c5dd494..3f9802c 100644 --- a/include/configs/palmld.h +++ b/include/configs/palmld.h @@ -28,6 +28,9 @@ #define CONFIG_CPU_PXA27X 1 /* Marvell PXA270 CPU */ #define CONFIG_PALMLD 1 /* Palm LifeDrive board */
+/* we will never enable dcache, because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF
/*
- Environment settings
*/ diff --git a/include/configs/palmtc.h b/include/configs/palmtc.h index 9c948c5..64771e7 100644 --- a/include/configs/palmtc.h +++ b/include/configs/palmtc.h @@ -30,6 +30,9 @@ #define CONFIG_CPU_PXA25X 1 /* Intel PXA255
CPU */
#define CONFIG_PALMTC 1 /* Palm Tungsten|C board
*/
+/* we will never enable dcache, because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF
/*
- Environment settings
*/ diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h index bf6394a..b92f70b 100644 --- a/include/configs/zipitz2.h +++ b/include/configs/zipitz2.h @@ -41,6 +41,9 @@ #define CONFIG_ENV_ADDR 0x40000 #define CONFIG_ENV_SIZE 0x20000
+/* we will never enable dcache, because we have to setup MMU first */ +#define CONFIG_SYS_DCACHE_OFF
#define CONFIG_SYS_MALLOC_LEN (128*1024) #define CONFIG_ARCH_CPU_INIT
Best regards, Marek Vasut
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/31/12 04:55, Marek Vasut wrote:
Dear Simon Glass,
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
- -- Tom
Dear Tom Rini,
On 10/31/12 04:55, Marek Vasut wrote:
Dear Simon Glass,
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.
I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.
Best regards, Marek Vasut
Marek,
-----Original Message----- From: Marek Vasut [mailto:marex@denx.de] Sent: Wednesday, October 31, 2012 9:41 AM To: Tom Rini Cc: Simon Glass; U-Boot Mailing List; Tom Warren Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Dear Tom Rini,
On 10/31/12 04:55, Marek Vasut wrote:
Dear Simon Glass,
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.
I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.
You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.
If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.
Tom
Best regards, Marek Vasut
Hi,
On Wed, Oct 31, 2012 at 9:52 AM, Tom Warren TWarren@nvidia.com wrote:
Marek,
-----Original Message----- From: Marek Vasut [mailto:marex@denx.de] Sent: Wednesday, October 31, 2012 9:41 AM To: Tom Rini Cc: Simon Glass; U-Boot Mailing List; Tom Warren Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Dear Tom Rini,
On 10/31/12 04:55, Marek Vasut wrote:
Dear Simon Glass,
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.
I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.
You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.
If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.
Is that the final word? If so, Tom Warren should be able to pull this through. If not, Marek are you going to send a patch to replace this patch? If that is coming soon, I suggest we wait a few days. If not, then we can perhaps take this patch and then Marek can clean up later.
Regards, Simon
Tom
Best regards, Marek Vasut
-- nvpublic
Dear Simon Glass,
Hi,
On Wed, Oct 31, 2012 at 9:52 AM, Tom Warren TWarren@nvidia.com wrote:
Marek,
-----Original Message----- From: Marek Vasut [mailto:marex@denx.de] Sent: Wednesday, October 31, 2012 9:41 AM To: Tom Rini Cc: Simon Glass; U-Boot Mailing List; Tom Warren Subject: Re: [PATCH] pxa: Disable dcache on palmld, palmtc, zipitz2
Dear Tom Rini,
On 10/31/12 04:55, Marek Vasut wrote:
Dear Simon Glass,
These platforms don't include dcache support. Define CONFIG_SYS_DCACHE_OFF so that functions don't try to call non-existent routines like flush_dcache_range().
Signed-off-by: Simon Glass sjg@chromium.org
Is that needed? Why not fix PXA by defining stub cache routines ?
Adding stubs sounds more like a work-around than disabling support that we won't have to me.
Yes, but then, the stubs will be optimized out.
I see using CONFIG_SYS_DCACHE_OFF being abused here. Every platform should implement at least cache operations stubs, then it'd be valid to use CONFIG_SYS_DCACHE_OFF to indicate the cache shall always be off. But the code would at least compile and work with CONFIG_SYS_DCACHE_OFF enabled or disabled.
We might eventually even be able to weed out this CONFIG_SYS_DCACHE_OFF option.
You are the PXA custodian, according to the wiki. Simon's fix is to get the PXA boards that use LCD to compile OK with the Tegra LCD cache flush changes that he implemented. I think it contains the appropriate change to get those builds working, which is all he's obligated to do.
If you want stubs written for those boards, why don't you do it, since it affects the boards you are responsible for? It seems to me that it's more in your bailiwick than Simon's - as you state, every platform should implement cache stubs, and these are your platforms.
Is that the final word? If so, Tom Warren should be able to pull this through. If not, Marek are you going to send a patch to replace this patch? If that is coming soon, I suggest we wait a few days. If not, then we can perhaps take this patch and then Marek can clean up later.
Just apply this. PXA is mostly dead anyway.
Best regards, Marek Vasut
participants (4)
-
Marek Vasut -
Simon Glass -
Tom Rini -
Tom Warren