On Wed, 26 Dec 2018 at 11:15, Pankaj Bansal <pankaj.bansal@xxxxxxx> wrote: > > Hello Ard et al. > > I have a query regarding the device tree usage in UEFI. > In our UEFI implementation for NXP SOCs, we are using device tree to detect Non discoverable platform devices. > Based on the device detected in device tree, a device instance is created and the device’s driver binds to that device’s handle (a DXE driver or an UEFI driver). > if the device were to be used for runtime service, then we need to allocate the memory for that device instance from runtime pool and set its virtual address using EfiConvertPointer. > To facilitate this, I wish to add an optional property to the device node “uefi-runtime”. > If this property is present in device tree the UEFI firmware will allocate the data from runtime pool for this device. > Also firmware will disable/delete the node in device tree before passing onto OS, so that OS doesn’t use the device. > > I wish to know your thoughts on this. If this doesn’t seem the right way, I am happy to hear your suggestions. > Hello Pankaj, In general, you are free to do whatever you like in the internal implementation of your firmware. You can invent your own DT properties, bindings, etc, or even invent your own description language altogether as long as you ensure that the descriptions don't leak into places where they are visible to the OS. However, I do wonder how generic this has to be. Since the DT and the firmware will be tightly coupled in any case, what is preventing you from defining the RTC and NOR flash devices as DT device paths in the firmware source, and attaching to them directly rather than traversing the device tree looking for uefi_runtime nodes. Note that *any* logic that operates on device trees that are provided by the OS to the firmware will be rejected. It is the firmware's job to describe the platform to the OS, not the other way around.
