> -----Original Message----- > From: Grant Likely [mailto:grant.lik...@arm.com] > Sent: Thursday, July 12, 2018 1:33 AM > To: Udit Kumar <udit.ku...@nxp.com>; boot-architecture@lists.linaro.org; > arm.ebbr-discuss <arm.ebbr-disc...@arm.com> > Cc: Ben Eckermann <ben.eckerm...@nxp.com>; Varun Sethi > <v.se...@nxp.com> > 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 to OS or OS loader. > > > > > > 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. Ok, That will create some work for new hardware 😊 > > > > 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. Ok > > > > > > 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 <arm.ebbr- > >> disc...@arm.com> > >> 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 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
