- boot-architecture - lists.linaro.org

[PATCH] README: add latexmk for debian/ubuntu

by Bill Mills

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

7 years, 4 months

3
2
0 0

[PATCH] Add requirements on runtime access to devices

by Grant Likely

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

7 years, 4 months

2
1
0 0

[PATCH] Create a new chapter to discuss shared storage

by Grant Likely

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

7 years, 4 months

3
5
0 0

[PATCH v2] Create a new chapter to discuss shared storage

by Grant Likely

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

7 years, 4 months

1
0
0 0

EBBR Weekly - Agenda 3 May 2018

by Grant Likely

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.

7 years, 4 months

1
3
0 0

Proposed EBBR Document Structure

by Grant Likely

I've been thinking about how to organize EBBR. It started matching the SBBR document structure with the ACPI & ACPI sections removed, but I've moved things around a bit (for instance, citations are now at the end and use the citation markup so they can be collected from the whole document.) We also want to talk about some device sharing issues that SBBR doesn't need to get into, so we need a place to put that stuff. For discussion, what do you think of the following Table of Contents? I do expect this to change, but I'd like to come to general agreement on how the document is structured. 1. About this Document 1.1 Introcution 1.2 Scope 2. UEFI 2.1 UEFI Version 2.2 UEFI Compliance 2.3 UEFI System Environment and Configuration 2.4 UEFI Boot Services 2.4.1 Required (Moved from Appendix to here) 2.4.2 Optional (this section may be redundant. If it isn't required, then by default it is optional!!) 2.5 UEFI Runtime Services 2.5.1 Required 2.5.2 Optional 3. System Configuration Data 3.1 Devicetree 3.2 ACPI 4. Privileged Firmware 4.1 PSCI 4.2 Secure Services 5. Hardware Configuration and Access 5.1 Shared Storage Media 5.1.1 Block device partitioning 5.1.2 Protecting firmware partitions/blocks 5.2 Shared access (i2c/SPI) 5.3 RTC (Everything below is additional guidance material, and doesn't make up part of the spec. I've not decided if I'd rather have it in the documentm, or as a separate guidance note) Appendix A - U-Boot implementation note (How to configure U-Boot to be EBBR compliant) Appendix B - EBBR Compliance Testing 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.

7 years, 4 months

6
14
0 0

[RFC PATCH] Fill out the system firmware discussion

by Grant Likely

Add some more detail on how to handle system firmware. I'm still undecided about this, so this patch is more of an RFC discussion than a serious patch. Please comment. Cc: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/ebbr.rst | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 53 insertions(+), 5 deletions(-) diff --git a/source/ebbr.rst b/source/ebbr.rst index 3998397..c24cef5 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -200,16 +200,64 @@ 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. +System Firmware Partitions +^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 system +firmware binaries. + +When system firmware is located at a fixed offset, It is strongly recommended +for the partition table to include protective partitions covering the location +of firmware to reduce risk of accidental destruction of the system firmware. + +System boot ROM should obtain the system firmware partition location +by reading the partition table. +Using a fixed offset into the storage media is deprecated and should +not be used for new SoC designs. +Future issues of this specification will disallow the use of fixed offsets. + +A system firmware partition should not also be used as a EFI System +Partition (ESP). +Pre-installed system firmware partitions must not use the ESP GUID, +and OS installation tools should not install EFI executables in a system +firmware partition. + +.. todo:: + + I'm not sure if this is a good idea. It might be that EBBR should define a + common GUID for system firmware partitions. It also might be that I'm worrying + too much and it is fine to use the ESP as a system firmware partition. + This TODO note is a bit of a discussion of the options. + + Options: + + - Require ESP and SFPs to be separate + - Should a common SFP GUID be defined so a single image can hold firmware + for multiple platforms? + - Don't have to repartition to add additional platforms. + - Yet repartitioning required to add the *first* platform + - Require FAT formatting? + - Probably also requires a vendor/soc/file pathname spec to avoid + conflicts. + - OS can mount the ESP without touching SFPs. This means firmware could + perform (mediated) operations on the SPF (ex. to update variables) + without unmounting the ESP. + - Downside: Requries at least two fixed sized partitions to boot the + platform: a SFP, and the ESP. A single combined SFP+ESP would be more + efficient on space. + - Allow ESP to be used as an SFP + - Downside: Partitioning/Install tools can't simply blank the ESP to reset + to scratch + - Upside: platform firmware can be added by simply dropping files + in the ESP + - Using the ESP filesystem is a more efficient use of space. + - Still need to define pathname spec to avoid conflicts + GPT partitioning ^^^^^^^^^^^^^^^^ -- 2.13.0

7 years, 4 months

3
3
0 0

[PATCH v2] Describe protective partitioning for platforms using shared storage

by Daniel Thompson

Currently EBBR contains nothing describing how systems that share storage media between firmware and OS behave. Add a description of how such as system can be robustly pre-partitioned. Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Notes: v2: * Added patch description. * Don't explicitly enumerate supported partitioning standards, defer to UEFI instead (this implicitly adds MBR and el-torito support). * Forbid hybrid GPT/MBR partitioning. * Require that pre-configured protective partitions using GPT to set the Platform Require Attribute Flag. * Improve documentation the 1MB threshold for MBR source/ebbr.rst | 47 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/source/ebbr.rst b/source/ebbr.rst index b6e48d6ac67d..39983974b1c1 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -197,7 +197,52 @@ virtualized service, by the hypervisor and not as part of the host firmware. System Volume Format -------------------- -The system firmware must support GPT partitioning. +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 ================== -- 2.17.0

7 years, 5 months

1
0
0 0

Notes on "requiring" separate storage

by William Mills

Hello, My notes on "requiring" (or strongly recommending) separate storage. A couple of times we have gone around the issue of "is it reasonable to require new platforms have separate storage for firmware". Pros: P1) No disk partition plan etc P2) Runtime var storage is much easier Cons: C1) Cost C2) Boot speed C3) Board becomes "state full" and brick-able C4) Need Buy-in from board makers I hope we understand the pros so I won't go deep on those. WRT C1 & C2: Cost & boot speed Pocket Beagle ($25) has a 2Kx8 I2C EEPROM built into the SIP (system in package). This allows a single binary SPL to boot from uSD on multiple boards (PocketBeagle BBW, BBB, BBBlue, TI EVM, etc) as the EEPROM has board ID info. I looked for other low cost boards with dedicated firmware storage. PINE A64-LTS ($32) and SOPINE ($30) have 16MB of SPI flash. The original PINE A64 ($15) has no on board storage. Are there other boards I should look at? What would this look like if we put: * SPL & vars only into SPI flash * SPL & U-boot & vars into SPI flash * SPL/U-boot or EDK2 + vars into QSPI I assume 64KB for SPL, <500KB for SPL+Uboot, and 1MB for EDK2. QSPI: 1MB $0.67 2MB $0.70 16MB $1.62 (PINE A64-LTS) 133MHz == 66MB/s U-boot, 500KB in 7ms EDK2, 1MB in 14ms SPI: 128KB $0.28 1MB $0.33 104Mhz == 13MB/s SPL only, 64KB in 5ms U-boot, 500KB in 38ms I2C: ID only 256x8 $0.09 BBB etc 4Kx8 $0.13 32bytes @100KHz = 2.5ms Note that on PocketBeagle the I2C cost is already baked into the SIP so you can't subtract this cost from the cost of the SPI flash. This is a legacy issue but does so that buy-in takes time to filter down. Would a future SIP include an SPI flash? If you do then you need to fix how big. WRT C3: State-full and brickable As long as the SOC supports multiple bootmodes and the board adds a button or switch to select a recovery mode, this can be handled. BeagleBone black boots from eMMC (which is brickable) but holding a button at power up causes it to ignore everything in eMMC and boot form uSD. The uSD in this recovery mode need not be EBBR compliant (but I would like to allow it to be.) PocketBeagle like board would need to add a jumper or similar. C4: Board maker buy-in Probably the biggest barrier. Must show value of EBBR on legacy boards before people see the value. But if legacy works OK then why change? Bill ---------------- William A. Mills Chief Technologist, Open Solutions, SDO Texas Instruments, Inc. 20450 Century Blvd Germantown MD 20878 240-643-0836

7 years, 5 months

3
3
0 0

not be able to attend today's call

by Udit Kumar

Hi Grant/All, I will not be able to attend today's call For issue#10, I sent v1 patch , and for issue#9 , I will follow over email. Thanks Udit

7 years, 5 months

1
0
0 0

Issue#9 Document hardware need (if any)

by Udit Kumar

Hi At present, I don't see any specific hardware requirement for EBBR except ARMv8 CPU. Current document covers it very well. IMO, we can deferred this ticket. Thoughts ? Regards Udit

7 years, 5 months

4
9
0 0

[PATCH] Describe protective partitioning for platforms using shared storage

by Daniel Thompson

Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major. Thanks to all the contributors to this topic so far! source/ebbr.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f173bd9..30a9c6ac2666 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -185,6 +185,53 @@ System Volume Format -------------------- The system firmware must support GPT partitioning. +It may optionally also support MBR partitioning. + +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-configured 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 +^^^^^^^^^^^^^^^^ + +Protective partitions should have the Platform Required Attribute Flag set +unless some immutable feature of the platform makes this impossible. + +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. + +It is recommended that an implementer on a platform where Platform Required +cannot be set contribute a list of Partition type GUIDs for protective +partitions to the table below. It is further recommended that disk partitioning +utilities treat such partitions in the same manner as those with the Platform +Required Attribute Flag set. + ++--------------------------------------+---------------------------------------+ +| Partition type GUID | Comment | ++======================================+=======================================+ +| 00000000-0000-0000-0000-000000000000 | Unused entry (example; do not honour) | ++--------------------------------------+---------------------------------------+ + +MBR partitioning +^^^^^^^^^^^^^^^^ + +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 strongly recommended that protective partitions with a type other +than 0xF8 be placed within 1MB of the start of the disk. UEFI Boot Services ================== -- 2.17.0

7 years, 5 months

5
15
0 0

[PATCH v1] Issue#10 Add EBBR compliance test

by Udit Kumar

v1: Changes from first version Reword and reorder the text This patch adds a appendix for EBBR compliance test. Signed-off-by: Udit Kumar <udit.kumar(a)nxp.com> --- source/ebbr.rst | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f1..9dc6a01 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -557,6 +557,34 @@ Service UEFI § EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 ========================================== ====== +******************************************* +APPENDIX E - EBBR Compliance Tests +******************************************* + +EBBR compliance test suite will be used to ensure EBBR compliance of +platform firmware. + +These tests will be carried out at two levels + +1. Firmware level + +2. OS level + +At firmware level, first level of tests will ensure that platform firmware +is implementing UEFI interfaces. +For this, EBBR compliance test suite will take leverage from UEFI SCT. +UEFI Self Certification Tests (SCTs) test the UEFI implementation requirements defined by EBBR. +To build UEFI SCT, please refer https://github.com/UEFI/UEFI-SCT + +Apart from UEFI SCT, Some EBBR specific tests may be developed. + +At OS level, Firmware Test Suite (FWTS) will be used, for more information +please refer https://wiki.ubuntu.com/FirmwareTestSuite + +In future, above tests will be integrated into EBBR test kit. + + + .. 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 -- 1.9.1

7 years, 5 months

1
0
0 0

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

by Frank Rowand

On 05/24/18 11:18, Mark Brown wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may use additional information from DT or kernel's >> config to decide whether to continue to defer probe or not. > > Should userspace have some involvement in this decision? It knows if > it's got any intention of loading modules for example. Kernel config > checks might be good enough, though it's going to be a pain to work out > if the relevant driver is built as a module for example. > A parallel issue is that loading an overlay could provide the resource that will allow the deferred probe to complete. (That is, once we finish implementing the run time overlays feature.) -Frank

7 years, 5 months

2
1
0 0

[PATCH v2 0/8] Make deferring probe forever optional

by Rob Herring

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. v2: - Add a DT property for pinctrl to flag using defaults - Add a debug timeout to stop deferring some number of seconds after initcalls are done (giving modules a chance to load) - Split pinctrl support to its own patch - WARN when we stop deferring probe for a device - Add IOMMU support - Add PM domain support Rob [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html Rob Herring (8): driver core: make deferring probe after init optional driver core: add a deferred probe timeout dt-bindings: pinctrl: add a 'pinctrl-use-default' property arm: dts: bcm283x: mark the UART pin muxing nodes with pinctrl-use-default pinctrl: optionally stop deferring probe at end of 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 | 7 +++ .../bindings/pinctrl/pinctrl-bindings.txt | 6 +++ arch/arm/boot/dts/bcm283x.dtsi | 2 + drivers/base/dd.c | 43 +++++++++++++++++++ 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 | 14 ++++-- include/linux/device.h | 2 + include/linux/of_iommu.h | 4 -- 16 files changed, 73 insertions(+), 48 deletions(-) -- 2.17.0

7 years, 5 months

8
23
0 0

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

by Robin Murphy

On 24/05/18 19:18, Mark Brown wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may use additional information from DT or kernel's >> config to decide whether to continue to defer probe or not. > > Should userspace have some involvement in this decision? It knows if > it's got any intention of loading modules for example. Kernel config > checks might be good enough, though it's going to be a pain to work out > if the relevant driver is built as a module for example. Arguably userspace has some control over that already, as in many cases it can just unbind and reprobe the consumer driver after loading the provider driver (in my silly IOMMU-drivers-as-modules PoC a while ago I was delighted to find that it can really be that simple). It's a bit harder when the device is the primary console or root filesystem, but I think that's effectively just another variant of the "defer until a module is loaded" chicken-and-egg problem. Robin.

7 years, 5 months

1
0
0 0

Re: [PATCH v2 1/8] driver core: make deferring probe after init optional

by Rob Herring

On Thu, May 24, 2018 at 1:18 PM, Mark Brown <broonie(a)kernel.org> wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may use additional information from DT or kernel's >> config to decide whether to continue to defer probe or not. > > Should userspace have some involvement in this decision? It knows if > it's got any intention of loading modules for example. Kernel config > checks might be good enough, though it's going to be a pain to work out > if the relevant driver is built as a module for example. I looked into whether we could hook into uevents in some way. If we knew when all the coldplug events had been handled, that would be sufficient. But it doesn't look to me like we can tell when that happens with the uevent netlink socket. I think about the only thing we can tell is if userspace has opened a socket. I'm not all that familiar with how the whole sequence works, so other opinions on this would be helpful. Also, for this to work with serial consoles, we have to make the decision before we get to userspace. I couldn't get systemd to create serial gettys either if we deferred later. There's some dependence on /dev/console, but I didn't get to the bottom of it. Rob

7 years, 5 months

1
0
0 0

[PATCH] README: Install dependencies on Fedora

by Daniel Thompson

Currently the README does not document how to install sphinx and texlive on Fedora. Fix this. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- README.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.rst b/README.rst index 851c078065a9..9eef58805021 100644 --- a/README.rst +++ b/README.rst @@ -49,6 +49,19 @@ new version can be installed with the Python package installer:: Export SPHINXBUILD (see above) if Sphinx was installed with pip --user, then follow Make commands below +On Fedora +^^^^^^^^^ + +:: + + # dnf install python2-sphinx texlive texlive-capt-of texlive-draftwatermark \ + texlive-fncychap texlive-framed texlive-needspace \ + texlive-tabulary texlive-titlesec texlive-upquote \ + texlive-wrapfig + +It is also possible to use python3-sphinx; this requires +SPHIXBUILD=sphinx-build-3 to be passed on the Make command line. + On Mac OS X ^^^^^^^^^^^ -- 2.17.0

7 years, 5 months

2
1
0 0

Re: [Arm.ebbr-discuss] [PATCH 1/2] Add revision history table

by Grant Likely

On 24/05/2018 14:33, Daniel Thompson wrote: > On Tue, May 22, 2018 at 05:14:00PM +0100, Grant Likely wrote: >> Adds the revision history table to the markup. >> >> Resolves: #4 >> Signed-off-by: Grant Likely <grant.likely(a)arm.com> >> --- >> source/ebbr.rst | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/source/ebbr.rst b/source/ebbr.rst >> index 4100b2f..b6e48d6 100644 >> --- a/source/ebbr.rst >> +++ b/source/ebbr.rst >> @@ -18,6 +18,19 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. >> :alt: Creative Commons License >> :align: right >> >> +.. tabularcolumns:: l c p{11.5cm} >> +.. table:: Revision History >> + >> + ================= ===== ============================================= >> + Date Issue Changes >> + ================= ===== ============================================= >> + 20 September 2018 B Confidentiality Change, EBBR version 0.51 >> + TBD TBD - Relicense to CC-BY-SA 4.0 >> + - Added Devicetree requirements >> + - Added Multiprocessor boot requirements >> + - Transitioned to reStructuredText and GitHub >> + ================= ===== ============================================= > > Is this going to be hand curated (e.g. patches that fail to update > changelog properly get caught during review) or will it be derived > post-hoc from the git history? Hand curated until someone writes a script to scrape commit lines. I don't think this table needs to be exhaustive though. Just the big picture items. Anyone who really cares can read the changebar version, or even just the git history. g. > > > Daniel. > 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.

7 years, 5 months

1
0
0 0

[PATCH 1/2] Add revision history table

by Grant Likely

Adds the revision history table to the markup. Resolves: #4 Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/ebbr.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/source/ebbr.rst b/source/ebbr.rst index 4100b2f..b6e48d6 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -18,6 +18,19 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. :alt: Creative Commons License :align: right +.. tabularcolumns:: l c p{11.5cm} +.. table:: Revision History + + ================= ===== ============================================= + Date Issue Changes + ================= ===== ============================================= + 20 September 2018 B Confidentiality Change, EBBR version 0.51 + TBD TBD - Relicense to CC-BY-SA 4.0 + - Added Devicetree requirements + - Added Multiprocessor boot requirements + - Transitioned to reStructuredText and GitHub + ================= ===== ============================================= + ******************* About This Document ******************* -- 2.13.0

7 years, 5 months

2
2
0 0

[PATCH] Issue#10 Add EBBR compliance test

by Udit Kumar

This patch adds a appendix for EBBR compliance test. Signed-off-by: Udit Kumar <udit.kumar(a)nxp.com> --- source/ebbr.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f1..880f126 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -557,6 +557,22 @@ Service UEFI § EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 ========================================== ====== +******************************************* +APPENDIX E - EBBR Compliance Tests +******************************************* + +UEFI Self Certification Tests (SCT) test the UEFI implementation. +EBBR is leveraging from UEFI, UEFI SCT test suites check for compliance +against the EBBR specification. +To build UEFI SCT, please refer https://github.com/UEFI/UEFI-SCT + +EBBR is very flexible and many features are platform dependent. +Therefore platform owner can decide, to implement and test optional features +with UEFI SCT. + + + + .. 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 -- 1.9.1

7 years, 5 months

2
3
0 0

[PATCH] Trivial: Fix glossary entrys

by Grant Likely

Some of the glossary terms got split across lines which put half the term in the description instead of the entry name. Fix the 'AArch64 State' and 'EFI Loaded Image' entries. Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/ebbr.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/ebbr.rst b/source/ebbr.rst index 4269b49..9e787ed 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -77,16 +77,16 @@ This document uses the following terms and abbreviations. The 64-bit ARM instruction set used in AArch64 state. All A64 instructions are 32 bits. - AArch64 - state The ARM 64-bit Execution state that uses 64-bit general purpose + AArch64 state + The ARM 64-bit Execution state that uses 64-bit general purpose registers, and a 64-bit program counter (PC), Stack Pointer (SP), and exception link registers (ELR). AArch64 Execution state provides a single instruction set, A64. - EFI - Loaded Image An executable image to be run under the UEFI environment, + EFI Loaded Image + An executable image to be run under the UEFI environment, and which uses boot time services. EL0 -- 2.13.0

7 years, 5 months

4
18
0 0

EBBR Weekly - Notes 17 May 2018

by Grant Likely

https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2018.05.17 # 17 May 2018 ## Attendees * Alex Graf (SUSE) * Ryan Harkin (Linaro) * Rob Herring (Linaro) * Udit Kumar (NXP) * Grant Likely (Arm) * Bill Mills (TI) * Tom Rini (Konsulko) * Daniel Thompson (Linaro) ## Agenda * Issue/Action review * Any other business ## Notes ### Issue/Action review * Issue #1 - Bill will assign to himself * Issue #2 - Leif on Holiday * Issue #3 - Daniel will take * Issue #4 - grant to take * Issue #8 - partitioning tool rules - Daniel will take * Issue #10 & 11 - Assign to Udit * Issue #10 - Document how to certify * Dong added that we can probably leverage UEFI SCT * Issue #13 - Daniel to take ### Other Business Rob: Looks like there is interest from the Google/Android folks in EBBR * Rob to set up a meeting with the relevant folks 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.

7 years, 5 months

1
0
0 0

[PATCH] Remove MP Start protocol from EBBR and revert to PSCI v1.0

by Grant Likely

EBBR platforms are unlikely to ever use the MP Start protocol used in some AArch64 server systems. It was only used to support platforms without EL3. No more EL2-only platforms are expected, and MP Start is being removed from the next release of SBBR. Devicetree platforms in the same scenario use the Linux spin table protocol instead. MP Start was only included for completeness to align the SBBR and EBBR specifications. Therefore remove it entirely, leaving PSCI and spin table as the only acceptable implementations. Also revert to PSCI v1.0 as that is the minimum level of functionality required. PSCI v1.1 adds new capabilities, but is not required for interoperability. Suggested-by: Dong Wei <dong.wei(a)arm.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/ebbr.rst | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/source/ebbr.rst b/source/ebbr.rst index 40f03f1..4100b2f 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -329,10 +329,9 @@ Power State Coordination Interface specification[PSCI_]. Platforms without EL3 must implement one of: - PSCI at EL2 (leaving only EL1 available to an operating system) -- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI platform -- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform +- Linux AArch64 spin tables[LINUXA64BOOT_] (Devicetree only) -However, the MP Startup and Spintable protocols are strongly discouraged. +However, the spin table protocol is strongly discouraged. Future versions of this specification will only allow PSCI, and PSCI should be implemented in all new designs. @@ -575,13 +574,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre…>`_, Linux kernel -.. [MPSTART] `MP Startup for Arm - <https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.…>`_, - 20 December 2012, `Microsoft <http://microsoft.com>`_ - -.. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1) - <http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coor…>`_, - 21 April 2017, `Arm Limited <http://arm.com>`_ +.. [PSCI] `Power State Coordination Interface Issue C (PSCI v1.0) + <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ + 30 January 2015, `Arm Limited <http://arm.com>`_ .. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ -- 2.13.0

7 years, 5 months

1
0
0 0

Re: [Arm.ebbr-discuss] [PATCH] Be specific about DT or ACPI requirements

by Grant Likely

On 18/05/2018 18:08, Mark Brown wrote: > On Fri, May 18, 2018 at 06:04:11PM +0100, Grant Likely wrote: > >> My bikeshed now has a sign that reads: > >> +As stated above, EBBR systems must not provide both ACPI >> +and Devicetree tables at the same time. >> +Systems that support both interfaces must provide a configuration >> +mechanism to select either ACPI or Devicetree, >> +and must ensure only the selected interface is provided >> +to the OS loader. > > I think that's a very pleasing shade, thanks! :) > > (Sorry, I spent far too long working on interoperability of some > particularly poorly specified networking standards so now have > difficulty reading any spec without assuming the worst.) > Thanks! I'll take that as you're Acked-by then. :-) g.

7 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture