Re: [Qemu-devel] Trying to execute code outside RAM or ROM at 0x08000230

[Peter Maydell]

On 8 June 2015 at 09:46, Liviu Ionescu <address@hidden> wrote:
>
>> On 07 Jun 2015, at 01:11, Peter Maydell <address@hidden> wrote:
>>
>> One handy debugging tool for tracking down this kind of thing is to
>> use the QEMU monitor's "info mtree" command,
>
> I added "-monitor stdio" to the Eclipse configuration used to start the 
> emulator, and I got access to the monitor, but apparently it uses some fancy 
> terminal commands, that are not properly handled by the Eclipse console:
>
> (qemu) info mtree
> i [K [Din [K [D [Dinf [K [D [D [Dinfo [K [D [D [D [Dinfo  [K [D [D [D [D 
> [Dinfo m [K [D [D [D [D [D [Dinfo mt [K [D [D [D [D [D [D [Dinfo mtr [K [D [D 
> [D [D [D [D [D [Dinfo mtre [K [D [D [D [D [D [D [D [D [Dinfo mtree [K
> Execute 'mon info mtree'.
>
> Q: is there any simple way to get rid of them?

This is probably the readline support (so you can do cursor
editing of command lines). You can turn that off, though I forget
the syntax -- it should be documented somewhere. (The cursor
sequences are just the usual VT100/etc ones for cursor movement
and character deletion, so it's a bit odd that you see them:
I would have expected that either the Eclipse console did all
its own editing and cursor movement and just sent the finished
line to QEMU, or that if it's sending the cursor escapes when
you do cursor movement that it doesn't get echoed back.)

What is printing the "Execute ..." line? A quick grep of the
sources suggests it's not QEMU.

> as for memory map, I get:
>
> memory
> 0000000000000000-ffffffffffffffff (prio 0, RW): system
>   0000000000000000-000000000001ffff (prio 0, R-): cortexm-mem-flash
>   0000000008000000-000000000801ffff (prio 0, R-): alias stm32-mem-flash-alias 
> @system 0000000000000000-000000000001ffff

This is still aliasing the whole system address space, rather
than just the flash device. The effects will be the same but
it's a conceptual error I think.

>   0000000020000000-0000000020004fff (prio 0, RW): cortexm-mem-sram
>   0000000022000000-0000000023ffffff (prio 0, RW): bitband
>   0000000040021000-0000000040021027 (prio 0, RW): stm32-rcc
>   0000000040022000-0000000040022023 (prio 0, RW): stm32-flash
>   00000000e0000000-00000000e0000fff (prio 0, RW): armv7m-itm
>   00000000e000e000-00000000e000efff (prio 0, RW): nvic
>     00000000e000e000-00000000e000efff (prio 0, RW): nvic_sysregs
>     00000000e000e100-00000000e000ecff (prio 1, RW): alias nvic-gic @gic_dist 
> 0000000000000100-0000000000000cff
>   00000000fffff000-00000000ffffffff (prio 0, RW): cortexm-mem-hack
>
> except the NVIC range, which is a bit more complicated than needed, the rest 
> seem fine to me.

What's the cortexm-mem-hack ?

> I/O
> 0000000000000000-000000000000ffff (prio 0, RW): io
>
> apparently this does not seem to harm anything, but it looks like an
> old Intel thing (which, in my opinion, was harmful enough at its time...)

The system I/O space always exists, but for ARM boards we don't
put anything in it, and we don't make it accessible to the guest.

-- PMM