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. > 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. You're mixing in *ALL KINDS* of stuff that's not MMU-related. Cache isn't. ETB isn't. Coprocessor access isn't. > 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. > 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... That's part of why I suggested that simpler answer. Really ... unless there's an active MMU, why even bother asking that question? The "break" came from trying to draw a needless distinction. > Should read/write to physical memory fail or succeed when > the CPU has no MMU? I'd say fail. Where I'd say "succeed" ... there is *ONLY* physical memory in such cases. (Note, that answer is consistent with the interpretation you gave above ... unlike a "fail" answer.) Any special casing should be for virtual addressing, and should boil down to that implicit identity mapping. > Say we provide default implementations that do "safe > no-op" for all fn's instead of failing. What would a NOP be though? How could it ever be "safe" if it tried to hide real errors, which must be handled? Treating virtual and physical addresses as being the same (for no-MMU targets) wouldn't be a NOP. > 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"... I don't follow. Disregarding all non-MMU stuff, and presuming the above commit gets reverted, what are the "no-ops" you refer to? > 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. 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. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
