qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] QEMU-AArch64 hangs up when executing AArch64 floating


From: Jiaqi Liu
Subject: Re: [Qemu-discuss] QEMU-AArch64 hangs up when executing AArch64 floating point instructions
Date: Wed, 22 Jul 2015 17:51:36 +0100

Hi Peter,

Thank you so much. I did as you suggested and it works well.

Best regards,

Jiaqi

On 21 July 2015 at 20:55, Peter Maydell <address@hidden> wrote:
On 21 July 2015 at 20:30, Jiaqi Liu <address@hidden> wrote:
> I used the following command to execute some AArch64 instructions contained
> in test.bin:
> qemu-system-aarch64 -cpu cortex-a57 -M virt -m 128M -nographic -s -S -kernel
> test.bin
>
> But QEMU hanged up while executing floating point instructions.
>
> The following AArch64 instruction block is contained in test.bin
> (disassembled in aarch64-none-elf-gdb):
> 0x0000000040081000:  mov  x0,  #0xa  // #10
> 0x0000000040081004:  mov   x1,  #0xb  // #11
> 0x0000000040081008:  fmov  d0,  x0
> 0x000000004008100c:  fmov  d1,  x1
>
> I debugged it with "aarch64-none-elf-gdb" and found that the first two
> integer mov instructions were successfully executed by qemu-system-aarch64.
>
> But QEMU hanged up at the 3rd intruction "fmov  d0,  x0", with one host CPU
> core usage 100%.
>
> Then I tested other floating point AArch64 instructions like "fabs" and
> "fadd", QEMU hanged up at all of them.

Assuming that's the only thing in your binary, that's expected
behaviour. On reset an ARM CPU does not start with the floating
point unit enabled. You have to manually enable it by writing
0b11 to the FPEN bits in the CPACR_EL1 system register.
If you don't enable the floating point unit, then any floating
point instruction will take an exception. Taking an exception
means that we'll start execution at the relevant exception entry
point. If you haven't put any code there (which I'm guessing you
haven't) then the likely thing that will happen is that we'll
try to execute garbage, which will cause another exception.
And so we go round in a loop continually taking exceptions.
This is exactly what the hardware would do if you tried to do
what you're doing as a boot ROM/firmware.

thanks
-- PMM


reply via email to

[Prev in Thread] Current Thread [Next in Thread]