Re: [ECOS] PowerPC cyg_hal_default_exception_vsr Bug?

["Jeffrey R. Szczepanski" <jrs at inscitek dot com>]

> On all PowerPC platforms, except for the 40x, cache control is
> independent of MMU settings.  The only way I can see that you
> would have a problem is if you happened to have a stack in an
> area of memory which was purposefully cache disabled using the
> MMU.  This would certainly not be normal (nor even desirable IMO)
>
> Perhaps you care to explain how the cache-ability might change
> with the MMU setting (other than what I've just outlined)?

Academic argument first: Well, I think your answer explains why it typically 
works, not what is technically "correct" from an architecture perspective. 
That is, with this being in the "arch" implementation under PowerPC, the 
code should be conservative and not assume anything about what variants or 
platforms might be doing (or not doing) with the caches and the MMU.

The practical problems of not re-enabling first can be subtle:
   - Coherency of the Level1/Level2 Caches: Real Mode (w/o MMU) specifies 
copy back of data accesses. If write-through was being used you have 
unexpected dirty data in the caches that has to be potentially dealt with 
depending on the Level1/Level2 cache strategy and if for example I/O bus 
operations (like from PCI) snooping is being used or not. Clearly, if the 
associated region was cahce inhibited completely, as you mentioned, there is 
definately a problem created. That is, once the MMU is turned on, changes 
hanging around in the cache are lost if the area happens to be inhibited 
with the WIMG bits.
   - MMU Page tables: Until MMU is re-enabled any translation settings in 
the BAT/PTE will be ignored. If Virtual and Physical addresses are not setup 
to be equal where the stack is located, this work not work either.

Regards,
Jeff

jrs at inscitek dot com






--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss