From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:15:55 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 D1BCE685; Thu, 22 May 2014 14:15:55 +0000 (UTC) Received: from msgw002-04.ocn.ad.jp (msgw002-04.ocn.ad.jp [180.37.203.79]) by mx1.freebsd.org (Postfix) with ESMTP id 9F489266E; Thu, 22 May 2014 14:15:55 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw002-04.ocn.ad.jp (Postfix) with ESMTP id 2EC37FFD1; Thu, 22 May 2014 23:15:54 +0900 (JST) Date: Thu, 22 May 2014 23:15:53 +0900 (JST) Message-Id: <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: SAITOU Toshihide In-Reply-To: <1400765234.1152.224.camel@revolution.hippie.lan> References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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 14:15:55 -0000 In message: <1400765234.1152.224.camel@revolution.hippie.lan> Ian Lepore writes: > 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? I will try ti_prcm_clk_enable() at the weekend. But someone's report would be appriciated because I remove the src and svn up now. -- SAITOU Toshihide