From owner-freebsd-arm@FreeBSD.ORG  Sat May 24 17:23:30 2014
Return-Path: <owner-freebsd-arm@FreeBSD.ORG>
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 E8034A62;
 Sat, 24 May 2014 17:23:30 +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 B468F2CF4;
 Sat, 24 May 2014 17:23:30 +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 BF2A4FFD7;
 Sun, 25 May 2014 02:23:28 +0900 (JST)
Date: Sun, 25 May 2014 02:23:27 +0900 (JST)
Message-Id: <20140525.022327.158424841.toshi@ruby.ocn.ne.jp>
To: smith.winston.101@gmail.com
Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz)
From: SAITOU Toshihide <toshi@ruby.ocn.ne.jp>
In-Reply-To: <CADH-AwFWPn6=tRVATAOw=PoGO-0AvF8j-vv4Ko1An=0qqpbhuw@mail.gmail.com>
References: <1400768866.1152.231.camel@revolution.hippie.lan>
 <20140524.200837.142870524.toshi@ruby.ocn.ne.jp>
 <CADH-AwFWPn6=tRVATAOw=PoGO-0AvF8j-vv4Ko1An=0qqpbhuw@mail.gmail.com>
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, ian@freebsd.org
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 24 May 2014 17:23:31 -0000

In message: <CADH-AwFWPn6=tRVATAOw=PoGO-0AvF8j-vv4Ko1An=0qqpbhuw@mail.gmail.com>
            Winston Smith <smith.winston.101@gmail.com> writes:
> On Sat, May 24, 2014 at 7:08 AM, SAITOU Toshihide <toshi@ruby.ocn.ne.jp> wrote:
>>>> > 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.
> 
> Just to clarify; you applied the ti_prcm_clk_enable() to fix the
> 'non-linefetch abort' (above).

No. I revert back and update the source about two days before, and so
far, I can't reproduce the above failure.


>> 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]
> 
> But now you're running into these 'translation fault' traps?

But only very few, plus I may have a bias when operating power cycle
(for expecting the same result).

-- 
SAITOU Toshihide