Re: Topics for EBBR

[Dong Wei]

+ Vincent

From: Heinrich Schuchardt 
Date: Saturday, September 3, 2022 at 12:18 AM
To: grant.lik...@linaro.org 
Cc: boot-architecture@lists.linaro.org 
Subject: Topics for EBBR
On 4/11/22 10:39, Grant Likely wrote:
> I don’t have any agenda items. If I don’t hear anything in the next few hours 
> then I will cancel the biweekly.
>
> g.
>

In https://github.com/ARM-software/ebbr we have pull requests concerning

* requiring the ESRT
* providing the EFI_CONFORMANCE_PROFILE_TABLE.

which should be decided upon.

When is the next meeting planned?

Best regards

Heinrich

___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
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
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: SystemReady and OCP Checklist

[Dong Wei]

Hi Francois,

I don’t feel that it is the responsibility of the BBR spec or the SystemReady 
program to describe how the partners are implementing their firmware solutions. 
 And these three categories are not exhaustive. I am not sure what purpose do 
we serve by providing such a list which we may not even able to make it 
exhaustive. It is not the intent for BBR spec or the SystemReady program to 
dictate how our partners implement their firmware. We certainly support OSF 
effort in OCP but that is responsibility of the OCP badge.

Thanks,
-DW

From: François Ozog 
Date: Monday, October 25, 2021 at 4:51 AM
To: Dong Wei 
Cc: Boot Architecture Mailman List 
Subject: Re: SystemReady and OCP Checklist
Hi Dong,

On Mon, 25 Oct 2021 at 13:45, Dong Wei 
mailto:dong@arm.com>> wrote:
In 4.4 of BBR when discussing LBBR recipe we do provide a note to point to the 
OSF checklist. However, SystemReady is not the place to require it. Arm 
supports both open and commercial firmware.

Indeed. Should we express not a requirement but a categorization so that 
customers can know what is the firmware level of ownership (valid even with 
commercial firmware)?
Category 1: full open source
Category 2: mostly open source with binaries redistribution license (OSF)
Category 3: commercial firmware with private redistribution license

Sent from my iPhone

> On Oct 25, 2021, at 6:44 AM, François Ozog 
> mailto:francois.o...@linaro.org>> wrote:
>
> Hi
>
> back in April we had a workshop on firmware sustainability. Since then a
> number of discussions related concerns on closed source components in TF-A
> and U-Boot communities. We are also approaching a technical maturity level
> on SystemReady that it looks timely to revisit this aspect.
>
> Would it be a good move to adopt the Open System Firmware check list
> <https://www.opencompute.org/wiki/Open_System_Firmware/Checklist> as part
> of SystemReady?
>
> *NOTE1:  believe SystemReady is at right level as it addresses compliance
> of platforms. EBBR is a technical recipe to make it work for a particular
> environment (like SBBR) and so not the best place to deal with
> redistribution license of binary blobs and other platform owernship
> aspects.*
>
> *NOTE2/ Adoption could come in different forms: referring to it, crafting a
> similar one for SystemReady scope, any other smart ways of doing it.*
>
>
> Cheers
>
> FF
>
> --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.o...@linaro.org<mailto:francois.o...@linaro.org> | Skype: ffozog
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org<mailto:boot-architecture@lists.linaro.org>
> https://lists.linaro.org/mailman/listinfo/boot-architecture
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.


--
[https://static.linaro.org/common/images/linaro-logo-web.png]
François-Frédéric Ozog | Director Business Development
T: +33.67221.6485
francois.o...@linaro.org<mailto:francois.o...@linaro.org> | Skype: ffozog

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: SystemReady and OCP Checklist

[Dong Wei]

>> SystemReady should require that the firmware complies to the license
requirements of its components.

SystemReady tests compliances to the hardware and firmware minimum interfaces, 
we are not dealing with code bases and there license requirements.

From: boot-architecture  on behalf 
of Heinrich Schuchardt 
Date: Monday, October 25, 2021 at 7:52 AM
To: François Ozog 
Cc: Tom Rini , Boot Architecture Mailman List 
, Wolfgang Denk 
Subject: Re: SystemReady and OCP Checklist
On 10/25/21 12:43, François Ozog wrote:
> Hi
>
> back in April we had a workshop on firmware sustainability. Since then a
> number of discussions related concerns on closed source components in TF-A
> and U-Boot communities. We are also approaching a technical maturity level

U-Boot is licenced under GPL. You must not include any code which is not
licensed under GPL or a compatible license (cf.
https://www.gnu.org/licenses/license-list.html) into U-Boot. This
disqualifies any closed source component but also open source which is
not GPL compatible like OpenSSL.

The BSD-3 license of TF-A is compatible with GPL.

For closed source TF-A components distributed with U-Boot the following
GPL exception *MIGHT* apply in some cases:

"However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable."

If you include TF-A within the U-Boot binary, all included TF-A
components must comply to the GPL license. This is typically the case if
U-Boot SPL loads BL31.

> on SystemReady that it looks timely to revisit this aspect.
>
> Would it be a good move to adopt the Open System Firmware check list
>  as part
> of SystemReady?

SystemReady should require that the firmware complies to the license
requirements of its components.

Open sourcing more firmware components increases the trustworthiness of
the platform.

Reading the Open System Firmware Checklist some requirements remain
unclear to me: The boot ROM that is part of the SoC lithography mask is
firmware. The checklist requires that firmware can be updated which is
obviously impossible for the boot ROM.

We need a list of software components that the requirements shall apply
to. Besides TF-A and U-Boot, please, consider if secure zone software
like OP-TEE modules and trust zone shall be included into the requirement.

Best regards

Heinrich

>
> *NOTE1:  believe SystemReady is at right level as it addresses compliance
> of platforms. EBBR is a technical recipe to make it work for a particular
> environment (like SBBR) and so not the best place to deal with
> redistribution license of binary blobs and other platform owernship
> aspects.*
>
> *NOTE2/ Adoption could come in different forms: referring to it, crafting a
> similar one for SystemReady scope, any other smart ways of doing it.*
>
>
> Cheers
>
> FF
>
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
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: SystemReady and OCP Checklist

[Dong Wei]

In 4.4 of BBR when discussing LBBR recipe we do provide a note to point to the 
OSF checklist. However, SystemReady is not the place to require it. Arm 
supports both open and commercial firmware.

Sent from my iPhone

> On Oct 25, 2021, at 6:44 AM, François Ozog  wrote:
>
> Hi
>
> back in April we had a workshop on firmware sustainability. Since then a
> number of discussions related concerns on closed source components in TF-A
> and U-Boot communities. We are also approaching a technical maturity level
> on SystemReady that it looks timely to revisit this aspect.
>
> Would it be a good move to adopt the Open System Firmware check list
>  as part
> of SystemReady?
>
> *NOTE1:  believe SystemReady is at right level as it addresses compliance
> of platforms. EBBR is a technical recipe to make it work for a particular
> environment (like SBBR) and so not the best place to deal with
> redistribution license of binary blobs and other platform owernship
> aspects.*
>
> *NOTE2/ Adoption could come in different forms: referring to it, crafting a
> similar one for SystemReady scope, any other smart ways of doing it.*
>
>
> Cheers
>
> FF
>
> --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
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: Native PE/COFF support for aarch64

[Dong Wei]

Sorry, meant to be a “Good job” emoji

From: boot-architecture  on behalf 
of Dong Wei 
Date: Friday, September 10, 2021 at 9:35 AM
To: François Ozog , Boot Architecture Mailman List 

Cc: Heinrich Schuchardt 
Subject: Re: Native PE/COFF support for aarch64
[??]

From: boot-architecture  on behalf 
of François Ozog 
Date: Friday, September 10, 2021 at 9:13 AM
To: Boot Architecture Mailman List 
Cc: Heinrich Schuchardt 
Subject: Native PE/COFF support for aarch64
Hi,

this mail just to inform you that there is a plan to support native
building of PE/COFF for aarch64 and in particular to support SBAT for
shim.efi.

It is seen possible to deliver this by the end of October (this is just an
early estimate).

Cordially

FF

--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
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
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: Native PE/COFF support for aarch64

[Dong Wei]

[??]

From: boot-architecture  on behalf 
of François Ozog 
Date: Friday, September 10, 2021 at 9:13 AM
To: Boot Architecture Mailman List 
Cc: Heinrich Schuchardt 
Subject: Native PE/COFF support for aarch64
Hi,

this mail just to inform you that there is a plan to support native
building of PE/COFF for aarch64 and in particular to support SBAT for
shim.efi.

It is seen possible to deliver this by the end of October (this is just an
early estimate).

Cordially

FF

--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
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: [EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

[Dong Wei]

+ Stuart, the author of BBSR

From: boot-architecture  on behalf 
of AKASHI Takahiro 
Date: Monday, February 15, 2021 at 4:19 PM
To: Grant Likely 
Cc: Heinrich Schuchardt , 
boot-architecture@lists.linaro.org , nd 

Subject: Re: [EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE
Hi Grant,

# apart from capsule update/EBBR,

On Mon, Feb 15, 2021 at 05:28:32PM +, Grant Likely wrote:
>
>
> On 12/02/2021 21:50, Heinrich Schuchardt wrote:
> > On 2/12/21 7:59 PM, Grant Likely wrote:
> > > EFI_UPDATE_CAPSULE is the industry standard method for applying firmware
> > > updates. Make it a requirement in EBBR so that fwupd, Windows Update,
> > > and any other generic firmware update service can support EBBR platforms.
> > >
> > > This is made required because the ability to update firmware is a
> > > critical part of building secure platforms.
> > >
> > > Fixes: #69
> > > Signed-off-by: Grant Likely 
> > > ---
> > >   source/chapter2-uefi.rst | 29 -
> > >   1 file changed, 28 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> > > index 3d48c99..4e8a24d 100644
> > > --- a/source/chapter2-uefi.rst
> > > +++ b/source/chapter2-uefi.rst
> > > @@ -352,7 +352,7 @@ are required to be implemented during boot
> > > services and runtime services.
> > >- Required
> > >- Optional
> > >  * - `EFI_UPDATE_CAPSULE`
> >
> > As you have secure firmware in mind, shouldn't we explicitly require
> > signature verification of capsules?
>
> Yes, but not yet. All the security requirements need to come in at the same
> time so that it makes sense, and it may be that we adopt BBSR as the
> security standard instead of adding it into EBBR.

looking at BBSR (v1.0a, downloaded from Arm site),
it mentions EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS as
one of required attributes for authenticated variables.
But it is already marked as deprecated in UEFI spec, and
I didn't implement it on U-Boot UEFI.

Has that statement in BBSR already been modified/fixed?

-Takahiro Akashi


> g.
>
> >
> > Best regards
> >
> > Heinrich
> >
> > > - - Optional
> > > + - Required for in-band update
> > >- Optional
> > >  * - `EFI_QUERY_CAPSULE_CAPABILITIES`
> > >- Optional
> > > @@ -435,6 +435,25 @@ Even when SetVariable() is not supported during
> > > runtime services, firmware
> > >   should cache variable names and values in EfiRuntimeServicesData
> > > memory so
> > >   that GetVariable() and GetNextVeriableName() can behave as specified.
> > >
> > > +Firmware Update
> > > +---
> > > +
> > > +Being able to update firmware to address security issues is a key
> > > feature of secure platforms.
> > > +EBBR platforms are required to implement either an in-band or an
> > > out-of-band firmware update mechanism.
> > > +
> > > +If firmware update is performed in-band (firmware on the
> > > application processor updates itself),
> > > +then the firmware shall implement EFI_UPDATE_CAPSULE and accept
> > > updates in the
> > > +"Firmware Management Protocol Data Capsule Structure" format as
> > > described in [UEFI]_ § 23.3,
> > > +"Delivering Capsules Containing Updates to Firmware Management
> > > Protocol.  [#FMPNote]_
> > > +Firmware is also required to provide an EFI System Resource Table
> > > (ESRT). [UEFI]_ § 23.4
> > > +Every firmware image that is updated in-band must be described in
> > > the ESRT.
> > > +
> > > +If firmware update is performed out-of-band (e.g., by an
> > > independent Board Management Controller,
> > > +or firmware is provided by a hypervisor), then the platform is not
> > > required to implement EFI_UPDATE_CAPSULE.
> > > +
> > > +EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called.
> > > +
> > > +
> > >   .. [#OPTEESupplicant] It is worth noting that OP-TEE has a
> > > similar problem
> > >  regarding secure storage.
> > >  OP-TEE's chosen solution is to rely on an OS supplicant
> > > agent to perform
> > > @@ -445,3 +464,11 @@ that GetVariable() and GetNextVeriableName()
> > > can behave as specified.
> > >  during runtime services.
> > >
> > > https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
> > > +
> > > +.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected
> > > to be suitable
> > > +   for use by generic firmware update services like fwupd and
> > > Windows Update.
> > > +   Both fwupd and Windows Update read the ESRT table to determine
> > > what firmware
> > > +   can be updated, and use an EFI helper application to call
> > > `EFI_UPDATE_CAPSULE`
> > > +   before ExitBootServices() is called.
> > > +
> > > +   https://fwupd.org/
> > >
> >
> ___
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
___
boot-architecture mailing list
boot-architecture@lists.linaro.org

Re: EBBR Biweekly for 18 Jan 2021

[Dong Wei]

In the old Itanium days, I created a PCDP table that also includes GUI console 
https://coral.googlesource.com/linux-imx/+/refs/tags/4-2/drivers/firmware/pcdp.h
 for non-Windows OSes.

Unfortunately, it did not get widely accepted, Linux on x86 still prefers to 
adopt Microsoft standards .

From: Ard Biesheuvel 
Date: Tuesday, January 19, 2021 at 12:30 AM
To: Dong Wei 
Cc: François Ozog , Grant Likely 
, Jeff Booher-Kaeding , 
Samer El-Haj-Mahmoud , mbrug...@suse.com 
, Jose Marinho , s...@google.com 
, bill.mi...@linaro.org , 
boot-architecture@lists.linaro.org , Reed 
Hinkel , takahiro.aka...@linaro.org 
, daniel.thomp...@linaro.org 
, Mark Brown , 
ati...@atishpatra.org , joakim.b...@linaro.org 
, d...@suse.de 
Subject: Re: EBBR Biweekly for 18 Jan 2021
On Tue, 19 Jan 2021 at 05:54, Dong Wei  wrote:
>
> There is also the SPCR table 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table?redirectedfrom=MSDN
> This is the primary serial console
>

One of the issues we still have not fixed in Linux is the
inconsistency in interpretation of what 'serial console' actually
means.

On Windows, the serial console is a low-level admin interface that may
be exposed in addition to the full blown graphical user interface,
which is always available. The SPCR describes how this admin interface
is exposed, but does not affect what happens on the GUI.

In Linux, the console *is* the primary interface, either graphical or
serial. Currently, the mere presence of a SPCR is taken as an
indication that only the serial console should be enabled; for this
reason, the UEFI ports we have for platforms with PCIe expansion carry
a driver that removes the SPCR again if UEFI detects the presence of a
graphical interface.

Unfortunately, this is not something we can easily change without
breaking existing systems. Note that annotating device objects in the
DSDT is probably not the right approach here, given that this requires
the AML interpreter to be up and running before we can decide where
the console lives.

As Heinrich points out, we have a similar problem today when it comes
to the graphical interface on DT systems, i.e., it is not clear how to
convey that the user expects the interaction with the system to occur
via the graphical UI and not via a serial port. For a bootloader such
as u-boot, it should be fairly easy to suppress the stdout-path if
u-boot itself is running on the graphical display, but it would be
better to communicate the presence of this GUI *in addition to* a
serial port serving as a console.
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: EBBR Biweekly for 18 Jan 2021

[Dong Wei]

There is also the SPCR table 
https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table?redirectedfrom=MSDN
This is the primary serial console

From: boot-architecture  on behalf 
of François Ozog 
Date: Monday, January 18, 2021 at 2:43 PM
To: Grant Likely 
Cc: Jeff Booher-Kaeding , Samer El-Haj-Mahmoud 
, mbrug...@suse.com , Jose 
Marinho , s...@google.com , 
bill.mi...@linaro.org , 
boot-architecture@lists.linaro.org , 
takahiro.aka...@linaro.org , nd , 
Mark Brown , ati...@atishpatra.org , 
joakim.b...@linaro.org , daniel.thomp...@linaro.org 
, d...@suse.de , Reed Hinkel 

Subject: Re: EBBR Biweekly for 18 Jan 2021
Hi

During the call you mentioned that SBBR had some defined values for console.

I can only find that the _HID="ARMH0011" identifies a SBSA com port but I
don't find any standard object path that would point to the UART to use.

let's assume:

   Device (COM0)
{
Name (_HID, "ARMH0011")  // _HID: Hardware ID
Name (_UID, Zero)  // _UID: Unique ID
Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource
Settings
{
Memory32Fixed (ReadWrite,
0x0900, // Address Base
0x1000, // Address Length
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,
,, )
{
0x0021,
}
})
Name (_ADR, 0x0900)  // _ADR: Address
}

   Device (COM1)
{
Name (_HID, "ARMH0011")  // _HID: Hardware ID
Name (_UID, One)  // _UID: Unique ID
Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource
Settings
{
Memory32Fixed (ReadWrite,
0x09002000, // Address Base
0x1000, // Address Length
)
Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,
,, )
{
0x0022,
}
})
Name (_ADR, 0x09002000)  // _ADR: Address
}

Which port to use as a console?

by definition we could say that \_SB_.COM0 is the port to use.
Or we could define \_SB_.SOUT as a reference object to any of the defined
UARTs.

Cheers

FF

On Mon, 18 Jan 2021 at 16:32, Grant Likely  wrote:

>
>
> On 17/01/2021 15:01, François Ozog wrote:
> > Hi Grant
> >
> > I’d like EBBR to specify  a solution to identify the default serial
> > console out of existing optional indications.
>
> Hi Francois,
>
> This is a good topic. EBBR starts from the assumption that whether ACPI
> or DT is used for the system description, the data will follow the
> requirements of the technology. For ACPI I don't think we need to add
> any language, but it would be worthwhile to require stdout-path is
> specified in the DT. Do you want to propose some language?
>
> > On DT systems , we shall state that /chosen/stdout-path must point to a
> > valid path.
> >
> > On ACPI, we may get the info form \_SB_.COM0 @ DSDT or specify we will
> > get the info from SPCR table. >
> > Regardless of the method , this is required to just boot and do not have
> > to care about clumsy command lines with early_console or console
> parameters.
>
> Agree. Mucking with the commandline should not be required.
>
>
> > I like this topic be added to the agenda ?
>
> yes. Can you also add an issue to track this topic please?
>
> g.
>
> > Le sam. 16 janv. 2021 à 13:59, Grant Likely  > > a écrit :
> >
> > Hi all,
> >
> > Next EBBR meeting is ON for Monday, 18 Jan 2021 at 16:00 GMT. I think
> > there is quite a backlog of items to discuss. Here's what I've got
> for
> > the agenda so far:
> >
> > * Update on specific required protocols
> > * https://github.com/ARM-software/ebbr/issues/60
> > 
> > * https://github.com/ARM-software/ebbr/issues/61
> > 
> > * https://github.com/ARM-software/ebbr/issues/64
> > 
> > * Firmware update requirements
> > * https://github.com/ARM-software/ebbr/issues/69
> > 
> > * DT fixup protocol proposal
> > * https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
> > 
> > * https://github.com/ARM-software/ebbr/issues/68
> > 
> > * Other business
> >
> > If you would like to discuss anything else, please reply to this
> email.
> >
> > Dial in details are here:
> >
> > ---
> >
> > Grant Likely is inviting you to a scheduled Zoom meeting.
> >
> >
> >
> > Topic: EBBR Biweekly
> >
> > Time: 18 Jan 2021, 

Re: [Arm.ebbr-discuss] Linaro blog post on 'the boot problem'

[Dong Wei]

Thanks much David!

Sent from my iPhone 

> On Sep 13, 2018, at 11:26 PM, David Rusling  wrote:
> 
> See here for a shoutout to EBBR and U-Boot...
> 
> David
> -- 
> David A Rusling
> CTO, Linaro
> https://linaro.org
> ___
> Arm.ebbr-discuss mailing list
> arm.ebbr-disc...@arm.com
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

[Dong Wei]

Agree, that's what we will do.

- DW
-
-Original Message-
From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of Graeme Gregory
Sent: Thursday, July 12, 2018 8:37 AM
To: udit.ku...@nxp.com
Cc: nd ; boot-architecture@lists.linaro.org; Mark Brown 
; arm.ebbr-discuss 
Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not 
working at runtime

On Thu, 12 Jul 2018 at 16:30, Udit Kumar  wrote:
>
> Hi Mark
>
> > -Original Message-
> > From: Mark Brown [mailto:broo...@kernel.org]
> > Sent: Thursday, July 12, 2018 8:20 PM
> > To: Udit Kumar 
> > Cc: Ard Biesheuvel ; Architecture Mailman
> > List ; nd ;
> > arm.ebbr-discuss 
> > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for
> > SetVariable() not working at runtime
> >
> > On Thu, Jul 12, 2018 at 02:19:49PM +, Udit Kumar wrote:
> >
> > > > > Do any existing implementations change variables from
> > > > > non-volatile to volatile?
> >
> > > > The UEFI spec is explicit about which variables are volatile and which 
> > > > are not.
> > > > Simply relaxing non-volatile to volatile in the general case
> > > > doesn't seem like a useful approach to me.
> >
> > > I believe at boot-time, UEFI specs will be followed for volatile
> > > and non-volatile
> > variables.
> > > Having this in statement EBBR, will help those platform, which
> > > cannot expose
> > non-volatile variables at runtime.
> >
> > If nothing currently does it the chances that anything will actually
> > cope well seem minimal.  Like Daniel said it seems more likely to
> > break things - if the variables are defined as being non-volatile
> > then the OS is unlikely to be checking at runtime if that's the case
> > or not unless it's explicitly written to work with EBBR.  If an
> > error is generated because a non-volatile variable can't be set then
> > that should at least fall into whatever error handling code is there to 
> > cover normal rutime failures which has some chance of doing something 
> > sensible.
>
> Right,
> There will be some breaks or say diversion from UEFI specs.
> If we need to follow UEFI specs 'Table 10. Global Variables' on such
> platform where we cannot write to NV storage at runtime, then in
> either case 1/ passing OS as no-efi-runtime or 2/ Returning errors/not
> saving to NV storage is violation of UEFI spec.
>
> Which divergence is acceptable ?
>
Neither, fix the specs with proper updates to support your use-case.

Or fix your platform to obey the specs you have chosen.

Don't write a spec to bend another spec that way leads to chaos.

Graeme
___
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: [RFC] uefi: Account for SetVariable() not working at runtime

[Dong Wei]

Grant,

I think the variables are defined by the specs as either non-volatile or 
volatile. It should not be changing.

- DW
-
-Original Message-
From: Grant Likely
Sent: Thursday, July 12, 2018 3:41 AM
To: boot-architecture@lists.linaro.org; arm.ebbr-discuss 

Cc: nd ; Grant Likely ; Dong Wei 
; Alexander Graf ; Peter Robinson 

Subject: [RFC] uefi: Account for SetVariable() not working at runtime

Add details on what to do if the platform is unable to set persistent variables 
in runtime services. The idea here is that the GetVariable() and SetVariable() 
APIs should continue to work, and the OS can obtain all the variable settings, 
but if it cannot be written then the NON_VOLATILE attribute is cleared so the 
OS knows that persistence is not available.

Cc: Dong Wei 
Cc: Alexander Graf 
Cc: Peter Robinson 
Signed-off-by: Grant Likely 
---

Alex/Peter: Does this approach work for you? I tried to come up with something 
that is faithful to the spec, gives the OS information that non-volatile 
variables aren't available, but still have the ability to query the boot 
environment.

Dong: Is this an appropriate way to use {Get,Set}Variable()?

Cheers,
g.

---
 source/chapter2-uefi.rst | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 
7b6843e..57594bc 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -197,13 +197,13 @@ command:
Operating Systems calls to reset the system will go via Runtime Services
and not directly to PSCI.

-Set Variable
-
-
-Non-volatile UEFI variables must persist across reset, and emulated variables 
-in RAM are not permitted.
-The UEFI Runtime Services must be able to update the variables directly 
without -the aid of the Operating System.
+Runtime Variable Access
+---

-.. note:: This normally requires dedicated storage for UEFI variables that is
-   not directly accessible from the Operating System.
+Non-volatile UEFI variables must persist across reset.
+If the platform is incapable of updating non-volatile variables from
+Runtime Services then it must clear the EFI_VARIABLE_NON_VOLATILE
+attribute from all non-volatile variables when ExitBootServices() is called.
+Similarly, if non-volatile variables cannot be set from Runtime
+Services, then
+SetVariable() must return EFI_INVALID_PARAMETER if the
+EFI_VARIABLE_NON_VOLATILE attribute is set.
--
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: [Arm.ebbr-discuss] EBBR v0.6-pre1 Released

[Dong Wei]

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.

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

[Dong Wei]

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.

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. Also, each SoC 
vendor would need to make request to the UEFI Forum to get their vendor 
subdirectories under /Firmware as well.



- 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: EBBR presentations at LInaro Connect and ELC-E

[Dong Wei]

Grant and I already submitted a session request at Linaro Connect. Should be 
able to get it. Also submitted one for Arm TechCon, but I may not be able to 
attend.


  *   DW

From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of Mills, William
Sent: Wednesday, July 4, 2018 11:24 AM
To: arm.ebbr-discuss 
Cc: Architecture Mailman List 
Subject: [Arm.ebbr-discuss] EBBR presentations at LInaro Connect and ELC-E

All,

We really should be doing presentations at Linaro Connect and ELC-E.
I can volunteer to help present at ELC-E but I think it would looks better if a 
small group was represented.

For Connect, I won’t volunteer to present.  I tried that last time and with my 
required schedule at connect it just does not work out.

The ELC-E CFP closed Monday.  Perhaps we can sweet talk an extension?  Grant, 
you might have the best chance.

Thanks,
Bill

---
William A. Mills
Chief Technologist, Open Source
Texas Instruments, Processors
20450 Century Blvd
Germantown MD, 20874
(work/mobile) +1-240-643-0836

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: UEFI requirements section

[Dong Wei]

Appendix A leveraged from SBBR 1.0, an older version that did not consider UEFI 
2.7. The idea behind UEFI spec section 2.6 is to lay out the baseline 
requirements and then it is up to the system design guide to figure out any 
additional interfaces to require. EBBR can be considered as one of the system 
design guides and it is specifically meant for the embedded space. So the first 
question is whether the baseline requirements can all be met by this embedded 
space (are there any that need to be made optional), and what other interfaces 
that are optional in the UEFI spec that may need to be made required.

Anyways I fully expect that we adapt that Appendix to this embedded space.

- DW
-
-Original Message-
From: Grant Likely
Sent: Friday, July 6, 2018 5:57 AM
To: Dong Wei ; boot-architecture@lists.linaro.org; 
arm.ebbr-discuss 
Subject: UEFI requirements section

Dong,

Looking at the current state of EBBR, Appendix A contains a big list of 
boot/runtime services and protocols that are required to be implemented.
However, I don't think this list has been audited, and I'm not sure how much of 
it is actually needed. Some of these things (like the list of boot/runtime 
services) seem to be required by the UEFI spec, so it is redundant to list them 
here.

I'm also unsure on the list of protocols. Some I'm sure are already required by 
the UEFI spec. e.g., UEFI section 2.6.1 requires EFI_LOADED_IMAGE_PROTOCOL, 
EFI_LOADED_IMAGE_DEVICE_PATH, EFI_DEVICE_PATH_PROTOCOL, 
EFI_DECOMPRESS_PROTOCOL, and EFI_DEVICE_PATH_UTILITIES_PROTOCOL, so is it 
necessary to list them in EBBR?

Looking at the current U-Boot implementation, only the following protocols are 
implemented:

include/efi_api.h|277| #define LOADED_IMAGE_PROTOCOL_GUID \ 
include/efi_api.h|519| #define EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID \ 
include/efi_api.h|590| #define EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID \ 
include/efi_api.h|603| #define EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID \ 
include/efi_api.h|619| #define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \ 
include/efi_api.h|853| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ 
include/efi_api.h|882| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ 
include/efi_api.h|933| #define EFI_DRIVER_BINDING_PROTOCOL_GUID \

Presumably Grub and the kernel only use the above protocols, and they are 
sufficient to handle perform the distro installer use case. Yet it is not 
compliant with UEFI 2.7. Notably missing are:

UEFI § 2.6.1
- EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL
- EFI_DEVICE_PATH_PROTOCOL
- EFI_DECOMPRESS_PROTOCOL
UEFI § 2.6.2
- EFI_SIMPLE_TEXT_EX_PROTOCOL
- EFI_BLOCK_IO_PROTOCOL
- EFI_DISK_IO_PROTOCOL
- EFI_UNICODE_COLLATION_PROTOCOL
- EFI_SERIAL_IO_PROTOCOL
- EFI_USB2_HC_PROTOCOL
- EFI_USB_IO_PROTOCOL

In fact, perhaps what EBBR needs is a list of exceptions to the UEFI §
2.6 requirements (expected to reduce over time as the U-Boot implementation 
matures). Thoughts?

For discussion, I've pasted the text of the current UEFI appendix below to make 
it easy to comment on the mailing list.

g.

---

.. _appendix-uefi-requirements:

#
APPENDIX A - UEFI Implementation Requirements 
#

Required Boot Services
**

== ==
ServiceUEFI §
== ==
EFI_RAISE_TPL  7.1
EFI_RESTORE_TPL7.1
EFI_ALLOCATE_PAGES 7.2
EFI_FREE_PAGES 7.2
EFI_GET_MEMORY_MAP 7.2
EFI_ALLOCATE_POOL  7.2
EFI_FREE_POOL  7.2
EFI_CREATE_EVENT   7.1
EFI_SET_TIMER  7.1
EFI_WAIT_FOR_EVENT 7.1
EFI_SIGNAL_EVENT   7.1
EFI_CLOSE_EVENT7.1
EFI_INSTALL_PROTOCOL_INTERFACE 7.3
EFI_REINSTALL_PROTOCOL_INTERFACE   7.3
EFI_UNINSTALL_PROTOCOL_INTERFACE   7.3
EFI_HANDLE_PROTOCOL7.3
EFI_REGISTER_PROTOCOL_NOTIFY   7.3
EFI_LOCATE_HANDLE  7.3
EFI_LOCATE_PROTOCOL7.3
EFI_LOCATE_DEVICE_PATH 7.3
EFI_INSTALL_CONFIGURATION_TABLE7.3
EFI_IMAGE_LOAD 7.4
EFI_IMAGE_START7.4
EFI_EXIT   7.4
EFI_IMAGE_UNLOAD   7.4
EFI_EXIT_BOOT_SERVICES 7.4
EFI_GET_NEXT_MONOTONIC_COUNT   7.5
EFI_STALL  7.5
EFI_SET_WATCHDOG_TIMER 7.5
EFI_CONNECT_CONTROLLER 7.3
EFI_DISCONNECT_CONTROLLER  7.3
EFI_OPEN_PROTOCOL  7.3
EFI_CLOSE_PROTOCOL 7.3

RE: [Arm.ebbr-discuss] [PATCH] Introduction: add a manifesto

[Dong Wei]

Very nice Grant. At some point we should make this into a blog or whitepaper. 
It is important to explain the rational behind any specification effort, I am 
glad to see EBBR taken a step in that direction.

- DW
-
-Original Message-
From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of Grant Likely
Sent: Friday, July 6, 2018 9:26 AM
To: boot-architecture@lists.linaro.org; arm.ebbr-discuss 

Cc: nd 
Subject: [Arm.ebbr-discuss] [PATCH] Introduction: add a manifesto

Give some rationale behind EBBR so the reader understands what problem the 
specification is intended to solve.

Signed-off-by: Bill Mills 
[glikely: made it more verbose to make the intent clear]
Signed-off-by: Grant Likely 
---
 source/chapter1-about.rst | 94 +++
 1 file changed, 94 insertions(+)

diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 
b667f1b..cb675d9 100644
--- a/source/chapter1-about.rst
+++ b/source/chapter1-about.rst
@@ -23,6 +23,100 @@ 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
+==
+
+EBBR as a specification defines requirements on platforms and operating
+systems, but requirements alone don't provide insight into why the
+specification is written the way it is, or what problems it is intended to 
solve.
+Using the assumption that better understanding of the thought process
+behind EBBR will result in better implementations, this section is a
+discussion of the goals and guiding principle that shaped EBBR.
+
+This section should be considered commentary, and not a formal part of the 
specification.
+
+EBBR was written as a response to the lack of boot sequence standardization in 
the embedded system ecosystem.
+As embedded systems are becoming more sophisticated and connected, it
+is becoming increasingly important for embedded systems to run standard
+OS distributions and software stacks, or to have consistent behaviour
+across a large deployment of heterogeneous platforms.
+However, the lack of consistency between platforms often requires
+per-platform customization to get an OS image to boot on multiple platforms.
+
+A large part of this ecosystem is based on U-Boot and Linux.
+Vendors have heavy investments in both projects and are not interested
+in large scale changes to their firmware architecture.
+The challenge for EBBR is to define a set of boot standards that reduce
+the 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).
+
+However, EBBR is a specification, not an implementation.
+The goal of EBBR is not to mandate U-Boot and Linux.
+Rather, it is to mandate interfaces that can be implemented by any
+firmware or OS project, while at the same time work with both
+Tianocore/EDK2 and U-Boot to 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.
+   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.
+
+The following guiding principals of the EBBR specification and its
+process:
+
+- Be agnostic about ACPI and Devicetree.
+
+  EBBR explicitly does not require a specific system description language.
+  Both Devicetree and ACPI are supported.
+  While ACPI provides more standardization, Devicetree is preferred in
+ may embedded  platforms for its flexibility.
+  The Linux kernel supports both equally well, and so EBBR doesn't
+ require one  over the other.
+  However, it does require the system description to be provided by the
+ platform, and that it conform to the relevant ACPI or DT specifications.
+
+- Focus on the UEFI interface, not a specific codebase
+
+  EBBR does not require a specific firmware implementation.
+  Any firmware project can implement these interfaces.
+  Neither U-Boot nor Tianocore/EDK2 are required.
+
+- Design to be implementable and useful today
+
+  The drafting process for EBBR worked closely with U-Boot and
+ Tianocore  developers to ensure that current upstream code will meet the 
requirements.
+
+- Design to be OS independent
+
+  This document uses Linux as an example but other OS's are expected.
+
+- Support multiple architectures
+
+  Any architecture can implement the EBBR requirements.
+
+  .. note::
+ At the time of writing this document only addresses AArch64, but AArch32 
and others architectures are expected.
+
+- Design for common 

RE: [Arm.ebbr-discuss] Questions about GPT

[Dong Wei]

Correct

- DW
-
-Original Message-
From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of Daniel Thompson
Sent: Tuesday, July 3, 2018 8:59 AM
To: Grant Likely 
Cc: boot-architecture@lists.linaro.org; h...@suse.de; arm.ebbr-discuss 
; Nicolas Dechesne ; 
architect...@cam-list1.cambridge.arm.com
Subject: Re: [Arm.ebbr-discuss] Questions about GPT

On Tue, Jul 03, 2018 at 04:46:38PM +0100, Grant Likely wrote:
> On 03/07/2018 10:08, Nicolas Dechesne wrote:
> > On Mon, Jul 2, 2018 at 11:59 PM Alexander Graf  wrote:
> > > On 02.07.18 20:40, William Mills wrote:
> [...]
> > > > I am still trying to figure out if a real issue exists or will
> > > > soon exist.  If this issue is real, I think it should be
> > > > addressed in UEFI but if not there then in EBBR.  We move
> > > > "disks" around a lot more than other people do.
> > >
> > > Yes, let's double check with Hannes :).
> >
> > On Dragonboard 820c, that has on board UFS disk:
> >
> > Found valid GPT with protective MBR; using GPT.
> > Disk /dev/sda: 6335488 sectors, 24.2 GiB
> > Model: THGBF7G8K4LBATRB
> > Sector size (logical/physical): 4096/4096 bytes
> >
>
> Hmmm. That's interesting. I had assumed that on UFS devices, device
> partitions would be used and the GPT would be omitted. Evidently that
> is not done on the 810c.

I might be missing something but can EFI run on top of raw hardware device 
partitions? I didn't think EFI provided any means to locate an ESP except when 
they are described in one of the three supported ways (GPT, MBR or El Torito).


Daniel.


> Is that just because sticking with GPT is the
> 'known-working-solution'? Will there eventually be a time when OSes
> use UFS-native partitioning? Or should the recommendation be to keep doing 
> GPT partitioning on the whole device?
>
> I'm assuming that UFS-native partitioning allows for better management
> of the underlying flash media, but I'm no expert.
>
> How do UFS partitions show up in Linux right now?
> Do we have good partitioning tools for UFS?
> Will UFS partitioning cause issues for the distros?

>
> g.
> ___
> Arm.ebbr-discuss mailing list
> arm.ebbr-disc...@arm.com
___
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 - Fog, Edge and Device

[Dong Wei]

Agree

- DW
-
-Original Message-
From: Olof Johansson 
Sent: Tuesday, June 12, 2018 10:58 AM
To: Dong Wei 
Cc: David Rusling ; wmi...@ti.com; 
boot-architecture@lists.linaro.org; arm.ebbr-discuss 
Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device

On Tue, Jun 12, 2018 at 10:16 AM, Dong Wei  wrote:
> There may be a need for making EBBR more aware to the community.
>
> I ran into a case at Computex last week. Ambedded makes storage servers using 
> Marvell SoCs. Even though Marvell provides UEFI code for the SoC, Ambedded 
> chose to do the uboot anyways.

I think a relevant distinction here is that if someone wants to still do 
u-boot, they should strongly consider using a version new enough to implement 
EBBR interfaces such as UEFI services. On price-sensitive devices where you 
want to optimize flash BOM cost, skipping Tianocore
*can* have cost impact, but if the interfaces are kept compatible that should 
be just fine.

As always, if the SoC vendor provides a reference implementation for their 
platforms such that doing the right thing is also doing the easiest thing when 
making a derivative product design, everybody wins.


-Olof
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 - Fog, Edge and Device

[Dong Wei]

There may be a need for making EBBR more aware to the community.

I ran into a case at Computex last week. Ambedded makes storage servers using 
Marvell SoCs. Even though Marvell provides UEFI code for the SoC, Ambedded 
chose to do the uboot anyways.


  *   DW

From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of David Rusling
Sent: Tuesday, June 12, 2018 1:25 AM
To: wmi...@ti.com
Cc: boot-architecture@lists.linaro.org; arm.ebbr-discuss 

Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device

Bill
On Mon, 11 Jun 2018 at 21:01 William Mills 
mailto:wmi...@ti.com>> wrote:

> I think it's likely useful to fog/edge but not critical, it will
> depend a lot on the size of the device. In the arm space it'll be
> either EBBR or SBBR/SBSA, either way standardisation will be good.
>
>
> Well, people misuse the term 'gateway' wildly from tiny bridge devices
> to grown up things.  It will be uneven, but the push will come.  Weaker
> than the data center.
>
>

Sure some of these devices will be so server like they should follow the
whole SBBR/SBSA.  But there will be others that need something lighter.
That is where the EBBR should come in.  We are trying to make sure it
scales down to even $7 boards.

Agreed.  So long as the devices are 'tethered' to a gateway, they can use 
whatever methods they want.  We're a long way from standardising all IoT 
devices so that they can be managed everywhere by anything.

I do think the EBBR is important for this Fog/Edge eco-system but I do
not think it will be obvious to everyone that they should pay attention.

Exactly why I'm covering 'The Boot Problem' @ the member's meeting in Paris 
next month.

The competition for EBBR will be the status quo.  Many people see no
need to make their HW run multiple OSes.  They believe that their custom
tweaked OS is the only thing that need ever run.

True

The same thing is true in the network switch world but the existance of
the ONIE project suggests that that world has seen the value of multiple
installable OSes.

I think that the SoC guys want it that way, they want to sell silicon into 
multiple places.  The device manufacturers care less.

A robust container eco-system actually decreases the need for EBBR
because all the real need for portability is hidden in the containers.
A given HW platform just needs the base container host and everything is
good.

Yes, containers help automate the payload, but they don't reduce the need for a 
sane set of firmware 'blobs' that interact safely and securely and are OTA 
updateable.

Luckily there is such a diversity for container hosts systems, the need
for EBBR re-emerges so the HW vendor does not need to lock into just one.

Cut down / embedded Kubernetes works for me


> > [2] EBBR et al is complex, so moving down the reference platform
> route makes
> > sense (to me at least).  I know that reference platforms created a
> lot of
> > debate in Linaro in LEG, but I think that has settled down now, with
> > everyone understanding what they are and are not and where the
> value is.
> >

I don't know if I agree with the complex part.  We are trying to make it
easy for HW vendors: Use latest upstream U-boot configured this way and
your done.  Want to add features? Add these things to your HW.

However for the U-boot/EDK/OS authors we do want a test platform and to
show it done well.

As already discussed some in the EBBR calls, QEMU should be "the
reference platform".  We can configure QEMU to be a very HW resource
rich system, a very HW resource constrained system, or any thing in between.

Agreed.

We hope and expect that multiple boards will then buy into this system
and be able to show it working.  But that is really up to each board's
owners / landing team whatever. These are not "reference platforms" but
examples of EBBR in the wild.  The more the merrier; no one is picking
just one real HW platform.

Good strategy but we need to have the reference Platforms discussion again...

David

Bill
--
David A Rusling
CTO, Linaro
https://linaro.org
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 - Fog, Edge and Device

[Dong Wei]

EBBR is a separate document from SBBR, and it is open in the git repository. We 
have no plan for an EBSA. We may include some small hardware requirements in 
EBBR if needed, but at this time no plan for EBSA.


  *   DW

From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of David Rusling
Sent: Monday, June 11, 2018 4:53 AM
To: Peter Robinson 
Cc: boot-architecture@lists.linaro.org; arm.ebbr-discuss 

Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device

All,
  thanks.  I'm pulling together a set of slides for the Linaro members meeting 
in July plus I'm looking to ensure that the sessions / meetings around this at 
YVR18 are correct.

  For EBBR, are you all planning equivalent documents to SBBR (that is, EBSA, 
etc or are you planning to broaden those documents to include embedded)?

David
On Tue, 22 May 2018 at 12:12 David Rusling 
mailto:david.rusl...@linaro.org>> wrote:
On Tue, 22 May 2018 at 11:52 Peter Robinson 
mailto:pbrobin...@gmail.com>> wrote:
On Tue, May 22, 2018 at 11:40 AM, David Rusling
mailto:david.rusl...@linaro.org>> wrote:
> All,
>   I'm writing a blog on Linaro's reorganisation (sounds fascinating doesn't
> it?).   I'm more talking about directions than teams etc, it's not a list of
> groups / SIGs etc.  One area I'd like to highlight is the importance of EBBR
> to LEDGE (aka Fog and Networking).  Some thoughts / questions:
>
> [1] do others believe that EBBR is key to Fog / Edge?  I'm less convinced
> that Device land will see the push (their is a symbiotic link between
> gateways and devices, with gateways being the 'point of security' for their
> 'slave' devices).

I think it's likely useful to fog/edge but not critical, it will
depend a lot on the size of the device. In the arm space it'll be
either EBBR or SBBR/SBSA, either way standardisation will be good.

Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown 
up things.  It will be uneven, but the push will come.  Weaker than the data 
center.

> [2] EBBR et al is complex, so moving down the reference platform route makes
> sense (to me at least).  I know that reference platforms created a lot of
> debate in Linaro in LEG, but I think that has settled down now, with
> everyone understanding what they are and are not and where the value is.
>
> [3] I presume the best way to reference EBBR is via the git repository.  Any
> other information I should reference (email lists etc)?

Yes, I would reference the githib pages [1], we should add things like
details of the mailing list into the README/wiki there so there's one
spot to reference for everything.

[1] https://github.com/ARM-software/ebbr

Yes, that's the hub for everything...

David

--
David A Rusling
CTO, Linaro
https://linaro.org
--
David A Rusling
CTO, Linaro
https://linaro.org
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] [PATCH] Add chapter for privileged/secure firmware

[Dong Wei]

Yes, I am referring to the upcoming SBBR v1.1 content. We changed the reference 
to PSCI back to 1.0 because that version is what we need for the MP support, 
1.1 is also fine but not the minimal requirement.

- DW
-
-Original Message-
From: Grant Likely
Sent: Friday, May 18, 2018 12:47 PM
To: Dong Wei <dong@arm.com>
Cc: boot-architecture@lists.linaro.org; nd <n...@arm.com>; arm.ebbr-discuss 
<arm.ebbr-disc...@arm.com>
Subject: Re: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure 
firmware

Hi Dong,

Thanks for the comments. Replies below...

On 18/05/2018 19:01, Dong Wei wrote:
> This part has been changed in the SBBR spec as we do expect server SoC to 
> support EL3 so we removed the non-PSCI mechanism. Also the PSCI Spec 
> reference is 1.0:

Can you double check that please? The copy on developer.arm.com is issue C 
(psci 1.0), but there is a more recent copy on infocenter; issue D for PSCI 1.1.

>
> UEFI is defined as a uniprocessor specification that only uses a single CPU 
> core for booting.
> Platforms providing EL3 must implement the Power State Coordination Interface 
> (PSCI) [5]. This interface will be as the main method to boot secondary 
> cores, implementing CPU idling, and providing reset and shutdown runtime 
> services.
>
> ... some ACPI related requirements...
>
> All secondary cores remain powered down during boot. After boot, OSPM can 
> call CPU_ON() into the PSCI firmware to power up a chosen core. The PSCI 
> firmware powers up, initializes the core, and starts execution at the 
> provided address.

That helps. Perhaps I'll drop the MP Boot language entirely and leave it at 
PSCI as the preferred, but Linux spin tables as a fallback, and only for DT 
systems.

g.

>
> - DW
> -
> -Original Message-
> From: arm.ebbr-discuss-boun...@arm.com
> <arm.ebbr-discuss-boun...@arm.com> On Behalf Of Grant Likely
> Sent: Friday, May 18, 2018 6:06 AM
> Cc: boot-architecture@lists.linaro.org; nd <n...@arm.com>;
> arm.ebbr-discuss <arm.ebbr-disc...@arm.com>
> Subject: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure
> firmware
>
> Document the requirements for secure firmware to implement PSCI, particularly 
> in regard to multiprocessor CPU startup protocol. PSCI is by far the 
> preferred solution, but make allowance for the other existing methods.
>
> Signed-off-by: Grant Likely <grant.lik...@arm.com>
> ---
>   source/ebbr.rst | 25 +
>   1 file changed, 25 insertions(+)
>
> diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9
> 100644
> --- a/source/ebbr.rst
> +++ b/source/ebbr.rst
> @@ -309,6 +309,25 @@ the aid of the Operating System.
>   .. note:: This normally requires dedicated storage for UEFI variables that 
> is
>  not directly accessible from the Operating System.
>
> +**
> +Priviledged or Secure Firmware
> +**
> +
> +Multiprocessor Startup Protocol
> +===
> +Firmware resident in Trustzone EL3 must implement and conform to the
> +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
> +
> +However, the MP Startup and Spintable protocols are strongly discouraged.
> +Future versions of this specification will only allow PSCI, and PSCI
> +should be implemented in all new designs.
> +
>   
>   APPENDIX A - Required UEFI Boot Services
>   
> @@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL  16.2
>   .. [DTSPEC] `Devicetree specification v0.2
>  
> <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2>`_,
>  `Devicetree.org <https://devicetree.org>`_
> +.. [LINUXA64BOOT] `Linux Documentation/arm64/booting.txt
> +   
> <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/arm64/booting.txt>`_,
> +   Linux kernel
> +.. [MPSTART] `MP Startup for Arm
> +   
> <https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.doc>`_,
> +   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_Coordination_Interface_PDD_v1_1_DEN0022D.pdf>`_,
>  21 April 2017, `Arm Limited <http://arm.

RE: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware

[Dong Wei]

This part has been changed in the SBBR spec as we do expect server SoC to 
support EL3 so we removed the non-PSCI mechanism. Also the PSCI Spec reference 
is 1.0:

UEFI is defined as a uniprocessor specification that only uses a single CPU 
core for booting.
Platforms providing EL3 must implement the Power State Coordination Interface 
(PSCI) [5]. This interface will be as the main method to boot secondary cores, 
implementing CPU idling, and providing reset and shutdown runtime services.

... some ACPI related requirements...

All secondary cores remain powered down during boot. After boot, OSPM can call 
CPU_ON() into the PSCI firmware to power up a chosen core. The PSCI firmware 
powers up, initializes the core, and starts execution at the provided address.

- DW
-
-Original Message-
From: arm.ebbr-discuss-boun...@arm.com  On 
Behalf Of Grant Likely
Sent: Friday, May 18, 2018 6:06 AM
Cc: boot-architecture@lists.linaro.org; nd ; arm.ebbr-discuss 

Subject: [Arm.ebbr-discuss] [PATCH] Add chapter for privileged/secure firmware

Document the requirements for secure firmware to implement PSCI, particularly 
in regard to multiprocessor CPU startup protocol. PSCI is by far the preferred 
solution, but make allowance for the other existing methods.

Signed-off-by: Grant Likely 
---
 source/ebbr.rst | 25 +
 1 file changed, 25 insertions(+)

diff --git a/source/ebbr.rst b/source/ebbr.rst index 700feba..59af3c9 100644
--- a/source/ebbr.rst
+++ b/source/ebbr.rst
@@ -309,6 +309,25 @@ the aid of the Operating System.
 .. note:: This normally requires dedicated storage for UEFI variables that is
not directly accessible from the Operating System.

+**
+Priviledged or Secure Firmware
+**
+
+Multiprocessor Startup Protocol
+===
+Firmware resident in Trustzone EL3 must implement and conform to the
+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
+
+However, the MP Startup and Spintable protocols are strongly discouraged.
+Future versions of this specification will only allow PSCI, and PSCI
+should be implemented in all new designs.
+
 
 APPENDIX A - Required UEFI Boot Services
 
@@ -542,6 +561,12 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL  16.2
 .. [DTSPEC] `Devicetree specification v0.2

`_,
`Devicetree.org `_
+.. [LINUXA64BOOT] `Linux Documentation/arm64/booting.txt
+   
`_,
+   Linux kernel
+.. [MPSTART] `MP Startup for Arm
+   
`_,
+   20 December 2012, `Microsoft `_
 .. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1)

`_,
21 April 2017, `Arm Limited `_
--
2.13.0

___
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