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

[Ben Leslie]

On Thu, May 5, 2011 at 19:56, Peter Maydell <address@hidden> wrote:
> On 5 May 2011 09:23, Ben Leslie <address@hidden> wrote:
>> FWIW, the reason why I'm not using -kernel is that the current
>> way the armv7m code works, it expects the provided kernel to
>> be a full flash image including appropriate vector table, whereas
>> right now I just want to debug some stand-alone code, not the full
>> system, which the above gdb approach works perfectly for.
>
> It would probably be better for the -kernel option to honour the
> entry point in the ELF file rather than insisting on full reset
> (and to try to load the reset SP from the vector table but not
> insist on that working). That is, we should support both "load
> this ELF image which is a full system image with a vector table"
> and "load this ELF image which is just a bare-metal (possibly
> semihosting) application".

Ideally that should work too, well in fact it would be more important
to get that working, and I guess the utility of my suggestion is
significantly lowered if that worked correctly.

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 guess the 'against' case is that if you
start up like that, and aren't running GDB it may be slightly confusing
for the user. However you would just get the same behaviour as you get
now when you pass in an image without a vector table.

(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.)

> 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.

(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.)

> As an aside: I think QEMU should have an option which is "just
> load a plain ELF or raw binary, with no funny Linux-kernel-specific
> behaviour" rather than overloading -kernel to mean "if it's a
> raw image it's Linux and if it's an ELF file it's not".

I agree, as far as I can tell right now (at least on arm), kernel can mean:

 1: A Linux kernel in linux kernel format.
 2: An ELF file (which may or may not have entry honoured)
 3: A raw binary.

OK, I think I may have forked this conversation with too may asides. Unless
there is a better suggestion I'll put together two patches, one that allows
-kernel to go unspecified, and a second that honours the ELF entry point
after reset. (Unless someone else wants to do it first!)

Cheers,

Ben