FDT on x86 and for non-fdtbus devices.

[Robert N. M. Watson]

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.
>>> 
>>> 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?
> 
> 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....
> 
> 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