From owner-freebsd-arm@FreeBSD.ORG Tue Apr 29 15:22:53 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 CB467801 for ; Tue, 29 Apr 2014 15:22:53 +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 8B0C9131A for ; Tue, 29 Apr 2014 15:22:53 +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 1Wf9rw-0001sE-2O; Tue, 29 Apr 2014 15:22:52 +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 s3TFMmT1016359; Tue, 29 Apr 2014 09:22:48 -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: U2FsdGVkX1+cZdoKGgeZxmnxS91PlniR Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC From: Ian Lepore To: Winston Smith In-Reply-To: References: <1398618984.61646.165.camel@revolution.hippie.lan> <1398624759.61646.174.camel@revolution.hippie.lan> <1398648505.61646.189.camel@revolution.hippie.lan> <1398732508.61646.245.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Apr 2014 09:22:48 -0600 Message-ID: <1398784968.22079.13.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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 15:22:53 -0000 On Tue, 2014-04-29 at 10:51 -0400, Winston Smith wrote: > On Mon, Apr 28, 2014 at 8:48 PM, Ian Lepore wrote: > > Okay, all done. As of r265071 all the recent ubldr changes have been > > merged to the 10-stable branch and should work to boot eMMC on BBB. > > Unless I missed something, the ubldr in 10-stable should now be the same > > as the one in -current. > > Hmmm ... 10-STABLE builds and boots from eMMC, but I'm now running > into a vm_fault when it tries (and fails) to set up the ethernet PHY: > > u-boot: > Net: not set. Validating first E-fuse MAC > Phy not found > PHY reset timed out > > > kernel: > ... > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff > irq 40,41,42,43 on simplebus0 > cpsw0: CPSW SS Version 1.12 (0) > cpsw0: Initial queue size TX=128 RX=384 > cpsw0: Ethernet address: 90:59:ef:4c:28:d7 > cpsw0: Failed to read from PHY. > cpsw0: attaching PHYs failed > > vm_fault(0xc07e2ad0, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc08e2af0 > FSR=00000005, FAR=00000018, spsr=80000093 > r0 =c27c8680, r1 =00000000, r2 =00000019, r3 =60000193 > r4 =00000000, r5 =c27c8680, r6 =00000006, r7 =c053c8a8 > r8 =c27c8680, r9 =c281b28c, r10=c28190c8, r11=c08e2b50 > r12=00000000, ssp=c08e2b40, slr=c055a590, pc =c038e374 > > [ thread pid 0 tid 100000 ] > Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] > db> > > > > The full bootlog is below. I'm not entirely sure that this isn't > something I've broken myself (I was messing with the > beaglebone_black.dts file yesterday!), although I thought I had > rebuilt everything properly -- and the same image boots from the SD > card. > > Here's the full log: > > > > U-Boot SPL 2013.04 (Apr 29 2014 - 08:26:49) > OMAP SD/MMC: 0 > mmc_send_cmd : timeout: No status update > reading bb-uboot.img > reading bb-uboot.img > > > U-Boot 2013.04 (Apr 29 2014 - 08:26:49) > > I2C: ready > DRAM: 512 MiB > WARNING: Caches not enabled > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net: not set. Validating first E-fuse MAC > Phy not found > PHY reset timed out > cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc1(part 0) is current device > SD/MMC found on device 1 > reading bb-uEnv.txt > reading bbubldr > 251703 bytes read in 37 ms (6.5 MiB/s) > reading bboneblk.dtb > 15278 bytes read in 8 ms (1.8 MiB/s) > Booting from mmc ... > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @9f242240 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@freebsd, Mon Apr 28 22:09:48 EDT 2014) > > DRAM: 512MB > MMC Device 2 not found > MMC Device 3 not found > MMC Device 2 not found > Number of U-Boot devices: 3 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=0 slice= partition=...MMC Device 2 not found > MMC Device 3 not found > disk0: device open failed with error=2, handle=1 > > Checking unit=1 slice= partition=... good. > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x468f08+0x17d8dc syms=[0x4+0x84b30+0x4+0x501f3] > /boot/kernel/geom_label.ko text=0x50dc data=0x864+0x30 > syms=[0x4+0x1020+0x4+0xfe2] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x0x80000100. This may be the problem -- ubldr's behavior for finding and using dtb files is more complex than it used to be. It may be that it used to claim to find and use the u-boot dtb, but it was really using a static dtb compiled into the kernel. Now if u-boot provides a valid dtb it'll actually get used, even if kernel has a static dtb compiled in. If you remove the u-boot env var 'fdtaddr' then it will fall back to using a compiled-in dtb file instead of a loaded one. What I've been doing these days is installing my dtb files in /boot/modules or /boot/kernel and then setting the dtb file name in a u-boot env var named fdtfile. That makes ubldr find and load the named file in the place it finds the kernel. -- Ian