Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu

[Peter Maydell]

On 15 June 2018 at 14:30, Guenter Roeck <address@hidden> wrote:
> Anyway, my problem is much more basic than device support. Whatever I try,
> I always get
>
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> R00=00000000 R01=00000000 R02=00000000 R03=00000000
> R04=00000000 R05=00000000 R06=00000000 R07=00000000
> R08=00000000 R09=00000000 R10=00000000 R11=00000000
> R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
> XPSR=40000003 -Z-- A handler
> FPSCR: 00000000
>
> even when I use a toolchain specifically built for Cortex-M3 and thumb2,
> and no matter which image I try to load. Presumably that means that it
> tries to execute or jump to a non-thumb2 instruction, but that doesn't
> really help me. Any idea, or should I just give up ?

Reading the runes that looks like an attempt to start an
image with no vector table in it: R15 is zero, R14 is the
magic "we just took an exception" number, R13 looks like
probably what you get if you started with a zero SP and
then pushed an exception frame.

Try running with -d in_asm,cpu,exec,int,unimp,guest_errors
which will print some logging which will tell you what it
tried to do. But I'm pretty sure what's happened is:

 * on reset, we read the initial PC and SP from the
   non-existent vector table; both are 0
 * in vector table entries, the LSB is the arm/thumb bit,
   so 0 means try to execute from 0 in arm mode
 * any attempt to execute in arm mode is an INVSTATE
   UsageFault
 * ...but at startup UsageFaults are disabled, so we
   escalate to HardFault
 * because SP was 0, the stack-frame setup for exception
   entry pushes it around to 0xffffffe0. This isn't RAM,
   so we take a derived BusFault on exception entry
   (which also escalates to HardFault)
 * we read the PC for the HardFault entry point from the
   vector table. This is 0...
 * ...so we again execute from 0 in arm mode, and fault
 * but because we're now in a HardFault handler we can't
   escalate our UsageFault to HardFault and instead must
   go into Lockup
 * QEMU doesn't implement the architectural lockup behaviour
   so we just abort().

Note that for M profile QEMU, the thing you pass to -kernel
must be be either (a) a raw image file which starts with a
vector table and is intended to be loaded at address zero,
or (b) be an ELF file which we will load at whatever address
it asks, but which must include a vector table at address
zero, because we don't honour the ELF entrypoint address
but instead always load the initial SP and PC from the
vector table.

thanks
-- PMM