From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 06:28:02 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 37A784A6; Tue, 12 Feb 2013 06:28:02 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E9638708; Tue, 12 Feb 2013 06:28:01 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1C6Rq9O018953; Tue, 12 Feb 2013 06:27:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id fh5tqhfq77xd6mzqd66m2skhxe; Tue, 12 Feb 2013 06:27:52 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1360604561.4545.115.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 22:27:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Ian Lepore X-Mailer: Apple Mail (2.1283) 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 06:28:02 -0000 On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: > =85 I still find it much more cumbersome to work with > than the old hints system. The very fact that you need > a special compiler to change the fdt data is part of that. This is my single biggest complaint about fdt as well. >> 2) We're still debating the role of the FDT vis a vis >> end user customization. Personally, I would like >> to find some more dynamic approach to handling >> pinmux at runtime. (E.g., if you want to use a pin >> for gpio, you do this: >> $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change >> $ gpioctl 1 7 on >> Similarly, I think that enabling uart2 should automatically >> adjust the pinmux appropriately. >=20 > I whole-heartedly agree with that last sentence, but it's about a > zillion miles from where our code is now. I'm not even sure it's = fully > possible, it just seems like a nice generic ideal "I asked for a uart, > so the uart driver should enable power, enable clocks, and assign pins > to make that happen." 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.) > The problem crops up when "assign pins" has > several sets of pins to choose from for a given device, and I know at > least the Atmel SoCs do this a lot. Tim