From owner-freebsd-arm@FreeBSD.ORG Sun Mar 2 16:41:16 2014 Return-Path: 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 AB4C37B4 for ; Sun, 2 Mar 2014 16:41:16 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 790D411AF for ; Sun, 2 Mar 2014 16:41:16 +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 1WK9Rz-000AYM-76; Sun, 02 Mar 2014 16:41:15 +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 s22GfCw9045450; Sun, 2 Mar 2014 09:41:12 -0700 (MST) (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: U2FsdGVkX19SK2E2ZxN37Yf7VTy7VVQc Subject: Re: A unified imx6 kernel config, old WANDBOARD-* configs going away From: Ian Lepore To: Warner Losh In-Reply-To: <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> References: <1393594966.1149.161.camel@revolution.hippie.lan> <1393731762.1149.233.camel@revolution.hippie.lan> <9BF14340-2267-473E-B047-E377AA258713@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Sun, 02 Mar 2014 09:41:12 -0700 Message-ID: <1393778472.1149.242.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s22GfCw9045450 Cc: Tim Kientzle , 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: Sun, 02 Mar 2014 16:41:16 -0000 On Sun, 2014-03-02 at 09:30 -0700, Warner Losh wrote: > On Mar 1, 2014, at 8:42 PM, Ian Lepore wrote: >=20 > > On Sat, 2014-03-01 at 18:01 -0700, Tom Everett wrote: > >> I'm looking at the crochet code, and I see in freebsd_install_fdt th= at both > >> *.dtb and *.dts are supported. However on the source tree it's imx6.= dtsi. > >> What's the difference b/t a dts file and a dtsi file? > >=20 > > A .dtsi file is an include file used by .dts files. A .dtb is the > > binary (compiled) form used by the kernel. > >=20 > > So there are several wandboard-something.dts files, each of which > > includes imx6.dtsi where all the common parts live. For a new imx6 > > device, a new board-named file similar to one of the wandboard files = is > > necessary, and it would also include imx6.dtsi. >=20 > As would other boards that use the imx6 SoC. They=A2d have their own .d= ts > file that included the imx6.dsti and customized it for how they are wir= ed > together. >=20 > > We're pushing hard towards just using the standard dtb files from > > vendors, but we've got a bit of work to do before we're there. >=20 > I have some rough changes that allow us to build N different DTBs as pa= rt > of the kernel build, but not glom them into the kernel. Not strictly re= quired > for this, but helpful. >=20 > I=A2m planning on having Atmel use 100% vendor supplied files as well. > It is a very good goal. There=A2s also efforts on the linux side to sep= arate out > the device-trees from the linux kernel, which is where I grabbed the re= cent > /vendor/device-tree stuff from. >=20 > Warner For imx6, the big obstacle to using vendor dtb files is now just the device instantiation order. The stock dts files list devices basically in order of their memory-mapped register addresses, but we need the interrupt controller to be available first regardless of where it's mapped, and likewise for a few other critical devices. I need to do another round of experimentation with the EARLY_DRIVER_MODULE() stuff and multipass device instantiation. We may not be all that far from success. -- Ian