This series came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.
I tested this on a RPi3 B with the pinctrl driver forced off. With this
change, the MMC/SD and UART drivers can function without the pinctrl
driver. I left the dts change out this time.
v2 and v3 of this series can be found here[2][3].
Rob
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
[2] https://lore.kernel.org/patchwork/project/lkml/list/?series=347413
[3] https://lore.kernel.org/patchwork/project/lkml/list/?series=357344
Rob Herring (6):
driver core: allow stopping deferred probe after init
dt-bindings: pinctrl: add a 'pinctrl-use-default' property
pinctrl: Support stopping deferred probe after initcalls
iommu: Stop deferring probe at end of initcalls
iommu: Remove IOMMU_OF_DECLARE
PM / Domains: Stop deferring probe at the end of initcall
.../admin-guide/kernel-parameters.txt | 9 +++
.../bindings/pinctrl/pinctrl-bindings.txt | 6 ++
drivers/base/dd.c | 59 +++++++++++++++++++
drivers/base/power/domain.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 -
drivers/iommu/arm-smmu.c | 7 ---
drivers/iommu/exynos-iommu.c | 2 -
drivers/iommu/ipmmu-vmsa.c | 3 -
drivers/iommu/msm_iommu.c | 2 -
drivers/iommu/of_iommu.c | 21 +------
drivers/iommu/qcom_iommu.c | 2 -
drivers/iommu/rockchip-iommu.c | 2 -
drivers/pinctrl/devicetree.c | 15 +++--
include/asm-generic/vmlinux.lds.h | 2 -
include/linux/device.h | 2 +
include/linux/of_iommu.h | 4 --
16 files changed, 90 insertions(+), 50 deletions(-)
--
2.17.1
Some of the language was ambiguous and it seemed like UEFI was optional.
Tighten it up to be clear the EBBR requires UEFI and add some details
about how EBBR informs how UEFI is used for embedded systems.
The block device partitioning section is also moved within the chapter
so it doesn't appear as a subsection of the system environment section
(which mainly talks about the CPU execution mode).
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/appendix-a-uefi-features.rst | 2 ++
source/chapter1-about.rst | 17 ++++++++++-------
source/chapter2-uefi.rst | 29 ++++++++++++++---------------
3 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/source/appendix-a-uefi-features.rst b/source/appendix-a-uefi-features.rst
index 0bdc712..709b929 100644
--- a/source/appendix-a-uefi-features.rst
+++ b/source/appendix-a-uefi-features.rst
@@ -1,3 +1,5 @@
+.. _appendix-uefi-requirements:
+
#############################################
APPENDIX A - UEFI Implementation Requirements
#############################################
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index d713cf3..b667f1b 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -5,18 +5,21 @@ About This Document
Introduction
============
-This Embedded Base Boot Requirements (EBBR) specification is intended for Arm
-embedded devices that want to take advantage of the UEFI technology to separate
-the firmware and OS development.
-For example, class-A embedded devices like networking platforms can benefit
+This Embedded Base Boot Requirements (EBBR) specification defines an interface
+between platform firmware and an operating system that is suitable for embedded
+platforms.
+EBBR compliant platforms present a consistent interface that will boot an EBBR
+compliant operating system without any custom tailoring required.
+For example, an Arm A-class embedded networking platform will benefit
from a standard interface that supports features such as secure boot and
firmware update.
-This specification defines the base firmware requirements if UEFI is chosen.
+This specification defines the base firmware requirements for EBBR compliant platforms.
The requirements in this specification are expected to be minimal yet complete,
while leaving plenty of room for innovations and design details.
This specification is intended to be OS-neutral.
-It leverages the prevalent industry standard firmware specifications of UEFI.
+
+It leverages the prevalent industry standard firmware specification of [UEFI]_.
Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com.
@@ -24,7 +27,7 @@ Scope
=====
This document defines the boot and runtime services that are expected by an
Operating System or hypervisor, for an Arm embedded device, which follows the
-UEFI specification.
+UEFI specification [UEFI]_.
This specification defines the boot and runtime services for a physical system,
including services that are required for virtualization.
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index d13c19e..a8bd71e 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -2,21 +2,26 @@
UEFI
****
+This chapter discusses specific UEFI implementation details for EBBR compliant
+platforms.
+
UEFI Version
============
-
-Boot and system firmware for Arm embedded devices can be based on the UEFI
-specification [UEFI]_, version 2.7 or later, incorporating the AArch64 bindings.
+This document uses version 2.7 of the UEFI specification [UEFI]_.
UEFI Compliance
===============
-Any UEFI-compliant system must follow the requirements that are laid out in
-section 2.6 of the UEFI specification [UEFI]_.
-However, to ensure a common boot architecture for embedded-class, systems
-compliant with this specification must always provide the UEFI services and
-protocols that are listed in Appendix A, Appendix B, and Appendix C of this
-document.
+EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6,
+except where explicit exemptions are provided by this document.
+
+EBBR compliant platforms shall also implement the UEFI services and
+protocols that are listed in :ref:appendix-uefi-requirements of this document.
+
+Block device partitioning
+-------------------------
+
+The system firmware must implement support for MBR, GPT and El Torito partitioning.
UEFI System Environment and Configuration
=========================================
@@ -50,12 +55,6 @@ UEFI-compliant Operating System.
In this instance, the UEFI boot-time environment can be provided, as a
virtualized service, by the hypervisor and not as part of the host firmware.
-System Volume Format
---------------------
-
-The system firmware must support all partitioning standards required
-by the UEFI specification.
-
UEFI Boot Services
==================
--
2.13.0
Give some rationale behind EBBR so the reader understands what problem
the specification is intended to solve.
Signed-off-by: Bill Mills <wmills(a)ti.com>
[glikely: made it more verbose to make the intent clear]
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter1-about.rst | 94 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index b667f1b..cb675d9 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -23,6 +23,100 @@ It leverages the prevalent industry standard firmware specification of [UEFI]_.
Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com.
+Guiding Principals
+==================
+
+EBBR as a specification defines requirements on platforms and operating systems,
+but requirements alone don't provide insight into why the specification is
+written the way it is, or what problems it is intended to solve.
+Using the assumption that better understanding of the thought process behind
+EBBR will result in better implementations, this section is a discussion of the
+goals and guiding principle that shaped EBBR.
+
+This section should be considered commentary, and not a formal part of the specification.
+
+EBBR was written as a response to the lack of boot sequence standardization in the embedded system ecosystem.
+As embedded systems are becoming more sophisticated and connected,
+it is becoming increasingly important for embedded systems to run standard OS
+distributions and software stacks, or to have consistent behaviour across a
+large deployment of heterogeneous platforms.
+However, the lack of consistency between platforms often requires per-platform
+customization to get an OS image to boot on multiple platforms.
+
+A large part of this ecosystem is based on U-Boot and Linux.
+Vendors have heavy investments in both projects and are not interested in large
+scale changes to their firmware architecture.
+The challenge for EBBR is to define a set of boot standards that reduce the
+amount of custom engineering required, make it possible for OS distributions to
+support embedded platforms, while still preserving the firmware stack product
+vendors are comfortable with.
+Or in simpler terms, EBBR is designed to solve the embedded boot mess by
+migrating existing firmware projects (U-Boot) to a defined standard (UEFI).
+
+However, EBBR is a specification, not an implementation.
+The goal of EBBR is not to mandate U-Boot and Linux.
+Rather, it is to mandate interfaces that can be implemented by any firmware or
+OS project, while at the same time work with both Tianocore/EDK2 and U-Boot to
+ensure that the EBBR requirements are implemented by both projects.
+[#EDK2Note]_
+
+.. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the
+ time of writing these are the two most important firmware projects.
+ Tianocore/EDK2 is a full featured UEFI implementation and so should
+ automatically be EBBR compliant. U-Boot is the incumbant firmware project
+ for embedded platforms and has added basic UEFI compliance.
+
+The following guiding principals of the EBBR specification and its
+process:
+
+- Be agnostic about ACPI and Devicetree.
+
+ EBBR explicitly does not require a specific system description language.
+ Both Devicetree and ACPI are supported.
+ While ACPI provides more standardization, Devicetree is preferred in may embedded
+ platforms for its flexibility.
+ The Linux kernel supports both equally well, and so EBBR doesn't require one
+ over the other.
+ However, it does require the system description to be provided by the
+ platform, and that it conform to the relevant ACPI or DT specifications.
+
+- Focus on the UEFI interface, not a specific codebase
+
+ EBBR does not require a specific firmware implementation.
+ Any firmware project can implement these interfaces.
+ Neither U-Boot nor Tianocore/EDK2 are required.
+
+- Design to be implementable and useful today
+
+ The drafting process for EBBR worked closely with U-Boot and Tianocore
+ developers to ensure that current upstream code will meet the requirements.
+
+- Design to be OS independent
+
+ This document uses Linux as an example but other OS's are expected.
+
+- Support multiple architectures
+
+ Any architecture can implement the EBBR requirements.
+
+ .. note::
+ At the time of writing this document only addresses AArch64, but AArch32 and others architectures are expected.
+
+- Design for common embedded hardware
+
+ EBBR support will be implemented on existing developer hardware.
+ Generally anything that has a near-upstream U-Boot implementation should be
+ able to implement the EBBR requirements.
+ EBBR was drafted with readily available hardware in mind, like the
+ Raspberry Pi and BeagleBone families of boards, and it is applicable for low cost boards (<$10).
+
+- Plan to evolve over time
+
+ The first release of EBBR is firmly targeting current embedded hardware.
+ Future versions will add capabilities which may tighten the hardware requirements.
+
+ However, existing compliant boards will remain compliant.
+
Scope
=====
This document defines the boot and runtime services that are expected by an
--
2.13.0
All,
I rely on your greater knowledge to help me understand these questions.
Thanks in advance.
1) GPT and block size
GPT uses LBA for its data stuctures
The size of a block is historically 512B but is moving to larger sizes
(4KB). The code needs to handle this on a per device mount basis.
How does the driver know the block size used in the LBA?
1A) By querying the device
1B) Some MBR magic?
If 1A then that means to me that dd if=/dev/sdb of=/dev/sdc won't
produce a usable image on sdc if its block size is different than sdb's.
(Of course I also assume that the total space ion sdc is also == or >
than that of sdb. Which brings me to ...)
2) Can GPT be grown?
In the above example if sdc is much bigger than sdb,
I presume this is OK, at least as long as the GPT header in LBA1 passes
its CRC. Mounters won't query the drive size and refuse to mount the
GPT just because it does not cover the whole disk right?
Now what happens if LBA1 becomes corrupted? Now does the driver query
the drive size and block size and look at drive_size-block_size for the
backup GOT header? Again does it use the block size from the device or
does try something else? (I suppose to could try several block sizes
until it found a good CRC. However it does seem that it must assume
that the redundant copy is at the end of the physical disk.)
So even if the GPT is "mounted" OK, the extra space on the drive is not
usable, even for new partitions. Are there utilities that will "grow"
the GPT? Such growing would find the new end of disk and move the
redundant GPT table & header there.
3) Is it actually required that the partition array start at LBA2?
If not, then it would be possible to create a GPT assuming 512B blocks
but allow it to be "re-block sized" later by leaving 7 512B blocks free
before the table. Of course the partitions themselves should be aligned
and sized to multiples of the max block size expected. This is probibly
already done as you would want them to align to the prefered read/write
and those will almost certianly be larger than 512B.
Why?
The main case I am thinking about is:
wget http://downloads.new-wizbang-os.org/images/latest/aarch64-disk.img
dd if=aarch64-disk.img of=/dev/my-usb-sd-adapter
Then boot the image and the OS will resize the GPT and last filesystem
to cover the 16GB of my SD card even though they only require a minimum
size of 2GB.
Thanks,
Bill
----------------
William A. Mills
Chief Technologist, Open Solutions, SDO
Texas Instruments, Inc.
20450 Century Blvd
Germantown MD 20878
240-643-0836
This series came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.
I tested this on a RPi3 B with the pinctrl driver forced off. With this
change, the MMC/SD and UART drivers can function without the pinctrl
driver. I left the dts change out this time.
v2 of this series can be found here[2].
Rob
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
[2] https://lore.kernel.org/patchwork/project/lkml/list/?series=347413
Rob Herring (6):
driver core: allow stopping deferred probe after init
dt-bindings: pinctrl: add a 'pinctrl-use-default' property
pinctrl: Support stopping deferred probe after initcalls
iommu: Stop deferring probe at end of initcalls
iommu: Remove IOMMU_OF_DECLARE
PM / Domains: Stop deferring probe at the end of initcall
.../admin-guide/kernel-parameters.txt | 9 +++
.../bindings/pinctrl/pinctrl-bindings.txt | 6 ++
drivers/base/dd.c | 57 +++++++++++++++++++
drivers/base/power/domain.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 -
drivers/iommu/arm-smmu.c | 7 ---
drivers/iommu/exynos-iommu.c | 2 -
drivers/iommu/ipmmu-vmsa.c | 3 -
drivers/iommu/msm_iommu.c | 2 -
drivers/iommu/of_iommu.c | 21 +------
drivers/iommu/qcom_iommu.c | 2 -
drivers/iommu/rockchip-iommu.c | 2 -
drivers/pinctrl/devicetree.c | 15 +++--
include/asm-generic/vmlinux.lds.h | 2 -
include/linux/device.h | 2 +
include/linux/of_iommu.h | 4 --
16 files changed, 88 insertions(+), 50 deletions(-)
--
2.17.1
All,
We really should be doing presentations at Linaro Connect and ELC-E.
I can volunteer to help present at ELC-E but I think it would looks better if a small group was represented.
For Connect, I won't volunteer to present. I tried that last time and with my required schedule at connect it just does not work out.
The ELC-E CFP closed Monday. Perhaps we can sweet talk an extension? Grant, you might have the best chance.
Thanks,
Bill
---------------------------------------------------
William A. Mills
Chief Technologist, Open Source
Texas Instruments, Processors
20450 Century Blvd
Germantown MD, 20874
(work/mobile) +1-240-643-0836
Dong,
Looking at the current state of EBBR, Appendix A contains a big list of
boot/runtime services and protocols that are required to be implemented.
However, I don't think this list has been audited, and I'm not sure how
much of it is actually needed. Some of these things (like the list of
boot/runtime services) seem to be required by the UEFI spec, so it is
redundant to list them here.
I'm also unsure on the list of protocols. Some I'm sure are already
required by the UEFI spec. e.g., UEFI section 2.6.1 requires
EFI_LOADED_IMAGE_PROTOCOL, EFI_LOADED_IMAGE_DEVICE_PATH,
EFI_DEVICE_PATH_PROTOCOL, EFI_DECOMPRESS_PROTOCOL, and
EFI_DEVICE_PATH_UTILITIES_PROTOCOL, so is it necessary to list them in EBBR?
Looking at the current U-Boot implementation, only the following
protocols are implemented:
include/efi_api.h|277| #define LOADED_IMAGE_PROTOCOL_GUID \
include/efi_api.h|519| #define EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID \
include/efi_api.h|590| #define EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID \
include/efi_api.h|603| #define EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID \
include/efi_api.h|619| #define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \
include/efi_api.h|853| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \
include/efi_api.h|882| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \
include/efi_api.h|933| #define EFI_DRIVER_BINDING_PROTOCOL_GUID \
Presumably Grub and the kernel only use the above protocols, and they
are sufficient to handle perform the distro installer use case. Yet it
is not compliant with UEFI 2.7. Notably missing are:
UEFI § 2.6.1
- EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL
- EFI_DEVICE_PATH_PROTOCOL
- EFI_DECOMPRESS_PROTOCOL
UEFI § 2.6.2
- EFI_SIMPLE_TEXT_EX_PROTOCOL
- EFI_BLOCK_IO_PROTOCOL
- EFI_DISK_IO_PROTOCOL
- EFI_UNICODE_COLLATION_PROTOCOL
- EFI_SERIAL_IO_PROTOCOL
- EFI_USB2_HC_PROTOCOL
- EFI_USB_IO_PROTOCOL
In fact, perhaps what EBBR needs is a list of exceptions to the UEFI §
2.6 requirements (expected to reduce over time as the U-Boot
implementation matures). Thoughts?
For discussion, I've pasted the text of the current UEFI appendix below
to make it easy to comment on the mailing list.
g.
---
.. _appendix-uefi-requirements:
#############################################
APPENDIX A - UEFI Implementation Requirements
#############################################
Required Boot Services
**********************
========================================== ======
Service UEFI §
========================================== ======
EFI_RAISE_TPL 7.1
EFI_RESTORE_TPL 7.1
EFI_ALLOCATE_PAGES 7.2
EFI_FREE_PAGES 7.2
EFI_GET_MEMORY_MAP 7.2
EFI_ALLOCATE_POOL 7.2
EFI_FREE_POOL 7.2
EFI_CREATE_EVENT 7.1
EFI_SET_TIMER 7.1
EFI_WAIT_FOR_EVENT 7.1
EFI_SIGNAL_EVENT 7.1
EFI_CLOSE_EVENT 7.1
EFI_INSTALL_PROTOCOL_INTERFACE 7.3
EFI_REINSTALL_PROTOCOL_INTERFACE 7.3
EFI_UNINSTALL_PROTOCOL_INTERFACE 7.3
EFI_HANDLE_PROTOCOL 7.3
EFI_REGISTER_PROTOCOL_NOTIFY 7.3
EFI_LOCATE_HANDLE 7.3
EFI_LOCATE_PROTOCOL 7.3
EFI_LOCATE_DEVICE_PATH 7.3
EFI_INSTALL_CONFIGURATION_TABLE 7.3
EFI_IMAGE_LOAD 7.4
EFI_IMAGE_START 7.4
EFI_EXIT 7.4
EFI_IMAGE_UNLOAD 7.4
EFI_EXIT_BOOT_SERVICES 7.4
EFI_GET_NEXT_MONOTONIC_COUNT 7.5
EFI_STALL 7.5
EFI_SET_WATCHDOG_TIMER 7.5
EFI_CONNECT_CONTROLLER 7.3
EFI_DISCONNECT_CONTROLLER 7.3
EFI_OPEN_PROTOCOL 7.3
EFI_CLOSE_PROTOCOL 7.3
EFI_OPEN_PROTOCOL_INFORMATION 7.3
EFI_PROTOCOLS_PER_HANDLE 7.3
EFI_LOCATE_HANDLE_BUFFER 7.3
EFI_LOCATE_PROTOCOL 7.3
EFI_INSTALL_MULTIPLE_PROTOCOL_INTERFACES 7.3
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES 7.3
EFI_CALCULATE_CRC32 7.5
EFI_COPY_MEM 7.5
EFI_SET_MEM 7.5
EFI_CREATE_EVENT_EX 7.5
========================================== ======
Required Runtime Services
*************************
========================================== ======
Service UEFI §
========================================== ======
EFI_GET_TIME 8.3
EFI_SET_TIME 8.3
EFI_GET_WAKEUP_TIME 8.3
EFI_SET_WAKEUP_TIME 8.3
EFI_SET_VIRTUAL_ADDRESS_MAP 8.4
EFI_CONVERT_POINTER 8.4
EFI_GET_VARIABLE 8.2
EFI_GET_NEXT_VARIABLE_NAME 8.2
EFI_SET_VARIABLE 8.2
EFI_GET_NEXT_HIGH_MONO_COUNT 8.5
EFI_RESET_SYSTEM 8.5
EFI_UPDATE_CAPSULE 8.5
EFI_QUERY_CAPSULE_CAPABILITIES 8.5
EFI_QUERY_VARIABLE_INFO 8.5
========================================== ======
.. note:: EFI_GET_WAKEUP_TIME and EFI_SET_WAKEUP_TIME must be
implemented, but
might simply return EFI_UNSUPPORTED.
Required UEFI Protocols
***********************
Core UEFI Protocols
===================
========================================== ======
Service UEFI §
========================================== ======
EFI_LOADED_IMAGE_PROTOCOL 9.1
EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL 9.2
EFI_DECOMPRESS_PROTOCOL 19.5
EFI_DEVICE_PATH_PROTOCOL 10.2
EFI_DEVICE_PATH_UTILITIES_PROTOCOL 10.3
========================================== ======
Media I/O Protocols
===================
========================================== ======
Service UEFI §
========================================== ======
EFI_LOAD_FILE2_PROTOCOL 13.2
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 13.4
EFI_FILE_PROTOCOL 13.5
========================================== ======
Console Protocols
=================
========================================== ======
Service UEFI §
========================================== ======
EFI_SIMPLE_TEXT_INPUT_PROTOCOL 12.2
EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL 12.3
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL 12.4
========================================== ======
Driver Configuration Protocols
==============================
========================================== ======
Service UEFI §
========================================== ======
EFI_HII_DATABASE_PROTOCOL 33.4
EFI_HII_STRING_PROTOCOL 33.4
EFI_HII_CONFIG_ROUTING_PROTOCOL 33.4
EFI_HII_CONFIG_ACCESS_PROTOCOL 33.4
========================================== ======
Optional UEFI Protocols
***********************
Basic Networking Support
========================
============================================ ======
Service UEFI §
============================================ ======
EFI_SIMPLE_NETWORK_PROTOCOL 24.1
EFI_MANAGED_NETWORK_PROTOCOL 25.1
EFI_MANAGED_NETWORK_SERVICE_BINDING_PROTOCOL 25.1
============================================ ======
.. note:: Networking services are optional on platforms that do not support
networking.
Network Boot Protocols
======================
========================================== ======
Service UEFI §
========================================== ======
EFI_PXE_BASE_CODE_PROTOCOL 24.3
EFI_PXE_BASE_CODE_CALLBACK_PROTOCOL 24.4
EFI_BIS_PROTOCOL 24.5
EFI_MTFTP4_PROTOCOL 30.3
EFI_MTFTP6_PROTOCOL 30.4
========================================== ======
.. note:: EFI_BIS_PROTOCOL is optional on machines that do not support
Secure
Boot.
IPV4 Network Support
====================
========================================== ======
Service UEFI §
========================================== ======
EFI_ARP_PROTOCOL 29.1
EFI_ARP_SERVICE_BINDING_PROTOCOL 29.1
EFI_DHCP4_SERVICE_BINDING_PROTOCOL 29.2
EFI_DHCP4_PROTOCOL 29.2
EFI_TCP4_PROTOCOL 28.1.2
EFI_TCP4_SERVICE_BINDING_PROTOCOL 28.1.1
EFI_IP4_SERVICE_BINDING_PROTOCOL 28.3.1
EFI_IP4_CONFIG2_PROTOCOL 28.5
EFI_UDP4_PROTOCOL 30.1.2
EFI_UDP4_SERVICE_BINDING_PROTOCOL 30.1.1
========================================== ======
.. note:: Networking services are optional on platforms that do not support
networking.
IPV6 Network Support
====================
========================================== ======
Service UEFI §
========================================== ======
EFI_DHCP6_PROTOCOL 29.3.2
EFI_DHCP6_SERVICE_BINDING_PROTOCOL 29.3.1
EFI_TCP6_PROTOCOL 28.2.2
EFI_TCP6_SERVICE_BINDING_PROTOCOL 28.2.1
EFI_IP6_SERVICE_BINDING_PROTOCOL 28.6.1
EFI_IP6_CONFIG_PROTOCOL 28.7
EFI_UDP6_PROTOCOL 30.2.2
EFI_UDP6_SERVICE_BINDING_PROTOCOL 30.2.1
========================================== ======
.. note:: Networking services are optional on platforms that do not support
networking.
VLAN Protocols
==============
========================================== ======
Service UEFI §
========================================== ======
EFI_VLAN_CONFIG_PROTOCOL 27.1
========================================== ======
iSCSI Protocols
===============
========================================== ======
Service UEFI §
========================================== ======
EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2
========================================== ======
.. note:: Support for iSCSI is only required on machines that lack
persistent
storage, such as a, HDD. This configuration is intended for thin
clients and
compute-only nodes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Tell people what to expect from EBBR in easy bullet form.
Signed-off-by: Bill Mills <wmills(a)ti.com>
---
source/chapter1-about.rst | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 125e400..83c682f 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -18,6 +18,46 @@ while leaving plenty of room for innovations and design details.
This specification is intended to be OS-neutral.
It leverages the prevalent industry standard firmware specifications of UEFI.
+Guiding Principals
+==================
+
+The following are the guiding principals of the EBBR specification and its
+process:
+
+- DeviceTree or ACPI
+
+ Describes the hardware and firmware to the OS
+
+- UEFI interface, not a specific codebase
+
+ Can be implemented by U-Boot or Tianocore/EDK2 or others
+
+- Implementable and useful today
+
+ EBBR is always defined so that current U-Boot can implement the requirements
+
+- OS independant
+
+ This document may use Linux as an example but other OS's are expected
+
+- Multiple Architectures
+
+ This document addresses AArch64 today but AArch32 and others are expected
+
+- Is designed with Embedded Hardware in mind
+
+ Works on today's boards
+
+ Simple low cost hardware recommendations for tomorrow's boards
+
+ Is appropriate for boards < $10
+
+- Will evolve
+
+ Future versions will add capabilities and may tighten hardware requirements
+
+ However, existing compliant boards will remain compliant
+
Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com.
Scope
--
2.7.4
On Ubuntu 16.04 the latexpdf target failed for me until I installed latexmk
Signed-off-by: Bill Mills <wmills(a)ti.com>
---
README.rst | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/README.rst b/README.rst
index c53ab3f..f20ddbf 100644
--- a/README.rst
+++ b/README.rst
@@ -38,7 +38,8 @@ On Debian and Ubuntu
::
# apt-get install python-sphinx texlive texlive-latex-extra libalgorithm-diff-perl \
- texlive-humanities texlive-generic-recommended texlive-generic-extra
+ texlive-humanities texlive-generic-recommended texlive-generic-extra \
+ latexmk
If the version of python-sphinx installed is too old, then an additional
new version can be installed with the Python package installer::
--
2.7.4
To make it absolutely clear that runtime services cannot retain access
to devices that are 'owned' by the OS, add a section spelling the
situation out. Devices may be owned by the OS, or owned by runtime
services, but not both.
Also rework the RTC clock section to allow for the RTC being
inaccessible for exactly that reason.
Resolves: #1, "Need policy on sharing devices between FW and OS"
Resolves: #14, "RTC should be optional"
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 33 +++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 05230d2..1f37944 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -143,17 +143,34 @@ To allow Operating Systems to use 64K page mappings, UEFI 2.7, constrains all
mapped 4K memory pages to have identical page attributes, within the same
physical 64K page.
-Real-time Clock
----------------
+Runtime Device Mappings
+-----------------------
+
+Firmware shall not create runtime mappings, or perform any runtime IO that will
+conflict with device access.
+Normally this means a device may be controlled by firmware, or controlled by
+the OS, but not both.
+e.g. If firmware attempts to access an eMMC device at runtime then it will
+conflict with transactions being performed by the OS.
+
+Devices that are provided to the OS (i.e., via PCIe discovery or ACPI/DT
+description) shall not be access by firmware at runtime.
+Similarly, devices retained by firmware (i.e., not discoverable by the OS)
+shall not be accessed by the OS.
+
+Only devices that explicitly support concurrent access by both firmware and an
+OS may be mapped at runtime by both firmware and the OS.
-The Real-time Clock must be accessible via the UEFI runtime firmware, and the
-following services must be provided:
+Real-time Clock (RTC)
+^^^^^^^^^^^^^^^^^^^^^
-- GetTime()
-- SetTime()
+In an embedded system design, it may not be possible to dedicate the RTC to
+runtime services. e.g., The RTC may be on a shared I2C bus which runtime
+services cannot access because it will conflict with the OS.
-It is permissible for SetTime() to return an error on systems where the
-Real-time Clock cannot be set by this call.
+Firmware must provide the UEFI GetTime() and SetTime() runtime service calls,
+but if an RTC isn't present, or cannot be accessed at runtime, then both calls
+shall return EFI_DEVICE_ERROR.
UEFI Reset and Shutdown
-----------------------
--
2.13.0
