Re: [PATCH v4 6/6] PM / Domains: Stop deferring probe at the end of initcall
On 10 July 2018 at 16:25, Rob Herring wrote: > On Mon, Jul 9, 2018 at 4:49 PM Ulf Hansson wrote: >> >> On 9 July 2018 at 17:41, Rob Herring wrote: >> > All PM domain drivers must be built-in (at least those using DT), so >> > there is no point deferring probe after initcalls are done. Continuing >> > to defer probe may prevent booting successfully even if managing PM >> > domains is not required. This can happen if the user failed to enable >> > the driver or if power-domains are added to a platform's DT, but there >> > is not yet a driver (e.g. a new DTB with an old kernel). >> > >> > Call the driver core function driver_deferred_probe_check_init_done() >> > instead of just returning -EPROBE_DEFER to stop deferring probe when >> > initcalls are done. >> > >> > Acked-by: "Rafael J. Wysocki" >> > Cc: Kevin Hilman >> > Cc: Ulf Hansson >> > Cc: Pavel Machek >> > Cc: Len Brown >> > Cc: Greg Kroah-Hartman >> > Cc: linux...@vger.kernel.org >> > Signed-off-by: Rob Herring >> > --- >> > v4: >> > - Add Rafael's ack >> > >> > v3: >> > - Update to new function name >> > >> > drivers/base/power/domain.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >> > index 4925af5c4cf0..8c12213875c6 100644 >> > --- a/drivers/base/power/domain.c >> > +++ b/drivers/base/power/domain.c >> > @@ -2253,7 +2253,7 @@ static int __genpd_dev_pm_attach(struct device *dev, >> > struct device_node *np, >> > mutex_unlock(&gpd_list_lock); >> > dev_dbg(dev, "%s() failed to find PM domain: %ld\n", >> > __func__, PTR_ERR(pd)); >> > - return -EPROBE_DEFER; >> > + return driver_deferred_probe_check_state(dev); >> > } >> >> This isn't the only error path where -EPROBE_DEFER may be returned >> during attach in genpd. > > Yes, but I think this is the only place you can fail to get the PD > device from DT. The case we care about is properties exist in the DT, > but no driver exists. That's correct. Thanks for clarifying! > > What would cause deferring in the latter cases? To power on the PM domain for example, which often is required to be able to probe the device. > > Rob Kind regards Uffe ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [PATCH v4 6/6] PM / Domains: Stop deferring probe at the end of initcall
On 9 July 2018 at 17:41, Rob Herring wrote: > All PM domain drivers must be built-in (at least those using DT), so > there is no point deferring probe after initcalls are done. Continuing > to defer probe may prevent booting successfully even if managing PM > domains is not required. This can happen if the user failed to enable > the driver or if power-domains are added to a platform's DT, but there > is not yet a driver (e.g. a new DTB with an old kernel). > > Call the driver core function driver_deferred_probe_check_init_done() > instead of just returning -EPROBE_DEFER to stop deferring probe when > initcalls are done. > > Acked-by: "Rafael J. Wysocki" > Cc: Kevin Hilman > Cc: Ulf Hansson > Cc: Pavel Machek > Cc: Len Brown > Cc: Greg Kroah-Hartman > Cc: linux...@vger.kernel.org > Signed-off-by: Rob Herring > --- > v4: > - Add Rafael's ack > > v3: > - Update to new function name > > drivers/base/power/domain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index 4925af5c4cf0..8c12213875c6 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2253,7 +2253,7 @@ static int __genpd_dev_pm_attach(struct device *dev, > struct device_node *np, > mutex_unlock(&gpd_list_lock); > dev_dbg(dev, "%s() failed to find PM domain: %ld\n", > __func__, PTR_ERR(pd)); > - return -EPROBE_DEFER; > + return driver_deferred_probe_check_state(dev); > } This isn't the only error path where -EPROBE_DEFER may be returned during attach in genpd. Have a look at the callers of __genpd_dev_pm_attach() and also have a second look inside __genpd_dev_pm_attach() itself. And in Rafael's tree. > > dev_dbg(dev, "adding to PM domain %s\n", pd->name); > -- > 2.17.1 Besides the above, I am fine with the approach as such. Kind regards Uffe ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released
On 09/07/2018 19:47, Dong Wei wrote: Grant, We don't need to change anything in the UEFI Spec. All we need to do is to request the addition of /Firmware directory in the registry. You can send the request to the USWG chair. There is a link on that page to send the request. Okay, I'll do that. Created a github issue to track the topic: https://github.com/ARM-software/ebbr/issues/25 g. Vendors do have the freedom to choose a name, but the name needs to be requested to the USWG chair so that USWG can check whether the name collides with any existing names and whether the request is legit. Sometimes vendors may need to change the proposed name if it collides with the existing one. - DW - -Original Message- From: Grant Likely Sent: Monday, July 9, 2018 11:17 AM To: Dong Wei ; boot-architecture@lists.linaro.org; arm.ebbr-discuss Subject: Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released On 09/07/2018 18:54, Dong Wei wrote: Grant, In section 4.2, the /Firmware directory is mentioned. What are the reasons why this new hierarchy of directories are created? Can we not use the existing /EFI hierarchy as shown at http://www.uefi.org/registry? I may have missed the rational when discussed. Because it doesn't contain EFI executables, or have anything to do with the UEFI spec at all. A different hierarchy was selected because it insulates firmware implementation details from the hierarchy used by an OS to install EFI binaries. If we do need to create a new /Firmware hierarchy, we need to register that with the UEFI Forum as the UEFI Forum owns the ESP name space to avoid conflicts. EBBR cannot single-handedly create new hierarchy. I'm okay with that. Care to propose suitable language for the EFI spec? Also, each SoC vendor would need to make request to the UEFI Forum to get their vendor subdirectories under /Firmware as well. Is that true? I lifted the description of the /FIRMWARE directory straight from UEFI section 13.3.1.3: "Applications that are loaded by other applications or drivers are not required to be stored in any specific location in the EFI system partition. The choice of the subdirectory name is up to the vendor, but all vendors must pick names that do not collide with any other vendor’s subdirectory name. This applies to system manufacturers, operating system vendors, BIOS vendors, and third party tool vendors, or any other vendor that wishes to install files on an EFI system partition." Seems to me that the vendors have freedom to chose a name. Cheers, g. - DW - -Original Message- From: arm.ebbr-discuss-boun...@arm.com On Behalf Of Grant Likely Sent: Friday, July 6, 2018 12:13 PM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss Subject: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released I've tagged the prerelease in preparation for a wider v0.6 RFC release next week. Please review and comment: https://github.com/glikely/ebbr/releases/tag/v0.6-pre1 (I've linked to the copy on my personal ebbr fork because I'm having trouble getting Travis-ci to deploy to the official repo. It will take a bit of effort to work out what is wrong) g. ___ Arm.ebbr-discuss mailing list arm.ebbr-disc...@arm.com 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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released
On 11/07/2018 06:33, Udit Kumar wrote: Hi Grant Few comments 1/ 1.1 Introduction For example, an Arm A-class embedded networking platform to For example, an Arm A-class embedded platform done 2/ 1.2 Guiding Principals EBBR as a specification defines requirements to EBBR as a specification define requirements The original is correct grammer. The alternative would be "EBBR as a specification will define requirements...", but that changes the tense of the entire paragraph. 3.1/ 1.3 Scope Please see, if we can remove reference to SBBR here. In case, we wish to put this reference then SBBR does not may about hardware requirement with SBBR having stricter requirements on hardware to with SBSA having stricter requirements on hardware I do want to position EBBR as compared to SBBR, particularly because SBBR compliance should always mean also EBBR compliant. I don't ever want a scenario where an SBBR system cannot be EBBR compliant. That would be an unnecessary fork of the ecosystem. I've changed the whole paragraph to this: """ This specification is similar to the Arm Server Base Boot Requirements specification [SBBR]_ in that it defines the firmware interface presented to an operating system. SBBR is targeted at the server ecosystem and places strict requirements on the platform to ensure cross vendor interoperability. EBBR on the other hand allows more flexibility to support embedded designs which do not fit within the SBBR model. """ 3.2/ 1.3 Scope Below may not be a valid example, SBBR recommends to use sperate storage but does not mandate it. In other discussion Dong Wei said this is left on implementation For example, an embedded system may use a single eMMC storage device to hold both firmware and operating system images How about this then? """ For example, a platform that isn't SBBR compliant because the SoC is only supported using Devicetree could be EBBR compliant, but not SBBR compliant. """ 4/ 2.4.3 Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table. Please help with some example tables here. I don't have any examples to give. The only point of this sentence is that EBBR does not preclude having additional tables populated in the UEFI configuration table, which could be anything. This language was originally in SBBR if I remember correctly. 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 Could we reword this please, first we said, either ACPI or devicetree. Later we are saying selection to be done. Both are true. A platform can include both ACPI & DT, but only one can be presented to software at a time. Also at what time, ACPI or devicetree to be selected build time or runtime Doesn't matter. Implementer can choose. All that matters is that by the time we're running executables only one or the other is presented. The language as written seems clear to me. Can you propose an alternate wording? 5/ FIRMWARE STORAGE Please elaborate ESP at first place, this is used instead of doing this later of the storage used for OS partitions and the ESP To of the storage used for OS partitions and the ESP (EFI System Partition) Fixed 6/ 4.1 Partitioning of Shared Storage Warning: A future issue of this specification will remove the MBR We are putting a requirement on hardware here. Do we want to update boot ROM to understand GPT in future hardware ? Yes. We want to push future platforms to understand GPT if firmware is being loaded from the same block device or LU as the OS. 7/ 5.2 Required Runtime Services Please add a note for Update capsule too, Similar to Get/Set Time, Update capsule can return EFI_UNSUPPORTED All of appendix A is probably going to be removed in the next release because it duplicates things that are already in UEFI. Instead, the next release of the spec will probably need to have exceptions to the spec due to U-Boot not being able to implement everything that is required yet. Regards Udit -Original Message- From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss- boun...@arm.com] On Behalf Of Grant Likely Sent: Saturday, July 7, 2018 12:43 AM To: boot-architecture@lists.linaro.org; arm.ebbr-discuss Subject: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released I've tagged the prerelease in preparation for a wider v0.6 RFC release next week. Please review and comment: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. com%2Fglikely%2Febbr%2Freleases%2Ftag%2Fv0.6- pre1&data=02%7C01%7Cudit.kumar%40nxp.com%7Ccc2fd094bcb9462f79 8908d5e3747e4a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6366 65011834763051&sdata=or0ngRAQ937f37XgY8vUPFEaX86YigH2a5J122v98 z0%3D&reserved=0 (I've linked to the copy on my personal ebbr fork because I'm havin
Re: [PATCH] Update manifesto from comments on mailing list
On 09/07/2018 13:39, Mark Brown wrote: On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: - While ACPI provides more standardization, Devicetree is preferred in may embedded - platforms for its flexibility. + While ACPI provides more standardization, Devicetree is preferred in many + embedded platforms for its flexibility. How about something more like While ACPI provides strong standardization for platforms that fit within its model many embedded platforms do not work well within that model so the standards offered by Devicetree are preferred. Bit of a pet peeve of mine since ASoC means I'm frequently having to think about systems that fall off the edge of what ACPI can express and it's just a miserable experience. Understood, but I'm going to leave it as is for now. I don't want to get into a discussion of the reasons Devicetree is preferred. I just want to acknowledge that both DT and ACPI are supported options. g. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [PATCH] Update manifesto from comments on mailing list
Hi Grant, On 9 July 2018 at 06:17, Grant Likely wrote: > Editing in response to comments from Bill Mills, Daniel Thompson, and > Alex Graf. Mostly trivial editorial, but did flush out the discussion of > how future updates to the specification would be handled, and added a > note about DT platform compatibility rules. > > Signed-off-by: Grant Likely > Cc: Bill Mills > Cc: Alexander Graf > Cc: Daniel Thompson > --- > source/chapter1-about.rst | 49 > --- > 1 file changed, 34 insertions(+), 15 deletions(-) > Reviewed-by: Simon Glass > diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst > index cb675d9..a2561d6 100644 > --- a/source/chapter1-about.rst > +++ b/source/chapter1-about.rst > @@ -23,7 +23,7 @@ It leverages the prevalent industry standard firmware > specification of [UEFI]_. > > Comments or change requests can be sent to arm.ebbr-disc...@arm.com. > > -Guiding Principals > +Guiding Principles > == > > EBBR as a specification defines requirements on platforms and operating > systems, > @@ -51,7 +51,7 @@ amount of custom engineering required, make it possible for > OS distributions to > support embedded platforms, while still preserving the firmware stack product > vendors are comfortable with. > Or in simpler terms, EBBR is designed to solve the embedded boot mess by > -migrating existing firmware projects (U-Boot) to a defined standard (UEFI). > +adding a defined standard (UEFI) to the existing firmware projects (U-Boot). > > However, EBBR is a specification, not an implementation. > The goal of EBBR is not to mandate U-Boot and Linux. > @@ -61,24 +61,33 @@ ensure that the EBBR requirements are implemented by both > projects. > [#EDK2Note]_ > > .. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the > - time of writing these are the two most important firmware projects. > + time of writing these are the two most important firmware projects that > + implement UEFI. > Tianocore/EDK2 is a full featured UEFI implementation and so should > - automatically be EBBR compliant. U-Boot is the incumbant firmware project > - for embedded platforms and has added basic UEFI compliance. > + automatically be EBBR compliant. > + U-Boot is the incumbant firmware project for embedded platforms and has > + steadily been adding UEFI compliance since 2016. Or 2015? That's when it got payload and app support. But I suspect you are talking about the efi_loader support only? Regards, Simon ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
[PATCH] v0.6-pre1 draft comments responses
Edits responding to comments from Udit Kumar Suggested-by: Udit Kumar Signed-off-by: Grant Likely --- source/chapter1-about.rst | 16 +--- source/chapter4-firmware-media.rst | 3 ++- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index a2561d6..1dafd39 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -10,7 +10,7 @@ between platform firmware and an operating system that is suitable for embedded platforms. EBBR compliant platforms present a consistent interface that will boot an EBBR compliant operating system without any custom tailoring required. -For example, an Arm A-class embedded networking platform will benefit +For example, an Arm A-class embedded platform will benefit from a standard interface that supports features such as secure boot and firmware update. @@ -149,12 +149,14 @@ Operating System. This specification is similar to the Arm Server Base Boot Requirements specification [SBBR]_ in that it defines the firmware interface presented to an -operating system, with SBBR having stricter requirements on hardware and -firmware than EBBR. -EBBR allows for design decisions that are common in the embedded space, but not -supported by the server ecosystem. -For example, an embedded system may use a single eMMC storage device to hold -both firmware and operating system images. +operating system. +SBBR is targeted at the server ecosystem and places strict requirements on the +platform to ensure cross vendor interoperability. +EBBR on the other hand allows more flexibility to support embedded designs +which do not fit within the SBBR model. +For example, a platform that isn't SBBR compliant because the SoC is only +supported using Devicetree could be EBBR compliant, but not SBBR compliant. + By definition, all SBBR compliant systems are also EBBR compliant, but the converse is not true. diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index 604df18..39a1c03 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -4,7 +4,8 @@ Firmware Storage In general, EBBR compliant platforms should use dedicated storage for boot firmware images and data, -independent of the storage used for OS partitions and the ESP. +independent of the storage used for OS partitions and the EFI System Partition +(ESP). This could be a physically separate device (e.g. SPI flash), or a dedicated logical unit (LU) within a device (e.g. eMMC boot partition, [#eMMCBootPartition]_ -- 2.13.0 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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [PATCH] Update manifesto from comments on mailing list
On 11/07/2018 21:13, Simon Glass wrote: Hi Grant, On 9 July 2018 at 06:17, Grant Likely wrote: Editing in response to comments from Bill Mills, Daniel Thompson, and Alex Graf. Mostly trivial editorial, but did flush out the discussion of how future updates to the specification would be handled, and added a note about DT platform compatibility rules. Signed-off-by: Grant Likely Cc: Bill Mills Cc: Alexander Graf Cc: Daniel Thompson --- source/chapter1-about.rst | 49 --- 1 file changed, 34 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass hahaha! You are about 5 minutes too late. I just pushed the patch to mainline. :-) The mailing list archives are forever... diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index cb675d9..a2561d6 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -23,7 +23,7 @@ It leverages the prevalent industry standard firmware specification of [UEFI]_. Comments or change requests can be sent to arm.ebbr-disc...@arm.com. -Guiding Principals +Guiding Principles == EBBR as a specification defines requirements on platforms and operating systems, @@ -51,7 +51,7 @@ amount of custom engineering required, make it possible for OS distributions to support embedded platforms, while still preserving the firmware stack product vendors are comfortable with. Or in simpler terms, EBBR is designed to solve the embedded boot mess by -migrating existing firmware projects (U-Boot) to a defined standard (UEFI). +adding a defined standard (UEFI) to the existing firmware projects (U-Boot). However, EBBR is a specification, not an implementation. The goal of EBBR is not to mandate U-Boot and Linux. @@ -61,24 +61,33 @@ ensure that the EBBR requirements are implemented by both projects. [#EDK2Note]_ .. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the - time of writing these are the two most important firmware projects. + time of writing these are the two most important firmware projects that + implement UEFI. Tianocore/EDK2 is a full featured UEFI implementation and so should - automatically be EBBR compliant. U-Boot is the incumbant firmware project - for embedded platforms and has added basic UEFI compliance. + automatically be EBBR compliant. + U-Boot is the incumbant firmware project for embedded platforms and has + steadily been adding UEFI compliance since 2016. Or 2015? That's when it got payload and app support. But I suspect you are talking about the efi_loader support only? Ask Alex, He provided the wording. :-) g. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: [PATCH] Update manifesto from comments on mailing list
On 11.07.18 22:15, Grant Likely wrote: > On 11/07/2018 21:13, Simon Glass wrote: >> Hi Grant, >> >> On 9 July 2018 at 06:17, Grant Likely wrote: >>> Editing in response to comments from Bill Mills, Daniel Thompson, and >>> Alex Graf. Mostly trivial editorial, but did flush out the discussion of >>> how future updates to the specification would be handled, and added a >>> note about DT platform compatibility rules. >>> >>> Signed-off-by: Grant Likely >>> Cc: Bill Mills >>> Cc: Alexander Graf >>> Cc: Daniel Thompson >>> --- >>> source/chapter1-about.rst | 49 >>> --- >>> 1 file changed, 34 insertions(+), 15 deletions(-) >>> >> >> Reviewed-by: Simon Glass > > hahaha! You are about 5 minutes too late. I just pushed the patch to > mainline. :-) > > The mailing list archives are forever... > >> >>> diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst >>> index cb675d9..a2561d6 100644 >>> --- a/source/chapter1-about.rst >>> +++ b/source/chapter1-about.rst >>> @@ -23,7 +23,7 @@ It leverages the prevalent industry standard >>> firmware specification of [UEFI]_. >>> >>> Comments or change requests can be sent to arm.ebbr-disc...@arm.com. >>> >>> -Guiding Principals >>> +Guiding Principles >>> == >>> >>> EBBR as a specification defines requirements on platforms and >>> operating systems, >>> @@ -51,7 +51,7 @@ amount of custom engineering required, make it >>> possible for OS distributions to >>> support embedded platforms, while still preserving the firmware >>> stack product >>> vendors are comfortable with. >>> Or in simpler terms, EBBR is designed to solve the embedded boot >>> mess by >>> -migrating existing firmware projects (U-Boot) to a defined standard >>> (UEFI). >>> +adding a defined standard (UEFI) to the existing firmware projects >>> (U-Boot). >>> >>> However, EBBR is a specification, not an implementation. >>> The goal of EBBR is not to mandate U-Boot and Linux. >>> @@ -61,24 +61,33 @@ ensure that the EBBR requirements are implemented >>> by both projects. >>> [#EDK2Note]_ >>> >>> .. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here >>> because at the >>> - time of writing these are the two most important firmware projects. >>> + time of writing these are the two most important firmware >>> projects that >>> + implement UEFI. >>> Tianocore/EDK2 is a full featured UEFI implementation and so should >>> - automatically be EBBR compliant. U-Boot is the incumbant firmware >>> project >>> - for embedded platforms and has added basic UEFI compliance. >>> + automatically be EBBR compliant. >>> + U-Boot is the incumbant firmware project for embedded platforms >>> and has >>> + steadily been adding UEFI compliance since 2016. >> >> Or 2015? That's when it got payload and app support. But I suspect you >> are talking about the efi_loader support only? > > Ask Alex, He provided the wording. :-) Yes, EBBR only cares about the efi_loader parts. I guess you could stretch the sentence to mean payload support too which really helped a lot, but then again 1 year left or right won't make a big difference. Alex ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
RE: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released
> -Original Message- > From: Grant Likely [mailto:grant.lik...@arm.com] > Sent: Thursday, July 12, 2018 1:33 AM > To: Udit Kumar ; boot-architecture@lists.linaro.org; > arm.ebbr-discuss > Cc: Ben Eckermann ; Varun Sethi > > Subject: Re: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released > > On 11/07/2018 06:33, Udit Kumar wrote: > > Hi Grant > > > > Few comments > > > > 1/ 1.1 Introduction > >> For example, an Arm A-class embedded networking platform > > to > >> For example, an Arm A-class embedded platform > > done > > > > > 2/ 1.2 Guiding Principals > >> EBBR as a specification defines requirements > > to > >> EBBR as a specification define requirements > > The original is correct grammer. The alternative would be "EBBR as a > specification will define requirements...", but that changes the tense of the > entire paragraph. Ok, please keep the original then > > > > 3.1/ 1.3 Scope > > Please see, if we can remove reference to SBBR here. > > In case, we wish to put this reference then SBBR does not may about > > hardware requirement > > > >> with SBBR having stricter requirements on hardware > > to > >> with SBSA having stricter requirements on hardware > > I do want to position EBBR as compared to SBBR, particularly because SBBR > compliance should always mean also EBBR compliant. I don't ever want a > scenario where an SBBR system cannot be EBBR compliant. That would be an > unnecessary fork of the ecosystem. > > I've changed the whole paragraph to this: > > """ > This specification is similar to the Arm Server Base Boot Requirements > specification [SBBR]_ in that it defines the firmware interface presented to > an > operating system. SBBR is targeted at the server ecosystem and places strict > requirements on the platform to ensure cross vendor interoperability. EBBR on > the other hand allows more flexibility to support embedded designs which do > not fit within the SBBR model. > """ Ok thanks, > > 3.2/ 1.3 Scope > > Below may not be a valid example, SBBR recommends to use sperate > > storage but does not mandate it. In other discussion Dong Wei said > > this is left on implementation > >> For example, an embedded system may use a single eMMC storage device > >> to hold both firmware and operating system images > > > How about this then? > > """ > For example, a platform that isn't SBBR compliant because the SoC is only > supported using Devicetree could be EBBR compliant, but not SBBR compliant. > """ Yes, this is valid example. Thanks > > > > 4/ 2.4.3 Configuration Tables > >> A UEFI system that complies with this specification may provide the > >> additional tables via the EFI Configuration Table. > > Please help with some example tables here. > > I don't have any examples to give. The only point of this sentence is that > EBBR > does not preclude having additional tables populated in the UEFI configuration > table, which could be anything. Ok > This language was originally in SBBR if I remember correctly. IMO, We can start the para with Compliant systems are required to provide one, but not both, of the following tables and in last of this para, we could mention this Compliant systems are required to provide one, but not both, of the following tables. • An Advanced Configuration and Power Interface [ACPI] table, or • a Devicetree [DTSPEC] system description 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 A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table. > >> 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 > > Could we reword this please, first we said, either ACPI or > > devicetree. Later we are saying selection to be done. > > Both are true. A platform can include both ACPI & DT, but only one can be > presented to software at a time. > > > Also at what time, ACPI or devicetree to be selected build time or > > runtime > > Doesn't matter. Implementer can choose. All that matters is that by the time > we're running executables only one or the other is presented. The language as > written seems clear to me. Can you propose an alternate wording? What about below, Compliant systems are required to provide one of the following tables. • An Advanced Configuration and Power Interface [ACPI] table, or • A Devicetree [DTSPEC] system description Systems that support both interfaces must provide a configuration mechanism to select either ACPI or Devicetree at compile time or at runtime. As stated above, EBBR systems must not provide both ACPI and Devicetree tables at the same time
RE: [PATCH] v0.6-pre1 draft comments responses
Thanks Grant > -Original Message- > From: Grant Likely [mailto:grant.lik...@arm.com] > Sent: Thursday, July 12, 2018 1:44 AM > To: boot-architecture@lists.linaro.org; arm.ebbr-disc...@arm.com > Cc: Udit Kumar ; Grant Likely > Subject: [PATCH] v0.6-pre1 draft comments responses > > Edits responding to comments from Udit Kumar > > Suggested-by: Udit Kumar > Signed-off-by: Grant Likely Reviewed by : Udit Kumar > --- > source/chapter1-about.rst | 16 +--- > source/chapter4-firmware-media.rst | 3 ++- > 2 files changed, 11 insertions(+), 8 deletions(-) > > diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index > a2561d6..1dafd39 100644 > --- a/source/chapter1-about.rst > +++ b/source/chapter1-about.rst > @@ -10,7 +10,7 @@ between platform firmware and an operating system that > is suitable for embedded platforms. > EBBR compliant platforms present a consistent interface that will boot an > EBBR > compliant operating system without any custom tailoring required. > -For example, an Arm A-class embedded networking platform will benefit > +For example, an Arm A-class embedded platform will benefit > from a standard interface that supports features such as secure boot and > firmware update. > > @@ -149,12 +149,14 @@ Operating System. > > This specification is similar to the Arm Server Base Boot Requirements > specification [SBBR]_ in that it defines the firmware interface presented to > an - > operating system, with SBBR having stricter requirements on hardware and - > firmware than EBBR. > -EBBR allows for design decisions that are common in the embedded space, but > not -supported by the server ecosystem. > -For example, an embedded system may use a single eMMC storage device to > hold -both firmware and operating system images. > +operating system. > +SBBR is targeted at the server ecosystem and places strict requirements > +on the platform to ensure cross vendor interoperability. > +EBBR on the other hand allows more flexibility to support embedded > +designs which do not fit within the SBBR model. > +For example, a platform that isn't SBBR compliant because the SoC is > +only supported using Devicetree could be EBBR compliant, but not SBBR > compliant. > + > By definition, all SBBR compliant systems are also EBBR compliant, but the > converse is not true. > > diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware- > media.rst > index 604df18..39a1c03 100644 > --- a/source/chapter4-firmware-media.rst > +++ b/source/chapter4-firmware-media.rst > @@ -4,7 +4,8 @@ Firmware Storage > > In general, EBBR compliant platforms should use dedicated storage for boot > firmware images and data, -independent of the storage used for OS partitions > and the ESP. > +independent of the storage used for OS partitions and the EFI System > +Partition (ESP). > This could be a physically separate device (e.g. SPI flash), or a dedicated > logical > unit (LU) within a device (e.g. eMMC boot partition, [#eMMCBootPartition]_ > -- > 2.13.0 > > 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. ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
