From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 14:45:36 2013 Return-Path: Delivered-To: freebsd-arch@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 89D194F0 for ; Thu, 14 Feb 2013 14:45:36 +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 4B277910 for ; Thu, 14 Feb 2013 14:45:36 +0000 (UTC) Received: from c0157.aw.cl.cam.ac.uk (c0157.aw.cl.cam.ac.uk [128.232.100.157]) by cyrus.watson.org (Postfix) with ESMTPSA id 7A00A46B3F; Thu, 14 Feb 2013 09:45:35 -0500 (EST) Subject: Re: FDT on x86 and for non-fdtbus devices. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> Date: Thu, 14 Feb 2013 14:45:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arch@FreeBSD.org Arch" , Marcel Moolenaar 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 14:45:36 -0000 On 14 Feb 2013, at 14:40, Warner Losh 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. >>>=20 >>> 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"? >>=20 >> 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? >=20 > IF you want to just add nodes to the FDT, I think that having a merge = function in ubldr and such wouldn't be too horribly hard. If you wanted = to change leaf nodes already in the tree, that would be quite a bit = harder, but might be doable in the kernel context.... >=20 > But I'm curious why your specific example wouldn't already live in the = FDT for your board.... We want to put hardware configuration parameters in the on-board FDT. We want to put software configuration parameters in the kernel targeted = for the board. For example -- avgen(4) allows us to export specific pieces of I/O = memory to userspace via named device nodes -- e.g., /dev/touchscreen. = The hardware-side configuration is the description of the device in I/O = memory; the software-side configuration is the name of the device node = and its default permissions. Likewise, some properties of flash layout = have to do with our hardware -- e.g., the locations of the primary and = backup FPGA bitfiles loaded by the hardware on power-on; other parts = have to do with software -- e.g., placement of /dev/map entries in that = flash (since we can't put a GPT on the front since it's reserved space = for board initialisation/boot vector); these also go into device.hints. = We'd much rather use more FDT to describe these parameters rather than = device.hints -- in particular, we might flash that software-specific FDT = data into flash as well, but it's not the same as the ROM-embedded bus = description. Robert=