On Mon, Nov 9, 2009 at 8:23 PM, David Brownell <davi...@pacbell.net> wrote: > On Monday 09 November 2009, Thomas Kindler wrote: >> btw: the current git-master still has the problem. > > Does it work if you replace that patch with > > git show d269122f91efaf2f745424c215fabb758b7e7ea0 |patch -p1 -R > > I don't like that patch at all. It adds needless clutter; > the same effect can be had without adding all those methods > and defaults. And it's the cause of this bug.
The only problem I see with going down the road of providing silent no-op defaults for generic MMU methods is that there may be methods that have a non-trivial "no-op". Some generic MMU/cache methods: virtual to physical translation, mmu enabled, flush cache line, flush data cache, generic embedded trace buffer fn's, more specifically mrc/mcr, etc. What does virt2phys translation mean when no MMU is present or MMU is disabled? Are addresses for a machine that has no MMU virtual/logic or physical? I'd say the answer is pick one to this particular question. My interpretation is that only an MMU can have logical/virtual addresses and that a non-MMU CPU has only physical addresses. This interpretation broke OpenOCD... Should read/write to physical memory fail or succeed when the CPU has no MMU? I'd say fail. Say we provide default implementations that do "safe no-op" for all fn's instead of failing. If you now invoke some higher level functionality that builds on these "safe no-op"'s you end up with a compound behavior that we can't really account for. I fear ending up in a situation where nobody dares touch the default "successful no-op" fn's because nobody knows what relies on their "no-op"... Sorry for breaking the release(again) though. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
