[linux-cirrus] Re: [PATCH] Re: FastBus mode, core running on HCLK

On Sat, 2007-02-03 at 21:53 +0100, Lennert Buytenhek wrote:
> On Sat, Feb 03, 2007 at 03:42:38PM -0500, Charles Moschel wrote:
> 
> > Until some more skilled can find where nF is being clobbered, or add
> > some code to see if it is or isn't set by the bootrom, how about this
> > patch?  It's against 2.6.20-rc7, and it works for me.
> 
> I have at least three ep93xx boards that boot in the right mode in
> 2.6.20-rcX, so it's unlikely that the mode setting is being clobbered
> by Linux.

Well, it _is_ set in the bootrom, but then it (looks to me) like it's
clobbered by redboot.  From
/~/sources/ecos/packages/hal/arm/arm9/ts7250/current/src/ts7250_misc.c:

 // Enable MMU
    asm volatile (
        "mcr    p15,0,%0,c1,c0,0;"
        "nop;nop;nop;nop;nop;nop;nop;nop;"
        :
        : "r"(MMU_Control_Init|MMU_Control_M)
        /* : */ );

(MMU_Control_Init | MMU_Control_M) evaluates to 0x0071.

What's the best way to fix this?

* Config option to force nF (and async?) bits on, as in patch I sent.
Not optimal, but duplicates what TS did in their 2.4 kernel.

* Do nothing upstream.  Would force TS users who use 2.6 to update
redboot (or use an out-of-tree patch as above).  Assumes an updated
redboot image would be made available by TS, and users would know about
it.

* Use the recently added adjust_cr() function to do this?  Could be part
of an ep93xx cpufreq patch.  Is anybody working on that?  [Pavels' imx
cpufreq patch added to 2.6.20 uses it to step into and out of FastBus
mode as part of the ARM920T speed changes.]

Regards, ......... Charlie

Other related posts: