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

[prqek]

______________________________________________________________
> Od: Peter Maydell <address@hidden>
> Komu: <address@hidden>
> Datum: 18.03.2014 23:51
> Předmět: Re: [Qemu-devel] qemu freezes while writing into coprocessor register
>
> CC: "QEMU Developers" <address@hidden>
>On 18 March 2014 20:42,  <address@hidden> wrote:
>> Hi,
>> I was sending this to the Qemu-discuss list, but this one seems to be a 
>> better choice.
>> I am trying to build u-boot for pxa261 processor. I`m trying to run it on 
>> qemu
>> (1.7.0), but it is not working. When the execution gets to assembler code
>> mcr p15, 0, r0, c9, c1, 1, qemu freezes. I tried to debug this, and it seems 
>> to
>> be somehow looping in sctlr_write function (from target-arm/helper.c). Here I
>> am lost, because I can`t find any loop, which could cause this.
>>
>> I also tried qemu 1.7.90 and it also freezes, but without the loop, at least 
>> in sctlr_write function
>
>There is no loop in sctlr_write, so it's not possible for us to loop in it,
>and 0, c9, c1, 1 isn't the SCTLR either.
>

I also didn`t find any loop, that is what confused me. But forget about the 
looping, with 1.7.90 it just freezes.

>Are you sure this is not simply that the *guest* has gone into an
>infinite loop? It's quite common for guest firmware and early kernel
>startup code to have a failure mode which goes like:
> * guest tries to access a system register
> * for some reason (qemu bug, guest bug) that register doesn't exist
>   or the guest doesn't have access permissions for it
> * this results in our sending the guest an UNDEF exception
> * the guest hasn't set up an exception vector table yet so either
>   + we take an insn abort exception trying to execute from the
>      non existent vector table, and go into an infinite loop of
>      insn abort exceptions
>   + execution falls straight through into the start of the guest image,
>      which then tries everything all over again, either failing in the
>      same place or possibly differently because it wasn't expecting
>      to be restarted
>

I am not sure, but I suppose so. I met this before, but this doesn`t seem to be 
this case. I start qemu with -S -s, connect with gdb and with si command get to 
the mcr instruction. When I execute one more si, gdb stops, I have to quit qemu 
or kill gdb. If something like you described happens, gdb would should show me 
some looping, am I right?


>Either way, you can get a better view of what's happening by enabling
>QEMU's debug logging (-d in_asm,exec,unimp -D qemu.log) or by
>connecting gdb to QEMU's gdbstub and singlestepping.
>

I`ll try that.

>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.

Thanks for you help.

>
>thanks
>-- PMM
>