On Wed, Apr 25, 2018 at 11:04:13AM +0100, Grant Likely wrote:
> 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.
So, the functionality in GRUB to replace a firmware-provided
devicetree needs to go. And dtb= loading should ideally be made
dependent on some sort of DEBUG config option.
Suppliers that consider the DTB a feature of the kernel image need to
go back to appending it to the kernel image.
And if overriding the firmware-provided system configuration is
necessary for booting at all, a trivial portable UEFI application can
be written to do that.
The thing I would like to add that is not just repeating myself is
just pointing out that "firmware" is not just EDK2/U-Boot. It is
entirely feasible that either of those inherit an already modified DTB
from an earlier firmware stage. (I.e., let's make sure we don't just
kick the GRUB problem one step up the stack.)
/
Leif
--
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
