On Sunday 25 October 2009, Øyvind Harboe wrote:
> The default implementation of target_read/write_phys_memory
> is to call target_read/write_memory, but I'm thinking the default
> implementation should return an error and
> LOG_ERROR("Not implemented").

I count three cases:

 - No MMU ... current approach is more-or-less correct
 - MMU, disabled ... ditto
 - MMU, enabled ... default is wrong

So rather than breaking the two-out-of-three cases that are
OK ... shouldn't there just be a target "mmu_enabled" flag
which controls this behavior?


I suspect things get torqued around because the underlying
hardware requires write_phys() to work something like

        if (mmu_enabled)
                flush caches and disable mmu
        target->write()
        if (phys)
                reenable mmu

Is that sort of correct?  It looks painful right now to
need to enable/disable the MMU on each write ... suggesting
to me that the thing still needs to be refactored.  The
current generic

        for (i = 0; i < count; i++)
                phys_or_virt_write(target, item[i])

should be more like

        if (mmu_enabled)
                flush and invalidate caches and disable mmu
        for (i = 0; i < count; i++)
                target->write(item[i])
        if (phys)
                reenable mmu

With nuances like needing to flush and invalidate caches even
in non-MMU cases when the write isn't going through the CPU.


> The optional [phys] argument to mww/mdw variants is still there for
> *all* targets though, even if they can't support it in principle
> (there aren't any Cortex M0/M3's w/MMU are there?).

See above.  Without an active MMU, there should never be a
distinction between the two modes since *ALL* accesses are
using physical addresses.

(And no -- Cortex-M parts have no MMU.  Same with ARM7TDMI,
and ARM9TDMI.  And various other cores, of course.)


> Which brings me to another thing...
> 
> Should commands that *could* be supported by targets be added
> even if the OpenOCD target code does not support it them?
> 
> If users are searching for the right way to do mrc/mcr operations
> for, say, XScale, would it not be better if the command was there
> but returned "not implemented"?

IMO, no.  Because then projects become mazes of "not implemented"
messages.  Better to have people ask "where is <command X>"?

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to