u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Driver model at UEFI runtime
Date: Thu, 9 Sep 2021 13:16:56 +0200	[thread overview]
Message-ID: <2461183e-ae0a-d8b3-3822-6a06ee90950d@gmx.de> (raw)

Hello Simon,

The EBBR specification requires that the UEFI SystemReset() runtime
service is available to the operating system.

Up to now this has been implemented by overriding function
efi_reset_system() which is marked as __efi_runtime.

Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM
and the System Reset Extension for SBI on RISC-V. This has kept the
number of implementations low. The only exceptions are:

* arch/arm/cpu/armv8/fsl-layerscape/cpu.c
* arch/arm/mach-bcm283x/reset.c for the Raspberry PIs
* arch/sandbox/cpu/start.c

Bin has suggested in
https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use
reset drivers based on the driver model.

Currently after ExitBootServices() the driver model does not exist anymore.

When evaluating Bin's suggestion one has to keep in mind that after
invoking ExitBootServices() most operating systems call
SetVirtualAddressMap(). Due to the change of the address map all
pointers used by U-Boot afterwards must be updated to match the new
memory map.

The impression that Ilias and I have is that keeping the driver model
alive after SetVirtualAddressMap() would incur:

* a high development effort
* a significant code size increase
* an enlarged attack surface

For RISC-V it has been clarified in the platform specification that the
SBI must implement the system reset extension. For ARMv8 using TF-A and
PSCI is what ARM suggests.

So for these architectures we do not expect a growth in the number of
drivers needed.

Ilias and my favorite would be keeping the design as is.

What is your view on this?

Best regards

Heinrich

             reply	other threads:[~2021-09-09 11:17 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 11:16 Heinrich Schuchardt [this message]
2021-09-09 20:00 ` Driver model at UEFI runtime Simon Glass
2021-09-10 14:14   ` Heinrich Schuchardt
2021-09-30  4:08     ` Simon Glass
2021-09-30 11:13       ` Mark Kettenis
2021-09-30 11:49         ` Heinrich Schuchardt
2021-09-30  5:11 ` Bin Meng
2021-09-30  6:23   ` François Ozog
2021-09-30  6:38     ` Bin Meng
2021-09-30  6:45       ` François Ozog
2021-09-30  6:46       ` Ilias Apalodimas
2021-09-30 11:40         ` Mark Kettenis
2021-09-30  6:56     ` Heinrich Schuchardt
2021-09-30  9:53       ` Michael Walle
2021-09-30 10:50         ` Heinrich Schuchardt
2021-09-30 12:07           ` Michael Walle
2021-09-30 13:24             ` Heinrich Schuchardt
2021-09-30 13:56             ` François Ozog
2021-09-30 15:12               ` Michael Walle
2021-09-30 15:47                 ` François Ozog
2021-09-30 16:25                   ` Michael Walle
2021-09-30 16:53                     ` François Ozog
2021-09-30 22:00                       ` Michael Walle
2021-09-30 22:20                         ` François Ozog
2021-09-30 22:54                           ` Michael Walle
2021-09-30 11:31     ` Mark Kettenis
2021-09-30 12:03       ` Heinrich Schuchardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2461183e-ae0a-d8b3-3822-6a06ee90950d@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=bmeng.cn@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).