FDT on x86 and for non-fdtbus devices.
Warner Losh
imp at bsdimp.com
Thu Feb 14 14:40:35 UTC 2013
On Feb 14, 2013, at 3:33 AM, Robert Watson wrote:
>
> 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?
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....
Warner
More information about the freebsd-arch
mailing list