boot-architecture

boot-architecture@lists.linaro.org

4 participants
648 discussions

[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, 2 months

[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, 3 months

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, 3 months

[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, 3 months

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, 3 months

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, 3 months

[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, 3 months

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, 3 months

[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, 3 months

[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, 3 months

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture