From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 18:54:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45B6E464 for ; Tue, 12 Feb 2013 18:54:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0D460A63 for ; Tue, 12 Feb 2013 18:54:06 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so437974oag.30 for ; Tue, 12 Feb 2013 10:54:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=FMDQ7US+3APq9/1LNNlOLqZ0Fjc7CAu5IJEZMEYCyzo=; b=Ch7KbMtb2gcYaIn97S4Yn7McJJL/OJy5PwIN3TKVlZwakxtkB9siCOk3W1fBOrcqkW 2q3ZC+4KCF7zJO18xQzk+3+lPXUBcqo276DCTZKzEUt3vnDgkZG19yMWXQsCwAWuAXtg evLPzMLLIahgjyAhpTyyDQHVG0xXMP9c7hZkV8yYwK4wuuKPTclGKt8sqZhqEiimdfs1 Pqr4J948LmTw6RC2cif7IyIdUhBZyVr72WqYw/y7GYFPhzgTMhTtSo/AyOGZEqNi1es4 3iLj5DfQbk3FBU02m1JsqpnXjr1brEsDuFFA88fPQ15co8didU/G59hXy69FeFgQnD9L CHww== X-Received: by 10.182.154.4 with SMTP id vk4mr14075967obb.70.1360695246180; Tue, 12 Feb 2013 10:54:06 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id p2sm53896315obb.6.2013.02.12.10.54.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:54:05 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> Date: Tue, 12 Feb 2013 11:54:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27A7F65F-C61D-424F-AD2C-65B29B49B700@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkI7NbRQEFJofXGb5H7RPKdMLp019A1RH4ERRBn9BzLbNgCT3ANCh2MLW95nAov27+RDpQN Cc: freebsd-arm@freebsd.org, Ian Lepore , Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:54:07 -0000 On Feb 12, 2013, at 10:15 AM, Tim Kientzle wrote: >=20 > On Feb 12, 2013, at 8:40 AM, Warner Losh wrote: >=20 >> The typical approach taken over in linux-land is to have a base = config, then have customizations done with a file that just includes the = base, and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: >>=20 >> include "GENERIC" >> nodevice foo >> device bar >> option FRED >> nooption WILMA >>=20 >> FDT is powerful enough to cope with those things today, with the = version we have in the tree. >=20 > Warner, >=20 > Could you point me to a good example of this? Or a second example: = http://lxr.linux.no/linux+v3.7.7/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts This is the 2 mmc version of the 9g20ek evaluation board. This includes = the common 9g20ek definitions, then refines them. The 9g20ek common = includes the SoC definitions. Others that include the SoC definition are = things like kizbox.dts. But again, the pinmux/pin group stuff doesn't seem to be in the 3.7 = kernel :( Warner > I've dug around a little bit in the Linux DTS files > but I'm not sure I yet understand what I'm looking > at well enough to tell which ones are good examples > of this technique in action. >=20 > I also have a question about FDT device probe > ordering: I found in tinkering with BeagleBone that > our current FDT implementation probes each > device in the order it appears in the FDT. > This caused me some confusion when I accidentally > had some device (I don't remember which one; call > it FOO) before the SCM controller (which handles pinmux). > The FOO attach blew up because it couldn't > get access to the SCM controller. (Yes, the FOO > driver did explicitly list SCM as a requirement.) >=20 > I wonder if simple bus shouldn't somehow > accommodate this; otherwise, it seems like > it could be a problem for doing DTS inclusion > correctly. >=20 > Tim >=20