Cache enabled with MMU Disabled on VxWorks 5.4 PPC - VxWorks

This is a discussion on Cache enabled with MMU Disabled on VxWorks 5.4 PPC - VxWorks ; Hello All, Do you know if VxWorks 5.4, for PPC603 really enables cache if MMU is disabled (INCLUDE_MMU_XXX is not defined), but caches are enabled? I am using BAT entries to mark parts or RAM to control cachability. The main ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

  1. Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    Hello All,

    Do you know if VxWorks 5.4, for PPC603 really enables cache if MMU is
    disabled (INCLUDE_MMU_XXX is not defined), but caches are enabled? I
    am using BAT entries to mark parts or RAM to control cachability.

    The main problem I have is that with MMU as well as Data Cache
    enabled, my vxworks hangs (sometimes before giving me the prompt, and
    sometimes after giving me the shell prompt). I am trying to isolate
    the issue and wanted to make sure if caches are enabled if I dont use
    MMU.

    Thanks for all the responses.
    - Sameer

  2. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    On Apr 11, 3:35 pm, sameer wrote:
    > Hello All,
    >
    > Do you know if VxWorks 5.4, for PPC603 really enables cache if MMU is
    > disabled (INCLUDE_MMU_XXX is not defined), but caches are enabled? I
    > am using BAT entries to mark parts or RAM to control cachability.
    >
    > The main problem I have is that with MMU as well as Data Cache
    > enabled, my vxworks hangs (sometimes before giving me the prompt, and
    > sometimes after giving me the shell prompt). I am trying to isolate
    > the issue and wanted to make sure if caches are enabled if I dont use
    > MMU.


    Unless you've got a botched up BSP, enabling caches is totally
    independent of enabling MMU.
    It is possible you have a BSP that was written by a confused person
    who set things up so
    that disabling MMU forces disabled cache.
    Having said that, if you do have cache on and MMU off, it is very
    unlikely that your system will boot.

    HTH,
    GV



  3. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    > Unless you've got a botched up BSP, enabling caches is totally
    > independent of enabling MMU.
    > It is possible you have a BSP that was written by a confused person
    > who set things up so
    > that disabling MMU forces disabled cache.


    I have a standard reference BSP, which inits things based on the usual
    "INCLUDE_XXX" flags. If the MMU is enabled, it enables MMU, if cache
    is enabled, it enables whatever caches are configured to be enabled.
    And this enabling/disabling happens through the VxWorks APIs.

    > Having said that, if you do have cache on and MMU off, it is very
    > unlikely that your system will boot.


    Oh really! I was not aware of that. Thanks for pointing that out.
    Any idea what is the reason for system to not boot in this
    configuration?


  4. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    On Apr 11, 11:34 pm, sameer wrote:
    >
    > Oh really! I was not aware of that. Thanks for pointing that out.
    > Any idea what is the reason for system to not boot in this
    > configuration?


    If the MMU is not enabled, the entire address space is cacheable and
    not guarded.
    This alone makes initializing hardware difficult -- carefully written
    code is required.
    If the caches are enabled, then it's just about impossible to
    successfully interact with devices.
    And, if you can't interact with devices, your system will misbehave in
    some way.

    HTH
    GV


  5. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    Umm I agree that if the cache is enabled for entire memory space,
    without MMU enabled, I might have problems. But if I use BAT
    registers and specify my device memory portions as "cache inhibit",
    should I not be safe?

    Or I have got it completely wrong and the truth is that not defining
    "INCLUDE_MMU_[BASIC/FULL] disables BAT as well as PTE (somehow I
    understood it as not including MMU disables just the PTEs).

    > > Oh really! I was not aware of that. Thanks for pointing that out.
    > > Any idea what is the reason for system to not boot in this
    > > configuration?

    >
    > If the MMU is not enabled, the entire address space is cacheable and
    > not guarded.
    > This alone makes initializing hardware difficult -- carefully written
    > code is required.
    > If the caches are enabled, then it's just about impossible to
    > successfully interact with devices.
    > And, if you can't interact with devices, your system will misbehave in
    > some way.
    >
    > HTH
    > GV



  6. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    On Apr 12, 3:28 pm, sameer wrote:
    > Umm I agree that if the cache is enabled for entire memory space,
    > without MMU enabled, I might have problems. But if I use BAT
    > registers and specify my device memory portions as "cache inhibit",
    > should I not be safe?
    >
    > Or I have got it completely wrong and the truth is that not defining
    > "INCLUDE_MMU_[BASIC/FULL] disables BAT as well as PTE


    Yes, you have it wrong.

    HTH,
    GV

  7. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    Thank you for the clarification. In the hindsight, it does explain a
    lot of things I have been observing (and ignoring :-)).



    On Apr 13, 6:12 am, gvarndell wrote:
    > On Apr 12, 3:28 pm, sameer wrote:
    >
    > > Umm I agree that if the cache is enabled for entire memory space,
    > > without MMU enabled, I might have problems. But if I use BAT
    > > registers and specify my device memory portions as "cache inhibit",
    > > should I not be safe?

    >
    > > Or I have got it completely wrong and the truth is that not defining
    > > "INCLUDE_MMU_[BASIC/FULL] disables BAT as well as PTE

    >
    > Yes, you have it wrong.
    >
    > HTH,
    > GV



  8. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    On Apr 13, 1:06 pm, sameer wrote:
    > Thank you for the clarification. In the hindsight, it does explain a
    > lot of things I have been observing (and ignoring :-)).


    You're probably not the first person who thought the BAT registers
    could be used in lieu of the MMU, but they are part of it, not a
    substitute for it.
    For simplicity, declare at least the system RAM in the sysPhysMemDesc
    table.
    If there are any odd-ball memory spaces too small to be worth devoting
    a BAT to, put them in there too.
    To the extent you can, try arrange PCI outbound windows in a
    contiguous memory space that is suitably aligned for BAT use.
    And don't forget to map the boot ROM or flash so that reboot will
    work..

    HTH,
    GV

  9. Re: Cache enabled with MMU Disabled on VxWorks 5.4 PPC

    Thanks once again GV. Actually, I did start by using both BAT and
    sysPhyMemDesc, as you suggested, but then my system wont boot at all
    (more about that in the next para). Thats when I tried moving
    everything to BAT and, in a desperate attempt, marked all memory as
    CACHE_INHIBIT in BAT, to eliminate any coherency issues that might be
    there. To eliminate the possibility of cache being the culprit, I was
    also playing with cacheEnable/cacheDisable scenarios, and hence the
    question.

    Now as to why my system was not coming up with sysPhyMemDesc[]. Found
    this simple answer, the hard way. This was an inherited BSP from an
    older product, and I added more RAM to it. We are partitioning the
    memory for use by vxWorks and by the main application (which has its
    own memory manager). When I updated the sysPhyMemDesc to reflect more
    memory, I overlooked the fact that this will need a larger PTE table
    and I need to provide more memory to vxWorks partition. As soon as I
    provided extra memory, things started working.

    I am still puzzled however by the fact that system hangs randomly, if
    I enable cache and mark all RAM as CACHE_INHIBIT. This is
    irrespective of whether I use BAT, or PTEs for translation. Still
    working on it.

    Thanks once again.

    On Apr 15, 3:36 am, gvarndell wrote:
    > On Apr 13, 1:06 pm, sameer wrote:
    >
    > > Thank you for the clarification. In the hindsight, it does explain a
    > > lot of things I have been observing (and ignoring :-)).

    >
    > You're probably not the first person who thought the BAT registers
    > could be used in lieu of the MMU, but they are part of it, not a
    > substitute for it.
    > For simplicity, declare at least the system RAM in the sysPhysMemDesc
    > table.
    > If there are any odd-ball memory spaces too small to be worth devoting
    > a BAT to, put them in there too.
    > To the extent you can, try arrange PCI outbound windows in a
    > contiguous memory space that is suitably aligned for BAT use.
    > And don't forget to map the boot ROM or flash so that reboot will
    > work..
    >
    > HTH,
    > GV



+ Reply to Thread