[PATCH] ARM: Implement cpu_v7_reset.

[PATCH] ARM: Implement cpu_v7_reset.

[Linus Walleij]

From: Per Fransson <per.xx.fransson@stericsson.com>

This implementation of cpu_v7_reset flushes the L1 cache
and turns off the MMU.

Signed-off-by: Per Fransson <per.xx.fransson@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
 arch/arm/mm/proc-v7.S |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index d5d9b58..f2e2c92 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -63,7 +63,18 @@ ENDPROC(cpu_v7_proc_fin)
  */
 	.align	5
 ENTRY(cpu_v7_reset)
-	mov	pc, r0
+	mov     r4, r0
+	mov     ip, #0
+	bl      v7_flush_kern_cache_all         @ invalidate I,D caches
+	dsb                                     @ drain WB
+#ifdef CONFIG_MMU
+	mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
+#endif
+	mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
+	bic     ip, ip, #0x000f                 @ ............wcam
+	bic     ip, ip, #0x1100                 @ ...i...s........
+	mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
+	mov     pc, r4
 ENDPROC(cpu_v7_reset)
 
 /*
-- 
1.6.3.3

[PATCH] ARM: Implement cpu_v7_reset.

[Stephen Boyd]

On 09/01/2010 07:01 AM, Linus Walleij wrote:
> From: Per Fransson <per.xx.fransson@stericsson.com>
> 
> This implementation of cpu_v7_reset flushes the L1 cache
> and turns off the MMU.
> 
> Signed-off-by: Per Fransson <per.xx.fransson@stericsson.com>
> Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
> ---

Is this needed to make kexec work on v7? It would be nice if something
like that was noted in the commit message besides what the patch is doing.

> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index d5d9b58..f2e2c92 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -63,7 +63,18 @@ ENDPROC(cpu_v7_proc_fin)
>   */
>  	.align	5
>  ENTRY(cpu_v7_reset)
> -	mov	pc, r0
> +	mov     r4, r0
> +	mov     ip, #0
> +	bl      v7_flush_kern_cache_all         @ invalidate I,D caches
> +	dsb                                     @ drain WB

Is this necessary considering that machine_kexec.c calls
flush_cache_all() right before calling cpu_reset()?

> +#ifdef CONFIG_MMU
> +	mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
> +#endif
> +	mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
> +	bic     ip, ip, #0x000f                 @ ............wcam
> +	bic     ip, ip, #0x1100                 @ ...i...s........
> +	mcr     p15, 0, ip, c1, c0, 0           @ ctrl register

On a related note, I was always a bit confused since proc-v6 and proc-v7
don't turn off the MMU in their cpu_reset functions, which doesn't seem
correct with respect to Documentation/arm/Booting. Is it necessary to
turn off the MMU when kexec'ing the kernel? Last time I tried kexec'ing
on a v6 it worked fine without turning off the MMU.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH] ARM: Implement cpu_v7_reset.

[Russell King - ARM Linux]

On Wed, Sep 01, 2010 at 04:01:59PM +0200, Linus Walleij wrote:
> From: Per Fransson <per.xx.fransson@stericsson.com>
> 
> This implementation of cpu_v7_reset flushes the L1 cache
> and turns off the MMU.

NAK - this is wrong.  Please check the updates I made to the shutdown code
(which already deal with the cache flushing and turning off cacheability.)

The only thing this should be doing is turning off the MMU and jumping to
the provided pointer.

[PATCH] ARM: Implement cpu_v7_reset.

[Uwe Kleine-König]

Hello,

> > +#ifdef CONFIG_MMU
> > +	mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
> > +#endif
> > +	mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
> > +	bic     ip, ip, #0x000f                 @ ............wcam
> > +	bic     ip, ip, #0x1100                 @ ...i...s........
> > +	mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
> 
> On a related note, I was always a bit confused since proc-v6 and proc-v7
> don't turn off the MMU in their cpu_reset functions, which doesn't seem
> correct with respect to Documentation/arm/Booting. Is it necessary to
> turn off the MMU when kexec'ing the kernel? Last time I tried kexec'ing
> on a v6 it worked fine without turning off the MMU.
The boot process isn't that strict.  Having the MMU off is the safest,
but e.g. having an 1:1 mapping worked OK last time I checked.  But this
has to be considered to be by chance and it might not work with 2.6.37.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: Implement cpu_v7_reset.

[Mika Westerberg]

Hi,

On Thu, Sep 02, 2010 at 12:23:07AM +0100, Russell King - ARM Linux wrote:
> 
> The only thing this should be doing is turning off the MMU and jumping to
> the provided pointer.

I have one question related to this.

When the MMU is turned off, should we be running on 1:1 mappings?

For example on OMAP3430 (with latest mainline kernel + this patch)
kexec hangs just after "Bye!" message is displayed on console. It
works fine when cpu_v7_reset() is run via __pa(cpu_v7_reset).

Thanks,
MW

[PATCH] ARM: Implement cpu_v7_reset.

[Russell King - ARM Linux]

On Thu, Sep 02, 2010 at 11:34:23AM +0300, Mika Westerberg wrote:
> Hi,
> 
> On Thu, Sep 02, 2010 at 12:23:07AM +0100, Russell King - ARM Linux wrote:
> > 
> > The only thing this should be doing is turning off the MMU and jumping to
> > the provided pointer.
> 
> I have one question related to this.
> 
> When the MMU is turned off, should we be running on 1:1 mappings?

Mappings are setup, but not for this code.  This code relies upon the
instruction which jumps to already be in the pipeline at the point when
the MMU is turned off - and the destination for that jump to be a 1:1
mapping.

[PATCH] ARM: Implement cpu_v7_reset.

[Russell King - ARM Linux]

On Thu, Sep 02, 2010 at 07:03:49AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> > > +#ifdef CONFIG_MMU
> > > +	mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
> > > +#endif
> > > +	mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
> > > +	bic     ip, ip, #0x000f                 @ ............wcam
> > > +	bic     ip, ip, #0x1100                 @ ...i...s........
> > > +	mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
> > 
> > On a related note, I was always a bit confused since proc-v6 and proc-v7
> > don't turn off the MMU in their cpu_reset functions, which doesn't seem
> > correct with respect to Documentation/arm/Booting. Is it necessary to
> > turn off the MMU when kexec'ing the kernel? Last time I tried kexec'ing
> > on a v6 it worked fine without turning off the MMU.
> The boot process isn't that strict.

Wrong.  The boot process _is_ that strict.  If the MMU is left on, you
need to have page tables present, and ensure that these aren't overwritten.
We make no guarantees on that, and there's no way to tell the following
kernel not to touch that area.

The only thing that's guaranteed is to turn the MMU off, as per the boot
process.

What just happens to work does not mean that "it's not that strict".

[PATCH] ARM: Implement cpu_v7_reset.

[Mika Westerberg]

On Thu, Sep 02, 2010 at 09:41:01AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 02, 2010 at 11:34:23AM +0300, Mika Westerberg wrote:
> > 
> > When the MMU is turned off, should we be running on 1:1 mappings?
> 
> Mappings are setup, but not for this code.  This code relies upon the
> instruction which jumps to already be in the pipeline at the point when
> the MMU is turned off - and the destination for that jump to be a 1:1
> mapping.

OK, thanks.

Any Idea what might cause the hang on OMAP3? Only way I was able
to get it working when MMU is disabled was to run cpu_v7_reset()
also via 1:1 mapping.

Thanks,
MW

[PATCH] ARM: Implement cpu_v7_reset.

[Russell King - ARM Linux]

On Thu, Sep 02, 2010 at 11:53:41AM +0300, Mika Westerberg wrote:
> On Thu, Sep 02, 2010 at 09:41:01AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 02, 2010 at 11:34:23AM +0300, Mika Westerberg wrote:
> > > 
> > > When the MMU is turned off, should we be running on 1:1 mappings?
> > 
> > Mappings are setup, but not for this code.  This code relies upon the
> > instruction which jumps to already be in the pipeline at the point when
> > the MMU is turned off - and the destination for that jump to be a 1:1
> > mapping.
> 
> OK, thanks.
> 
> Any Idea what might cause the hang on OMAP3? Only way I was able
> to get it working when MMU is disabled was to run cpu_v7_reset()
> also via 1:1 mapping.

Well, as the current v6 and v7 cpu_reset() code is broken, it's hardly
surprising that it doesn't work.  It needs to be something like this
(I haven't tested it yet.)

diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 22aac85..6b873f9 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -59,6 +59,16 @@ ENTRY(cpu_v6_proc_fin)
  */
 	.align	5
 ENTRY(cpu_v6_reset)
+	mov	ip, #0
+	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
+	mcr	p15, 0, ip, c7, c10, 4		@ drain WB
+#ifdef CONFIG_MMU
+	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I & D TLBs
+#endif
+	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
+	bic	ip, ip, #0x000f			@ ............wcam
+	bic	ip, ip, #0x1100			@ ...i...s........
+	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
 	mov	pc, r0
 
 /*
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 6a8506d..3542ee0 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -63,6 +63,16 @@ ENDPROC(cpu_v7_proc_fin)
  */
 	.align	5
 ENTRY(cpu_v7_reset)
+	mov	ip, #0
+	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
+	dsb
+#ifdef CONFIG_MMU
+	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I & D TLBs
+#endif
+	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
+	bic	ip, ip, #0x000f			@ ............wcam
+	bic	ip, ip, #0x1100			@ ...i...s........
+	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
 	mov	pc, r0
 ENDPROC(cpu_v7_reset)
 

[PATCH] ARM: Implement cpu_v7_reset.

[Mika Westerberg]

On Thu, Sep 02, 2010 at 11:39:57AM +0100, Russell King - ARM Linux wrote:
> 
> Well, as the current v6 and v7 cpu_reset() code is broken, it's hardly
> surprising that it doesn't work.  It needs to be something like this
> (I haven't tested it yet.)

Thanks.

> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 6a8506d..3542ee0 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -63,6 +63,16 @@ ENDPROC(cpu_v7_proc_fin)
>   */
>  	.align	5
>  ENTRY(cpu_v7_reset)
> +	mov	ip, #0
> +	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches

I guess this is not anymore supported in ARMv7, it causes undefined
instruction trap.

> +	dsb
> +#ifdef CONFIG_MMU
> +	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I & D TLBs
> +#endif
> +	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
> +	bic	ip, ip, #0x000f			@ ............wcam
> +	bic	ip, ip, #0x1100			@ ...i...s........
> +	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
>  	mov	pc, r0
>  ENDPROC(cpu_v7_reset)

I tested this patch without that cache invalidate instruction + dsb
and it still hangs. Exactly the same code works perfectly when it is run
via 1:1 mapping.

MW

[PATCH] ARM: Implement cpu_v7_reset.

[Russell King - ARM Linux]

On Thu, Sep 02, 2010 at 02:52:06PM +0300, Mika Westerberg wrote:
> On Thu, Sep 02, 2010 at 11:39:57AM +0100, Russell King - ARM Linux wrote:
> > 
> > Well, as the current v6 and v7 cpu_reset() code is broken, it's hardly
> > surprising that it doesn't work.  It needs to be something like this
> > (I haven't tested it yet.)
> 
> Thanks.
> 
> > diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> > index 6a8506d..3542ee0 100644
> > --- a/arch/arm/mm/proc-v7.S
> > +++ b/arch/arm/mm/proc-v7.S
> > @@ -63,6 +63,16 @@ ENDPROC(cpu_v7_proc_fin)
> >   */
> >  	.align	5
> >  ENTRY(cpu_v7_reset)
> > +	mov	ip, #0
> > +	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
> 
> I guess this is not anymore supported in ARMv7, it causes undefined
> instruction trap.
> 
> > +	dsb
> > +#ifdef CONFIG_MMU
> > +	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I & D TLBs
> > +#endif
> > +	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
> > +	bic	ip, ip, #0x000f			@ ............wcam
> > +	bic	ip, ip, #0x1100			@ ...i...s........
> > +	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
> >  	mov	pc, r0
> >  ENDPROC(cpu_v7_reset)
> 
> I tested this patch without that cache invalidate instruction + dsb
> and it still hangs. Exactly the same code works perfectly when it is run
> via 1:1 mapping.

Where are you ultimately jumping to?

[PATCH] ARM: Implement cpu_v7_reset.

[Per Fransson]

I tested the v7 version below and it works fine.

Regards,
Per

On 09/02/2010 12:39 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 02, 2010 at 11:53:41AM +0300, Mika Westerberg wrote:
>> On Thu, Sep 02, 2010 at 09:41:01AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Sep 02, 2010 at 11:34:23AM +0300, Mika Westerberg wrote:
>>>>
>>>> When the MMU is turned off, should we be running on 1:1 mappings?
>>>
>>> Mappings are setup, but not for this code.  This code relies upon the
>>> instruction which jumps to already be in the pipeline at the point when
>>> the MMU is turned off - and the destination for that jump to be a 1:1
>>> mapping.
>>
>> OK, thanks.
>>
>> Any Idea what might cause the hang on OMAP3? Only way I was able
>> to get it working when MMU is disabled was to run cpu_v7_reset()
>> also via 1:1 mapping.
>
> Well, as the current v6 and v7 cpu_reset() code is broken, it's hardly
> surprising that it doesn't work.  It needs to be something like this
> (I haven't tested it yet.)
>
> diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
> index 22aac85..6b873f9 100644
> --- a/arch/arm/mm/proc-v6.S
> +++ b/arch/arm/mm/proc-v6.S
> @@ -59,6 +59,16 @@ ENTRY(cpu_v6_proc_fin)
>    */
>   	.align	5
>   ENTRY(cpu_v6_reset)
> +	mov	ip, #0
> +	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
> +	mcr	p15, 0, ip, c7, c10, 4		@ drain WB
> +#ifdef CONFIG_MMU
> +	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I&  D TLBs
> +#endif
> +	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
> +	bic	ip, ip, #0x000f			@ ............wcam
> +	bic	ip, ip, #0x1100			@ ...i...s........
> +	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
>   	mov	pc, r0
>
>   /*
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 6a8506d..3542ee0 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -63,6 +63,16 @@ ENDPROC(cpu_v7_proc_fin)
>    */
>   	.align	5
>   ENTRY(cpu_v7_reset)
> +	mov	ip, #0
> +	mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches
> +	dsb
> +#ifdef CONFIG_MMU
> +	mcr	p15, 0, ip, c8, c7, 0		@ invalidate I&  D TLBs
> +#endif
> +	mrc	p15, 0, ip, c1, c0, 0		@ ctrl register
> +	bic	ip, ip, #0x000f			@ ............wcam
> +	bic	ip, ip, #0x1100			@ ...i...s........
> +	mcr	p15, 0, ip, c1, c0, 0		@ ctrl register
>   	mov	pc, r0
>   ENDPROC(cpu_v7_reset)
>
>
>

[PATCH] ARM: Implement cpu_v7_reset.

[Mika Westerberg]

On Thu, Sep 02, 2010 at 01:18:38PM +0100, Russell King - ARM Linux wrote:
> > 
> > I tested this patch without that cache invalidate instruction + dsb
> > and it still hangs. Exactly the same code works perfectly when it is run
> > via 1:1 mapping.
> 
> Where are you ultimately jumping to?

This is the normal kexec to a new kernel case so jump is to
relocate_new_kernel(), if that was what you meant.

MW

[PATCH] ARM: Implement cpu_v7_reset.

[Mika Westerberg]

On Thu, Sep 02, 2010 at 04:48:34PM +0300, Mika Westerberg wrote:
> On Thu, Sep 02, 2010 at 01:18:38PM +0100, Russell King - ARM Linux wrote:
> > > 
> > > I tested this patch without that cache invalidate instruction + dsb
> > > and it still hangs. Exactly the same code works perfectly when it is run
> > > via 1:1 mapping.
> > 
> > Where are you ultimately jumping to?
> 
> This is the normal kexec to a new kernel case so jump is to
> relocate_new_kernel(), if that was what you meant.

Hello,

I think I found something which might explain this weird behavior
on OMAP3s. If you look at ARM Cortex-A8 TRM (chapter 6.4 MMU
interaction with memory system):

	http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Cihfgdif.html

There is following paragraph:

        "After a CP15 c1 instruction disables the MMU, the processor
        flushes all following instructions in the pipeline. The
        processor then begins refetching instructions and uses flat
        address mapping. In flat address mapping, PA = VA."

They even provide a sample flow:

	MRC p15, 0, r1, c1, c0, 0    ; read CP15 Register 1
	BIC r1, r1, #0x1
	MCR p15, 0, r1, c1, c0, 0    ; disabled
	Fetch flat
	Fetch flat
	...

Does this make sense?

Regards,
MW

[PATCH] ARM: Implement cpu_v7_reset.

[Per Fransson]

Per Fransson <per.xx.fransson <at> stericsson.com> writes:

> 
> 
> I tested the v7 version below and it works fine.
> 
> Regards,
> Per
> 

Oh, no it doesn't, sorry. I must have got my kernel images mixed up. It chokes
on

mcr	p15, 0, ip, c7, c7, 0		@ invalidate I,D caches

/Per

[PATCH] ARM: Implement cpu_v7_reset.

[Per Fransson]

Mika Westerberg <mika.westerberg <at> iki.fi> writes:

> 
> On Thu, Sep 02, 2010 at 04:48:34PM +0300, Mika Westerberg wrote:
> > On Thu, Sep 02, 2010 at 01:18:38PM +0100, Russell King - ARM Linux wrote:
> > > > 
> > > > I tested this patch without that cache invalidate instruction + dsb
> > > > and it still hangs. Exactly the same code works perfectly when it is run
> > > > via 1:1 mapping.
> > > 

How do you run it via a 1-1 mapping? Do you call the physical address of
cpu_reset() from machine_kexec() after calling setup_mm_for_reboot()? I.e.

	outer_inv_all();
	setup_mm_for_reboot(0); /* mode is not used, so just pass 0*/
	(virt_to_phys(cpu_reset))(reboot_code_buffer_phys);

In that case, we're relying on two pieces of code being identity mapped,
cpu_v7_reset() and relocate_new_kernel(). I still promote limiting the scope of
setup_mm_for_reboot() to the bare minimum, so as not to destroy the user-space
mapping. If we set up a 1-1 around cpu_reset() for example, couldn't we idle
away there until we are sure the MMU is off and *then* jump to the physical
address of relocate_new_kernel() which wouldn't have to be 1-1 mapped?

>         "After a CP15 c1 instruction disables the MMU, the processor
>         flushes all following instructions in the pipeline. The
>         processor then begins refetching instructions and uses flat
>         address mapping. In flat address mapping, PA = VA."
> 

If this is the case, the Qemu issue I mentioned here

  http://lists.infradead.org/pipermail/linux-arm-kernel/2010-July/019678.html

wasn't so far off the mark after all =o)

Regards,
Per

[PATCH] ARM: Implement cpu_v7_reset.

[Mika Westerberg]

On Mon, Sep 06, 2010 at 08:58:25AM +0000, Per Fransson wrote:
> 
> How do you run it via a 1-1 mapping? Do you call the physical address of
> cpu_reset() from machine_kexec() after calling setup_mm_for_reboot()? I.e.
> 
> 	outer_inv_all();
> 	setup_mm_for_reboot(0); /* mode is not used, so just pass 0*/
> 	(virt_to_phys(cpu_reset))(reboot_code_buffer_phys);

Yeah, I had something like that first but then I decided to isolate
this into proc-v7.S see [1]. I've tested that code on OMAP3430,
OMAP3530 and OMAP3630 and it works there. Unfortunately I don't
have any other v7 hardware except those :(

> In that case, we're relying on two pieces of code being identity mapped,
> cpu_v7_reset() and relocate_new_kernel(). I still promote limiting the scope of
> setup_mm_for_reboot() to the bare minimum, so as not to destroy the user-space
> mapping. If we set up a 1-1 around cpu_reset() for example, couldn't we idle
> away there until we are sure the MMU is off and *then* jump to the physical
> address of relocate_new_kernel() which wouldn't have to be 1-1 mapped?

I agree with you. Now that I've been playing with this kdump code,
it is indeed useful to be able to access memory of the panic'd
process.

> >         "After a CP15 c1 instruction disables the MMU, the processor
> >         flushes all following instructions in the pipeline. The
> >         processor then begins refetching instructions and uses flat
> >         address mapping. In flat address mapping, PA = VA."
> > 
> 
> If this is the case, the Qemu issue I mentioned here
> 
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2010-July/019678.html
> 
> wasn't so far off the mark after all =o)

This is exactly what is happening on Cortex-A8 (at least on those OMAPs which
I've been testing on).

Regards,
MW

[1] - cpu_v7_reset via 1:1 mappings

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 6a8506d..66c12c0 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -63,10 +63,53 @@ ENDPROC(cpu_v7_proc_fin)
  */
 	.align	5
 ENTRY(cpu_v7_reset)
-	mov	pc, r0
+	/*
+	 * ARM Cortex-A8 TRM chapter 6.4 says:
+	 *
+	 *    After a CP15 c1 instruction disables the MMU, the processor
+	 *    flushes all following instructions in the pipeline. The processor
+	 *    then begins refetching instructions and uses flat address mapping.
+	 *    In flat address mapping, PA = VA.
+	 *
+	 * This means that in Cortex-A8 we need to disable the MMU through the
+	 * identity mapped region.
+	 */
+	mrc	p15, 0, r5, c0, c0, 0		@ read main ID register
+	and	r6, r5, #0xff000000		@ ARM?
+	teq	r6, #0x41000000
+	bne	__disable_mmu
+
+	mov	r6, #0x0000ff00			@ check primary part number
+	orr	r6, r6, #0x00f0			@ bits [15:4]
+	and	r6, r6, r5
+
+	mov	r5, #0xc000			@ is it Cortex-A8 (0xc080)?
+	orr	r5, r5, #0x0080
+	teq	r5, r6
+	bne	__disable_mmu
+
+	/*
+	 * This is Cortex-A8 so call via identity mapping.
+	 */
+	ldr	pc, =__virt_to_phys(__disable_mmu)
 ENDPROC(cpu_v7_reset)
 
 /*
+ * Disables the MMU and jumps into address given in r0.
+ */
+__disable_mmu:
+	mov     ip, #0
+#ifdef CONFIG_MMU
+	mcr     p15, 0, ip, c8, c7, 0           @ invalidate I & D TLBs
+#endif
+	mrc     p15, 0, ip, c1, c0, 0           @ ctrl register
+	bic     ip, ip, #0x000f                 @ ............wcam
+	bic     ip, ip, #0x1100                 @ ...i...s........
+	mcr     p15, 0, ip, c1, c0, 0           @ ctrl register
+	mov     pc, r0
+ENDPROC(__disable_mmu)
+
+/*
  *	cpu_v7_do_idle()
  *
  *	Idle the processor (eg, wait for interrupt).