From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 16:40:15 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 95F95218 for ; Tue, 12 Feb 2013 16:40:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5D333F8 for ; Tue, 12 Feb 2013 16:40:15 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ni5so272406obc.26 for ; Tue, 12 Feb 2013 08:40:09 -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=UKUgwil6aKXOUsptpnpucta84q3Q47vdRe8MWsuciaI=; b=FzF3Ch+RzrK1jXUOF4Xdo3GHVi2Th57SOwmS3FQMosibj5hK+Bz2KjN1PBxJu9BRWb z0SWbqPsuipBpmGe1+xoLLvkjXfSSyGChz78ZzWL/Rq58UnepOPh668Bc3JKGI23NCBF u+XTXGZ66bTDmMoHGGrmBBXuK/NaZFWWw3EcEfZ4QJprN27BZjmQADZmVj8hLYbXRK3s H90cqxNDiZwtiuSYHHup45qAF3O2uEdUckx7osiXXIRWDoE888q5xSvO9FEwyN5lxinf fE3m+NJMz2t9inA9coVDVDNH1YMr2eMzlt+DAMkTGKBrXmmkcSEhOaKL5QSq8MzM/H3y vFdQ== X-Received: by 10.182.118.105 with SMTP id kl9mr14052799obb.52.1360687209241; Tue, 12 Feb 2013 08:40:09 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id jd1sm53469627obb.8.2013.02.12.08.40.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:40:08 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> Date: Tue, 12 Feb 2013 09:40:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlT000iSoPaiQlLHbQ3c7o0J/2CLRE5Xm6EKKSR3QNKdk1GkXXNlm+TdIcFt5P6bUOiwmsj Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore 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:40:15 -0000 On Feb 11, 2013, at 11:27 PM, Tim Kientzle wrote: > On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: >=20 >> =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. >=20 > This is my single biggest complaint about fdt as well. And the better solution is? We have nothing that's better... >>> 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." >=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. The tables should come in from the FDT. I know that's a pain, but it = makes it so that when the next rev of the silicon comes out that has = slightly different swizzled pins easier to integrate. > 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. This is the approach that's favored by those driving the FDT = definitions. I've seen it work well in the Atmel case where they have = the same basic core that they remix with different devices to produce = the different SoCs optimized for different market segments. They have = gotten tot he point where a new SoC with old IP just needs a new FDT to = be supported by the kernel. > 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 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: include "GENERIC" nodevice foo device bar option FRED nooption WILMA FDT is powerful enough to cope with those things today, with the version = we have in the tree. Warner >> 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. >=20 >=20 > Tim >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"