Hello Ard, Thanks for replying
> -----Original Message----- > From: Ard Biesheuvel [mailto:[email protected]] > Sent: Wednesday, December 26, 2018 7:16 PM > To: Pankaj Bansal <[email protected]> > Cc: Varun Sethi <[email protected]>; Udit Kumar <[email protected]>; linux- > efi <[email protected]>; [email protected] > Subject: Re: Uefi runtime property in device tree > > On Wed, 26 Dec 2018 at 11:15, Pankaj Bansal <[email protected]> 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
