Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

[Peter Maydell]

On Thu, 30 Sept 2021 at 12:34, abhijeet inamdar
<abhijeetinamdar3005@gmail.com> wrote:
> Actually the ELF generates the .bin file which is being used to run on the 
> target (hardware). It's address starts from zero when I see the starting 
> frames of it. As follows:
>
> IN:
> 0x00000002:  c0de       stm      r0!, {r1, r2, r3, r4, r6, r7}
> 0x00000004:  0003       movs     r3, r0
> 0x00000006:  0000       movs     r0, r0
> 0x00000008:  0001       movs     r1, r0
> 0x0000000a:  0000       movs     r0, r0
> 0x0000000c:  0002       movs     r2, r0
> 0x0000000e:  0000       movs     r0, r0
> 0x00000010:  0168       lsls     r0, r5, #5
> 0x00000012:  0000       movs     r0, r0
> 0x00000014:  5838       ldr      r0, [r7, r0]

This clearly isn't code; it's some kind of data. It's not
a vector table, because it starts
 0xc0deXXXX
 0x00000003
 0x00000001
 0x00000002
 0x00000168

and those aren't plausible looking addresses.

The guest CPU loads the reset SP and PC. The reset PC
is 0x00000003, so we start at address 0x00000002 in Thumb
mode. The data at that address is not a sensible instruction
(it's that "stm r0!..."), but we execute it. r0 is 0, so this
is going to store new random data all over the existing
data that we were incorrectly executing. The inevitable
result is that we take an exception, and this time the
vector table is full of zeros, so now we try to execute
from 0x0 in non-Thumb mode, which means we take another exception,
which is Lockup.

The solution remains the same: you need to load a guest
image which puts a valid vector table in guest memory
at the address where the CPU expects it (which looks like
0x0 in this case). Until you do this, your guest code
will crash in mysterious-looking ways because you are
not running what you think you are running.

-- PMM