From owner-freebsd-arm@FreeBSD.ORG Thu May 22 13:27:24 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72439597 for ; Thu, 22 May 2014 13:27:24 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44B1021DD for ; Thu, 22 May 2014 13:27:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnT1g-000218-U9; Thu, 22 May 2014 13:27:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4MDRE9n046354; Thu, 22 May 2014 07:27:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Iv7VZXSVNd5d6gaSHb40D Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: SAITOU Toshihide In-Reply-To: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 07:27:14 -0600 Message-ID: <1400765234.1152.224.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:27:24 -0000 On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote: > In message: > Winston Smith writes: > > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide wrote: > >> If abort like > >> > >> musbotg0: TI AM335X USBSS v0.0.13 > >> Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > >> trapframe: 0xc0a2eb60 > > > > I see this with the 1Ghz uboot, it occurs about 50% of the time, see: > > > > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200 > > Although it is an ad hoc workaround but ``usb start'' at u-boot command > prompt (someone mentioned before) or add device_printf("!\n") before > ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of > am335x_usbss.c prevent this panic for me. An 'external non-linefetch abort' on a TI chip usually means that the clocks for a device never got turned on and you attempted to read or write a register in that device. If 'usb start' makes the problem go away, that tends to confirm that thought. The thing is, I don't understand why adding a printf to the code with no other changes would help in any way. I though maybe it was adding some delay to allow the clock-start call to take effect, but the clock enable call is after the USBSS_REVREG read, and that seems wrong. Does it fix the problem to move the ti_prcm_clk_enable() call to be before the USBSS_REVREG read in attach? -- Ian