______________________________________________________________
> Od: Peter Maydell <peter.mayd...@linaro.org>
> Komu: <pr...@centrum.cz>
> Datum: 18.03.2014 23:51
> Předmět: Re: [Qemu-devel] qemu freezes while writing into coprocessor register
>
> CC: "QEMU Developers" <qemu-devel@nongnu.org>
>On 18 March 2014 20:42, <pr...@centrum.cz> 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
>
