exynos4412 hangs on enabling MMU

[Ruslan Bukin]

On Sun, Nov 11, 2012 at 11:23:32AM -0700, Ian Lepore wrote:
> On Tue, 2012-10-30 at 10:08 -0600, Warner Losh wrote:
> > On Oct 30, 2012, at 8:36 AM, Ian Lepore wrote:
> > 
> > > On Tue, 2012-10-30 at 16:32 +0400, Ruslan Bukin wrote:
> > >> hello!
> > >> 
> > >> exynos hangs on mcr cmd in this context:
> > >> 
> > >> /* Enable MMU */
> > >> [..]
> > >> orr     r0, r0, #(CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_DC_ENABLE)
> > >> mcr     p15, 0, r0, c1, c0, 0
> > >> [..]
> > >> 
> > >> without CPU_CONTROL_MMU_ENABLE flag, mcr command works,
> > >> but board hangs again on line:
> > >> str r3, [r1], #0x0004 /* get zero init data */
> > >> 
> > >> any suggestions?
> > >> 
> > >> -Ruslan
> > > 
> > > I don't have a direct answer to your question, but there is something
> > > related that I've always wondered about locore.S...  It starts by
> > > assuming the bootloader turned on the data cache, so it disables it,
> > > then it sets up TTB and TLB and other MMU-related stuff, then it turns
> > > back on the cache.  
> > > 
> > > Shouldn't it have flushed the cache in there somewhere before turning it
> > > back on?  
> > > 
> > > The part I don't know is whether the cache flush happens implicitly as a
> > > side effect of some of the other cp15 commands for setting up the MMU.
> > > 
> > > Also, I have no idea whether this is related or not, but on armv4
> > > platforms on -current, the kernel init locks up somewhere in initarm()
> > > about 20% of the time.  It locks up at different points, sometimes it
> > > only makes it few lines into initarm(), sometimes it gets almost to the
> > > end before locking up.  The variability makes me think it's somehow
> > > related to caching or the MMU or something like that.  It's a problem
> > > that never happens on freebsd 8, but I haven't had time yet to start
> > > bisecting the changes to see where it quit working.
> > 
> > I'd be interested in tracking that down...  I've been booting lots of armv5 boards lately and haven't seen this hang with current.
> > 
> > Warner
> 
> So my mission this morning was to track this down, and I started by
> diff'ing the current locore.S against the one from freebsd 8.2 that I
> know for sure never hangs.  The significant difference jumped out at me
> right away, and it's the code Ruslan referenced in his original post.
> 
> It appears there was a paste-o or mis-merge when the armv6 support came
> in; it turns on the data cache too early.  Usually this is harmless (at
> least for me), but sometimes there'll be something in the cache that
> causes a hang, either immediately (as happens to Ruslan) or later when
> some innocuous instruction sequence (such as returning from a function
> call) stumbles across stale cache data and wanders into the weeds.
> 
> The attached patch fixes the problem, turning on the MMU but not
> enabling data cache until later in the kernel init (it happens during
> cpu_setup()).  There is a similar sequence to enable the MMU and data
> cache at the bottom of locore.S.  I think it's the code that enables
> processors other than the primary/boot.  Maybe it's okay to enable the
> cache in that context, or maybe it's another paste-o.  I didn't change
> it because I can't test that code.
> 
> For testing, I inserted a call to kern_reboot() in start_init() so that
> I could get several different units here (atmel rm92 and sam9) all
> rebooting constantly to see if they'd hang.  With the original locore.S
> they always hang within 6-8 reboot cycles.  With the patched code
> they've been rebooting continuously for several hours without a single
> hang.
> 
> -- Ian
> 

Hi, Ian,

Sorry, I have recently reverted locore.S and it works :)
Not sure what it was, may be some misconfiguration.
so locore works from current

nevertheless, locore.S works with your patch fine,
but I don't think I good tester because I still
have problems in machine-dependent part
(I have messages like 
"WARNING: Some AP's failed to start")

-Ruslan