On 29 October 2014 07:03, Liviu Ionescu <i...@livius.net> wrote: > > On 28 Oct 2014, at 16:18, Peter Maydell <peter.mayd...@linaro.org> 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
