using identity_mapping_add & switching MMU state - how ?

Frank Hofmann frank.hofmann at tomtom.com
Fri Jun 3 08:20:36 EDT 2011


On Thu, 2 Jun 2011, Lorenzo Pieralisi wrote:

[ ... ]
>>  	mrc	p15, 0, r1, c1, c0, 0
>>  	bic	r1, #CR_M
>>  	mcr	p15, 0, r1, c1, c0, 0	@ MMU OFF
>
> I know it is a silly question, but are you sure your pc is pointing
> to a 1:1 physical address here ? This might explain also why if you call
> cpu_do_resume straight off you have to skip the mmu resume code since it
> creates a temporary mapping based on the current program counter. if it
> is a virtual address it goes pop, methinks.

You could be right there - that might actually _be_ the silly thing. After 
all, I'm coming from virtual ...


As said, I can't do the following:

 	mrc	p15, 0, r1, c1, c0, 0
 	bic	r1, #CR_M
 	mcr	p15, 0, r1, c1, c0, 0	@ MMU OFF
 	mrc	p15, 0, r1, c1, c0, 0
 	orr	r1, #CR_M
 	mcr	p15, 0, r1, c1, c0, 0	@ MMU ON

That ends in a hang; but yes the pc when exexuting this is still 
_virtual_.


[ ... ]
> See comment above, cpu_resume_mmu creates a 1:1 mapping based on the
> current PC (it uses adr), it should do no harm unless PC is running
> virtual.


Now just for the fun of it, I've attempted to do (note: on v6 - cpu_reset 
is only a `mov pc, r0` there, no MMU off):

 	identity_mapping_add(pgd_that_is_in_use, __pa(_stext), __pa(_etext));
 	... flush things ...
 	cpu_proc_fin();
 	cpu_reset(__pa(__builtin_return_address(0)));	/* return physical */

just to test whether a transfer to a physical / 1:1 mapped addr works, 
i.e. if the 1:1 mapping is ok. At return, then:

 	ldr	r4, =.Lvirt_label	@ pc-relative load
 	mov	pc, r4			@ back to virtual
.ltorg
.align 5
.Lvirt_label:
 	/* continue as if normal */

to go back to virtual. But that also hangs.


FrankH.



More information about the linux-arm-kernel mailing list