From owner-freebsd-arm@FreeBSD.ORG Thu May 22 16:56:04 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 D3DAC771; Thu, 22 May 2014 16:56:04 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 199E925A5; Thu, 22 May 2014 16:56:03 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id ec20so1268084lab.19 for ; Thu, 22 May 2014 09:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jw5n9B2wyqZXA3xQaHHAk9J2W/CyUfsXLrSoC2c3yT0=; b=Co1sar9UEjIikE5n/4+ocVu8Nv+sgT0KzGqc1aj2RJxdNEMZ5ZxsmfiKhHaFEpOuKR Lrkc8fc/uFabgWwR5anlJftBSVlE5fyJmhZr1wMc+Aa1Kk+w+N5cj1t/CEvbyQ2mC/4k 5eck1NI/LDe1C9mZgHACbdPtfAXPi7tLZxbv8q4wESfmYQuM4mDO13JzC9SsOqyCkE8S UUEG10Hmh6bic238BudrXj098Dtz7Q2sYDGn4tp4RzPzNI2DljIWboSNVzRF5DjkWKsL aY22rUfOnpUR7BFQumglbxFLdmWFkx1374Zw8OIqeZvsbaH8JjZgFN/CLl/tU/M6f/YX tbVA== MIME-Version: 1.0 X-Received: by 10.152.43.98 with SMTP id v2mr2152933lal.83.1400777761899; Thu, 22 May 2014 09:56:01 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.141.196 with HTTP; Thu, 22 May 2014 09:56:01 -0700 (PDT) In-Reply-To: <1400772412.1152.250.camel@revolution.hippie.lan> References: <20140521.214356.02299991.toshi@ruby.ocn.ne.jp> <20140522.002051.68155865.toshi@ruby.ocn.ne.jp> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <537DF45D.8010304@hot.ee> <1400772412.1152.250.camel@revolution.hippie.lan> Date: Thu, 22 May 2014 12:56:01 -0400 X-Google-Sender-Auth: q25cFOGVMjM_bYtSZ4cYXPO0nLw Message-ID: Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm 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 16:56:04 -0000 On Thu, May 22, 2014 at 11:26 AM, Ian Lepore wrote: > On Thu, 2014-05-22 at 15:58 +0300, Sulev-Madis Silber (ketas) wrote: > > On 2014-05-22 14:46, SAITOU Toshihide wrote: > > > In message: < > CADH-AwGb36EUknNofdch1Q4Pn8GAN+Ep9SdiJ_f7Q2v9e4kW1g@mail.gmail.com> > > > Winston Smith writes: > > >> On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide < > toshi@ruby.ocn.ne.jp> 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. > > > > > > Anyway I understand my procedure is workaround, and is working by > > > chance or side effect, but eMMC boot and 1000 MHz operation is fun. > > > > > > > > > I wish I could get that working too... I tried to trace device detection > > path in loader but only found that the problem must be in uboot. Since > > loader is program that runs in uboot. At least now I know how that works > > a bit more. But actual issue remains unresolved. What's weird is how I > > actually boot from eMMC and it's present in uboot... Loader comes from > > eMMC and then loader suddenly has no devices inside it. The hell is that. > > I vaguely remember Patrick Kelsey mentioning something a while back > about having u-boot patches to fix some problem in device enumeration > API so that ubldr could see all the devices properly. Maybe that's > needed to fix this problem? > > I've added him to the cc list. > The u-boot device enumeration patches I developed were against u-boot 2013.04 and they are part of crochet builds if you build for that u-boot version. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot-2013.04_api_api_storage.c.patch The above patch changes storage device enumeration in two ways. The first is that it correctly sets the 'more' flag when starting enumeration, so it is actually possible to enumerate more than one storage device. The second is that it treats a found block device of type DEV_TYPE_UNKNOWN as a block device of size zero, instead of a failure to find anything. This second change allows storage drivers, such as the mmc driver, to report an empty card slot as a zero-sized block device of unknown type and have it appear in the enumeration results. https://github.com/kientzle/crochet-freebsd/blob/master/board/BeagleBone/files/uboot-2013.04_drivers_mmc_mmc.c.patch The above patch patch changes the mmc driver so it reports empty card slots (really, any failing device) as zero-sized devices of type DEV_TYPE_UNKNOWN. These two patches together result in the enumeration of both the SD card slot and the eMMC device on the BBB no matter where you booted from and no matter whether the SD card slot is empty or occupied. The other patches for 2013.04 in crochet make sure the full u-boot image knows which device was booted from so that ubldr is loaded from the same device. I found this to be important for my sanity when valid, but differing, images were present on both the SD card and the eMMC. If you aren't running u-boot code with the above fixes or something functionally equivalent, you can wind up with some frustrating outcomes, as outlined below. When booting from SD or eMMC, the first thing that the ROM code runs is the SPL, which is a stripped down u-boot that is configured to use whatever MMC controller the ROM code told it was used to boot from. So for the SPL, the storage/mmc device enumeration code never comes into play. If the processor boots from the eMMC, the SPL will see the eMMC and load the full u-boot from there. This part is pretty much foolproof. Next, the full u-boot is running, and what happens next depends on what kind of device enumeration code you have in u-boot, and possibly also what you have in the SD card slot. The unmodified 2013.04 code will fail if there is nothing in the SD card slot, because it will only look there and find nothing (this is my guess as to what is being described above). If there is something in the SD card slot, it will find it and try to continue with what is on it. Either way though, it is actually unaware of the eMMC device from which it was loaded. In other words, the best case for eMMC booting with unmodified 2013.04 u-boot is that you run the SPL off of eMMC, load the full u-boot from the eMMC, then proceed with what is on the SD card. I haven't yet taken a look at what is new and different, if anything, in storage device enumeration in 2014.04, and thus which of my 2013.04 patches need to be applied there as well. -Patrick