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