[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu
From: |
Peter Maydell |
Subject: |
Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu |
Date: |
Fri, 15 Jun 2018 14:54:33 +0100 |
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
- [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/14
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Peter Maydell, 2018/06/15
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/15
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu,
Peter Maydell <=
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/15
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/15
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Peter Maydell, 2018/06/16
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/16
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Peter Maydell, 2018/06/16
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/16
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Peter Maydell, 2018/06/19
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/19
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Peter Maydell, 2018/06/20
- Re: [Qemu-arm] Booting Cortex-M3 Linux kernels in qemu, Guenter Roeck, 2018/06/20