From owner-freebsd-arm@freebsd.org Wed Apr 13 14:41:28 2016 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 11356B0F634 for ; Wed, 13 Apr 2016 14:41:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAD36177D for ; Wed, 13 Apr 2016 14:41:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: cfc78a9a-0185-11e6-8bda-c73aafa13d19 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 13 Apr 2016 14:41:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u3DEfOKY019181; Wed, 13 Apr 2016 08:41:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1460558484.52955.21.camel@freebsd.org> Subject: Re: No usable event timer found on RPI2 From: Ian Lepore To: Michael Tuexen Cc: freebsd-arm@freebsd.org Date: Wed, 13 Apr 2016 08:41:24 -0600 In-Reply-To: References: <20160409020229.GF71221@www.zefox.net> <20160409164903.GG71221@www.zefox.net> <1460220814.1091.338.camel@freebsd.org> <20160409181716.GH71221@www.zefox.net> <1460240966.1091.340.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:41:28 -0000 On Wed, 2016-04-13 at 16:34 +0200, Michael Tuexen wrote: > > On 10 Apr 2016, at 00:29, Ian Lepore wrote: > > > > On Sat, 2016-04-09 at 11:17 -0700, bob prohaska wrote: > > > On Sat, Apr 09, 2016 at 10:53:34AM -0600, Ian Lepore wrote: > > > > > > > > The rpi.dtb file lives on the FAT partition where u-boot is, > > > > but > > > > it's > > > > created by the freebsd build process and installing the kernel > > > > puts > > > > the > > > > new dtb into /boot/dtb on the freebsd rootfs. Something else > > > > (crochet > > > > or some similar script, or you by hand) have to copy from there > > > > to > > > > the > > > > FAT partition on the sdcard. > > > > > > > > Note that right now all of this is unique to rpi. For other > > > > arm > > > > boards, u-boot isn't involved in the dtb file loading at all > > > > and > > > > the > > > > file is normally read by ubldr from the freebsd filesystem. > > > > > > > > There may come a day when all arm boards have to work more like > > > > rpi > > > > does now (due to the way the u-boot world is evolving). > > > > > > > > > > > > > > What inhibits making the copy to FAT part of kernel install? > > > > > > > The freebsd build process doesn't know anything about filesystems, > > it > > just installs things to DESTDIR (which is / by default). > > > > If you're doing the kernel build and install native on the rpi, you > > could get the effect you want by doing: > > > > mount -t msdosfs /dev/mmcsd0s1 /boot/dtb > > make installkernel > > umount /boot/dtb > > > > At least, I think that should work. > Hi Ian, > > I'm running into the same problem. I updated the source on a RPI2 > today, > build a new kernel (with modules), installed it, manually copied > /boot/dtb/rpi2.dtb > to /boot/msdos/ (which is mounted) and rebooted. > The dtb files have the correct date, but the kernel panics. Do I need > to copy more? > > Thanks for your help! > Sorry, I don't have any particular insight into this one (I don't have an rpi2). I was just chiming in on the previous question about the specific issue of where the .dtb file lives and how it gets loaded (and it turns out I was a bit wrong about that: it's actually the rpi firmware (in the gpu) that loads the dtb file and passes it to u-boot). -- Ian