> -----Original Message-----
> From: Ard Biesheuvel [mailto:[email protected]]
> Sent: Thursday, April 26, 2018 2:12 PM
> To: Grant Likely <[email protected]>
> Cc: Udit Kumar <[email protected]>; Leif Lindholm
> <[email protected]>; Pankaj Bansal <[email protected]>;
> [email protected]; [email protected]; Varun Sethi
> <[email protected]>; Wasim Khan <[email protected]>; [email protected]; Rod
> Dorris <[email protected]>
> Subject: Re: [PATCH 2/2] drivers: firmware: efi: install new fdt in
> configuration
> table
>
> On 26 April 2018 at 10:37, Grant Likely <[email protected]> wrote:
> > On 25/04/2018 15:48, Udit Kumar wrote:
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Leif Lindholm [mailto:[email protected]]
> >>> Sent: Wednesday, April 25, 2018 4:20 PM
> >>> To: Grant Likely <[email protected]>
> >>> Cc: Udit Kumar <[email protected]>; Ard Biesheuvel
> >>> <[email protected]>; Pankaj Bansal <[email protected]>;
> >>> [email protected]; [email protected]; Varun Sethi
> >>> <[email protected]>; Wasim Khan <[email protected]>; [email protected];
> Rod
> >>> Dorris <[email protected]>
> >>> 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�����r��y����b�X��ǧv�^�){.n�+����{�y����^n�r���z���h�����&�� �G���h�(�階�ݢj"���m������z�ޖ���f���h���~�m�
