On 8 June 2015 at 09:46, Liviu Ionescu <i...@livius.net> wrote: > >> On 07 Jun 2015, at 01:11, Peter Maydell <peter.mayd...@linaro.org> 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
