From owner-freebsd-arm@FreeBSD.ORG  Sat May 24 16:49:29 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 34A1ACAA;
 Sat, 24 May 2014 16:49:29 +0000 (UTC)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com
 [IPv6:2a00:1450:400c:c05::22d])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 9FB5F2A22;
 Sat, 24 May 2014 16:49:28 +0000 (UTC)
Received: by mail-wi0-f173.google.com with SMTP id bs8so2265496wib.6
 for <multiple recipients>; Sat, 24 May 2014 09:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=4rfUF6F8jp7W2NuBTjGMGmze8RgrfACjYQeNjZYt/zg=;
 b=oh0q9P8CqcIzMUdNwLveb4PXejHntawYdR6oX306wTim3cQgVM1ychY3Npu/mp2Lg8
 OMkQ8gScKkdfKQLDEuT+YPZL/JryTyMyqnDxS3+StLetLQFa3PITkwuOiAlT2KYitCM4
 qrM/5lM9FG2YsEugnwj8nnU8DgVcbYm6JydO4wuL+U+I3saZdBapl4BhotpaaGplVKGg
 IajDw4Jt4Ke3jUQ/HSNkbLiYJme/KFqkmJ2OvcV+n5EeclntsLePEc21qkAprqDHx0qG
 QKc1gcoMreny3rYUahpMoBZioqojzeaErEnijOp6o27lOE37oDv0Q7tj5h7Hb3NlY/O0
 v56g==
MIME-Version: 1.0
X-Received: by 10.194.57.38 with SMTP id f6mr12362954wjq.59.1400950166857;
 Sat, 24 May 2014 09:49:26 -0700 (PDT)
Received: by 10.217.10.195 with HTTP; Sat, 24 May 2014 09:49:26 -0700 (PDT)
In-Reply-To: <20140524.200837.142870524.toshi@ruby.ocn.ne.jp>
References: <1400765234.1152.224.camel@revolution.hippie.lan>
 <20140522.231553.186386229.toshi@ruby.ocn.ne.jp>
 <1400768866.1152.231.camel@revolution.hippie.lan>
 <20140524.200837.142870524.toshi@ruby.ocn.ne.jp>
Date: Sat, 24 May 2014 12:49:26 -0400
Message-ID: <CADH-AwFWPn6=tRVATAOw=PoGO-0AvF8j-vv4Ko1An=0qqpbhuw@mail.gmail.com>
Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz)
From: Winston Smith <smith.winston.101@gmail.com>
To: SAITOU Toshihide <toshi@ruby.ocn.ne.jp>
Content-Type: text/plain; charset=UTF-8
Cc: FreeBSD ARM <freebsd-arm@freebsd.org>, Ian Lepore <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 16:49:29 -0000

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).


> 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?