Hi Alex
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Friday, April 27, 2018 1:18 PM To: Udit Kumar udit.kumar@nxp.com; William Mills wmills@ti.com Cc: boot-architecture@lists.linaro.org; nd@arm.com; Rod Dorris rod.dorris@nxp.com; arm.ebbr-discuss@arm.com Subject: Re: DT handling, [Ref Linux-Efi]
On 27.04.18 08:24, Udit Kumar wrote:
Hi There is bit of discussion on linux-efi too , to handle DT update
I guess some members of this forum are active there too.
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .spinics.net%2Flists%2Flinux-efi%2Fmsg13700.html&data=02%7C01%7Cudit.k
umar%40nxp.com%7Cd320a10fef8446e2aec308d5ac132cd3%7C686ea1d3bc2b 4c6fa9
2cd99c5c301635%7C0%7C0%7C636604120716683231&sdata=USXfARVLtgi2umi %2BSw
LxLwJPqiDztVuNGpTGz09T0q0%3D&reserved=0
To summaries 1/ Ownership of DTB IMO should be firmware and we should retain this ownership in EBBR as well, Any objections/thoughts ?
I fully agree. On top of that we need to make clear that backward and forward compatibility are not optional.
This will be on kernel drivers, not to break the contract.
For that I think we may need to actually give people workable solutions to create device trees that are compatible with multiple levels of kernel support. The main areas I'm aware of that keep breaking are:
- fine grained interrupt controller support
- clock support
- power domain support
- pinctrl support
In-line with similar problems I am facing currently, new kernel doesn't boot with old uefi firmware. Kernel device tree is updated and therefore driver is, the combination of old device tree and new kernel is not working, This comes down to mainly on management of device trees. Here if we consider, firmware and kernel development is independent then driver should run with same level of functions with new kernel and old device tree. New functions/binding added in driver couldn't be used.
Every time a device tree changes in any of the above, that usually ends up in backwards incompatibility.
My idea to solve that would be to basically create a device tree that has self- contained overlays that only trigger when certain feature strings are available.
This will be good, but can we predict what will be overlays ?
That way the base device tree could for example contain fixed clocks, but an overlay can get applied when the clock driver is enabled in the kernel configuration. That overlay would then enable the kernel to drive clocks.
With assumption, firmware has nothing to fix for overlays. i.e clock-frequency (if given in overlay)
Further down, we could even extend dtc with annotations that indicate "this property should only be exposed when feature string X is available" to not force people to write overlays inside the device tree.
Update 1/ Updating whole device tree from OS [Capsule update can be used ]
I think the device tree should be part of firmware. If you need to update it, update your firmware (or a firmware specific method, not specified by EBBR).
Edk2, supports DTB as part of firmware and separate data blob as well.. I think, this is work in progress by Bhupesh to update only DTB.
2/ Just modifying the device tree DTBO
Yes, dtbo support in the boot chain definitely makes sense.
My preferred way to handle DTBO in firmware will be https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsou
rce.android.com%2Fdevices%2Farchitecture%2Fdto%2Fmultiple&data=02%7C0 1
%7Cudit.kumar%40nxp.com%7Cd320a10fef8446e2aec308d5ac132cd3%7C686e a1d3b
c2b4c6fa92cd99c5c301635%7C0%7C0%7C636604120716683231&sdata=a8rseb EngRA
dKP%2Fs3wFSfqMHYrOf4hn6JNfQpXdFgzU%3D&reserved=0 See picture Runtime DTO implementation for multiple DTs
To store this information in partition, options we have 1/ Run time variables
You mean EFI variables? We could certainly have a driver in firmware that reads certain EFI variables to apply dtbos from.
Yes, there will be a need of generic driver which reads variable and merge DTB and DTBO.
2/ Some driver in Linux writing to DTBO partition
What is a DTBO partition?
This is defined in android, if there is agreement we can define something like this or other.
3/ Some other way ??
In a lot of cases I think we will end up with enumerable extensions to systems that will want to have a dtbo applied by their respective driver. As outlined in the notes from last week, that driver could expose availability of such an extension to the OS (grub) which could then apply an OS provided dtbo.
Could be, if grub does not need platform information for these DTBO.
I am not sure, if distro are updating device tree which is default shipped with
board ??
I would prefer they didn't :). Right now we leave people little chance, because device trees keep changing incompatibly. If we get rid of that problem, there will be very little incentive by distros to ship device trees.
Thanks Udit