From owner-freebsd-arm@FreeBSD.ORG Tue Nov 13 07:04:32 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E82FE8A4 for ; Tue, 13 Nov 2012 07:04:32 +0000 (UTC) (envelope-from br@mx.bsdpad.com) Received: from mx.bsdpad.com (mx.bsdpad.com [50.22.178.118]) by mx1.freebsd.org (Postfix) with ESMTP id C13558FC0C for ; Tue, 13 Nov 2012 07:04:32 +0000 (UTC) Received: from mx.bsdpad.com ([50.22.178.118]) by mx.bsdpad.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TYA9y-000HGd-Li; Tue, 13 Nov 2012 10:39:46 +0400 Received: (from br@localhost) by mx.bsdpad.com (8.14.5/8.14.5/Submit) id qAD6djRK066378; Tue, 13 Nov 2012 10:39:45 +0400 (MSK) (envelope-from br) Date: Tue, 13 Nov 2012 10:39:45 +0400 From: Ruslan Bukin To: Ian Lepore Subject: Re: exynos4412 hangs on enabling MMU Message-ID: <20121113063944.GA66146@jail.io> References: <20121030123231.GA91006@jail.io> <1351607803.1120.27.camel@revolution.hippie.lan> <7FA4A9AA-F217-4425-9A21-E0967237540C@bsdimp.com> <1352658212.1217.14.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1352658212.1217.14.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:04:33 -0000 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