From owner-freebsd-arm@FreeBSD.ORG Thu May 22 14:27:51 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CE2AA0 for ; Thu, 22 May 2014 14:27:51 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 411C32777 for ; Thu, 22 May 2014 14:27:51 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WnTyH-0006xa-QF; Thu, 22 May 2014 14:27:50 +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 s4MERkF0046436; Thu, 22 May 2014 08:27:46 -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: U2FsdGVkX18RU3XJjtt3a15o0iZXCJCp Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Ian Lepore To: SAITOU Toshihide In-Reply-To: <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> References: <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 2014 08:27:46 -0600 Message-ID: <1400768866.1152.231.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 14:27:51 -0000 On Thu, 2014-05-22 at 23:15 +0900, SAITOU Toshihide wrote: > 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. > If you have done svn up -rnnnnn on individual files, I think svn will then leave those files at that revision when you do future updates. Doing 'svn revert -R .' in the src directory should get everything reset so that 'svn up' will pull the latest versions of everything again. Of course, it will also revert *every* change you've made under src, so use it carefully! It should be faster than checking out a fresh copy, and you can still do a -DNO_CLEAN build and rebuild just the things that have changed. Of course you can also use svn revert on a single file or directory too. -- Ian