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
Special care is needed when storage is shared between firmware and the
OS. Add a chapter that discusses the issues and puts down the
requirements for using shared storage.
Resolves: #19
Cc: Daniel Thompson <daniel.thompson(a)linaro.org>
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter2-uefi.rst | 44 ------
source/chapter4-firmware-media.rst | 267 +++++++++++++++++++++++++++++++++++++
source/index.rst | 1 +
3 files changed, 268 insertions(+), 44 deletions(-)
create mode 100644 source/chapter4-firmware-media.rst
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 07426a4..05230d2 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -56,50 +56,6 @@ System Volume Format
The system firmware must support all partitioning standards required
by the UEFI specification.
-On systems where the system firmware binaries reside on the System Volume then
-the System Volume must be pre-configured with a partition table and include
-protective partitions to reduce risk of accidental destruction of the system
-firmware.
-
-All pre-installed partition tables must use GPT partitioning unless
-some immutable feature of the platform (such as a mask programmed boot ROM)
-makes this impossible; on such platforms MBR partitioning may be
-used as an alternative.
-
-GPT partitioning
-^^^^^^^^^^^^^^^^
-
-Any pre-installed partition table must strictly conform to the UEFI
-specification and include a protective MBR authored exactly as
-described in UEFI specification (hybrid partitioning schemes are not
-permitted).
-
-Pre-installed protective partitions must have the Platform Required
-Attribute Flag set.
-
-It is recommended that automatic system disk partitioning utilities
-preserve Platform Required partitions as is, and that manual disk
-partitioning utilities provide warnings and/or other safe guards to
-reduce risk of accidental removal.
-
-MBR partitioning
-^^^^^^^^^^^^^^^^
-
-Pre-installed protective partitions should have a partition type of 0xF8
-unless some immutable feature of the platform makes this impossible.
-
-It is recommended that disk partitioning utilities treat such
-partitions in the same manner as GPT partitions with the Platform
-Required Attribute Flag set.
-
-It is recommended that pre-installed protective partitions that are not
-type 0xF8 be located wholly within 1MB of the start of the disk.
-
-Automatic disk partitioning utilities shall not create partitions
-within 1MB of the start of the disk. Manual disk partitioning
-utilities should avoid recommending that partitions start within
-1MB of the start of the disk.
-
UEFI Boot Services
==================
diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst
new file mode 100644
index 0000000..f8a03db
--- /dev/null
+++ b/source/chapter4-firmware-media.rst
@@ -0,0 +1,267 @@
+****************
+Firmware Storage
+****************
+
+In general, it is recommended for all platforms to store firmware images
+and data on a dedicated storage device which is not accessed by the operating
+system.
+It is common practice to boot firmware out of a dedicated SPI flash,
+while the OS is loaded from another source, whether it be SATA, SD, USB,
+Network boot, or something else.
+
+However, many embedded systems have size, cost, or usage constraints that
+make separate firmware storage unfeasible.
+On such systems, firmware and the OS reside on the same media.
+
+Some shared media provides dedicate boot regions, but in many cases
+firmware needs to reside in a normal region of storage.
+Care must be taken to ensure firmware kept in normal storage does not
+conflict with normal usage of the media by an OS.
+
+* Firmware must be stored on the media in a way that does not conflict
+ with normal partitioning and usage by the operating system.
+* Normal operation of the OS must not interfere with firmware files
+* Firmware needs a method to modify variable storage at runtime while the
+ OS controls access to the device
+
+Partitioning of Shared Storage
+==============================
+
+Shared storage must use GPT partitioning unless the storage media provides
+device-native partitioning [#UFSparts]_,
+or if an immutable property of the platform (ex. the masked boot ROM)
+is incompatible with the SoC boot ROM).
+MBR partitioning shall be used when the platform is incompatible with GPT.
+
+.. warning::
+
+ MBR partitioning is deprecated and only included for legacy support.
+ All new platforms are expected to use either GPT or device-native
+ partitioning.
+
+ GPT partitioning supports a much larger number of partitions, and
+ has build in redundancy by storing two copies of the partition table.
+
+ A future issue of this specification will remove the MBR allowance.
+
+All firmware images and data stored in normal media should be contained
+in a regular partition,
+which can either be a dedicated firmware partition,
+or the UEFI System Partition (ESP).
+
+The system should locate firmware by reading the partition table.
+Using a fixed offset into the storage media is deprecated and should not
+be used for new SoC designs.
+If a fixed offset is required by the hardware, then it is strongly recommended
+for the firmware location to be covered by a protective partition to protect
+against accidentally overwriting system firmware.
+
+.. warning::
+
+ Fixed offsets to firmware data is supported only for legacy reasons.
+ All new platforms are expected to use partitions to locate firmware files.
+
+ A future issues of this specification will disallow the use of fixed
+ offsets.
+
+GPT partitioning
+----------------
+
+Any pre-installed partition table must strictly conform to the UEFI
+specification and include a protective MBR authored exactly as
+described in UEFI specification (hybrid partitioning schemes are not
+permitted).
+
+Pre-installed protective partitions must have the Platform Required
+Attribute Flag set.
+
+It is recommended that automatic system disk partitioning utilities
+preserve Platform Required partitions as is, and that manual disk
+partitioning utilities provide warnings and/or other safe guards to
+reduce risk of accidental removal.
+
+The system should locate firmware images by searching for partitions with
+the following UUIDs in order:
+
+.. table::
+
+ ==================================== ======== ========================
+ UUID Priority Description
+ ==================================== ======== ========================
+ Vendor defined UUID 1 (Not recommended)
+ Proprietary vendor
+ dedicated firmware
+ partition. Should only
+ be used if firmware
+ cannot use a FAT
+ filesystem.
+ TBD 2 EBBR compliant dedicated
+ firmware partition
+ C12A7328-F81F-11D2-BA4B-00A0C93EC93B 3 UEFI System Partition
+ as defined in
+ UEFI § 5.3.3
+ ==================================== ======== ========================
+
+.. note::
+
+ Should the vendor defined UUID be included in this table at all?
+
+MBR partitioning
+^^^^^^^^^^^^^^^^
+
+Pre-installed protective partitions should have a partition type of 0xF8
+unless some immutable feature of the platform makes this impossible.
+
+It is recommended that disk partitioning utilities treat such
+partitions in the same manner as GPT partitions with the Platform
+Required Attribute Flag set.
+
+It is recommended that pre-installed protective partitions that are not
+type 0xF8 be located wholly within 1MB of the start of the disk.
+
+Automatic disk partitioning utilities shall not create partitions
+within 1MB of the start of the disk. Manual disk partitioning
+utilities should avoid recommending that partitions start within
+1MB of the start of the disk.
+
+.. [#UFSParts] For example, Universal Flash Storage (UFS) provides
+ device-native partitioning and does not require a discrete MBR or
+ GPT partition table.
+
+Firmware Partition Filesystem
+=============================
+
+Where possible, firmware images and data should be stored in a filesystem.
+Firmware can be stored either in a dedicated firmware partition,
+or in certain circumstances in the UEFI System Partition (ESP).
+Using a filesystem makes it simpler to manage multiple firmware file and
+makes it possible for a single disk image to contain firmware for multiple
+platforms.
+
+Dedicated firmware partitions are recommended to be formatted with a FAT
+filesystem as defined by the UEFI specification.
+However, dedicated firmware partition must not be used as an ESP.
+EFI binaries in a dedicated firmware partition should be ignored
+by default.
+
+When firmware is stored in the ESP, the ESP must contain a partition named
+``/FIRMWARE`` in the root directory.
+Dedicated firmware partitions should use the same ``/FIRMWARE`` hierarchy.
+All firmware images and data must be stored in platform vendor
+subdirectories under ``/FIRMWARE``.
+
+Vendors may choose their own subdirectory name under ``/FIRMWARE``,
+but must choose names the do not conflict with other vendors.
+Normally the vendor name will be the name of the SoC vendor, because the
+firmware directory name will be hard coded in the SoC's boot ROM.
+Vendors are recommended to use their Devicetree vendor prefix as their
+vendor subdirectory name.
+
+Vendors are free to decide how to structure subdirectories under their
+own vendor directory, but they must use a naming convention that allows
+multiple SoCs to be supported in the same filesystem.
+
+For example, a vendor named Acme with two SoCs, ACME100 & AM300, could
+choose to use the SoC part number as a subdirectory in the firmware path::
+
+ /FIRMWARE
+ /ACME
+ /ACME100
+ fw.img
+ /ACME300
+ fw.img
+
+It is also recommended for dedicated firmware partitions to use the
+``/FIRMWARE`` file hierarchy.
+
+The following is a sample directory structure for firmware files::
+
+ /FIRMWARE
+ /<Vendor 1 Directory>
+ /<SoC A Directory>
+ <Firmware image>
+ <Firmware data>
+ /<SoC B Directory>
+ <Firmware image>
+ <Firmware data>
+ /<Vendor 2 Directory>
+ <Common Firmware image>
+ <Common Firmware data>
+ /<Vendor 3 Directory>
+ /<SoC E Directory>
+ <Firmware image>
+
+Operating systems and installers should not manipulate any files in the
+``/FIRMWARE`` hierarchy during normal operation.
+
+.. todo:
+
+ * Recommend failover A/B image layout to protect against corrupted
+ firmware.
+ * Define firmware update procedure. In what circumstances could an
+ OS automatically update firmware files in ``/FIRMWARE``?
+
+The sections below discuss the requirements when using both fixed and
+removable storage.
+However, it should be noted that the recommended behaviour of firmware
+should be identical regardless of storage type.
+In both cases, the recommended boot sequence is to first search for firmware
+in a dedicated firmware partition, and second search for firmware in the
+ESP.
+The only difference between fixed and removable storage is the recommended
+factory settings for the platform.
+
+
+Fixed Shared Storage
+--------------------
+
+Fixed storage is storage that is permanently attached to the platform,
+and cannot be moved between systems.
+eMMC and Universal Flash Storage (UFS) device are often used as
+shared fixed storage for both firmware and the OS.
+
+Where possible, it is prefered for the system to boot from a dedicated boot
+region on media that provides one (ex. eMMC) that is sufficiently large.
+Otherwise, the platform storage should be pre-formatted in the factory with
+a partition table, a dedicated firmware partition, and firmware binaries
+installed.
+
+Operating systems must not use the dedicated firmware partition,
+but shall instead create a normal ESP for installing the EFI applications
+including the OS loader.
+OS partitioning tools must take care not to modify or delete dedicated
+firmware partitions.
+
+Removable Shared Storage
+------------------------
+
+Removable storage is any media that can be physically removed from
+the system and moved to another machine as part of normal operation
+(ex. SD cards, USB thumb drives, and CDs).
+
+There are two primary scenarios for storing firmware on removable media.
+
+1. Platforms that only have removable media (ex. The Raspberry Pi has an
+ SD card slot, but no fixed storage).
+2. Recovery when on-board firmware has been corrupted. If firmware on
+ fixed media has been corrupted, some platforms support loading firmware
+ from removable media which can then be used to recover the platform.
+
+In both cases, it is desirable to start with a stock OS boot image,
+copy it to the media (SD or USB), and then add the necessary firmware files
+to make the platform bootable.
+Typically, OS boot images won't include a dedicated firmware partition,
+and it is inconvenient to repartition the media to add one.
+It is simpler and easier for the user if they are able to copy
+the required firmware files into the ``/FIRMWARE`` directory tree on the ESP
+using the basic file manager tools provided by all desktop operating systems.
+
+On removable media, firmware should be stored in the ESP under the
+``/FIRMWARE`` directory structure as described above.
+Platform vendors should support their platform by providing a single
+.zip file that places all the required firmware files in the correct
+locations when extracted in the ESP ``/FIRMWARE`` directory.
+For simplicity sake, it is expected the same .zip file will recover the
+firmware files in a dedicated firmware partition.
+
+
diff --git a/source/index.rst b/source/index.rst
index 5ddd19f..8099ac6 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -37,5 +37,6 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
chapter1-about
chapter2-uefi
chapter3-secureworld
+ chapter4-firmware-media
appendix-a-uefi-features
references
--
2.13.0
Special care is needed when storage is shared between firmware and the
OS. Add a chapter that discusses the issues and puts down the
requirements for using shared storage.
v2:
- Remove table of firmware partition types as unnecessary at this point
- Remove most of the UFS native partitioning discussion. Native
partitioning is akin to SCSI Logical Units (LU) which can effectively
be treated as independent devices with their own partition table. No
need to handle them specially.
- Tighten up language to be more specific.
Resolves: #19
Cc: Daniel Thompson <daniel.thompson(a)linaro.org>
Cc: Rob Herring <robh(a)kernel.org>
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/chapter1-about.rst | 5 +
source/chapter2-uefi.rst | 44 -------
source/chapter4-firmware-media.rst | 245 +++++++++++++++++++++++++++++++++++++
source/index.rst | 1 +
4 files changed, 251 insertions(+), 44 deletions(-)
create mode 100644 source/chapter4-firmware-media.rst
diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
index 125e400..d713cf3 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -91,6 +91,11 @@ This document uses the following terms and abbreviations.
execute Secure Monitor code, which handles the transitions between
Non-secure and Secure states. EL3 is always in Secure state.
+ Logical Unit (LU)
+ A logical unit (LU) is an externally addressable, independent entity
+ within a device. In the context of storage, a single device may use
+ logical units to provide multiple independent storage areas.
+
OEM
Original Equipment Manufacturer. In this document, the final device
manufacturer.
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 07426a4..05230d2 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -56,50 +56,6 @@ System Volume Format
The system firmware must support all partitioning standards required
by the UEFI specification.
-On systems where the system firmware binaries reside on the System Volume then
-the System Volume must be pre-configured with a partition table and include
-protective partitions to reduce risk of accidental destruction of the system
-firmware.
-
-All pre-installed partition tables must use GPT partitioning unless
-some immutable feature of the platform (such as a mask programmed boot ROM)
-makes this impossible; on such platforms MBR partitioning may be
-used as an alternative.
-
-GPT partitioning
-^^^^^^^^^^^^^^^^
-
-Any pre-installed partition table must strictly conform to the UEFI
-specification and include a protective MBR authored exactly as
-described in UEFI specification (hybrid partitioning schemes are not
-permitted).
-
-Pre-installed protective partitions must have the Platform Required
-Attribute Flag set.
-
-It is recommended that automatic system disk partitioning utilities
-preserve Platform Required partitions as is, and that manual disk
-partitioning utilities provide warnings and/or other safe guards to
-reduce risk of accidental removal.
-
-MBR partitioning
-^^^^^^^^^^^^^^^^
-
-Pre-installed protective partitions should have a partition type of 0xF8
-unless some immutable feature of the platform makes this impossible.
-
-It is recommended that disk partitioning utilities treat such
-partitions in the same manner as GPT partitions with the Platform
-Required Attribute Flag set.
-
-It is recommended that pre-installed protective partitions that are not
-type 0xF8 be located wholly within 1MB of the start of the disk.
-
-Automatic disk partitioning utilities shall not create partitions
-within 1MB of the start of the disk. Manual disk partitioning
-utilities should avoid recommending that partitions start within
-1MB of the start of the disk.
-
UEFI Boot Services
==================
diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst
new file mode 100644
index 0000000..604df18
--- /dev/null
+++ b/source/chapter4-firmware-media.rst
@@ -0,0 +1,245 @@
+****************
+Firmware Storage
+****************
+
+In general, EBBR compliant platforms should use dedicated storage for boot
+firmware images and data,
+independent of the storage used for OS partitions and the ESP.
+This could be a physically separate device (e.g. SPI flash),
+or a dedicated logical unit (LU) within a device
+(e.g. eMMC boot partition, [#eMMCBootPartition]_
+or UFS boot LU [#LogicalUnitNote]_).
+
+However, many embedded systems have size, cost, or implementation
+constraints that make separate firmware storage unfeasible.
+On such systems, firmware and the OS reside in the same storage device.
+Care must be taken to ensure firmware kept in normal storage does not
+conflict with normal usage of the media by an OS.
+
+* Firmware must be stored on the media in a way that does not conflict
+ with normal partitioning and usage by the operating system.
+* Normal operation of the OS must not interfere with firmware files.
+* Firmware needs a method to modify variable storage at runtime while the
+ OS controls access to the device. [#LUVariables]_
+
+.. [#eMMCBootPartition] Watch out for the ambiguity of the word 'partition'.
+ In most of this document, a 'partition' is a contiguous region of a block
+ device as described by a GPT or MBR partition table,
+ but eMMC devices also provide a dedicated 'boot partition' that is addressed
+ separately from the main storage region, and does not appear in the
+ partition table.
+
+.. [#LogicalUnitNote] For the purposes of this document, logical units are
+ treated as independent storage devices, each with their own GPT or MBR
+ partition table.
+ A platform that uses one LU for firmware, and another LU for OS partitions
+ and the ESP is considered to be using dedicated firmware storage.
+
+.. [#LUVariables] Runtime access to firmware data may still be an issue when
+ firmware is stored in a dedicated LU, simply because the OS remains in
+ control of the storage device command stream. If firmware doesn't have
+ a dedicated channel to the storage device, then the OS must proxy all
+ runtime storage IO.
+
+Partitioning of Shared Storage
+==============================
+
+A shared storage device shall use GPT partitioning unless it is incompatible
+with the platform boot sequence.
+In which case, MBR partitioning shall be used. [#MBRReqExample]_
+
+.. [#MBRReqExample] For example, if the boot ROM doesn't understand GPT
+ partitioning, and will only work with an MBR, then the storage must be
+ partitioned using an MBR.
+
+.. warning::
+
+ MBR partitioning is deprecated and only included for legacy support.
+ All new platforms are expected to use GPT partitioning.
+ GPT partitioning supports a much larger number of partitions, and
+ has built in resiliency.
+
+ A future issue of this specification will remove the MBR allowance.
+
+Firmware images and data in shared storage should be contained
+in partitions described by the GPT or MBR.
+The platform should locate firmware by searching the partition table for
+the partition(s) containing firmware.
+
+However, some SoCs load firmware from a fixed offset into the storage media.
+In this case, to protect against partitioning tools overwriting firmware, the
+firmware image shall either reside entirely within the first 1MiB of storage,
+or should be covered by a protective partition entry in the partition table as
+described in sections :ref:`section-gpt-parts` and :ref:`section-mbr-parts`.
+
+Automatic partitioning tools (e.g. an OS installer) must not create
+partitions within the first 1MiB of storage, or delete, move, or modify
+protective partition entries.
+Manual partitioning tools should provide warnings when modifying
+protective partitions or creating partitions within the first 1MiB.
+
+.. warning::
+
+ Fixed offsets to firmware data is supported only for legacy reasons.
+ All new platforms are expected to use partitions to locate firmware files.
+
+ A future issues of this specification will disallow the use of fixed
+ offsets.
+
+.. _section-gpt-parts:
+
+GPT partitioning
+----------------
+
+The partition table must strictly conform to the UEFI specification and include
+a protective MBR authored exactly as described in [UEFI]_ § 5 (hybrid
+partitioning schemes are not permitted).
+
+Protective partitions must have the Platform Required Attribute Flag set.
+
+.. _section-mbr-parts:
+
+MBR partitioning
+^^^^^^^^^^^^^^^^
+
+Protective partitions should have a partition type of 0xF8 unless some
+immutable feature of the platform makes this impossible.
+
+.. _section-fw-partition-fs:
+
+Firmware Partition Filesystem
+=============================
+
+Where possible, firmware images and data should be stored in a filesystem.
+Firmware can be stored either in a dedicated firmware partition,
+or in certain circumstances in the UEFI System Partition (ESP).
+Using a filesystem makes it simpler to manage multiple firmware files and
+makes it possible for a single disk image to contain firmware for multiple
+platforms.
+
+When firmware is stored in the ESP, the ESP should contain a partition named
+``/FIRMWARE`` in the root directory,
+and all firmware images and data should be stored in platform vendor
+subdirectories under ``/FIRMWARE``.
+
+Dedicated firmware partitions should be formatted with a FAT
+filesystem as defined by the UEFI specification.
+Dedicated firmware partitions should use the same ``/FIRMWARE`` directory
+hierarchy.
+OS tools shall ignore dedicated firmware partitions,
+and shall not attempt to use a dedicated firmware partition as an ESP.
+
+Vendors may choose their own subdirectory name under ``/FIRMWARE``,
+but shall choose names the do not conflict with other vendors.
+Normally the vendor name will be the name of the SoC vendor, because the
+firmware directory name will be hard coded in the SoC's boot ROM.
+Vendors are recommended to use their Devicetree vendor prefix as their
+vendor subdirectory name.
+
+Vendors are free to decide how to structure subdirectories under their
+own vendor directory, but they shall use a naming convention that allows
+multiple SoCs to be supported in the same filesystem.
+
+For example, a vendor named Acme with two SoCs, AM100 & AM300, could
+choose to use the SoC part number as a subdirectory in the firmware path::
+
+ /FIRMWARE
+ /ACME
+ /AM100
+ fw.img
+ /AM300
+ fw.img
+
+It is also recommended for dedicated firmware partitions to use the
+``/FIRMWARE`` file hierarchy.
+
+The following is a sample directory structure for firmware files::
+
+ /FIRMWARE
+ /<Vendor 1 Directory>
+ /<SoC A Directory>
+ <Firmware image>
+ <Firmware data>
+ /<SoC B Directory>
+ <Firmware image>
+ <Firmware data>
+ /<Vendor 2 Directory>
+ <Common Firmware image>
+ <Common Firmware data>
+ /<Vendor 3 Directory>
+ /<SoC E Directory>
+ <Firmware image>
+
+Operating systems and installers should not manipulate any files in the
+``/FIRMWARE`` hierarchy during normal operation.
+
+.. todo:
+
+ * Recommend failover A/B image layout to protect against corrupted
+ firmware.
+ * Define firmware update procedure. In what circumstances could an
+ OS automatically update firmware files in ``/FIRMWARE``?
+
+The sections below discuss the requirements when using both fixed and
+removable storage.
+However, it should be noted that the recommended behaviour of firmware
+should be identical regardless of storage type.
+In both cases, the recommended boot sequence is to first search for firmware
+in a dedicated firmware partition, and second search for firmware in the
+ESP.
+The only difference between fixed and removable storage is the recommended
+factory settings for the platform.
+
+
+Fixed Shared Storage
+--------------------
+
+Fixed storage is storage that is permanently attached to the platform,
+and cannot be moved between systems.
+eMMC and Universal Flash Storage (UFS) device are often used as
+shared fixed storage for both firmware and the OS.
+
+Where possible, it is prefered for the system to boot from a dedicated boot
+region on media that provides one (e.g., eMMC) that is sufficiently large.
+Otherwise, the platform storage should be pre-formatted in the factory with
+a partition table, a dedicated firmware partition, and firmware binaries
+installed.
+
+Operating systems must not use the dedicated firmware partition for installing
+EFI applications including, but not limited to, the OS loader and OS specific
+files. Instead, a normal ESP should be created.
+OS partitioning tools must take care not to modify or delete dedicated
+firmware partitions.
+
+Removable Shared Storage
+------------------------
+
+Removable storage is any media that can be physically removed from
+the system and moved to another machine as part of normal operation
+(e.g., SD cards, USB thumb drives, and CDs).
+
+There are two primary scenarios for storing firmware on removable media.
+
+1. Platforms that only have removable media (e.g., The Raspberry Pi has an
+ SD card slot, but no fixed storage).
+2. Recovery when on-board firmware has been corrupted. If firmware on
+ fixed media has been corrupted, some platforms support loading firmware
+ from removable media which can then be used to recover the platform.
+
+In both cases, it is desirable to start with a stock OS boot image,
+copy it to the media (SD or USB), and then add the necessary firmware files
+to make the platform bootable.
+Typically, OS boot images won't include a dedicated firmware partition,
+and it is inconvenient to repartition the media to add one.
+It is simpler and easier for the user if they are able to copy
+the required firmware files into the ``/FIRMWARE`` directory tree on the ESP
+using the basic file manager tools provided by all desktop operating systems.
+
+On removable media, firmware should be stored in the ESP under the
+``/FIRMWARE`` directory structure as described in
+:ref:`section-fw-partition-fs`.
+Platform vendors should support their platform by providing a single
+.zip file that places all the required firmware files in the correct
+locations when extracted in the ESP ``/FIRMWARE`` directory.
+For simplicity sake, it is expected the same .zip file will recover the
+firmware files in a dedicated firmware partition.
diff --git a/source/index.rst b/source/index.rst
index 5ddd19f..8099ac6 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -37,5 +37,6 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
chapter1-about
chapter2-uefi
chapter3-secureworld
+ chapter4-firmware-media
appendix-a-uefi-features
references
--
2.13.0
Hi folks,
This is a call for agenda items for tomorrow's EBBR meeting. So far I
just have:
- Action item review
- Any other business
As always, this Google doc will be used to capture notes. Please help
filling it in. You may need to request edit access if I haven't already
added you.
https://docs.google.com/document/d/1RdlFp5SIrvjcVOGoGEFVYDsqTqFBJHugbBMV5Mu…
---
Every Thursday at 16:30 UTC/BST, 8:30 PST/PDT, 00:30 CST
(following UTC/BST daylight savings time shifts)
Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK
Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
Phone +44 2033215213,, 4664465#
Find a local number:
https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
Conference ID: 4664465
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.
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.
