From owner-freebsd-arm@FreeBSD.ORG Sat May 24 11:08:40 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 7FD66F27; Sat, 24 May 2014 11:08:40 +0000 (UTC) Received: from msgw001-03.ocn.ad.jp (msgw001-03.ocn.ad.jp [180.37.203.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2FA1B21C8; Sat, 24 May 2014 11:08:39 +0000 (UTC) Received: from localhost (p12095-ipngn100104sizuokaden.shizuoka.ocn.ne.jp [153.185.230.95]) by msgw001-03.ocn.ad.jp (Postfix) with ESMTP id CEF0AAE2913; Sat, 24 May 2014 20:08:38 +0900 (JST) Date: Sat, 24 May 2014 20:08:37 +0900 (JST) Message-Id: <20140524.200837.142870524.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: <1400768866.1152.231.camel@revolution.hippie.lan> References: <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> <1400768866.1152.231.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: Sat, 24 May 2014 11:08:40 -0000 In message: <1400768866.1152.231.camel@revolution.hippie.lan> Ian Lepore writes: > 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. Thankyou for your infomation, I could revert back and svn up. But after that I lost .svn repository accidentally, so I can't tell a revision number (about ~two days before I think) for this report sorry. Anyway I will never do that. BEAGLEBONE config is changed to include beaglebone-black.dts, boot from SD by pressing S2, repeat power cycle and hit enter key randomly when ``Hit [Enter] to boot immediately''. result: 'external non-linefetch abort' was disappeared, and very few 'translation fault' was observed. vm_fault(0xc092d960, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0a26b30 FSR=00000005, FAR=00000018, spsr=80000193 r0 =c288d380, r1 =00000000, r2 =00000019, r3 =60000193 r4 =00000000, r5 =c288d380, r6 =00000006, r7 =c053e8fc r8 =c288d380, r9 =c28e928c, r10=c28e70c8, r11=c0a26b90 r12=00000000, ssp=c0a26b80, slr=c055fedc, pc =c0391098 [ thread pid 0 tid 100000 ] Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] It maybe that the test has lost the meagning but tried. without change: 3 error / 20 trial with change: 1 error / 20 trial I think operation bias exist from halfway through because the error disappear against my expectation (it's a happy thing though). -- SAITOU Toshihide