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

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

[Liviu Ionescu]

while working on the STM32 emulation, I noticed a problem related to the specific memory layout of STM32 devices.

these devices have the FLASH region at 0x08000000 instead of 0x00000000, and since the specs require the presence of the reset vector at 0x0, there is an internal alias of the entire region 0x08000000 at 0x00000000.

however programming the flash via a jtag works only in the 0x08000000 range, and although possible to make the linker script to run the code at 0x0 and program it at 0x08000000, this is usually not done, and most STM32 applications are linked to run directly at 0x08000000.

unfortunately qemu is not very happy with this arrangement :-(


the STM32 initialisation code I used, similar to that used by Alistair, takes a reversed approach, it first creates the main flash region at 0x00000000: 

    MemoryRegion *flash_mem = g_new(MemoryRegion, 1);

    memory_region_init_ram(flash_mem, NULL, "cortexm-mem-flash", flash_size,
            &error_abort);
    vmstate_register_ram_global(flash_mem);
    memory_region_set_readonly(flash_mem, true);
    memory_region_add_subregion(system_memory, 0x00000000, flash_mem);

and then creates a memory alias at 0x08000000:

    MemoryRegion *flash_alias_mem = g_malloc(sizeof(MemoryRegion));

    memory_region_init_alias(flash_alias_mem, NULL, "stm32-mem-flash-alias",
            get_system_memory(), 0, flash_size_kb);
    memory_region_set_readonly(flash_alias_mem, true);
    memory_region_add_subregion(get_system_memory(), 0x08000000,
            flash_alias_mem);


this works fine, however it crashes when the core tries to executes the first instruction in the 0x08000000 region.

it crashes in cputlb.c: get_page_addr_code() since the memory region is found as 'unassigned':

    if (memory_region_is_unassigned(mr)) {
        CPUClass *cc = CPU_GET_CLASS(cpu);

        if (cc->do_unassigned_access) {
            cc->do_unassigned_access(cpu, addr, false, true, 0, 4);
        } else {
            cpu_abort(cpu, "Trying to execute code outside RAM or ROM at 0x"
                      TARGET_FMT_lx "\n", addr);
        }
    }

I tried to disable the if(), but later bad things happened... :-(


since my experience at that great depth in qemu is limited, I would appreciate any advice on how to proceed.


at first sight emulation follows a very complicated path required in larger ARM cores, but completely useless for cortex-m, since none have MMUs and TLBs.

ideally cortex-m cores should have a configuration bit to completely skip MMU specific processing.


thank you in advance,

Liviu

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

[Peter Maydell]

On 6 June 2015 at 20:01, Liviu Ionescu <ilg@livius.net> wrote:
> while working on the STM32 emulation, I noticed a problem related to the specific memory layout of STM32 devices.
>
> these devices have the FLASH region at 0x08000000 instead of 0x00000000, and since the specs require the presence of the reset vector at 0x0, there is an internal alias of the entire region 0x08000000 at 0x00000000.
>
> however programming the flash via a jtag works only in the 0x08000000 range, and although possible to make the linker script to run the code at 0x0 and program it at 0x08000000, this is usually not done, and most STM32 applications are linked to run directly at 0x08000000.
>
> unfortunately qemu is not very happy with this arrangement :-(

Aliased memory regions do in general work, we use them in several
boards. There's probably just a bug in how you've set this one up.

> the STM32 initialisation code I used, similar to that used by Alistair, takes a reversed approach, it first creates the main flash region at 0x00000000:
>
>     MemoryRegion *flash_mem = g_new(MemoryRegion, 1);
>
>     memory_region_init_ram(flash_mem, NULL, "cortexm-mem-flash", flash_size,
>             &error_abort);
>     vmstate_register_ram_global(flash_mem);
>     memory_region_set_readonly(flash_mem, true);
>     memory_region_add_subregion(system_memory, 0x00000000, flash_mem);
>
> and then creates a memory alias at 0x08000000:
>
>     MemoryRegion *flash_alias_mem = g_malloc(sizeof(MemoryRegion));
>
>     memory_region_init_alias(flash_alias_mem, NULL, "stm32-mem-flash-alias",
>             get_system_memory(), 0, flash_size_kb);

So, there's two odd things here:
 (1) why are you making this an alias of a chunk of the system address
     space, rather than just an alias of the flash memory you just created?
     The stm32 soc code does the latter.
 (2) this function takes the memory region size in bytes, so assuming
     your variable flash_size_kb is what the name suggests, you're
     trying to map a region that's a lot smaller than you want.

(The second one is probably the actual problem here.)

Try
    memory_region_init_alias(flash_alias_mem, NULL, "stm32-mem-flash-alias",
                             flash_mem, 0, flash_size);
which is what the stm32f205_soc code does.

One handy debugging tool for tracking down this kind of thing is to
use the QEMU monitor's "info mtree" command, which will show you all
the memory regions, where they've been put in the address space and
how large they are.

>     memory_region_set_readonly(flash_alias_mem, true);
>     memory_region_add_subregion(get_system_memory(), 0x08000000,
>             flash_alias_mem);
>
>
> this works fine, however it crashes when the core tries to executes the first instruction in the 0x08000000 region.
>
> it crashes in cputlb.c: get_page_addr_code() since the memory region is found as 'unassigned':

Yes; we can't execute code from memory that isn't backed by
real host RAM. It's not exactly a crash since it's a controlled
error-message-printing exit, but it does look rather misleading.
If you get here it typically means that either the board is
not putting RAM where it should, or the guest program has a bug
and is jumping off to an incorrect address.

> at first sight emulation follows a very complicated path required in larger ARM cores, but completely useless for cortex-m, since none have MMUs and TLBs.
>
> ideally cortex-m cores should have a configuration bit to completely skip MMU specific processing.

No, we need most of the code -- we still need to handle the mapping
of guest (virtual) addresses to host virtual addresses (or to io
read/write callbacks), which is most of what the CPUTLB code is about.
The only thing that differs between an MMU based system and an MPU
(or MMU/MPU-disabled) system is that get_phys_addr() will take a
simpler path that handles MPU like behaviour rather than doing a
page table walk.

-- PMM

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

[Liviu Ionescu]

> On 07 Jun 2015, at 01:11, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> ...
> So, there's two odd things here:
> (1) why ... a chunk ...
> (2) ... size in bytes ... flash_size_kb is what the name suggests, you're
>     trying to map a region that's a lot smaller than you want.

right, this was a bug in my code.

the two sequences are not in the same file, the first part is in the cortexm-mcu object and the second one is in stm32-mcu, which is the base for actual stm32xx mcus, and it was more difficult to see the difference; thank you for spotting it.

> (The second one is probably the actual problem here.)

yes, the message went away, but there must be another problem, since execution stops with a HardFault right at address 0x0.

I'll try to debug it separately.

> One handy debugging tool for tracking down this kind of thing is to
> use the QEMU monitor's "info mtree" command,

ok, thank you for the hint.


regards,

Liviu

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

[Liviu Ionescu]

> On 07 Jun 2015, at 01:11, Peter Maydell <peter.maydell@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?


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
  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.


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...)


regards,

Liviu

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

[Peter Maydell]

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

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

[Liviu Ionescu]

> On 08 Jun 2015, at 12:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On 8 June 2015 at 09:46, Liviu Ionescu <ilg@livius.net> wrote:
>> 
>> 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.

I could not find anything in the manual.

> 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.)

it might be an interference between the Eclipse simple consoles and QEMU expecting full terminal support.

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

it is part of the increased verbosity needed by my use case. for this I added -verbose, which can be issued multiple times to increase the verbosity level.

the QEMU plugin issues a GDB custom 'monitor system_reset' command after loading the ELF file, and I need to see it in the console.

unfortunately my implementation is faulty, I need to check if the monitor is running in an interactive session and no longer display the verbosity related messages.

(btw, is there a simple way to tell if the monitor is running interactive or the command came from GDB?)

> the 
>> 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.

ah, right, I finally got your point, the address range is ok, but the @system name is wrong.

now it reads:

  0000000000000000-000000000001ffff (prio 0, R-): cortexm-mem-flash
  0000000008000000-000000000801ffff (prio 0, R-): alias stm32-mem-flash-alias @cortexm-mem-flash 0000000000000000-000000000001ffff

> What's the cortexm-mem-hack ?

from arm7vm.c:

    /* Hack to map an additional page of ram at the top of the address
       space.  This stops qemu complaining about executing code outside RAM
       when returning from an exception.  */
    memory_region_init_ram(hack, NULL, "armv7m.hack", 0x1000, &error_abort);
    vmstate_register_ram_global(hack);
    memory_region_add_subregion(system_memory, 0xfffff000, hack);


regards,

Liviu

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

[Peter Maydell]

On 8 June 2015 at 11:51, Liviu Ionescu <ilg@livius.net> wrote:
>> On 08 Jun 2015, at 12:17, Peter Maydell <peter.maydell@linaro.org> wrote:
>> What is printing the "Execute ..." line? A quick grep of the
>> sources suggests it's not QEMU.
>
> it is part of the increased verbosity needed by my use case.
> for this I added -verbose, which can be issued multiple times
> to increase the verbosity level.

Is this verbosity also the thing printing the line with all
the escape characters in it? Do you get those when you're
actually editing the line as you type them in?

>> What's the cortexm-mem-hack ?
>
> from arm7vm.c:
>
>     /* Hack to map an additional page of ram at the top of the address
>        space.  This stops qemu complaining about executing code outside RAM
>        when returning from an exception.  */
>     memory_region_init_ram(hack, NULL, "armv7m.hack", 0x1000, &error_abort);
>     vmstate_register_ram_global(hack);
>     memory_region_add_subregion(system_memory, 0xfffff000, hack);

I wondered if it might be that, but that memory region is named
"armv7m.hack". There's no "cortexm-mem-hack" in the current QEMU
sources.

-- PMM

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

[Liviu Ionescu]

> On 08 Jun 2015, at 13:56, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> Is this verbosity also the thing printing the line with all
> the escape characters in it?

I don't think so, the code added at around line 4135 in monitor.c looks like:

#if defined(CONFIG_VERBOSE)
        if (verbosity_level >= VERBOSITY_COMMON) {
            printf("Execute 'mon %s'.\n\n", cmdline);
        }
#endif
        cmd->mhandler.cmd(mon, qdict);

>  Do you get those when you're
> actually editing the line as you type them in?

no, editing seems fine, the garbled line is displayed after Enter.

> I wondered if it might be that, but that memory region is named
> "armv7m.hack". There's no "cortexm-mem-hack" in the current QEMU
> sources.

I'm not using armv7m.c, I have a separate hierarchy of objects, like "cortexm-mcu", "stm32-mcu", "stm32f103rb", etc.

regards,

Liviu

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

[Liviu Ionescu]

> On 08 Jun 2015, at 14:05, Liviu Ionescu <ilg@livius.net> wrote:
> 
> 
>> On 08 Jun 2015, at 13:56, Peter Maydell <peter.maydell@linaro.org> wrote:
>> 
>> Is this verbosity also the thing printing the line with all
>> the escape characters in it?
> 
> I don't think so, the code added at around line 4135 in monitor.c looks like:
> 
> #if defined(CONFIG_VERBOSE)
>        if (verbosity_level >= VERBOSITY_COMMON) {
>            printf("Execute 'mon %s'.\n\n", cmdline);
>        }
> #endif
>        cmd->mhandler.cmd(mon, qdict);

I checked and the gdb monitor instance is created with zero flags, so I updated the verbosity code to read:

#if defined(CONFIG_VERBOSE)
        if (verbosity_level >= VERBOSITY_COMMON) {
            if (mon->flags == 0) {
                printf("Execute 'mon %s'.\n\n", cmdline);
            }
        }
#endif


and I no longer get the Execute... echo for the interactive monitor.

but the terminal control chars are still there:

(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
memory
0000000000000000-ffffffffffffffff (prio 0, RW): system
...


regards,

Liviu

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

[Liviu Ionescu]

> On 08 Jun 2015, at 13:56, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> ... Is this verbosity also the thing printing the line with all
> the escape characters in it? 

no, after some more debugging I identified the place where these chars are displayed: in the readline.c file:

/* update the displayed command line */
static void readline_update(ReadLineState *rs)
{
    int i, delta, len;

    if (rs->cmd_buf_size != rs->last_cmd_buf_size ||
        memcmp(rs->cmd_buf, rs->last_cmd_buf, rs->cmd_buf_size) != 0) {
        for(i = 0; i < rs->last_cmd_buf_index; i++) {
            rs->printf_func(rs->opaque, "\033[D");
        }
    ...
}

I could not find a configuration to disable this, so I completely removed the content of this function and the Eclipse console is now free of funny chars.

as I said, probably the qemu readline implementation assumes all consoles in the world are vt100 terminals, which is obviously too optimistic, a notable exception being exactly the Eclipse console.


regards,

Liviu

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

[Peter Maydell]

On 8 June 2015 at 15:04, Liviu Ionescu <ilg@livius.net> wrote:
> as I said, probably the qemu readline implementation assumes all
> consoles in the world are vt100 terminals, which is obviously too
> optimistic, a notable exception being exactly the Eclipse console.

Well, readline assumes that you have an interactive terminal, since
you're interacting with it. You can always turn off the readline
feature if you don't want it.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=112948
is the eclipse bug for "console should support ANSI escape sequences".

-- PMM

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

[Liviu Ionescu]

> On 08 Jun 2015, at 17:10, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> ... You can always turn off the readline
> feature if you don't want it.

how? with the existing manual I could not figure out how to do it.

the only option that worked for me was '-monitor stdio'. most of other option combinations just terminated qemu without any error message reported (which is another problem with qemu).


regards,

Liviu

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

[Peter Maydell]

On 8 June 2015 at 15:54, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 08 Jun 2015, at 17:10, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> ... You can always turn off the readline
>> feature if you don't want it.
>
> how? with the existing manual I could not figure out how to do it.

Hmm, you're right, we have 'readline' mode and 'control' mode.
The latter won't have the cursor-editing, but it's the QMP
protocol monitor (intended for controlling QEMU from other programs,
different syntax to the human monitor protocol).
That's irritating because the underlying monitor.c code thinks
of readline and QMP-vs-HMP as orthogonal, but vl.c's parsing
doesn't.

(Syntax: -chardev stdio,id=monchr -mon chardev=monchr,mode=$MODE
where $MODE is either 'readline' or 'control'.)

-- PMM

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

[Liviu Ionescu]

> On 08 Jun 2015, at 18:21, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> ... 'readline' mode and 'control' mode.
> The latter won't have the cursor-editing, but it's the QMP
> protocol monitor (intended for controlling QEMU from other programs,
> different syntax to the human monitor protocol).

> -chardev stdio,id=monchr -mon chardev=monchr,mode=control

this great syntax is accepted, but, unless I'm expected to enter json formatted strings, the behaviour is definitely not for humans:

info mtree
{"error": {"class": "GenericError", "desc": "Invalid JSON syntax"}}
{"error": {"class": "GenericError", "desc": "Invalid JSON syntax"}}

the reason I commented out terminal control in readline_update() was that I could not find a way to disable it from the command line.


regards,

Liviu

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

[Peter Maydell]

On 8 June 2015 at 16:50, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 08 Jun 2015, at 18:21, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> ... 'readline' mode and 'control' mode.
>> The latter won't have the cursor-editing, but it's the QMP
>> protocol monitor (intended for controlling QEMU from other programs,
>> different syntax to the human monitor protocol).
>
>> -chardev stdio,id=monchr -mon chardev=monchr,mode=control
>
> this great syntax is accepted, but, unless I'm expected to enter json formatted strings, the behaviour is definitely not for humans

Yes, that was my point. You ought ideally to be able
to say 'hmp but no readline', but our command line
parsing conflates the two things.

-- PMM