Re: Uefi runtime property in device tree

[Pankaj Bansal <pankaj.bansal@nxp.com>]

Hello Ard,

Thanks for replying

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Wednesday, December 26, 2018 7:16 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Varun Sethi <V.Sethi@nxp.com>; Udit Kumar <udit.kumar@nxp.com>; linux-
> efi <linux-efi@vger.kernel.org>; edk2-devel@lists.01.org
> Subject: Re: Uefi runtime property in device tree
> 
> On Wed, 26 Dec 2018 at 11:15, Pankaj Bansal <pankaj.bansal@nxp.com> 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.

The UEFI driver model that we are following, creates the device instances for all the devices
attached to a controller by parsing DT node and sub nodes of a controller on ConnectController call.
So we are not traversing the DT for runtime devices, rather we need to know if the device is runtime
or not when parsing the DT node.

Take the case of SPI NOR for example. When a SPI controller is connected, then instances for all the NOR flash devices
attached to controller are created. Only one of the NOR flash attached to SPI bus is going to be used for runtime service.

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

I have a question : if we want to use DT for DXE phase in firmware and to boot OS, should we use a common DT for firmware and OS or separate?

If DT HAS TO BE SAME, then how do we solve this conundrum ? https://elinux.org/Device_Tree_Linux#forward_and_backward_dts_compatibility
Current practice is that
•	new kernels work with old devicetrees
•	old kernels may or may not work with new devicetrees
This means that if a binding is modified in a non-compatible manner then the kernel implementation must still recognize the old binding until old devicetrees have been obsoleted and no longer exist.

i.e. a platform's DT is updated in linux 4.19 and I start to use it in UEFI. Then I try to boot linux 4.9 with it and it fails.

Regards,
Pankaj Bansal