Re: [Qemu-devel] qemu freezes while writing into coprocessor register

[Peter Maydell]

On 19 March 2014 08:29,  <address@hidden> wrote:
>> Od: Peter Maydell <address@hidden>
>>That said, we don't implement whatever 0, c9, c1, 1 is on PXA261
>>(and so we will UNDEF it, resulting probably in the effects listed
>>above). What do you expect it to do?
>
> This is the piece of code with comments:
> /*
>  * Enable MMU to use DCache as DRAM.
>  *
>  * This is useful on PXA25x and PXA26x in early bootstages, where there is no
>  * other possible memory available to hold stack.
>  */
> #if defined(CONFIG_CPU_PXA25X) || defined(CONFIG_CPU_PXA26X)
> .macro CPWAIT reg
>     mrc p15, 0, \reg, c2, c0, 0
>     mov \reg, \reg
>     sub pc, pc, #4
> .endm
> lock_cache_for_stack:
>     /* Domain access -- enable for all CPs */
>     ldr r0, =0x0000ffff
>     mcr p15, 0, r0, c3, c0, 0
>
>     /* Point TTBR to MMU table */
>     ldr r0, =mmutable
>     mcr p15, 0, r0, c2, c0, 0
>
>     /* Kick in MMU, ICache, DCache, BTB */
>     mrc p15, 0, r0, c1, c0, 0
>     bic r0, #0x1b00
>     bic r0, #0x0087
>     orr r0, #0x1800
>     orr r0, #0x0005
>     mcr p15, 0, r0, c1, c0, 0
>     CPWAIT  r0
>
>     /* Unlock Icache, Dcache */
>     mcr p15, 0, r0, c9, c1, 1  // <- execution stops here
>     mcr p15, 0, r0, c9, c2, 1 // <- never gets here
>
>     /* Flush Icache, Dcache, BTB */
>     mcr p15, 0, r0, c7, c7, 0
>
>     /* Unlock I-TLB, D-TLB */
>     mcr p15, 0, r0, c10, c4, 1
>     mcr p15, 0, r0, c10, c8, 1
>
>     /* Flush TLB */
>     mcr p15, 0, r0, c8, c7, 0
>
>     /* Allocate 4096 bytes of Dcache as RAM */
>
>     /* Drain pending loads and stores */
>     mcr p15, 0, r0, c7, c10, 4
>
>     mov r4, #0x00
>     mov r5, #0x00
>     mov r2, #0x01
>     mcr p15, 0, r0, c9, c2, 0
>     CPWAIT  r0
>
>     /* 128 lines reserved (128 x 32bytes = 4096 bytes total) */
>     mov r0, #128
>     ldr r1, =0xfffff000
>
> The problem could also in this code, as I understand it, it`s supposed
> to use the cache for stack until RAM is ready, but to honest, I don`t
> fully understand the datials how this should happen. The reason why
> I think that the problem originates in qemu, is that everyhting seems
> to stop at this instruction.

Yes, I've found a copy of the PXA255 user's manual, which is
what documents the behaviour of these xscale-specific cp ops.
These all have to do with implementing cache lockdown. The
code here is trying to lock the memory for the stack into the
cache, which can't work on QEMU because we don't implement
caches at all. However it probably doesn't depend on this, so
implementing these registers as NOPs is probably sufficient.

If I write a patch to add these will you be able to apply it
and test it?

thanks
-- PMM