I tried both patches, neither one works on my system.
r0 is set to 517d on entry to aligned_call which is
the setting for C1 of the mmu. Bits 6 and 14 look
suspect to me but clearing them them in any
combination has not effect.
--- Russell King - ARM Linux Admin
<[EMAIL PROTECTED]> wrote:
> Jamey Hicks writes:
> > > The system hangs after executing the
> instruction to
> > > enable the mmu "mcr p15, 0, r0, c1, c0"
> located a
> > > few lines after the "aligned_call:" label. If
> I
> > > comment out that instruction, it hangs on the
> next
> > > instruction trying to jump to
> .Lalready_done_mmap via
> > > the "mov pc,lr" instruction. (Sounds like
> an
> > > addressing problem to me)
> > This code that initially enables the MMU is very
> fragile -- it depends on
> > the timing of the instructions being exactly
> right. As it is now, the MMU
> > must be enabled after the "mov pc, lr" instruction
> is fetched but before it
> > is executed.
>
> You are correct that it is very fragile. There
> have, however, been problems
> have been caused by the kernel image growing past
> the 2MB size. This has
> been fixed in new kernels.
>
> > (A) If the MMU is enabled before the mov is
> fetched, then you
> > get a instruction fetch fault because there is no
> mapping in the MMU table
> > for addresses in the 0x8000 page.
>
> The current code breaks if the Icache is disabled
> (since there will be
> 3 fetches flat after the mcr).
>
> Looking through the patch, I have the following
> comments:
>
> > --- linux/arch/arm/kernel/head-armv.S Wed Nov 24
> 01:23:11 1999=0A=
> > +++ linux-2.3.29/arch/arm/kernel/head-armv.S Mon
> Dec 27 11:11:05 =
> > 1999=0A=
> > @@ -74,6 +74,15 @@=0A=
> > __entry: teq r0, #0=0A=
> > movne r0, #'i'=0A=
> > bne __error=0A=
> > + mov r6, #0xbc000000
> > + mcr p15, 0, r0, c7, c5, 0 @ flush I cache
> > + mcr p15, 0, r0, c7, c10, 4 @ drain WB
> > + mrc p15, 0, r5, c1, c0, 0
> > + str r5, [r6, #0x22]
> > + bic r5, r5, #0x1000
> > + bic r5, r5, #0x000c
> > + mcr p15, 0, r5, c1, c0, 0
> > + str r5, [r6, #0x44]
>
> This should not be necessary, and is not the right
> way to fix the problem.
> This is processor independent code, so it's not good
> to add unconditional
> processor dependencies to it. Can you explain why
> you need this?
>
> > #ifdef CONFIG_ALIGNMENT_TRAP
> > orr r0, r0, #2 @ ...........A.
> > #endif
> > + b __own_cacheline
> > + .align 5
> > +__own_cacheline:
> > mcr p15, 0, r0, c1, c0
> > + mov r0, r0
> > + mov r0, r0
> > + mov r0, r0
> > + mov r0, r0
> > + mov r0, r0
> > mov pc, lr
>
> According to the SA110 documentations, this will
> most definitely break.
> The mov pc, lr will not always be fetched before the
> mcr takes effect,
> especially when the I-cache is off.
>
> > @@ -156,12 +173,37 @@=0A=
> > str r3, [r0], #4=0A=
> > teq r0, r2=0A=
> > bne 1b=0A=
> > +__create_page_table_entries_for_kernel: =0A=
> > + /*=0A=
> > + * map in 2MB for the location of the kernel
> before the MMU is =
> > enabled.=0A=
> > + */=0A=
> > + add r0, r4, #0x8000 >> 18=0A=
> > + mov r3, #0x0c @ SECT_CACHEABLE |
> SECT_BUFFERABLE=0A=
> > + orr r3, r3, r8 @
> page table flags=0A=
> > + add r3, r3, r5 @
> start of DRAM=0A=
> > + str r3, [r0], #4=0A=
> > + add r3, r3, #1 << 20 @
> next 1MB segment =
> > address=0A=
> > + str r3, [r0], #4=0A=
> > +#ifdef CONFIG_FOOTBRIDGE =0A=
> > + /*=0A=
> > + * map in 1MB for the flash before the MMU is
> enabled.=0A=
> > + * and map in 1MB for the
> corelogic=0A=
> > + */=0A=
> > + add r0, r4, #0x41000000 >> 18=0A=
> > + mov r3, #0x0c @ SECT_CACHEABLE |
> SECT_BUFFERABLE=0A=
> > + orr r3, r3, r8 @
> page table flags=0A=
> > + add r3, r3, r5 @
> start of DRAM=0A=
> > + add r3, r3, #0x41000000
> @ =
> > physical address of FLASH=0A=
> > + str r3, [r0], #4
> =0A=
> > + add r3, r3, #0x01000000 @
> physical address of =
> > footbridge=0A=
> > + str r3, [r0], #4=0A=
> > +#endif =0A=
>
> Err, wtf? The kernel pages are already setup by the
> code fragment that
> follows this section you added. Also, the stuff for
> mapping in the
> footbridge and flash should not be required. Can
> you explain why you've
> added this?
>
> Here is a cleaner patch, which will be in the next
> 2.3.34 patch:
>
> --- linux-orig/arch/arm/kernel/head-armv.S Sun Dec
> 19 15:39:32 1999
> +++ linux/arch/arm/kernel/head-armv.S Tue Dec 28
> 22:49:05 1999
> @@ -95,12 +95,18 @@
> .long SYMBOL_NAME(init_task_union)+8192
>
> /*
> - * This needs to be aligned to a cache line.
> + * This needs to be aligned to a cache line, and
> the
> + * MMU and cache turned on separately.
> */
> .align 5
> __aligned_call:
> ldr lr, __switch_data
> - mcr p15, 0, r0, c1, c0
> + bic r3, r0, #1
> + mcr p15, 0, r3, c1, c0 @ turn caches on
> + mov r0, r0
> + mov r0, r0
> + mov r0, r0
> + mcr p15, 0, r0, c1, c0 @ turn mmu on
> mov pc, lr
>
> /*
>
> _____
> |_____|
> -------------------------------------------------
> ---+---+-
> | | Russell King
> [EMAIL PROTECTED] --- ---
> | | | |
> http://www.arm.linux.org.uk/~rmk/armlinux.html /
> / |
> | +-+-+
> --- -+-
> / | THE developer of ARM Linux
> |+| /|\
> / | | |
> --- |
> +-+-+
> -------------------------------------------------
> /\\\ |
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://messenger.yahoo.com
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
