Date: Thu, 14 Feb 2013 14:45:23 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: FDT on x86 and for non-fdtbus devices. Message-ID: <B0375E90-369C-4F9C-AAB9-2106C7D68623@FreeBSD.org> In-Reply-To: <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <alpine.BSF.2.00.1302141031480.65091@fledge.watson.org> <8606E19D-98A2-4E2C-A9E3-5056C1BAC34E@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B0375E90-369C-4F9C-AAB9-2106C7D68623>