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 <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
