boot-architecture

boot-architecture@lists.linaro.org

1 participants
643 discussions

[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

[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

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

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

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

[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

[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

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

[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

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

← Newer
1
...
39
40
41
42
43
44
45
...
65
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture