From owner-freebsd-arm@freebsd.org Thu Jan 4 05:42:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3868BE8B9B5 for ; Thu, 4 Jan 2018 05:42:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DAE987AF8D; Thu, 4 Jan 2018 05:42:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w045gbkk015841 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jan 2018 21:42:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w045gafF015840; Wed, 3 Jan 2018 21:42:37 -0800 (PST) (envelope-from fbsd) Date: Wed, 3 Jan 2018 21:42:36 -0800 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI2 boot hangs with red light on Message-ID: <20180104054236.GA15764@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515039689.1759.27.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 05:42:39 -0000 On Wed, Jan 03, 2018 at 09:21:29PM -0700, Ian Lepore wrote: > > There are no architectural differences between ubldr built for armv6 vs > armv7, and either version could load either flavor of kernel. ?There > have been some bugfixes applied to ubldr in the past few months. > > -- Ian It seems the problems lie elsewhere. I've updated the contents of /boot/msdos to -rwxr-xr-x 1 root wheel 1494 Jan 3 20:45 LICENCE.broadcom -rwxr-xr-x 1 root wheel 50248 Jan 3 20:45 bootcode.bin -rwxr-xr-x 1 root wheel 75 Jan 3 20:45 config.txt -rwxr-xr-x 1 root wheel 6551 Jan 3 20:45 fixup.dat -rwxr-xr-x 1 root wheel 2578 Jan 3 20:45 fixup_cd.dat -rwxr-xr-x 1 root wheel 9694 Jan 3 20:45 fixup_db.dat -rwxr-xr-x 1 root wheel 9694 Jan 3 20:45 fixup_x.dat -rwxr-xr-x 1 root wheel 13419 Jun 26 2017 rpi2.dtb -rwxr-xr-x 1 root wheel 2820196 Jan 3 20:45 start.elf -rwxr-xr-x 1 root wheel 667460 Jan 3 20:45 start_cd.elf -rwxr-xr-x 1 root wheel 4956676 Jan 3 20:45 start_db.elf -rwxr-xr-x 1 root wheel 3904228 Jan 3 20:45 start_x.elf -rwxr-xr-x 1 root wheel 380264 Jan 3 20:33 u-boot.bin -rwxr-xr-x 1 root wheel 892172 Jan 3 20:48 ubldr -rwxr-xr-x 1 root wheel 232112 Jan 3 20:48 ubldr.bin (yes, rpi2.dtb is stale, but it seems not to matter) A hands-off boot now looks like this: U-Boot 2017.09 (Jan 02 2018 - 23:46:36 -0800) DRAM: 948 MiB RPI 2 Model B (0xa21041) MMC: sdhci@7e300000: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... unable to get device descriptor (error=-22) ** First descriptor is NOT a primary desc on 0:1 ** 7 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 2 Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint 1 Timeout poll on interrupt endpoint 0 Timeout poll on interrupt endpoint switch to partitions #0, OK mmc0 is current device Timeout poll on interrupt endpoint Scanning mmc 0:1... Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 232112 bytes read in 38 ms (5.8 MiB/s) ## Starting application at 0x01000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x3af5d988 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Mon Jan 1 16:41:31 PST 2018 bob@www.zefox.com) DRAM: 948MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=0 slice= partition=... Checking unit=1 slice= partition=... good. Booting from disk1s2a: /boot/kernel/kernel data=0x69ab94+0x1d946c syms=[0x4+0x72bd0+0x4+0xa6299] Hit [Enter] to boot immediately, or any other key for command prompt. Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 9 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 8 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 7 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 6 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 5 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 4 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 3 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 2 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 1 second... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel]... /boot/dtb/bcm2836-rpi-2-b.dtb size=0x308d Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. Kernel entry at 0x1200100... Kernel args: (null) It looks as if /boot/kernel loads but won't run, and /boot/kernel.spare, which formerly ran, no longer does. Curiously, an intermediate kernel, which didn't run, now loads and starts but halts with ugen0.8: at usbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number AA010509160727180727 da0: 40.000MB/s transfers da0: 59836MB (122544516 512 byte sectors) da0: quirks=0x2 Release APs WARNING: WITNESS option enabled, expect reduced performance. random: unblocking device. arc4random: no preloaded entropy cache Trying to mount root from ufs:/dev/ufs/rootfs [rw]... arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache In this case the red LED is off. The behavior of the status LEDs remains quite different from formerly. Long-time behavior was a flash of red, then dark. Later, it's red on and a flash of green, with red staying on until the kernel started and both went dark. It's been pointed out that the RPI2 kernel is deprecated, and this is an RPI2 kernel. Might that be at least part of the trouble? Thanks for reading! bob prohaska