diff mbox

[U-Boot,1/2] integratorap: disable dcache

Message ID 1310598267-9711-1-git-send-email-linus.walleij@linaro.org
State Changes Requested
Headers show

Commit Message

Linus Walleij July 13, 2011, 11:04 p.m. UTC
The Integrator AP with CM920T (ARM920T) does not boot without
D-cache disabled throughout, the actual problem comes at "bootm",
at this point U-Boot tries to disable D-cache which doesn't work
on this machine for some reason. The result is usually an
illegal instruction trap or similar as the PC goes astray in
memory and crash something like this:

 undefined instruction
 pc : [<01ff1c44>]          lr : [<01fd8430>]
 sp : 01fa7e08  ip : 01fa7dc0     fp : 00000000
 r10: 01fef318  r9 : 00000015     r8 : 01fa7f70
 r7 : 00000015  r6 : 00008000     r5 : 01fa7fe8  r4 : 00000000
 r3 : 01fef380  r2 : 01fef8b0     r1 : ffffffff  r0 : fffffffe
 Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
 Resetting CPU ...

Disabling D-cache brings the board support to a working state that
can boot the Linux kernel.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 include/configs/integratorap.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Comments

Wolfgang Denk July 14, 2011, 11:39 a.m. UTC | #1
Dear Linus Walleij,

In message <1310598267-9711-1-git-send-email-linus.walleij@linaro.org> you wrote:
> The Integrator AP with CM920T (ARM920T) does not boot without
> D-cache disabled throughout, the actual problem comes at "bootm",
> at this point U-Boot tries to disable D-cache which doesn't work
> on this machine for some reason. The result is usually an
> illegal instruction trap or similar as the PC goes astray in
> memory and crash something like this:
> 
>  undefined instruction
>  pc : [<01ff1c44>]          lr : [<01fd8430>]
>  sp : 01fa7e08  ip : 01fa7dc0     fp : 00000000
>  r10: 01fef318  r9 : 00000015     r8 : 01fa7f70
>  r7 : 00000015  r6 : 00008000     r5 : 01fa7fe8  r4 : 00000000
>  r3 : 01fef380  r2 : 01fef8b0     r1 : ffffffff  r0 : fffffffe
>  Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
>  Resetting CPU ...
> 
> Disabling D-cache brings the board support to a working state that
> can boot the Linux kernel.
> 
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  include/configs/integratorap.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Sorry, but again I have to point out that I really dislike papering
over existing bugs.  If the disable D-cache in bootm does not work,
_this_ should be analyzed and fixed instead of globally disabling he
data cache.

NAK.

Best regards,

Wolfgang Denk
Linus Walleij July 14, 2011, 5:57 p.m. UTC | #2
On Thu, Jul 14, 2011 at 1:39 PM, Wolfgang Denk <wd@denx.de> wrote:

> Sorry, but again I have to point out that I really dislike papering
> over existing bugs.  If the disable D-cache in bootm does not work,
> _this_ should be analyzed and fixed instead of globally disabling he
> data cache.

No problem, I didn't label it as RFC since what it does is actually fix a
regression.

At one point U-boot was working on the Integrator and now
it doesn't, it seems commit 880eff5cfb9df6f0855f4e48affd349ca64692e9
"ARM: cp15: setup mmu and enable dcache" is causing it.

Heiko, Alessandro, do you have any hints on how to go about flushing
and disabling the D-cache in bootm for ARM920T? It doesn't seem to
work on this ARM CPU chip in its current form...

Yours,
Linus Walleij
Heiko Schocher July 15, 2011, 7:42 a.m. UTC | #3
Hello Linus,

Linus Walleij wrote:
> On Thu, Jul 14, 2011 at 1:39 PM, Wolfgang Denk <wd@denx.de> wrote:
> 
>> Sorry, but again I have to point out that I really dislike papering
>> over existing bugs.  If the disable D-cache in bootm does not work,
>> _this_ should be analyzed and fixed instead of globally disabling he
>> data cache.
> 
> No problem, I didn't label it as RFC since what it does is actually fix a
> regression.
> 
> At one point U-boot was working on the Integrator and now
> it doesn't, it seems commit 880eff5cfb9df6f0855f4e48affd349ca64692e9
> "ARM: cp15: setup mmu and enable dcache" is causing it.
> 
> Heiko, Alessandro, do you have any hints on how to go about flushing
> and disabling the D-cache in bootm for ARM920T? It doesn't seem to
> work on this ARM CPU chip in its current form...

Hmm.. trying bootm with actual u-boot on a davinci (arm926ejs) based
board, there I couldn;t use the Davinci-EMAC (if I disable the dcache
it works ...)

Seems above commit introduced problems for other arm architectures,
drivers, ...

Hmm... if we globally always enable the dcache, we have a lot of more
drivers to fix (I think) ...

bye,
Heiko
Laurence Withers July 15, 2011, 8:54 a.m. UTC | #4
On Fri, Jul 15, 2011 at 09:42:53AM +0200, Heiko Schocher wrote:
> Hmm.. trying bootm with actual u-boot on a davinci (arm926ejs) based
> board, there I couldn;t use the Davinci-EMAC (if I disable the dcache
> it works ...)

I can confirm there are some cache coherency problems with the DaVinci EMAC
driver. I've done a port to a new board based on the DA850 and had problems
with corrupt Ethernet packets until I disabled the dcache altogether. The
clue was the packets started working when I added a hex dump just before
eth_send()!

While I haven't come across any explicit documentation I presume the EMAC
controller's independent DMA engine is simply not aware of the ARM's cache.

I haven't yet identified whether there's some mechanism already in U-Boot for
marking particular bits of memory as uncacheable, which would seem to be the
correct approach, but turning of dcache doesn't really have any side effects
that cause problems for me.

Bye for now,
Stefan Roese July 15, 2011, 9:31 a.m. UTC | #5
Hi Laurence,

On Friday 15 July 2011 10:54:41 Laurence Withers wrote:
> On Fri, Jul 15, 2011 at 09:42:53AM +0200, Heiko Schocher wrote:
> > Hmm.. trying bootm with actual u-boot on a davinci (arm926ejs) based
> > board, there I couldn;t use the Davinci-EMAC (if I disable the dcache
> > it works ...)
> 
> I can confirm there are some cache coherency problems with the DaVinci EMAC
> driver. I've done a port to a new board based on the DA850 and had problems
> with corrupt Ethernet packets until I disabled the dcache altogether. The
> clue was the packets started working when I added a hex dump just before
> eth_send()!
> 
> While I haven't come across any explicit documentation I presume the EMAC
> controller's independent DMA engine is simply not aware of the ARM's cache.

Yes.

> I haven't yet identified whether there's some mechanism already in U-Boot
> for marking particular bits of memory as uncacheable, which would seem to
> be the correct approach, but turning of dcache doesn't really have any
> side effects that cause problems for me.

The "side effect" is a slow down on boot time. And it should be avoided if 
possible.

We have stumbled over this d-cache "problem" on powerpc a while ago. I suggest 
you take a look at the EHCI driver for example (drivers/usb/host/ehci-hcd.c). 
Please search for CONFIG_EHCI_DCACHE). We implemented the following functions 
on powerpc for d-cache handling:

- flush_dcache_range()
- invalidate_dcache_range()

The API was taken from Linux at that time. Now I notice that unfortunately 
this API seems to be powerpc specific in Linux. IMHO it would make sense to 
either implement this API for all other platforms using dcache with DMA 
engines (e.g. USB), or introduce another cache/flush/invalidate API and move 
powerpc to it as well.

Best regards,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
Linus Walleij July 15, 2011, 9:36 a.m. UTC | #6
On Fri, Jul 15, 2011 at 9:42 AM, Heiko Schocher <hs@denx.de> wrote:

>> Heiko, Alessandro, do you have any hints on how to go about flushing
>> and disabling the D-cache in bootm for ARM920T? It doesn't seem to
>> work on this ARM CPU chip in its current form...
>
> Hmm.. trying bootm with actual u-boot on a davinci (arm926ejs) based
> board, there I couldn;t use the Davinci-EMAC (if I disable the dcache
> it works ...)

I take it that due to the above you cannot even get so far as to testing
"bootm" on that platform with recent kernels?

If you upload the kernel with say "loady" over serial (this is what
I have to use on this board that has no ethernet) then does the "bootm"
command work?

Thanks,
Linus Walleij
diff mbox

Patch

diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h
index 26eac8b..acdb37c 100644
--- a/include/configs/integratorap.h
+++ b/include/configs/integratorap.h
@@ -48,6 +48,7 @@ 
 #define CONFIG_CM_INIT		1
 #define CONFIG_CM_REMAP		1
 #undef CONFIG_CM_SPD_DETECT
+#define CONFIG_SYS_DCACHE_OFF
 
 /*
  * Size of malloc() pool