Re: [Qemu-devel] Better Cortex-M support?

[Peter Maydell]

On 29 October 2014 07:03, Liviu Ionescu <address@hidden> wrote:
>
> On 28 Oct 2014, at 16:18, Peter Maydell <address@hidden> wrote:
>
>> (There's also flash at address zero.)
>
> if this is wrong, can you suggest a fix?

No, it's correct, because it's what the board has.

> some time ago when I first used qemu the entire memory
> was similar, ram or flash alike. should I define them explicitly?

I'm pretty sure this is because you were accidentally
using a totally broken QEMU config that put an M class CPU
into a board model that doesn't work with M class CPUs,
and which happened to have a lot of RAM in the area
you were using.

The memory layout (which bits are flash and which RAM)
depend on the board you're targeting. So you need to make
sure you compile for the right hardware.

>> so valid RAM is only from 0x20000000 to 0x20010000,
> ...
>> I suggest you relink your binary to fit in the 64K
>> of RAM this board has.
>
> https://dl.dropboxusercontent.com/u/78151643/minimal.elf
>
>
> with the above updated file it runs fine standalone with:
>
> /opt/local/bin/qemu-system-arm -machine lm3s6965evb -nographic -monitor null 
> -serial null -semihosting -kernel qemu_osx_aep_gcc_minimal_Debug/minimal.elf
>
> but if I add '-gdb tcp::51234 -S', I can connect with GDB
> and debug, but the semihosting output is no longer working.
>
> is this a bug or a feature that I missed?

I think I'd call that a bug; I suspect there's an
unfortunate interaction between the gdbstub and
semihosting because for M profile semihosting is hooked
off the breakpoint instruction. Are we treating the
breakpoint as a breakpoint and dropping into gdb
rather than treating it as a semihosting call?
(On A/R profile this problem doesn't exist because
semihosting calls use SVC.)

thanks
-- PMM