public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* Uefi runtime property in device tree
@ 2018-12-26 10:15 Pankaj Bansal
  2018-12-26 10:17 ` Pankaj Bansal
  2018-12-26 13:46 ` Ard Biesheuvel
  0 siblings, 2 replies; 5+ messages in thread
From: Pankaj Bansal @ 2018-12-26 10:15 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Varun Sethi, Udit Kumar, linux-efi, edk2-devel@lists.01.org

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Uefi runtime property in device tree
  2018-12-26 10:15 Uefi runtime property in device tree Pankaj Bansal
@ 2018-12-26 10:17 ` Pankaj Bansal
  2018-12-26 13:46 ` Ard Biesheuvel
  1 sibling, 0 replies; 5+ messages in thread
From: Pankaj Bansal @ 2018-12-26 10:17 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Varun Sethi, Udit Kumar, linux-efi, edk2-devel@lists.01.org

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Uefi runtime property in device tree
  2018-12-26 10:15 Uefi runtime property in device tree Pankaj Bansal
  2018-12-26 10:17 ` Pankaj Bansal
@ 2018-12-26 13:46 ` Ard Biesheuvel
  2018-12-27  9:53   ` Pankaj Bansal
  1 sibling, 1 reply; 5+ messages in thread
From: Ard Biesheuvel @ 2018-12-26 13:46 UTC (permalink / raw)
  To: Pankaj Bansal; +Cc: Varun Sethi, Udit Kumar, linux-efi, edk2-devel@lists.01.org

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Uefi runtime property in device tree
  2018-12-26 13:46 ` Ard Biesheuvel
@ 2018-12-27  9:53   ` Pankaj Bansal
  2018-12-27  9:58     ` Ard Biesheuvel
  0 siblings, 1 reply; 5+ messages in thread
From: Pankaj Bansal @ 2018-12-27  9:53 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Varun Sethi, Udit Kumar, linux-efi, edk2-devel@lists.01.org

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Uefi runtime property in device tree
  2018-12-27  9:53   ` Pankaj Bansal
@ 2018-12-27  9:58     ` Ard Biesheuvel
  0 siblings, 0 replies; 5+ messages in thread
From: Ard Biesheuvel @ 2018-12-27  9:58 UTC (permalink / raw)
  To: Pankaj Bansal; +Cc: Varun Sethi, Udit Kumar, linux-efi, edk2-devel@lists.01.org

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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-12-27  9:58 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-26 10:15 Uefi runtime property in device tree Pankaj Bansal
2018-12-26 10:17 ` Pankaj Bansal
2018-12-26 13:46 ` Ard Biesheuvel
2018-12-27  9:53   ` Pankaj Bansal
2018-12-27  9:58     ` Ard Biesheuvel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox