Jamey Hicks writes:
> In order to run with the I cache disabled, I would like to add the following
> instructions to __create_page_tables:

Why do you want to disable the I cache?

> Regarding your 2.3.34 patch: this code is now enabling the I cache before
> enabling the MMU.  Does this make two places where the I cache is enabled
> (here and proc-sa110.S)?  Would you accept a patch that conditionalizes this
> with #ifdef CONFIG_NOICACHE?

proc-sa110.S doesn't ever enable the I cache - it merely passes a value for the
control register to enable the caches and mmu's with, which head-armv.S uses.

> Regarding the 'mcr    p15, 0, r0, c1, c0' after __aligned_call.  The SA110
> manual does not specify when the MMU is enabled

It does - section 7.4: Interaction of the MMU, Icache, Dcache and Write Buffer

  To enable the MMU:

  (1) Program cr2
  (2) Program level 1 and level 2 page tables as required
  (3) Enable the MMU by setting bit 0 of the control register

  Note:
  Care must be taken if the translated address differs from the untranslated
  address as the three instructions following the enabling of the MMU will
  have been fetched using "flat translation" and enabling the MMU may be
  considered as a branch with delayed execution.

> or when the PC is updated by the following 'mov pc, lr'.

Any instructions following the mov pc, lr will be prefetched, but not executed.
Therefore, if they are from an invalid region that would generate an abort, the
abort is ignored by the StrongARM.

   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [EMAIL PROTECTED]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++        Please use [EMAIL PROTECTED] for           ++
++                        kernel-related discussions.                      ++

Reply via email to