Re: [Qemu-devel] Allow ARMv7M to be started without a kernel

[Peter Maydell]

On 5 May 2011 13:03, Ben Leslie <address@hidden> wrote:
> I still think it is somewhat nice that the simulator target can work
> just like a blank board though, and then connect GDB to it either
> directly for the sim or via JTAG for a real board. Then it is the
> same work flow for simulated or real hardware. (And the code change
> is just one if statement).

I would personally be happy with that (or with a "no really I don't
want an image" option or something), but I would like consistency
across targets rather than an armv7m specific change.

> (As an aside it would probably be good to implement the lockup mechanism
> of ARMv7M so that with an invalid reset vector it goes into lockup and
> something useful could be  displayed on stderr.)

There are a few known bugs in QEMU's v7m exception model, and yes,
not implementing lockup is one of them. Incidentally, technically
it's possible to write an architecturally compliant program that puts
the core into lockup and then rescues itself via an NMI handler, but
"gone into lockup" would be a useful thing to trace if we had a consistent
mechanism for enabling "emit trace for events indicating likely OS bugs".
I don't have any time personally to look at v7M issues (Linaro's focus
is A profile cores) but I'll review patches if anybody submits them.

[The best way to think of Lockup is as a continual attempt to execute
an instruction until either it works or you get a reset or suitably high
priority exception; so you assert the lockup signal for the things the
spec says cause lockup, and you deassert lockup if you find you have
managed to successfully execute an instruction. Implementing this in
QEMU is left as an exercise for the reader :-)]

>> The combination of v7M reset with image loading and the possibility
>> of a debugger altering the pc/sp while the core is in reset is a bit
>> complicated, though :-)
>
> I'm not sure if it is that complicated, I would assume that in armv7_reset
> after calling cpu_reset the PC is set to the entry point in a similar way
> to to how it is done in arm_boot.c

> I don't think GDB gets a chance to touch the registers until after CPU reset
> so I'm not sure if that will cause an issue.

The trouble is that unlike A&R profiles (where the reset PC is a constant
value), the reset PC/SP are loaded from memory. So PC/SP aren't actually
set when the core goes into reset, but as the first thing that happens
when we come out of reset and start doing work. So if QEMU does the "load
initial PC/SP" in reset then (a) this isn't what the hardware does and
(b) trying to load an image with a vector table via the debugger won't
work (because we read PC from RAM before the debugger wrote to it). If
you do the "load PC/SP" after reset, then any change the user made to
PC/SP in gdb gets overridden (unless you take special measures to avoid that).
(See also the comment in target-arm/helper.c:cpu_reset() about another
case we're not getting right.)

I think you need to work out a consistent way everything should behave
first, rather than trying to generate patches to make point fixes to
cases that are causing problems.

> (Another aside: ARMv7M is meant to cause a Hard Fault if something tries to
> set the 'thumb' bit to zero, which would also help avoid some of the
> silly problems I had when getting my code to run.)

Strictly, it should generate a UsageFault (with UFSR.INVSTATE set) when
the core next tries to execute an instruction with the T bit clear. (If
this happens immediately after reset then the UsageFault will be escalated
to HardFault; if your HardFault handler also tries to execute in ARM
mode then we go into Lockup.) QEMU might not get the right fault status
bits, but it should certainly generate some kind of fault because
disas_arm_insn() causes an exception to be generated if it's invoked for
an M profile core.

-- PMM