On 28 October 2014 14:37, Liviu Ionescu <i...@livius.net> wrote: > On 28 Oct 2014, at 16:18, Peter Maydell <peter.mayd...@linaro.org> wrote: >> Thanks. I've identified what's happening here, and >> it's not a bug in QEMU as such. The 'lm3s6965evb' >> model is of a microcontroller with 64KB of SRAM, >> so valid RAM is only from 0x20000000 to 0x20010000, >> but your binary is trying to use the area beyond that >> as RAM as well, and is therefore misbehaving.
>> (We ignore any attempt to specify RAM size via the >> command line -m switch, so your '-m 513M' has no effect). > > that explains it. my linker script assumes 1MB of flash and 1MB of RAM. > > what would be the recommended solution for a generic Cortex-M3 emulation, > make it back work with '-cpu cortex-m3' or do you mandate to use add a > generic '-machine cortex-m3'? There's no such thing as a "generic Cortex-M3 emulation". We model actual hardware (though in this case not a very useful set of boards). >> I suggest you relink your binary to fit in the 64K >> of RAM this board has. (There's also flash at address >> zero.) > > yeah, the flash issue is another item on my features list. > > the behaviour that I expect is to have the flash as a read only > area, where gdb will be allowed to write in a similar way as when > writing the physical flash (same as J-Link does). I think writes via gdb will be treated in the same way as writes by the CPU (ie interpreted as attempts to program the flash device). QEMU doesn't support a "debug access" abstraction. -- PMM
