Some thoughts, > -----Original Message----- > From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss- > boun...@arm.com] On Behalf Of Udit Kumar > Sent: Saturday, April 28, 2018 4:07 PM > To: Alexander Graf <ag...@suse.de>; William Mills <wmi...@ti.com> > Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris > <rod.dor...@nxp.com>; arm.ebbr-disc...@arm.com > Subject: Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi] > > > Hi Alex > > > -----Original Message----- > > From: Alexander Graf [mailto:ag...@suse.de] > > Sent: Friday, April 27, 2018 1:18 PM > > To: Udit Kumar <udit.ku...@nxp.com>; William Mills <wmi...@ti.com> > > Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris > > <rod.dor...@nxp.com>; arm.ebbr-disc...@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%2Fw > > > ww > > > .spinics.net%2Flists%2Flinux- > efi%2Fmsg13700.html&data=02%7C01%7Cudit > > > .k > > > > > > umar%40nxp.com%7Cd320a10fef8446e2aec308d5ac132cd3%7C686ea1d3bc2 > b > > 4c6fa9 > > > > > > 2cd99c5c301635%7C0%7C0%7C636604120716683231&sdata=USXfARVLtgi2um > i > > %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%2Fs > > > ou > > > > > > rce.android.com%2Fdevices%2Farchitecture%2Fdto%2Fmultiple&data=02%7 > C0 > > 1 > > > > > > %7Cudit.kumar%40nxp.com%7Cd320a10fef8446e2aec308d5ac132cd3%7C686 > e > > 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.
We probably don't need to provide a genetic DT driver in UEFI U-Boot, instead, we will have to mention how SoC/platform vendors publish DTB/DTBO in EBBR spec. For example, The EFI_CONFIGURATION_TABLE in EFI System table could be used to publish the pointer to DTB and DTBO. Declare two GUIDs in EBBR, one for DTB another for DTBO. OS boot loader is responsible to merge DTB/DTBO according DTB/DTBO discovered in EFI Configuration Table. To read DT from EFI variable into memory, memory map to DT in EEPROM or other mechanisms is platform implementation. No matter which approach, DT producer has to create configuration table in EFI system table follow the data structure defined in EBBR. Another way instead of using GUID in configuration table is to publish DTB/DTBO in EFI device path, this way is more UEFI oriented IMO. However, we have to defined corresponding device path node in UEFI spec for DT. Similar to using system configuration table. DT producer has to install EFI device path for either DTB or DTBO. Then OS boot loaders locate those EFI device paths of DTB and DTBO and merge it. My thoughts based on UEFI perspective. > > > > 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 > > _______________________________________________ > Arm.ebbr-discuss mailing list > arm.ebbr-disc...@arm.com _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
