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.
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
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.
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?
thanks
-- PMM
