The UEFI spec already specifies the image format. No need to specify in
EBBR.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 6 ------
1 file changed, 6 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 177a81c..f89ac04 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -73,12 +73,6 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
-UEFI Loaded Images
-------------------
-
-UEFI loaded images for AArch64 must be in 64-bit PE/COFF format and must
-contain only A64 code.
-
Configuration Tables
--------------------
--
2.13.0
Hi everyone,
I've tagged v0.7 of EBBR for review. Please feel free to circulate and
solicit feedback. It will certainly be discussed at ELC Europe next week
in Edinburgh.
https://github.com/ARM-software/ebbr/releases/tag/v0.7
Thanks,
g.
ResetSystem() was over-specified in the document. UEFI already documents
the behaviour of ResetSystem() sufficiently. Add notes on expected
behaviour when platform specific or standard interface methods are
available.
Resolves: #29
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 0cbddff..8a3ff1a 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -175,23 +175,16 @@ and the OS must use a device driver to control the RTC.
UEFI Reset and Shutdown
-----------------------
-The UEFI Runtime service ResetSystem() must implement the following commands,
-for purposes of power management and system control.
-
-- EfiResetCold()
-- EfiResetShutdown()
- * EfiResetShutdown must not reboot the system.
-
-If firmware updates are supported through the Runtime Service of
-UpdateCapsule(), then ResetSystem() might need to support the following
-command:
-
-- EfiWarmReset()
-
-.. note:: On platforms implementing the Power State Coordination Interface
- specification [PSCI]_, it is still required that EBBR compliant
- Operating Systems calls to reset the system will go via Runtime Services
- and not directly to PSCI.
+ResetSystem() is required to be implemented in boot services, but it is
+optional for runtime services.
+During runtime services, the operating system should first attempt to
+use ResetSystem() to reset the system.
+If ResetSystem() returns EFI_UNSUPPORTED, then the OS may fall back to
+an architecture or platform specific mechanism.
+
+On AArch64 platforms implementing [PSCI]_,
+if ResetSystem() is not implemented then the Operating System should fall
+back to making a PSCI call to reset or shutdown the system.
Runtime Variable Access
-----------------------
--
2.13.0
For those of you dialing into the weekly EBBR call, the dial in details
have changed (see below). We'll use WebEx instead of Skype for Business
from here on.
Agenda 27/09/2018:
• YVR18 Recap
• Review meeting time
• Release schedule
• Get/SetVariable – once more with feeling
• reference platforms/qemu
Anyone is welcome to join. Feel free to pass this invitation along. Let
me know if anyone has trouble dialling/connecting to the SfB bridge.
Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST)
[1]
https://lists.linaro.org/pipermail/boot-architecture/2018-April/000419.html
g.
---
Grant Likely's Personal Room
https://arm-onsite.webex.com/meet/gralik01
Access code: 809 053 990
Join by phone
1-408-792-6300 Call-in toll number (US/Canada)
1-877-668-4490 Call-in toll-free number (US/Canada)
44-203-478-5285 Call-in toll number (UK)
08-002061177 Call-in toll-free (UK)
Access code: 809 053 990
More access numbers:
https://arm-onsite.webex.com/cmp3300/webcomponents/widget/globalcallin/glob…https://www.webex.com/pdf/tollfree_restrictions.pdf
Hello,
Can we add a discussion in upcoming meetings about the participation
of SMMU in the booting procedure?
In the past there's been a number of proposals on how to mitigate
attacks, were a rogue PCI card is inserted into the system.
Some of them include shutting down external DMA ports until the OS
explicitly powers them up or blocking DMA using BME bit etc
Keeping in mind this will enhance the security of devices would it
make sense to include it as a 'MUST' if the hardware is present or a
recommendation would be enough?
If we enable if a number of questions will rise as well such as, What
happens if the SMMU is already configured? Should the OS reconfigure
it ?
/Ilias
