From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 14:57:08 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5E342CFF for ; Tue, 12 Feb 2013 14:57:08 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C1085988 for ; Tue, 12 Feb 2013 14:57:07 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1CEv6w1082433 for ; Tue, 12 Feb 2013 07:57:07 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1CEujre041017; Tue, 12 Feb 2013 07:56:45 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Tim Kientzle In-Reply-To: <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.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> Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2013 07:56:44 -0700 Message-ID: <1360681004.4545.160.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, 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 14:57:08 -0000 On Mon, 2013-02-11 at 22:27 -0800, Tim Kientzle wrote: > On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: > [snip] > > At least for BeagleBone, I think I see a way to > make the pinmux code work this way. That code is > all table-driven, so with some creative reworking of > the tables, it should be feasible to define groups of > pins and a mechanism to manage them. Tedious > work, to be sure, simply because of the sheer number > of definitions involved, but nothing particularly complicated. > > Another approach I've considered is to have the > necessary pinmux assignments be part of the > device entry in the DTS. (BeagleBone DTS, at > least, defines a single list of pinmux settings for > the board, which I don't like at all.) This would > be similar to the way interrupts and memory > regions are assigned today. That would at > least move the problem down to the level of > enabling/disabling particular entries in the DTS. > Unfortunately, I don't yet understand the inner workings > of simplebus and the FDT management in the kernel > well enough to be able to tackle this just yet. > > Having pinmux settings be part of the associated > device node in the DTS would also make your next > issue a little easier to manage, I think. (For example, > the DTS in SVN could have several versions of a single > device with most of them disabled.) I've seen a block at the bottom of some dts source named "choices" or something like that. That seems to hint at the possibility of describing a variety of stock configurations for various devices and then the choosing of configurations might be little more than manipulating some strings in that section. That's the sort of thing that might be easy to handle within ubldr. Doing more than that in ubldr might set us on the path of turning it into a dts compiler. -- Ian