From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 18:45:37 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 49DDD7D for ; Tue, 12 Feb 2013 18:45:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mx1.freebsd.org (Postfix) with ESMTP id ED42A9EA for ; Tue, 12 Feb 2013 18:45:35 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uz6so418170obc.34 for ; Tue, 12 Feb 2013 10:45:35 -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=UI49bIT2vE2qThO0/g0svTWNYrPnWnJKkU/zz3QogJo=; b=T2fKOz5mhl7IuqaXmWoel4o+P/mEb/LzxpwfP/twtQn0YqZyG8/MKA/YBIUhc2V/DQ u4aiPI/EnngXuVocLxqSMvGlnfJLQZvuf+biQs7SZjtBuG3AG5ekzvJup9WpvP0qrIxj I5EWFnbPMByIpGEwscQECgHzfPFUs5theAgA9/CNu1XJCX2ZOEUb2Mg/adFg5KLZ4Qvy nybB+/r6d7gQ3Qo6pMEh70SSEWnwdw0fChCCaZWTTYTwEJVuM4L2viF0nCIE3qCSI6YV coCEbVQL1qVyKw84iVaefzKD1ZNcHRu4XhTfsOkUCzXETxEwlBQr8Iw8aUna/XFPInhe yEgg== X-Received: by 10.60.6.199 with SMTP id d7mr14005587oea.137.1360694735367; Tue, 12 Feb 2013 10:45:35 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id yn8sm53859401obb.12.2013.02.12.10.45.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:45:34 -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:45:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F763292-2EA4-426A-B84A-8DE533BA6308@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: ALoCoQkXWCVv9AHif0mMyxyXFGHGn/zk7fnDt32z15fqoW+G6lYoM/MKCjTANnrPT6+QWUnpoqle 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:45:37 -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? Yes. http://lxr.linux.no/linux+v3.7.7/arch/arm/boot/dts/at91sam9n12ek.dts is = the dts for the Atmel AT91SAM9N12-EK evaluation board. It just includes = the base Atmel AT91SAM9N dts at the top, then adds its model string, = boot args, memory size, clocks and devices (by changing their status to = "okay". It also wires up different GPIOs to the linux-speciifc triggers = like sd card or nand activity, and finally says that certain GPIO is = connected to the wakeup key. But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing... > 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.) This I'm less sure about. Warner > I wonder if simple bus shouldn't somehow > accommodate this; otherwise, it seems like > it could be a problem for doing DTS inclusion > correctly.