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.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
