On 5/13/20 2:48 PM, Grant Likely wrote:
On 12/05/2020 18:54, Ard Biesheuvel wrote:
On 5/12/20 7:23 PM, Grant Likely wrote:
On 12/05/2020 18:16, Ard Biesheuvel wrote:
On Tue, 12 May 2020 at 19:05, Grant Likely <grant.lik...@arm.com>
wrote:
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson
<daniel.thomp...@linaro.org>
wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt
wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/
for a
limited set of changes to the dtb, then those specific
cases can
be spelled out as things firmware is allowed to modify in a
replacement DTB. Any scenarios here need to be very
specific.
What specific cases do we know about?
None. There is no way the firmware can currently
manipulate the DTB
after the EFI stub has taken ownership of it. We load the
firmware
provided one, copy it into a new allocation and make our
changes
there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is
needed for
when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been
installed as a
config table.
Second, if an Efi application replaces the DTB, what are the
known
scenarios for wanting firmware to apply fixups to the DTB
(again; need
to be very specific)
None. The firmware should not expect to be given the
opportunity to
tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree
command if it
does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part
of the
system firmware) is entitled to make changes that the system
firmware
must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros
targeting
servers and desktops.
In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then
it is
part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see
it as the
"authoritative entity" to deal with chosen node (bootargs, cma) and
speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and
for
development and testing.
However from an EBBR point of view there is no reason to care
about the
role of grub in the DT lifecycle because it is not in scope. Once we
have handed over to next component (whether it is grub, the
efistub, a
bsd loader or any other OS component) then we no longer get a say in
what happens to the DT.
To get back to something concrete in the EBBR text, how about the
addition of the following text to the Devicetree section?
---
Firmware must have the DTB resident in memory and listed in the EFI
system table before executing any UEFI applications. Firmware must not
modify the resident DTB while a UEFI application is executing,
including
during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB.
Firmware must ignore any changes to the DTB made by an application and
simply pass the modified or replaced DTB through to the operating
system. Firmware must not depend on the in-memory DTB for its own
operation. I.e., Once execution of a UEFI application begins, firmware
must treat the resident DTB as an anonymous blob and not depend on any
data in the DTB.
---
I think that covers the use cases of UEFI applications making
changes to
the DTB (for any number of valid reasons); but spells out that the
firmware is not to make use of or change the DTB once application
execution begins.
This still suggests that the system firmware is involved at all in
passing the DTB once it has handed off to any UEFI application
including the OS loader, but it shouldn't be.
The system firmware should simply
a) *produce* the DTB as a config table before calling any other
applications (or even other 3rd party drivers if they are supported -
this amounts to the meaning of EndOfDxe in PI)
b) not *consume* a DTB from the config table - even if it uses DT
internally, it should not reload the DT that a loader may have
installed.
Can you suggest how I describe this in the spec?
Perhaps something along the lines of:
"""
If a DTB is used to describe the platform to the OS, it must be
installed as a EFI configuration table under the appropriate GUID by
the system firmware before starting any UEFI applications or drivers
that are not part of the system firmware image themselves. Once the
DTB is installed as a configuration table, the system firmware must
not make any modifications to it.
Works for me.
UEFI applications are permitted to replace the installed DTB.
Modifications to the installed DTB are not allowed, but it is
permitted to clone the installed DTB, apply any changes to the clone
and install it as a replacement.
I think this goes too far. Modifying a DTB in place is normal practice.
Why is in not permitted to modify the firmware-provided DTB in-place?
This is related to the below. If the system firmware is permitted to use
DTB internally, we should either require it to publish a copy, or
require other agents to make a copy. Otherwise, these other agents may
modify the data structure that the firmware relies on for its internal
implementation. Of course, this assumes the internal and external DT are
the same and thus compatible, which may not be the case.
The system firmware may use DTB internally in its implementation, but
it must not rely on DTB images that are installed as EFI configuration
tables by other agents under the reserved DTB GUID.
Works for me
g.
"""
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
