Uefi runtime property in device tree

Uefi runtime property in device tree

[Pankaj Bansal]

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.

Thanks & Regards,
Pankaj Bansal

Uefi runtime property in device tree

[Pankaj Bansal]

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.

Thanks & Regards,
Pankaj Bansal

Re: Uefi runtime property in device tree

[Ard Biesheuvel]

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.

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.

Re: Uefi runtime property in device tree

[Pankaj Bansal]

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

Re: Uefi runtime property in device tree

[Ard Biesheuvel]

On Thu, 27 Dec 2018 at 10:53, Pankaj Bansal <pankaj.bansal@nxp.com> wrote:
>
> 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.
>

But how does that matter? You cannot share the controller between the
OS and the firmware anyway? The same applies to I2C controllers for
RTC, for instance: it doesn't really fit a generic driver model.

In my experience, this kind of 'flexibility' looks good in theory, but
doesn't give that much benefit in practice.

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

As I said before, how the firmware uses DT internally is entirely up
to you. You can use the same DT or different DTs. The only contract
you are bound by is the contract between the firmware and the OS, and
this only applies to DT info that is exposed to the OS.