> -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@xxxxxxxxxx] > Sent: Thursday, April 26, 2018 2:12 PM > To: Grant Likely <grant.likely@xxxxxxx> > Cc: Udit Kumar <udit.kumar@xxxxxxx>; Leif Lindholm > <leif.lindholm@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 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. Should we keep the dtb for UEFI and OS separate or not? The bootloader is expected to control only those devices from which it expects to get the OS to boot. The dtb file for bootloader will contain only these devices' nodes, while the dtb passed to OS will contain list of all devices that are available on a platform. > > 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. ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
