Date: Thu, 14 Feb 2013 10:33:58 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org> Subject: Re: FDT on x86 and for non-fdtbus devices. Message-ID: <alpine.BSF.2.00.1302141031480.65091@fledge.watson.org> In-Reply-To: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1302141031480.65091>