> -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@xxxxxxxxxx] > Sent: Wednesday, April 25, 2018 4:20 PM > To: Grant Likely <grant.likely@xxxxxxx> > Cc: Udit Kumar <udit.kumar@xxxxxxx>; Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx>; Pankaj Bansal <pankaj.bansal@xxxxxxx>; > mark.rutland@xxxxxxx; linux-efi@xxxxxxxxxxxxxxx; Varun Sethi > <V.Sethi@xxxxxxx>; Wasim Khan <wasim.khan@xxxxxxx>; nd@xxxxxxx; Rod > Dorris <rod.dorris@xxxxxxx> > Subject: Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in configuration > table > > 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. In my view , dtb= sort of option should go away. If we are booting some debug image in development environment then why not to re-flash DTB > 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. If hosting one distribution, I could see this as valid option. > 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.) In case of hosting multiple distribution, and each requiring its own overlays. What is your views on merging DTBO (distribution specific) and DTB (firmware provided). IMO, Grub selects which Kernel to boot, so it can merge needed DTBO. > / > 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
