From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 10:33:58 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0F21DFB for ; Thu, 14 Feb 2013 10:33:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C1255337 for ; Thu, 14 Feb 2013 10:33:58 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 70D6346B3F; Thu, 14 Feb 2013 05:33:58 -0500 (EST) Date: Thu, 14 Feb 2013 10:33:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marcel Moolenaar Subject: Re: FDT on x86 and for non-fdtbus devices. In-Reply-To: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> Message-ID: References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-arch@FreeBSD.org Arch" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 10:33:58 -0000 On Wed, 13 Feb 2013, Marcel Moolenaar wrote: > I think one way to state the problem in a generic way is: How can we obtain > the FDT pnode_t given an arbitrary device_t and use the pnode_t to query for > properties, etc. > > Are people already doing things like this? Is there an interest in being > able to do things like this? Are changes to drivers to have them query FDT > contributable at all or do people think such would be "pollution"? Only loosely related, but another thing we'd like to be able to do at SRI/Cambridge is merge ROM-discovered FDT configuration data with kernel-linked configuration data. For example, we'd like to rely on the device's ROM for a list of physical device layouts and so on, but embed our description of flash layout, additional device driver configuration information (e.g., /dev node information for avgen, which exports devices unsupported by specific device drivers using a generic memory-mapped interface), etc, in the compiled kernel for the device. I'm not sure if that's something that's of interest in this context as well? Robert