Hi Alex > -----Original Message----- > From: Alexander Graf [mailto:[email protected]] > Sent: Friday, April 27, 2018 1:18 PM > To: Udit Kumar <[email protected]>; William Mills <[email protected]> > Cc: [email protected]; [email protected]; Rod Dorris > <[email protected]>; [email protected] > 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
