- boot-architecture - lists.linaro.org

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

2
1
0 0

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

by Grant Likely

On 18/05/2018 17:45, Mark Brown wrote: > On Fri, May 18, 2018 at 05:28:10PM +0100, Grant Likely wrote: > >> +Devicetree tables at the same time. Platforms that want to offer >> +both ACPI and Devicetree solutions must implement a boot time >> +mechanism to select one or the other, before the OS Loader is >> +executed. > > How about "...must configure this using a mechanism that ensures that > one or the other is chosen and provided to the OS loader when it is > executed"? It doesn't really matter for sensible systems but I can see > someone misreading the above and thinking there must be a prompt on boot > or something, I do think this is me being paranoid about perverse > implementors though. > 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. g.

7 years, 11 months

1
0
0 0

Re: [Arm.ebbr-discuss] [PATCH] Move citations to the end of the document

by Grant Likely

On 18/05/2018 14:18, Tom Rini wrote: > On Fri, May 18, 2018 at 02:06:08PM +0100, Grant Likely wrote: > >> Use reStructuredText citation markup to capture all referenced >> documents. Sphinx will take care of creating a table of references at >> the end of the document. >> >> Fixes #6 >> Signed-off-by: Grant Likely <grant.likely(a)arm.com> > [snip] >> @@ -132,22 +115,11 @@ This document defines the boot and runtime services that are expected by an >> Operating System or hypervisor, for an ARM embedded device, which follows the >> UEFI specification. >> >> -This document references the following specification and versions: >> - >> - UEFI 2.7 >> - Published June 2017, includes the AArch64 bindings. >> - > > Is it clear enough when rendering the final document that here we don't > need a link down to the UEFI reference? Not sure what you mean. Can you elaborate? I do think the introduction chapter needs to be reworked anyway to talk about standardizing the firmware interface. It too quickly jumps to "when UEFI is chosen", when what I'd rather it present is "here is a standardized platform taylored to embedded systems"... and then get to UEFI is part of that standard. (it isn't about chosing UEFI; it is about choosing a standard platform) > >> This specification defines the boot and runtime services for a physical system, >> including services that are required for virtualization. >> It does not define a standardized abstract virtual machine view for a Guest >> Operating System. >> >> -When present with in a system, this document makes additional references to the >> -Power State Coordination Interface: >> - >> - PSCI 1.1 >> - Published April 2017. >> - > [snip] >> @@ -306,9 +278,10 @@ command: >> >> - EfiWarmReset() >> >> -.. note:: When Runtime Services and PSCI co-exist, it is anticipated that >> - Operating System calls to reset the system will go via Runtime Services and >> - not directly to PSCI. >> +.. note:: On platforms implementing the Power State Coordination Interface >> + specification[PSCI_], it is still required that EBBR compliant >> + Operating Systems calls to reset the system will go via Runtime Services >> + and not directly to PSCI. >> >> Set Variable >> ------------ > > Is all of the above equivalent in terms of talking about PSCI? Thanks! Ummm, yes? But I'm not sure that I understand what you're asking. Thanks for the reviews on all the other patches. g.

7 years, 11 months

1
0
0 0

Multi-cpu boot protocol?

by Grant Likely

I'm adding some EBBR text around the CPU state at boot and I've lost track of what is being done for multicore bringup. What is the current state-of-the-art for multicore boot protocol when PSCI isn't available? SBBR allows for the MP Boot Protocol; with the intend of phasing it out: https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.… The kernel documents the spin table method: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre… What are the cool kids currently doing here? g. 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, 11 months

3
6
0 0

Re: [Arm.ebbr-discuss] [PATCH] Move contributing details to CONTRIBUTING file

by Daniel Thompson

On Wed, May 16, 2018 at 03:46:06PM +0100, Grant Likely wrote: > To match convention used by many projects on GitHub, put the > contribution details into a separate file instead of the top level > README. Also tighten up some of the language around contributing to be > clearer. > > Suggested-by: Jilayne Lovejoy <jilayne.lovejoy(a)arm.com> > Signed-off-by: Grant Likely <grant.likely(a)arm.com> > --- > CONTRIBUTING.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Makefile | 2 +- > README.rst | 67 ++++------------------------------------------------- > source/ebbr.rst | 4 ++-- > 4 files changed, 78 insertions(+), 65 deletions(-) > create mode 100644 CONTRIBUTING.rst > > diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst > new file mode 100644 > index 0000000..e101e5f > --- /dev/null > +++ b/CONTRIBUTING.rst > @@ -0,0 +1,70 @@ > +Contributing > +============ > + > +Master copy of this project is hosted on GitHub: > +https://github.com/ARM-software/ebbr > + > +Anyone may contribute to the EBBR project. > +Contributions are licensed under CC-BY-SA-4.0_ and must be made with a > +Developer Certificate of Origin (DCO_) attestation as described below. > + > +EBBR discussion uses the boot-architecture_ and arm.ebbr-discuss mailing lists. > +The 'official' list is arm.ebbr-discuss, but the list archives are not > +yet public, so boot-architecture_ is being used to keep everything in > +the open. > + > +* boot-architechture(a)lists.linaro.org That is not how you spell "architecture" (as I just discovered when I copy 'n pasted from the current README). Once that is fixed: Reviewed-by: Daniel Thompson <daniel.thompson(a)linaro.org> Daniel. > +* arm.ebbr-discuss(a)arm.com > + > +Past discussions can be found in the boot-architecture-archive_. > + > +We use the IRC channel `#ebbr`_ on OFTC_. > + > +DCO Attestation > +--------------- > + > +To help track the origin of contributions, this project uses the same > +DCO_ "sign-off" process as used by the Linux kernel. > +The sign-off is a simple line at the end of the explanation for the > +patch, which certifies that you wrote it or otherwise have the right to > +pass it on as an open-source patch. > +The rules are pretty simple: if you can certify the below: > + > +Developer's Certificate of Origin 1.1 > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +By making a contribution to this project, I certify that: > + > + (a) The contribution was created in whole or in part by me and I > + have the right to submit it under the open source license > + indicated in the file; or > + > + (b) The contribution is based upon previous work that, to the best > + of my knowledge, is covered under an appropriate open source > + license and I have the right under that license to submit that > + work with modifications, whether created in whole or in part > + by me, under the same open source license (unless I am > + permitted to submit under a different license), as indicated > + in the file; or > + > + (c) The contribution was provided directly to me by some other > + person who certified (a), (b) or (c) and I have not modified > + it. > + > + (d) I understand and agree that this project and the contribution > + are public and that a record of the contribution (including all > + personal information I submit with it, including my sign-off) is > + maintained indefinitely and may be redistributed consistent with > + this project or the open source license(s) involved. > + > +then you just add a line saying:: > + > + Signed-off-by: Random J Developer <random(a)developer.example.org> > + > +.. _CC-BY-SA-4.0: LICENSE > +.. _#ebbr: https://webchat.oftc.net/?channels=%23ebbr&uio=d4 > +.. _OFTC: https://www.oftc.net/ > +.. _DCO: https://developercertificate.org/ > +.. _boot-architecture: https://lists.linaro.org/mailman/listinfo/boot-architecture > +.. _boot-architecture-archive: https://lists.linaro.org/pipermail/boot-architecture > + > diff --git a/Makefile b/Makefile > index 91bb4be..46ed82a 100644 > --- a/Makefile > +++ b/Makefile > @@ -17,4 +17,4 @@ help: > # Catch-all target: route all unknown targets to Sphinx using the new > # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). > %: Makefile > - @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) > \ No newline at end of file > + @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) > diff --git a/README.rst b/README.rst > index 57fac8f..67c7e85 100644 > --- a/README.rst > +++ b/README.rst > @@ -73,79 +73,22 @@ License > ======= > > This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 > -International License. To view a copy of this license, visit > +International License (CC-BY-SA-4.0). To view a copy of this license, visit > http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to > Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. > > +Contributions are accepted under the same with sign-off under the Developer's > +Certificate of Origin. For more on contributing to EBBR, see CONTRIBUTING.rst_. > + > A copy of the license is included in the LICENSE_ file. > > .. image:: https://i.creativecommons.org/l/by-sa/4.0/88x31.png > :target: http://creativecommons.org/licenses/by-sa/4.0/ > :alt: Creative Commons License > > +.. _CONTRIBUTING.rst: ./CONTRIBUTING.rst > .. _LICENSE: ./LICENSE > > -Contributing > -============ > - > -Master copy of this project is hosted on GitHub: > -https://github.com/ARM-software/ebbr > - > -Anyone may contribute to the EBBR project. EBBR discussion uses the > -boot-architecture_ and arm.ebbr-discuss mailing lists. > -The 'official' list is arm.ebbr-discuss, but the list archives are not > -yet public, so boot-architecture_ is being used to keep everything in > -the open. > - > -* boot-architechture(a)lists.linaro.org > -* arm.ebbr-discuss(a)arm.com > - > -Past discussions can be found in the boot-architecture-archive_. > - > -To help track the origin of contributions, this project uses the same > -DCO_ "sign-off" process as used by the Linux kernel. > -The sign-off is a simple line at the end of the explanation for the > -patch, which certifies that you wrote it or otherwise have the right to > -pass it on as an open-source patch. The rules are pretty simple: if you > -can certify the below: > - > -Developer's Certificate of Origin 1.1 > -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > - > -By making a contribution to this project, I certify that: > - > - (a) The contribution was created in whole or in part by me and I > - have the right to submit it under the open source license > - indicated in the file; or > - > - (b) The contribution is based upon previous work that, to the best > - of my knowledge, is covered under an appropriate open source > - license and I have the right under that license to submit that > - work with modifications, whether created in whole or in part > - by me, under the same open source license (unless I am > - permitted to submit under a different license), as indicated > - in the file; or > - > - (c) The contribution was provided directly to me by some other > - person who certified (a), (b) or (c) and I have not modified > - it. > - > - (d) I understand and agree that this project and the contribution > - are public and that a record of the contribution (including all > - personal information I submit with it, including my sign-off) is > - maintained indefinitely and may be redistributed consistent with > - this project or the open source license(s) involved. > - > -then you just add a line saying:: > - > - Signed-off-by: Random J Developer <random(a)developer.example.org> > - > -IRC Channel: ``#ebbr`` on ofct > - > -.. _DCO: https://developercertificate.org/ > -.. _boot-architecture: https://lists.linaro.org/mailman/listinfo/boot-architecture > -.. _boot-architecture-archive: https://lists.linaro.org/pipermail/boot-architecture > - > Writers Guide > ============= > > diff --git a/source/ebbr.rst b/source/ebbr.rst > index 414e3af..4269b49 100644 > --- a/source/ebbr.rst > +++ b/source/ebbr.rst > @@ -1,12 +1,12 @@ > .. EBBR Source Document > - Copyright Arm Ltd. 2018 > + Copyright Arm Limited, 2018 > SPDX-License-Identifier: CC-BY-SA-4.0 > > #################################################### > Embedded Base Boot Requirements (EBBR) Specification > #################################################### > > -Copyright © 2017-2018 Arm Ltd and Contributors. > +Copyright © 2017-2018 Arm Limited and Contributors. > > This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 > International License. To view a copy of this license, visit > -- > 2.13.0 > > _______________________________________________ > Arm.ebbr-discuss mailing list > Arm.ebbr-discuss(a)arm.com

7 years, 11 months

1
0
0 0

Assigning EBBR issues

by Grant Likely

On the weekly call today I suggested for people to assign issues to themselves if they wanted to take it on. Turns out GitHub doesn't allow that unless you've got write access to the project. So, if you want to take on an issue, add a comment saying so and I'll send you an invite to join the project. Once you've accepted the invite I can assign issues to you. g. 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, 11 months

1
0
0 0

[PATCH] Move contributing details to CONTRIBUTING file

by Grant Likely

To match convention used by many projects on GitHub, put the contribution details into a separate file instead of the top level README. Also tighten up some of the language around contributing to be clearer. Suggested-by: Jilayne Lovejoy <jilayne.lovejoy(a)arm.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- CONTRIBUTING.rst | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Makefile | 2 +- README.rst | 67 ++++------------------------------------------------- source/ebbr.rst | 4 ++-- 4 files changed, 78 insertions(+), 65 deletions(-) create mode 100644 CONTRIBUTING.rst diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst new file mode 100644 index 0000000..e101e5f --- /dev/null +++ b/CONTRIBUTING.rst @@ -0,0 +1,70 @@ +Contributing +============ + +Master copy of this project is hosted on GitHub: +https://github.com/ARM-software/ebbr + +Anyone may contribute to the EBBR project. +Contributions are licensed under CC-BY-SA-4.0_ and must be made with a +Developer Certificate of Origin (DCO_) attestation as described below. + +EBBR discussion uses the boot-architecture_ and arm.ebbr-discuss mailing lists. +The 'official' list is arm.ebbr-discuss, but the list archives are not +yet public, so boot-architecture_ is being used to keep everything in +the open. + +* boot-architechture(a)lists.linaro.org +* arm.ebbr-discuss(a)arm.com + +Past discussions can be found in the boot-architecture-archive_. + +We use the IRC channel `#ebbr`_ on OFTC_. + +DCO Attestation +--------------- + +To help track the origin of contributions, this project uses the same +DCO_ "sign-off" process as used by the Linux kernel. +The sign-off is a simple line at the end of the explanation for the +patch, which certifies that you wrote it or otherwise have the right to +pass it on as an open-source patch. +The rules are pretty simple: if you can certify the below: + +Developer's Certificate of Origin 1.1 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +By making a contribution to this project, I certify that: + + (a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + + (b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + + (c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + + (d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. + +then you just add a line saying:: + + Signed-off-by: Random J Developer <random(a)developer.example.org> + +.. _CC-BY-SA-4.0: LICENSE +.. _#ebbr: https://webchat.oftc.net/?channels=%23ebbr&uio=d4 +.. _OFTC: https://www.oftc.net/ +.. _DCO: https://developercertificate.org/ +.. _boot-architecture: https://lists.linaro.org/mailman/listinfo/boot-architecture +.. _boot-architecture-archive: https://lists.linaro.org/pipermail/boot-architecture + diff --git a/Makefile b/Makefile index 91bb4be..46ed82a 100644 --- a/Makefile +++ b/Makefile @@ -17,4 +17,4 @@ help: # Catch-all target: route all unknown targets to Sphinx using the new # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). %: Makefile - @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) \ No newline at end of file + @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) diff --git a/README.rst b/README.rst index 57fac8f..67c7e85 100644 --- a/README.rst +++ b/README.rst @@ -73,79 +73,22 @@ License ======= This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 -International License. To view a copy of this license, visit +International License (CC-BY-SA-4.0). To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. +Contributions are accepted under the same with sign-off under the Developer's +Certificate of Origin. For more on contributing to EBBR, see CONTRIBUTING.rst_. + A copy of the license is included in the LICENSE_ file. .. image:: https://i.creativecommons.org/l/by-sa/4.0/88x31.png :target: http://creativecommons.org/licenses/by-sa/4.0/ :alt: Creative Commons License +.. _CONTRIBUTING.rst: ./CONTRIBUTING.rst .. _LICENSE: ./LICENSE -Contributing -============ - -Master copy of this project is hosted on GitHub: -https://github.com/ARM-software/ebbr - -Anyone may contribute to the EBBR project. EBBR discussion uses the -boot-architecture_ and arm.ebbr-discuss mailing lists. -The 'official' list is arm.ebbr-discuss, but the list archives are not -yet public, so boot-architecture_ is being used to keep everything in -the open. - -* boot-architechture(a)lists.linaro.org -* arm.ebbr-discuss(a)arm.com - -Past discussions can be found in the boot-architecture-archive_. - -To help track the origin of contributions, this project uses the same -DCO_ "sign-off" process as used by the Linux kernel. -The sign-off is a simple line at the end of the explanation for the -patch, which certifies that you wrote it or otherwise have the right to -pass it on as an open-source patch. The rules are pretty simple: if you -can certify the below: - -Developer's Certificate of Origin 1.1 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By making a contribution to this project, I certify that: - - (a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - - (b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - - (c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - - (d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. - -then you just add a line saying:: - - Signed-off-by: Random J Developer <random(a)developer.example.org> - -IRC Channel: ``#ebbr`` on ofct - -.. _DCO: https://developercertificate.org/ -.. _boot-architecture: https://lists.linaro.org/mailman/listinfo/boot-architecture -.. _boot-architecture-archive: https://lists.linaro.org/pipermail/boot-architecture - Writers Guide ============= diff --git a/source/ebbr.rst b/source/ebbr.rst index 414e3af..4269b49 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -1,12 +1,12 @@ .. EBBR Source Document - Copyright Arm Ltd. 2018 + Copyright Arm Limited, 2018 SPDX-License-Identifier: CC-BY-SA-4.0 #################################################### Embedded Base Boot Requirements (EBBR) Specification #################################################### -Copyright © 2017-2018 Arm Ltd and Contributors. +Copyright © 2017-2018 Arm Limited and Contributors. This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit -- 2.13.0

7 years, 11 months

2
1
0 0

[PATCH 2/2] Add PDF output

by Grant Likely

Use Sphinx-doc to generate PDF output from the source text. With Sphinx installed, a PDF version of the document can be generated by typing: 'make latexpdf' Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- .gitignore | 1 + Makefile | 20 +++++++ README.rst | 56 +++++++++++++++++++ source/conf.py | 163 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ source/ebbr.rst | 22 ++++++-- 5 files changed, 259 insertions(+), 3 deletions(-) create mode 100644 .gitignore create mode 100644 Makefile create mode 100644 source/conf.py diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..796b96d --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +/build diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..91bb4be --- /dev/null +++ b/Makefile @@ -0,0 +1,20 @@ +# Minimal makefile for Sphinx documentation +# + +# You can set these variables from the command line. +SPHINXOPTS = +SPHINXBUILD = sphinx-build +SPHINXPROJ = EBBR +SOURCEDIR = source +BUILDDIR = build + +# Put it first so that "make" without argument is like "make help". +help: + @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) + +.PHONY: help Makefile + +# Catch-all target: route all unknown targets to Sphinx using the new +# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). +%: Makefile + @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) \ No newline at end of file diff --git a/README.rst b/README.rst index 1babcf4..57fac8f 100644 --- a/README.rst +++ b/README.rst @@ -13,6 +13,62 @@ expected in September 2018. You can find the current draft text in this repository, but be aware that everything in the draft text is subject to change before an official v1.0 release is published. +Build Instructions +================== + +Requirements +^^^^^^^^^^^^ + +* Sphinx version 1.5 or later: http://sphinx-doc.org/contents.html +* LaTeX (and pdflatex, and various LaTeX packages) + +On Debian and Ubuntu +^^^^^^^^^^^^^^^^^^^^ +:: + + # apt-get install python-sphinx texlive texlive-latex-extra libalgorithm-diff-perl \ + texlive-humanities texlive-generic-recommended texlive-generic-extra + +If the version of python-sphinx installed is too old, then an additional +new version can be installed with the Python package installer:: + + $ apt-get install python-pip + $ pip install --user --upgrade Sphinx + $ export SPHINXBUILD=~/.local/bin/sphinx-build + +Export SPHINXBUILD (see above) if Sphinx was installed with pip --user, then follow Make commands below + +On Mac OS X +^^^^^^^^^^^ + +* Install MacTeX_ +* Install pip if you do not have it:: + + $ sudo easy_install pip + +* Install Sphinx:: + + $ pip install --user --upgrade Sphinx + +.. _MacTeX: http://tug.org/mactex + +Make Targets +^^^^^^^^^^^^ + +To generate PDF:: + + $ make latexpdf + +To generate hierarchy of HTML pages:: + + $ make html + +To generate a single HTML page:: + + $ make singlehtml + +Output goes in `./build` subdirectory. + License ======= diff --git a/source/conf.py b/source/conf.py new file mode 100644 index 0000000..fd4267b --- /dev/null +++ b/source/conf.py @@ -0,0 +1,163 @@ +#!/usr/bin/env python3 +# -*- coding: utf-8 -*- +# +# EBBR specification build configuration file, created by +# sphinx-quickstart on Thu May 10 18:49:38 2018. +# +# This file is execfile()d with the current directory set to its +# containing dir. +# +# Note that not all possible configuration values are present in this +# autogenerated file. +# +# All configuration values have a default; values that are commented out +# serve to show the default. + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +# +# import os +# import sys +# sys.path.insert(0, os.path.abspath('.')) + +import subprocess + +# -- General configuration ------------------------------------------------ + +# If your documentation needs a minimal Sphinx version, state it here. +# +# needs_sphinx = '1.0' + +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = ['sphinx.ext.todo', + 'sphinx.ext.githubpages'] + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# The suffix(es) of source filenames. +# You can specify multiple suffix as a list of string: +# +# source_suffix = ['.rst', '.md'] +source_suffix = '.rst' + +# The master toctree document. +master_doc = 'ebbr' + +# General information about the project. +project = 'Embedded Base Boot Requirements (EBBR) Specification' +copyright = '2018 Arm, Ltd. and Contributors' +author = 'Arm, Ltd. and Contributors' + +# The version info for the project you're documenting, acts as replacement for +# |version| and |release|, also used in various other places throughout the +# built documents. +# +# The short X.Y version. +try: + version = str(subprocess.check_output(["git", "describe", "--dirty"]), 'utf-8').strip() +except: + version = "unknown-rev" +# The full version, including alpha/beta/rc tags. +release = version + +# The language for content autogenerated by Sphinx. Refer to documentation +# for a list of supported languages. +# +# This is also used if you do content translation via gettext catalogs. +# Usually you set "language" from the command line for these cases. +language = None + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +# This patterns also effect to html_static_path and html_extra_path +exclude_patterns = [] + +# The name of the Pygments (syntax highlighting) style to use. +pygments_style = 'sphinx' + +# If true, `todo` and `todoList` produce output, else they produce nothing. +todo_include_todos = True + + +# -- Options for HTML output ---------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +# +html_theme = 'alabaster' + +# Theme options are theme-specific and customize the look and feel of a theme +# further. For a list of options available for each theme, see the +# documentation. +# +# html_theme_options = {} + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +html_static_path = ['_static'] + + +# -- Options for HTMLHelp output ------------------------------------------ + +# Output file base name for HTML help builder. +htmlhelp_basename = 'EBBRdoc' + + +# -- Options for LaTeX output --------------------------------------------- + +latex_elements = { + # The paper size ('letterpaper' or 'a4paper'). + # + 'papersize': 'a4paper', + + # The font size ('10pt', '11pt' or '12pt'). + # + # 'pointsize': '10pt', + + # Additional stuff for the LaTeX preamble. + # + # 'preamble': '', + + # Latex figure (float) alignment + # + # 'figure_align': 'htbp', +} + +# Release numbers with a qualifier (ex. '-rc', '-pre') get a watermark. +if '-' in release: + latex_elements['preamble'] = '\\usepackage{draftwatermark}\\SetWatermarkScale{.45}\\SetWatermarkText{%s}' % (release) + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, +# author, documentclass [howto, manual, or own class]). +latex_documents = [ + (master_doc, 'EBBR.tex', project, author, 'manual'), +] + + +# -- Options for manual page output --------------------------------------- + +# One entry per manual page. List of tuples +# (source start file, name, description, authors, manual section). +man_pages = [ + (master_doc, 'ebbr', project, [author], 1) +] + + +# -- Options for Texinfo output ------------------------------------------- + +# Grouping the document tree into Texinfo files. List of tuples +# (source start file, target name, title, author, +# dir menu entry, description, category) +texinfo_documents = [ + (master_doc, 'EBBR', project, author, 'EBBR', + 'One line description of project.', 'Miscellaneous'), +] + + + diff --git a/source/ebbr.rst b/source/ebbr.rst index be51f90..414e3af 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -2,8 +2,24 @@ Copyright Arm Ltd. 2018 SPDX-License-Identifier: CC-BY-SA-4.0 +#################################################### +Embedded Base Boot Requirements (EBBR) Specification +#################################################### + +Copyright © 2017-2018 Arm Ltd and Contributors. + +This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 +International License. To view a copy of this license, visit +http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to +Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. + +.. image:: https://i.creativecommons.org/l/by-sa/4.0/88x31.png + :target: http://creativecommons.org/licenses/by-sa/4.0/ + :alt: Creative Commons License + :align: right + ******************* -ABOUT THIS DOCUMENT +About This Document ******************* Introduction @@ -439,7 +455,7 @@ APPENDIX D - Optional UEFI Protocols ******************************************* Basic Networking Support -==================== +======================== ============================================ ====== Service UEFI § @@ -453,7 +469,7 @@ EFI_MANAGED_NETWORK_SERVICE_BINDING_PROTOCOL 25.1 networking. Network Boot Protocols -==================== +====================== ========================================== ====== Service UEFI § -- 2.13.0

7 years, 11 months

2
2
0 0

[RFC PATCH] driver core: make deferring probe forever optional

by Rob Herring

Deferred probe will currently wait forever on dependent devices to probe, but sometimes a driver will never exist. It's also not always critical for a driver to exist. Platforms can rely on default configuration from the bootloader or reset defaults for things such as pinctrl and power domains. This is often the case with initial platform support until various drivers get enabled. There's at least 2 scenarios where deferred probe can render a platform broken. Both involve using a DT which has more devices and dependencies than the kernel supports. The 1st case is a driver may be disabled in the kernel config. The 2nd case is the kernel version may simply not have the dependent driver. This can happen if using a newer DT (provided by firmware perhaps) with a stable kernel version. Unfortunately, this change breaks with modules as we have no way of knowing when modules are done loading. One possibility is to make this opt in or out based on compatible strings rather than at a subsystem level. Ideally this information could be extracted automatically somehow. OTOH, maybe the lists are pretty small. There's only a handful of subsystems that can be optional, and then only so many drivers in those that can be modules (at least for pinctrl, many drivers are built-in only). Cc: Alexander Graf <agraf(a)suse.de> Signed-off-by: Rob Herring <robh(a)kernel.org> --- This patch 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. Rob [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html drivers/base/dd.c | 16 ++++++++++++++++ drivers/pinctrl/devicetree.c | 2 +- include/linux/device.h | 2 ++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index c9f54089429b..5848808b9d7a 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -226,6 +226,15 @@ void device_unblock_probing(void) driver_deferred_probe_trigger(); } + +int driver_deferred_probe_optional(void) +{ + if (initcalls_done) + return -ENODEV; + + return -EPROBE_DEFER; +} + /** * deferred_probe_initcall() - Enable probing of deferred devices * @@ -240,6 +249,13 @@ static int deferred_probe_initcall(void) /* Sort as many dependencies as possible before exiting initcalls */ flush_work(&deferred_probe_work); initcalls_done = true; + + /* + * Trigger deferred probe again, this time we won't defer anything + * that is optional + */ + driver_deferred_probe_trigger(); + flush_work(&deferred_probe_work); return 0; } late_initcall(deferred_probe_initcall); diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c index b601039d6c69..096e52a5c506 100644 --- a/drivers/pinctrl/devicetree.c +++ b/drivers/pinctrl/devicetree.c @@ -120,7 +120,7 @@ static int dt_to_map_one_config(struct pinctrl *p, np_config); of_node_put(np_pctldev); /* OK let's just assume this will appear later then */ - return -EPROBE_DEFER; + return driver_deferred_probe_optional(); } /* If we're creating a hog we can use the passed pctldev */ if (pctldev && (np_pctldev == p->dev->of_node)) diff --git a/include/linux/device.h b/include/linux/device.h index 0059b99e1f25..8de920442bc1 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -332,6 +332,8 @@ struct device *driver_find_device(struct device_driver *drv, struct device *start, void *data, int (*match)(struct device *dev, void *data)); +int driver_deferred_probe_optional(void); + /** * struct subsys_interface - interfaces to device functions * @name: name of the device function -- 2.17.0

7 years, 11 months

7
14
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture