Instead of masking out GetVariable() when SetVariable() isn't available
during runtime services, simplify the requirements without losing the
ability to read variables by using the RuntimeServicesSupported variable
from UEFI v2.8.1 (unreleased); Mantis issue 1961.
Peter Jones's earlier patch also specified a Capsule-on-Disk format for
updating variables that the OS could store in the ESP. I've not included
that specification in this patch as it is logically a separate feature.
It may reappear in a separate patch at a later date, or it may get
proposed for inclusion in the UEFI spec proper.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
Cc: Peter Jones <pjones(a)redhat.com>
---
source/chapter2-uefi.rst | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 379f0ca..4f74d43 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -201,14 +201,15 @@ variables stored on shared media. [#OPTEESupplicant]_
If a platform does not implement modifying non-volatile variables with
SetVariable() after ExitBootServices(),
-then it must not provide any variable operations after ExitBootServices().
-Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(),
-GetNextVariableName() and SetVariable().
-Firmware shall not emulated non-volatile variables using volatile RAM cache.
+then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(),
+and must advertise that SetVariable() isn't available during runtime services
+via the "RuntimeServicesSupported" variable as defined in UEFI version 2.8.1.
+EFI applications can read RuntimeServicesSupported to determine if calls
+to SetVariable() need to be performed before calling ExitBootServices().
-.. note:: The behaviour when SetVariable() is not supported during runtime
- services is still under discussion and subject to change.
- Do not make any firmware implementation decisions based on this text yet.
+Even when SetVariable() is not supported during runtime services, firmware
+should cache variable names and values in EfiRuntimeServicesData memory so
+that GetVariable() and GetNextVeriableName() can behave as specified.
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
@@ -216,5 +217,7 @@ Firmware shall not emulated non-volatile variables using volatile RAM cache.
storage operations on behalf of OP-TEE.
The same solution may be applicable to solving the UEFI non-volatile
variable problem, but it requires additional OS support to work.
+ Regardless, EBBR compliance does not require SetVariable() support
+ during runtime services.
https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage…
--
2.13.0
On Fri, Dec 7, 2018 at 9:16 AM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Fri, Dec 07, 2018 at 08:57:06AM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 2:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> > > The issues with the existing install_dtbs sounded unrelated to this.
>
> > Maybe, what are the issues? We can't change the source layout
> > transparently if dtbs_install is not being used.
>
> I thought that was the thing with adding -@ so overlays could be used?
I don't think so as that is during building, not install. Any user can
set '-@' with 'make DTC_FLAGS="-@" ...' already. The issue with that
was changing the default globally and no way to set per platform. Now
that I think about, moving the sources to subdirs may allow setting
DTC_FLAGS per subdir which may be good enough.
Rob
On Thu, Dec 6, 2018 at 2:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber(a)suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system? If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary. It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all).
Correct.
> This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.
The kernel may have used directories, but that's not what the distros
did according to Andreas:
> We already had that discussion for arm64 because Debian chose to ignore
> the kernel-installed subdirectories and installed .dtb files into a flat
> directory, which collided with openSUSE sticking to the kernel choice.
So are the distros different or who changed to align? That's not clear
from this thread.
> The issues with the existing install_dtbs sounded unrelated to this.
Maybe, what are the issues? We can't change the source layout
transparently if dtbs_install is not being used.
My question here is whether a flat install is useful on arm64. We can
either have a kconfig variable that arm32 sets to do flat installs or
it could be some command line make variable and then any user can pick
what they want for any arch.
Rob
On Thu, Dec 6, 2018 at 12:07 PM Mark Brown <broonie(a)kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber(a)suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system? If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary. It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all). This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.
Yeah, install needs to remain flat even if the dts files move into
subdirectories. It will be painful for everybody if the install
location moves.
> The issues with the existing install_dtbs sounded unrelated to this.
Agreed.
-Olof
Rob,
Am 04.12.18 um 19:36 schrieb Rob Herring:
> I've put together a script to move the dts files and update the
> makefiles. It doesn't handle files not following a common prefix which
> isn't many and some includes within the dts files will need some fixups
> by hand.
>
> MAINTAINERS will also need updating.
>
> A few questions:
>
> Do we want to move absolutely everything to subdirs?
This refactoring is a terrible idea!
While it would've been nice to have more structure from the start,
bootloaders like U-Boot expect a flat structure for arm .dtb files now.
If you start installing them into subdirs instead, they won't find the
files anymore under the hardcoded name.
Doing this only for new platforms would be much less invasive and allow
to prepare bootloaders accordingly. Alternatively, white-list which ones
are safe to move around. But don't just script a refactoring because it
looks nicer in the source tree, without testing what side effects this
can have for board/distro users of the compiled files in practice.
We already had that discussion for arm64 because Debian chose to ignore
the kernel-installed subdirectories and installed .dtb files into a flat
directory, which collided with openSUSE sticking to the kernel choice.
This topic becomes even more important with EBBR: There is neither a
mechanism in place to sync .dts files into U-Boot or EDK2 source trees,
nor are capsule updates implemented in U-Boot for easily deploying such
bootloaders with new .dts sources or paths yet. And I can assure you
that just getting users to dd the right bootloader can be difficult...
Since DT forward and backward compatibility is often being neglected,
for example with optional properties or renamed compatibles that break
booting with previous drivers, new kernel versions often need updated
Device Trees to make use of new/enhanced drivers. Therefore it is
unfortunately often enough a necessity to load newer kernel-based .dtb
files matching the kernel (as opposed to the dream of kernel-independent
hardware descriptions) when working with the latest -rc or -next kernels
at least. For examples of DTs needing updates, look no further than
Linaro's 96boards - in case of hikey960/EDK2 GRUB is another layer where
.dtb paths may be hardcoded, ditto for arm; and Armada was an example
where the upstream bindings for the network IP changed incompatibly.
DT overlays are another topic that is not making any progress upstream
according to the ELCE BoF, so beyond the Raspberry Pi the only known
working way to apply them is to write a U-Boot boot.scr script, which
can either reuse $fdtcontroladdr DT or use the filename $fdtfile or
hardcode one, the latter two of which would break with your renaming.
So expect people to be using .dtb files, expect them to be affected by
file movements to subdirectories here, and don't expect each user to
understand or be able to fix things themselves if they fall apart as
result of your changes and they suddenly no longer have Ethernet/Wifi.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
I don't have an agenda for today. The one remaining blocker for 1.0 release is still open. I had hoped to get it written this past week, but haven't got it done yet.
I did have a very productive meeting with Qualcomm last week. They have good feedback on the v0.6 draft, but I'll let them speak for themselves.
I'm cancelling todays meeting, but I'll open the call anyway simply because it is so late that I'm sending this email. If you want to chat, feel free to dial in.
If you do have a topic you want to discuss next week, please email me in the next week.
g.
