On 04/29/2018 11:36 PM, Chang, Abner (HPS SW/FW Technologist) wrote:
Some thoughts,
-----Original Message----- From: arm.ebbr-discuss-bounces@arm.com [mailto:arm.ebbr-discuss- bounces@arm.com] On Behalf Of Udit Kumar Sent: Saturday, April 28, 2018 4:07 PM To: Alexander Graf agraf@suse.de; 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: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]
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%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.
Point 1:
As brought up before, we need to figure out how much of this is in EBBR. If the firmware applies the overlays and the OS only updates the DTO/DTBO via capsule update, then it is not really part of the OS interface.
On the other hand, I do see value in the OS having some viability into this data for finer grain updates. If the firmware package for every variant of the BeagleBone has to be updated for each cape (daughter card) that comes out, that is a lot of churn.
However, currently having one DT that works with every kernel version that may run, I would call aspirational. I agree with the goal but is it achievable in 6 months? Should we not be looking at a solution for EBBR.0?
Likewise, we don't want every vendor using u-boot to do it a different way so even if not part of the Firmware / OS interface, there is value in making recommendations for structure. Should this be in EBBR or devicetree.org? I don't know but we need to discuss somewhere and it might as well be this group.
Point 2:
The Android binary format is not appropriate for general use. It is defined only for their model where there are exactly two DT to be combined, one that defines the SOC and one that defines the "board" aka "phone". The format defines only one axis of selection and thus even the SOC DTs and the board DTs cannot share a partition.
I agree with the principal of looking at prior art and defacto standards but we should not adopt something that is flawed.
I also think the Android practice of dedicating a whole partition to each file is very awkward. The firmware already has to be smart enough to read the EFI application from the EFI partition so having extra files in this partition should not a burden.
Bill