On 25/04/2018 07:49, Udit Kumar wrote:
2) Kernel provides/overrides DTB
The kernel always has the option of loading it's own DTB, either because
firmware doesn't provide one, or it needs a newer DTB. This is similar
to CONFIG_ACPI_CUSTOM_DSDT in ACPI land. However, if the kernel is
overriding the DTB, then firmware has no part of it, and it should not
be allowed to modify the DTB at ExitBootServices() time.
For our platforms at least, this will not work unless firmware is doing
modifications. I think this I likely true for Ard as well.
Firmware has a logic to modify default DTB for available devices, reading board configuration
programming required muxes, based upon this removing/adding devices
into DTB.
IMO, this will not be an optimal way to use untouched DTB provided by kernel.
Right, which is part of the reason for insisting on the firmare being
responsible. If the kernel or Grub overrides the DTB, then it is an
explicit *rejection* of anything firmware provides; presumable because
something is broken and it has to be worked around.
If the DTB update is given to firmware first, then presumably the work
has been done to make sure the new DTB (or base DTB if you will) has
been verified to work with firmware's behavour.
This is where Ard will argue that if you're updating the DT, then you
should update the entirety of firmware because they are closely linked.
I don't go quite that far as I can think of a lot of scenarios where
just a DTB change is desired that does not conflict with firmware
behavour. The details of this are of course implementation specfic and I
don't want to create a specification of what can and cannot be changed
when doing a DTB updated; but I don't want to discard the use case out
of hand.
[...]
- Firmware should have a built-in DTB that will boot a mainline kernel
- Firmware should provide mechanism for installing updated DTB
- Reflashing entire firmware just for DTB updates is discouraged
- DTB update could be either temporary or persistant
- If persistent, DTB should be stored in firmware flash region
- ie. not in system partitition.
- Firmware can require DTB update to be signed
- Built-in DTB remains as failsafe that can always recovered to
- Firmware remains 'responsible' for DTB
- Firmware allowed to modify updated DTB
- Firmware update mechanism logically separate from OS boot
- Though it could be scripted by Grub
- Firmware 'vendor' responsible for official updates to DTB
- Question: should there be a standard capsule update mechanism for
DTB updates?
- By default, OS distributions should use firmware provided DTB
- Require user intervention DTB override is needed
I see, this in two ways
1/ Replacement of DTB is needed, In this case, my preference will be to update
whole firmware.
Fair enough. That is the choice of the firmware vendor
2/ Update in DTB is needed. I think above could be as above,
In addition, I see
- OS is providing DTB update as DTBO for given distribution
- Which could lend as runtime variable in firmware.
- Firmware is checking that and storing on flash with give Id
- Boot-loader (grub) is checking for runtime variable for DTBO for given distribution
- grub is merging firmware provided (DTB) and DTBO before handing over to OS
That has possibilities. I would view that as a bug mitigation technique
when firmware cannot be updated, and I'm not opposed to it.
However, if the DTB update mechanism is standard, and if we have a
common database of DTBs, it would be possible for the distribution to
automatically manage DTB updates.
This way , will not be standard for non-UEFI boot .
We don't have any standard for non-UEFI boot regardless. :-) I'd like to
tackle the EDK2 & U-Boot based UEFI scenarios first. After that we
should take a look at LittleKernel and see if the same things can be
applied there.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
