[U-Boot] [PATCH 1/2] integratorap: disable dcache
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(-)
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
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
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
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
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,
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
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
participants (5)
-
Heiko Schocher -
Laurence Withers -
Linus Walleij -
Stefan Roese -
Wolfgang Denk