From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 16:44:48 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 DDDC1344 for ; Tue, 12 Feb 2013 16:44:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mx1.freebsd.org (Postfix) with ESMTP id A243D12D for ; Tue, 12 Feb 2013 16:44:47 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wc20so283233obb.1 for ; Tue, 12 Feb 2013 08:44:47 -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=gqDq6rb01H0LuC9oAv/pO3WvMVQRRbQuJa29qa5Hodw=; b=Q/kwi1266JHj1B0gfPkpBRhEoproKtoxwE5HVXUFNKm8WWDsHgDEpJ2wu3Svb29FU/ KqQdKUOBGeViZP+LmbRiR4o6NGNSiXUhLUlzkt9qB7ez2bL+XV8fvxpVkSxgxFsONKXv vWOK4snh+LbdNrP5JcTDl9PzkK87zPxiQXnFTEaSCMwiYqjR0fpLQaAGm9NfT1lMStIi PauOJWsQtidLiUtcXAvojsuZHGcjdzF/MVS8QS1C88DmiEmR7WzSTEzsj41iQLe4y4i5 TMRO1Bf3/vCSTIBa6DSzdP3y6p3ArY0kBUERe7FTpY34KExYRG7me2DvniSkSEUHOHs4 8r1Q== X-Received: by 10.60.170.232 with SMTP id ap8mr13992980oec.29.1360687487538; Tue, 12 Feb 2013 08:44:47 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id p2sm53488066obb.6.2013.02.12.08.44.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:44:46 -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: <1360681004.4545.160.camel@revolution.hippie.lan> Date: Tue, 12 Feb 2013 09:44:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F135283-ACDB-4126-A74F-04FF9321399C@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> <1360681004.4545.160.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlDREJckeN29sxmbbthIdu4bEbXHrRwMeBRwzXdotBJm6xg+edFqnFa8qAXGVTgfvO1k4K8 Cc: Tim Kientzle , 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 16:44:48 -0000 On Feb 12, 2013, at 7:56 AM, Ian Lepore wrote: > On Mon, 2013-02-11 at 22:27 -0800, Tim Kientzle wrote: >> On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: >>=20 > [snip] >>=20 >> 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. >>=20 >> 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. >>=20 >> 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.) >=20 > 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. "chosen" is what you are talking about. It isn't quite what you think it is for. This section is for = communicating some settings to the kernel, but it isn't supposed to = enable/disable devices. What you are describing sounds cool, but I have = grave doubts it would work. It also goes against the main tenants of = FDT, which is that you have a simple binary blob that describes how = you've configured/wired your hardware together and the kernel can = completely rely on that to do configuration. Adding weird settings in = the chosen setting gets us back to the days of having some things = compiled in, and some things selected with hints. btw, what's wrong with optionally turning ubldr into a dts compiler? = Assuming, that is, that the BSD dts compiler project makes progress = enough to keep up with the GPL'd one? Warner=