On Mon, Nov 9, 2009 at 10:12 PM, David Brownell <davi...@pacbell.net> wrote: > On Monday 09 November 2009, Řyvind Harboe wrote: >> 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". > > My issue with that patch is that it should not be needed! > > If there is no mmu() method ... that's sufficient to > know that has_mmu() == false. Etc.
So all CPUs that have an MMU should implement this fn? OK. That would be just about all targets... >> What does virt2phys translation mean when no MMU >> is present or MMU is disabled? > > Simplest answer: it's an identity mapping. If there > is *ever* a question, treat a no-MMU target as if it's > an MMU-enabled target with a permanently installed > memory mapping equating virtual and physical addresses. Why should virt2phys not fail on CPUs with no MMU? Are we sure that *all* higher level code would do the right thing when we treat virt2phys as an identity mapping? Clearly the answer to that question is obvious, it just makes me wonder... Minimally we have to document that virt2phys MUST implement *only* a successful identity mapping when no MMU is supported for that target. > I don't follow. Disregarding all non-MMU stuff, > and presuming the above commit gets reverted, what > are the "no-ops" you refer to? Lets say we define a polymorphic cache flushing fn. Should it succeed as a no-op on targets without a cache or should it fail? >> Sorry for breaking the release(again) though. > > Are you saying there's some other bug related to the > MMU stuff, which made it into the v0.3.1 branch? > > You might have lost some context. The above patch, > which caused $SUBJECT bug, is newer than that. Ah. Phew! > I suspect the MMU stuff does need more thinking, > but I can't see any way for it to cause trouble > for no-MMU targets (like $SUBJECT) unless some > kind of inappropriate distinction gets made. But > unfortunately that patch (which I want to revert) > does make such a distinction. You're more up to speed on this issue than me currently... -- Ø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
