On 26 April 2018 at 10:37, Grant Likely <grant.likely@xxxxxxx> wrote: > On 25/04/2018 15:48, Udit Kumar wrote: >> >> >> >>> -----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 > > > I don't want to drop the prototyping use cases on the floor. ie. Wiring up a > development board to external hardware. The development board is already > supported, but the user is going to be experimenting with DT changes as they > go. Reflashing the DT is not a good option in this case. It is more usefule > to be able to load the DT modifications at runtime before booting the > kernel, because they will change every boot. > > I can see this scenario playing out for both full DT replacement and DTBO > scenarios. > This applies mainly to prototyping under the OS, right? One aspect we did not consider yet I think is the use of DT to describe the platform to ARM-TF and UEFI itself. I expect this to become more common going forward, and will make replacing just the DTB even trickier. So overriding the DTB like we allow for DSDT makes perfect sense, but as a development feature only. I still think the idea of just dropping an updated DTB into an existing firmware build consisting of ARM-TF, UEFI etc (and perhaps even OP-TEE?) is not something that is going to be feasible in general. -- 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
