public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH RESEND v2] armv7: Disable D cache for goni target (s5p)
Date: Mon, 01 Aug 2011 11:50:12 +0530	[thread overview]
Message-ID: <4E36459C.9010708@ti.com> (raw)
In-Reply-To: <CACRpkdaq8E586bPXahnpHW8xqYYZ7L2X_Vgx4x=x1w0in+mAkA@mail.gmail.com>

Hi Linus,

On Sunday 31 July 2011 01:48 PM, Linus Walleij wrote:
> Hi Aneesh, thanks for taking time for this!
>
> On Fri, Jul 29, 2011 at 12:13 PM, Aneesh V<aneesh@ti.com>  wrote:
>
>> 1. Drivers using DMA:
>> i. Flush the buffer before initiating a memory to peripheral DMA.
>> ii. Invalidate the buffer after a peripheral to memory DMA (before
>> MPU reads it)
>
> No problems with this. I only use the serial port and it's working
> flawlessly downloading a uImage to target with caches enabled.
>
>> 2. Cleanup before Linux:
>> Flush the entire SDRAM and disable the cache.
>>
>> I think you are hit by not doing 2 properly. If you have dirty entries
>> in the cache when Linux boots you will have coherency issues. I had
>> faced similar issues when I had some issues in armv7
>> cleanup_before_linux(). I had to do an extra invalidate to solve it.
>> Please see how this has been done for armv7 in arch/arm/cpu/armv7/cpu.c
>> in function cleanup_before_linux().
>
> Yes, this is the problem. The problem is further that I've tried
> several variants of code and of course following the ARM920T manual
> on how to do this.
>
> Actually I think the problem is really not with the cache *at all* but
> with the MMU. The current ARM CP15 MMU code sets up an
> identity mapping and it is always turned on/off in conjunction with
> the cache.
>
> The moste pedantic and careful code I have does this:
>
> +#ifdef CONFIG_ARM920T
> +       /* Flush all cache */
> +       debug("FLUSH I-cache\n");
> +       asm volatile("mcr p15, 0, %0, c7, c5, 0" : : "r" (0));
> +       isb();
> +       debug("FLUSH D-cache\n");
> +       asm volatile("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
> +       isb();
> +       debug("FLUSH all cache\n");
> +       asm volatile("mcr p15, 0, %0, c7, c7, 0" : : "r" (0));
> +       isb();
> +       /* Flush I+D TLB */
> +       debug("FLUSH I+D TLB\n");
> +       asm volatile("mcr p15, 0, %0, c8, c7, 0" : : "r" (0));
> +       isb();
> +       /* Drain write buffer */
> +       debug("Drain write buffer\n");
> +       asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
> +       isb();
> +#endif
>
> This is called in arch/arm/lib/cache.c generic CP15 code as it
> calls __flush_cache before it turns off the MMU.
>
> At this point the program counter goes astray and the machine
> hangs :-(

Is it hanging when you return from the function? What is the order in
which you are disabling the cache, flushing it etc. This order is
important. I had faced some issues initially when I developed the code
for armv7. Please see a discussion about those issues in this thread:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/91332/focus=91965

>
> It's something like removing the identity map is not good for the
> CPU, it gets lost. I think. (Working hopothesis.)

I am not sure if identity mapping is the issue for you. At least, it's
not causing any trouble on armv7.

PC going astray may be due to restoring wrong r14, which in turn, could
be due to a cache-coherency problem.

best regards,
Aneesh

  reply	other threads:[~2011-08-01  6:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18  7:23 [U-Boot] [PATCH RESEND v2] armv7: Disable D cache for goni target (s5p) Lukasz Majewski
2011-07-18 10:35 ` Linus Walleij
2011-07-28  5:04   ` Minkyu Kang
2011-07-28 22:34     ` Linus Walleij
2011-07-29 10:13       ` Aneesh V
2011-07-29 10:31         ` Chander Kashyap
2011-07-29 10:53           ` Aneesh V
2011-07-31  8:18         ` Linus Walleij
2011-08-01  6:20           ` Aneesh V [this message]
2011-07-29  2:56     ` Chander Kashyap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E36459C.9010708@ti.com \
    --to=aneesh@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox