Re: Re: Firmware Partition Filesystem query

On Fri, Jul 19, 2024 at 07:51:26PM +, Ghennadi Procopciuc wrote: > > Yes, ideally this is what EBBR recommends as the second-best option (the > > best > > option being to use a dedicated storage). > > Ok, I thought that the ideal case is when all firmware images are stored on a > dedicated sto

Re: OS provided DT proposal

On Tue, May 07, 2024 at 08:17:02PM +0200, Francesco Dolcini wrote: > On Mon, May 06, 2024 at 05:05:25PM -0600, Tom Rini wrote: > > On Mon, May 06, 2024 at 01:13:00PM +0200, Francesco Dolcini wrote: > > > On Wed, May 01, 2024 at 09:18:01PM +, Humphreys, Jonathan wrote: > > > > Problem statement:

Re: OS provided DT proposal

On Wed, May 01, 2024 at 09:18:01PM +, Humphreys, Jonathan wrote: > The firmware would pass the device tree filename/id to the OS loader, instead > of > the DTB itself. The OS loader would determine the location of the matching > DTBs > based on the chosen OS to boot, load the matching DTB fro

Re: [PATCH 00/21] Qualcomm generic board support

On Tue, Dec 05, 2023 at 10:36:28AM +, ff wrote: > > Le 5 déc. 2023 à 10:46, Sumit Garg a écrit : > > > > + U-boot custodians list > > > >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > >> wrote: > >> > >> On 05/12/2023 08:13, Sumit Garg wrote: > > @DT bindings maintainers, > > >

Re: [PATCH 00/21] Qualcomm generic board support

On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > > wrote: > > > >

Re: Further clarifications

On Mon, Nov 13, 2023 at 05:07:43PM -0600, Jon Humphreys wrote: > Daniel Thompson writes: > > On Mon, Nov 13, 2023 at 11:18:04AM -0600, Jon Humphreys wrote: > >> - why is EBBR dictating the location of firmwares? The firmware > >> locations are a contract with the boo

Re: Further clarifications

On Mon, Nov 13, 2023 at 11:18:04AM -0600, Jon Humphreys wrote: > Hi all. I've organized some of my requests for clarification below. I > appreciate you helping me understand the spec. Where the spec needs > clarification itself, I'll create a ticket to track. > > Basic (dumb) questions: > --

Re: Clarification on firmware location on removable storage

On Mon, Oct 23, 2023 at 02:44:45PM +0200, Heinrich Schuchardt wrote: > On 23.10.23 13:30, Daniel Thompson wrote: > > On Fri, Oct 20, 2023 at 09:10:45AM -0500, Jon Humphreys wrote: > > > Heinrich Schuchardt writes: > > > > I personally would prefer firmware using

Re: Clarification on firmware location on removable storage

On Fri, Oct 20, 2023 at 09:10:45AM -0500, Jon Humphreys wrote: > Heinrich Schuchardt writes: > > I personally would prefer firmware using the firmware folder in the ESP > > over using a firmware partition because the partitioning scheme would > > not be firmware specific. > > I argue the opposite

Re: Recommendation for identifying partition with firmware to be loaded from SD-card

On Mon, May 01, 2023 at 04:26:25PM +0200, Heinrich Schuchardt wrote: > > > Often firmware is separated into multiple parts due to firmware > restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file). > > Here the same considerations apply. Using a partition type GUID to > identify further

Re: SystemReady and OCP Checklist

On Tue, Oct 26, 2021 at 08:21:22AM +0200, François Ozog wrote: > Hi Tom > > > Le lun. 25 oct. 2021 à 18:59, Tom Rini a écrit : > > > On Mon, Oct 25, 2021 at 05:41:44PM +0100, Daniel Thompson wrote: > > > On Mon, Oct 25, 2021 at 03:59:49PM +0200, Heinrich Schucha

Re: SystemReady and OCP Checklist

On Mon, Oct 25, 2021 at 03:59:49PM +0200, Heinrich Schuchardt wrote: > On 10/25/21 15:32, Daniel Thompson wrote: > > On Mon, Oct 25, 2021 at 01:51:34PM +0200, Heinrich Schuchardt wrote: > > > On 10/25/21 12:43, François Ozog wrote: > > > > Hi > > > >

Re: SystemReady and OCP Checklist

On Mon, Oct 25, 2021 at 01:51:34PM +0200, Heinrich Schuchardt wrote: > 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 commu

Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote: > Hi Paul > > Too posting because I think we also need to address this at a higher level. > > i think we discussed this topic quite a while back. I may be wrong but it > may be Bill Mills who proposed to have an eeprom on the extensio

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

On Fri, Jul 09, 2021 at 09:05:09AM +0200, François Ozog wrote: > Le ven. 9 juil. 2021 à 03:09, Julius Werner a écrit : > > > > Of course every project would like not to change... > > > > > > For TF-A I wonder whether it will/should in fact use devicetree if there > > is a lot of complex data? TBD

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

On Tue, Jun 22, 2021 at 12:35:17PM +0200, Matthias Brugger wrote: > > > On 21/06/2021 22:55, Grant Likely wrote: > > > > > > On 21/06/2021 21:53, Grant Likely wrote: > > [...] > > > >> I've pushed my edited copy out to a temporary branch. You can see it here: > >> > >> https://github.com/ARM-s

Re: [PATCH v4] Add RISC-V support content to the EBBR specification

On Mon, Jun 21, 2021 at 03:35:02PM -0700, Atish Patra wrote: > On Mon, Jun 21, 2021 at 1:53 PM Grant Likely wrote: > > > > > > > > On 21/06/2021 18:35, Atish Patra wrote: > > > On Mon, Jun 21, 2021 at 10:19 AM Grant Likely > > > wrote: > > >> > > >> > > >> > > >> On 10/05/2021 18:37, Atish Patra

Re: [PATCH] Override UEFI section 2.6 requirements

On Wed, Feb 03, 2021 at 04:01:27PM +, Grant Likely wrote: > On 03/02/2021 15:17, Ilias Apalodimas wrote: > > On Wed, Feb 03, 2021 at 03:53:09PM +0100, Fran�ois Ozog wrote: > > > > > > > > > > Sure, but we're not talking about U-Boot, we're talking about EBBR the > > > > > standard and U-Boot

Re: [PATCH v2 2/2] Add RISC-V support content to the EBBR specification

On Wed, Oct 21, 2020 at 11:20:17AM +0100, Grant Likely wrote: > > + HS Mode > > + Hypervisor-extended-supervisor mode which virtualizes the supervisor > > mode. > > + > > + U Mode > > + User mode where userspace application is expected to run. > > + > > + HSM > > + Hart State

Re: [PATCH v2 2/2] Add RISC-V support content to the EBBR specification

On Fri, Oct 16, 2020 at 12:33:07PM -0700, Atish Patra wrote: > On Fri, Oct 16, 2020 at 4:29 AM Daniel Thompson > wrote: > > On Thu, Oct 15, 2020 at 06:10:32PM -0700, Atish Patra wrote: > > > + M Mode > > > + Machine mode is the most secure and privileged mode

Re: [PATCH v2 2/2] Add RISC-V support content to the EBBR specification

On Thu, Oct 15, 2020 at 06:10:32PM -0700, Atish Patra wrote: > This patch adds all minimum mandatory requirements to make RISC-V compatible > with EBBR. > > Signed-off-by: Atish Patra > --- > source/chapter1-about.rst | 42 +++-- > source/chapter2-uefi.rst

Re: Specifying the boot flow

On Wed, Oct 07, 2020 at 10:52:30AM -0600, Simon Glass wrote: > Hi Heinrich, > > On Thu, 1 Oct 2020 at 15:15, Heinrich Schuchardt wrote: > > > > Am 1. Oktober 2020 22:27:43 MESZ schrieb Simon Glass : > > >Hi Heinrich, > > > > > >On Mon, 28 Sep 2020 at 12:20, Heinrich Schuchardt > > >wrote: > > >>

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

On Tue, Oct 06, 2020 at 10:00:40AM +0200, François Ozog wrote: > Le mar. 6 oct. 2020 à 09:21, Ard Biesheuvel a écrit : > > > On Tue, 6 Oct 2020 at 06:35, Heinrich Schuchardt > > wrote: > > > > > > Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely < > > grant.lik...@arm.com>: > > > > > > > >

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

On Mon, Oct 05, 2020 at 04:12:11PM +0200, François Ozog wrote: > The driving idea is that there is an existing bootflow, non UEFI that > allows vmlinuz, initrd and DTB to be protected in a single FIT. The > trustworthiness of the solution is higher that regular distro on pure UEFI > systems but doe

Re: [PATCH] Add a reference to RFC 2119

On Mon, Sep 14, 2020 at 02:40:20PM +0100, Daniel Thompson wrote: > Define the meanings of "MUST" and similar language for clarity. > > Fixes: #46 > Signed-off-by: Daniel Thompson Looks like Grant and I both thought "let's just fix this one before the meeting&qu

[PATCH] Add a reference to RFC 2119

Define the meanings of "MUST" and similar language for clarity. Fixes: #46 Signed-off-by: Daniel Thompson --- source/chapter1-about.rst | 4 1 file changed, 4 insertions(+) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 3744d8a14086..3b5339a9c202 10

Re: [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property

On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote: > I've not heard back, and I've got a conflict this afternoon. I'm going > to resched for later in the week. Going to aim for Wednesday. Are you trying the schedule a full EBBR meeting or just a discussion about this thread? Daniel.

Re: [PATCH] Refine firmware shared storage requirements.

On Wed, Sep 02, 2020 at 01:49:40PM +0100, Grant Likely wrote: > > > On 01/09/2020 15:54, Daniel Thompson wrote: > > On Tue, Sep 01, 2020 at 11:59:09AM +0100, Grant Likely wrote: > > > The existing language around how firmware and an OS can share a storage > > >

Re: [PATCH] Refine firmware shared storage requirements.

On Wed, Sep 02, 2020 at 02:26:26PM +0200, Heinrich Schuchardt wrote: > On 02.09.20 12:11, Daniel Thompson wrote: > > On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote: > >> On 01.09.20 16:49, Daniel Thompson wrote: > >>> On Tue, Sep 01, 2020

Re: [EBBR RFC] Remove the exclusive-or language around DT or ACPI

On Tue, Sep 01, 2020 at 02:35:54PM +0300, Ard Biesheuvel wrote: > On Tue, 1 Sep 2020 at 14:26, Peter Robinson wrote: > > On Tue, Sep 1, 2020 at 12:21 PM Grant Likely wrote: > > > On 01/09/2020 12:06, Heinrich Schuchardt wrote: > > > > What would we expect to happen if the ACPI and DT content are

Re: [PATCH] Refine firmware shared storage requirements.

On Tue, Sep 01, 2020 at 04:53:49PM +0200, Heinrich Schuchardt wrote: > On 01.09.20 16:49, Daniel Thompson wrote: > > On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote: > >> On 01.09.20 12:59, Grant Likely wrote: > >>> The existing language around ho

Re: Storage of public key certificates for capsule authentication

On Mon, Aug 31, 2020 at 08:07:08PM +0300, Ard Biesheuvel wrote: > > I'd like to see people's view on who signs what, in the following use case: > > - Car vendor A builds a car with tier1-1 and tier1-2 boards provided by > > silicon1 and silicon2. > > - TF-A, OP-TEE, SCMI-TA, U-Boot are provided by

Re: [PATCH] Refine firmware shared storage requirements.

On Tue, Sep 01, 2020 at 11:59:09AM +0100, Grant Likely wrote: > The existing language around how firmware and an OS can share a storage > device doesn't go into sufficient detail on how the firmware should > protect firmware data on the device. Add language for both the GPT and > MBR partitioning s

Re: [PATCH] Refine firmware shared storage requirements.

On Tue, Sep 01, 2020 at 03:55:15PM +0200, Heinrich Schuchardt wrote: > On 01.09.20 12:59, Grant Likely wrote: > > The existing language around how firmware and an OS can share a storage > > device doesn't go into sufficient detail on how the firmware should > > protect firmware data on the device.

Re: Adding RISC-V to EBBR

On Thu, Aug 20, 2020 at 01:09:03PM -0700, Atish Patra wrote: > On Thu, Aug 20, 2020 at 1:03 PM Heinrich Schuchardt > wrote: > > On 8/20/20 9:32 PM, Atish Patra wrote: > > > On Thu, Aug 20, 2020 at 8:46 AM Grant Likely > > > wrote: > > > > 2. RISC-V related sectio

Re: RFC: EBBR specification update

On Tue, May 26, 2020 at 11:28:32PM +0200, Heinrich Schuchardt wrote: > On 5/26/20 5:24 PM, Daniel Thompson wrote: > > On Tue, May 26, 2020 at 05:02:04PM +0200, François Ozog wrote: > >> Le mar. 26 mai 2020 à 16:38, Grant Likely a écrit : > >>> On 26/05/2020 15:30,

Re: RFC: EBBR specification update

On Tue, May 26, 2020 at 05:02:04PM +0200, François Ozog wrote: > Le mar. 26 mai 2020 à 16:38, Grant Likely a écrit : > > On 26/05/2020 15:30, François Ozog wrote: > > > On Mon, 25 May 2020 at 21:55, Grant Likely > > > wrote: > > [...] > > >MBR partitioning > >

Re: RFC: EBBR specification update

On Wed, May 20, 2020 at 07:00:53PM +0200, François Ozog wrote: > On Wed, 20 May 2020 at 18:39, Daniel Thompson > wrote: > > > On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote: > > > On 11/03/2020 16:42, Daniel Thompson wrote: > > > > On Wed, Mar 11

Re: RFC: EBBR specification update

On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote: > On 11/03/2020 16:42, Daniel Thompson wrote: > > On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote: > > > We have the following cases: > > > > > > - FW compatible with GPT (I me

Re: RFC: EBBR specification update

On Tue, May 19, 2020 at 05:51:41PM +0100, Grant Likely wrote: > On 12/03/2020 04:58, Sumit Garg wrote: > > On Thu, 12 Mar 2020 at 03:11, Francois Ozog > > wrote: > > > > > > Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt a > > > écrit : > >

Re: [DTE] Why device trees are not static

On Wed, May 20, 2020 at 08:59:04AM -0600, Simon Glass wrote: > Hi, > > On Tue, 19 May 2020 at 20:34, Frank Rowand wrote: > > > > Hi Heinrich, > > > > On 5/16/20 8:46 AM, Heinrich Schuchardt wrote: > > > On 5/15/20 7:10 AM, François Ozog wrote: > > > > > >> Would the topic of dynamic parts of

Re: [EBBR PATCH] Add EFI GUID for device tree blob

On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote: > On Thu, 7 May 2020 at 16:50, Daniel Thompson > wrote: > > > On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote: > > > On 06.05.20 17:14, Ard Biesheuvel wrote: > > > > O

Re: [EBBR PATCH] Add EFI GUID for device tree blob

On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote: > On 06.05.20 17:14, Ard Biesheuvel wrote: > > On 5/6/20 5:01 PM, Grant Likely wrote: > >> On 06/05/2020 15:56, Ard Biesheuvel wrote: > >>> On 5/6/20 4:54 PM, Grant Likely wrote: > > > On 06/05/2020 15:52, Ard Biesh

Re: [EBBR PATCH] Add EFI GUID for device tree blob

On Wed, May 06, 2020 at 06:59:54PM +0100, Grant Likely wrote: > On 06/05/2020 17:57, Ard Biesheuvel wrote: > > On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt wrote: > > > > > > On 06.05.20 17:14, Ard Biesheuvel wrote: > > > > On 5/6/20 5:01 PM, Grant Likely wrote: > > ... > > > > > Right, so th

Re: RFC: EBBR specification update

On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote: > On Wed, 11 Mar 2020 at 12:45, Daniel Thompson > wrote: > > > On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote: > > > On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt > > wrote: > &g

Re: RFC: EBBR specification update

On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote: > On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt wrote: > > On 3/11/20 12:04 AM, Heinrich Schuchardt wrote: > > > On 3/10/20 7:37 PM, Francois Ozog wrote: > > >> Le mar. 10 mars 2020 à 18:37, D

Re: RFC: EBBR specification update

On Wed, Mar 11, 2020 at 12:04:45AM +0100, Heinrich Schuchardt wrote: > > > > > The 1MB was to deal with limitations in the boot rom. If the boot rom > > > > > needs extra space, would it not be better to have an initial loader > > > that > > > > > understands partitioning in the 1st 1MB and load th

Re: RFC: EBBR specification update

On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote: > On Tue, 10 Mar 2020 at 18:19, Daniel Thompson > wrote: > > > On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: > > > 0.1 - EBBR goal > > > May be a reassessment on the &quo

Re: RFC: EBBR specification update

On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote: > > > 0.2 - normative text > > > The normative section shall be stated clearly: is " 1.2. Guiding > > > Principles" normative? > > > > > > IETF and ETSI have different language conventions to express > > > absolutely mandated and variou

Re: RFC: EBBR specification update

On Tue, Mar 10, 2020 at 05:02:27PM +0100, Francois Ozog wrote: > Hi, > > Following implementation (or work towards) of EBBR 1.0 + UEFI Secure > boot + UEFI update capsule we learnt a lot. > > Here are some topics that may need some clarification on the EBBR > specs and It looks timely to start wo

Re: EBBR Monthly - 4th Tuesday

There was an e-mail thread about clarifying (non-)requirement of HII that I think was left dangling. Shouldn't need to discuss the technical bits but ensuring we "undangle" it might be good. Daniel. On Tue, 25 Jun 2019 at 14:05, Grant Likely wrote: > Hi All, > > Monthly EBBR meeting is schedul

Re: [RFC]: Kernel lockdown & secureboot

On Wed, 19 Jun 2019 at 15:57, Francois Ozog wrote: > Hi > > I was tasked to come back to Linaro TSC with an answer on Linaro and kernel > lockdown for UEFI SecureBoot, hence the call for feed back. > > So I did some research... The kernel lockdown does not seem to be a full > consensus yet: > htt

Re: [Arm.ebbr-discuss] EBBR v1.0-rc1

Hi Folks Afraid I have to send apologies to today's meeting. No objections from me! Daniel. On Tue, Mar 26, 2019 at 09:10:38AM +, Grant Likely wrote: > Hi all, > > Last week I tagged v1.0-rc1 of EBBR. The release .pdf can be found here: > > https://github.com/ARM-software/ebbr/releases

Re: [Arm.ebbr-discuss] [PATCH v2] Refactor ResetSystem() requirements

On Thu, Oct 18, 2018 at 04:26:34PM +0100, Grant Likely wrote: > On 16/10/2018 17:12, Daniel Thompson wrote: > > On Thu, Oct 11, 2018 at 03:05:33PM +, Grant Likely wrote: > > > ResetSystem() was over-specified in the document. UEFI already documents > > > t

Re: [Arm.ebbr-discuss] [PATCH v2] Refactor ResetSystem() requirements

On Thu, Oct 18, 2018 at 03:53:17AM +, Udit Kumar wrote: > Hi Daniel > > > > +ResetSystem() is required to be implemented in boot services, but it > > > +is optional for runtime services. > > > +During runtime services, the operating system should first attempt to > > > +use ResetSystem() to r

Re: [Arm.ebbr-discuss] [PATCH v2] Refactor ResetSystem() requirements

On Thu, Oct 11, 2018 at 03:05:33PM +, Grant Likely wrote: > ResetSystem() was over-specified in the document. UEFI already documents > the behaviour of ResetSystem() sufficiently. Add notes on expected > behaviour when platform specific or standard interface methods are > available. > > Resolv

Re: [Arm.ebbr-discuss] SMMU included in EBBR spec

On Wed, Oct 03, 2018 at 03:55:45PM +0100, Grant Likely wrote: > On 02/10/2018 14:02, Daniel Thompson wrote: > > On 25/09/2018 10:07, Ilias Apalodimas wrote: > > > Hello, > > > > > > Can we add a discussion in upcoming meetings about the participation &g

Re: [Arm.ebbr-discuss] SMMU included in EBBR spec

On 25/09/2018 10:07, Ilias Apalodimas wrote: Hello, Can we add a discussion in upcoming meetings about the participation of SMMU in the booting procedure? If I were you I'd roll up to one of the Thursday meetings. There's usually time for a bit of any other business. In the past there's b

Re: [Arm.ebbr-discuss] [PATCH 5/7] Refactor ResetSystem() requirements

On Thu, Sep 27, 2018 at 10:53:51AM +, Udit Kumar wrote: > > -Original Message- > > From: Grant Likely > > Sent: Wednesday, September 26, 2018 6:01 PM > > To: Udit Kumar ; boot-architecture@lists.linaro.org; > > arm.ebbr-disc...@arm.com > > Cc: n...@arm.com > > Subject: Re: [Arm.ebbr-di

Re: [Arm.ebbr-discuss] U-boot

On Mon, Jul 30, 2018 at 01:16:08PM +0100, David Rusling wrote: > [4] There's not yet a standard 64 bit aarch64 release of Debian buster > (9). That's terrible progress. I managed to build my own but not > without a lot of faffing about. Is the real problem: a) That there is no AArch64 Debian

Re: [Arm.ebbr-discuss] [PATCH 2/2] Put contribution details front and center in readme

On Thu, Jul 19, 2018 at 12:17:14PM -0500, Grant Likely wrote: > How to participate in this project wasn't very clear. Put information on > how to contribute in a prominent place in the README. > > Suggested-by: David Rusling > Signed-off-by: Grant Likely Reviewed-by: Da

Re: [Arm.ebbr-discuss] [PATCH] Add weekly conference call to CONTRIBUTING

On Thu, Jul 19, 2018 at 12:27:43PM -0500, Grant Likely wrote: > Add the conference call details to the CONTRIBUTING file so it is easy to > find. > > Signed-off-by: Grant Likely > --- > CONTRIBUTING.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/CONTRIBUTING.rst b/CON

Re: [Arm.ebbr-discuss] [PATCH 1/2] Fix link to readable text

> Resolves: #24 > > Signed-off-by: Grant Likely Reviewed-by: Daniel Thompson > --- > README.rst | 11 ++- > 1 file changed, 2 insertions(+), 9 deletions(-) > > diff --git a/README.rst b/README.rst > index f20ddbf..db2aa4a 100644 > --- a/README.rst >

Re: [Arm.ebbr-discuss] EBBR Weekly - Agenda 12 July 2018

On Thu, Jul 12, 2018 at 04:24:59PM +0100, Grant Likely wrote: > Next EBBR meeting is in a few minutes. Here are the agenda items I've got > for today: > > - Issue review > - Set/GetVariable() behaviour when non-volatile doesn't work at runtime > - v0.6 release > - Review distribution list Just re

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

On Thu, Jul 12, 2018 at 11:41:08AM +0100, Grant Likely wrote: > 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 s

Re: [PATCH] Update manifesto from comments on mailing list

On Mon, Jul 09, 2018 at 01:17:56PM +0100, 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 > n

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

On Mon, Jul 09, 2018 at 12:07:18PM +0100, Grant Likely wrote: > On 06/07/2018 18:28, William Mills wrote: > > Grant, > > > > Excellent. Some suggestions in-line: > > > > On 07/06/2018 12:26 PM, Grant Likely wrote: > > > Give some rationale behind EBBR so the reader understands what problem > > >

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

On Fri, Jul 06, 2018 at 01:28:20PM -0400, William Mills wrote: > Grant, > > Excellent. Some suggestions in-line: > > On 07/06/2018 12:26 PM, Grant Likely wrote: > > Give some rationale behind EBBR so the reader understands what problem > > the specification is intended to solve. > > > > Signed-o

Re: [Arm.ebbr-discuss] [PATCH] Introduction: Add a manifesto

On Thu, Jul 05, 2018 at 09:17:59AM -0400, Bill Mills wrote: > Tell people what to expect from EBBR in easy bullet form. > > Signed-off-by: Bill Mills > --- > source/chapter1-about.rst | 40 > 1 file changed, 40 insertions(+) > > diff --git a/source/chapt

Re: [Arm.ebbr-discuss] [PATCH] Add requirements on runtime access to devices

Perhaps insert: the RTC may not be implemented or, I know we acknowledge that the RTC may not be present in the next paragraph but its hard to read the opening paragraph without an early admission that RTC is optional ;-). Other than that: Reviewed-by: Daniel Thompso

Re: [PATCH] Create a new chapter to discuss shared storage

On Thu, Jul 05, 2018 at 11:11:23AM +0100, Grant Likely wrote: > > > +On removable media, firmware should be stored in the ESP under the > > > +``/FIRMWARE`` directory structure as described above. > > > +Platform vendors should support their platform by providing a single > > > +.zip file that plac

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

... you will see most of the LUNs (those that aren't special) being allocated their own block device: https://gist.github.com/daniel-thompson/45275d0667bf93581703ad0dbc867a29 > I've also learned that removable UFS cards exist. If the platform > strictly requires a UFS boot partition o

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 >

Re: [PATCH] Create a new chapter to discuss shared storage

On Fri, Jun 29, 2018 at 06:02:50PM +0100, Grant Likely wrote: > Special care is needed when storage is shared between firmware and the > OS. Add a chapter that discusses the issues and puts down the > requirements for using shared storage. > > Resolves: #19 > > Cc: Daniel T

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

On Mon, Jul 02, 2018 at 02:40:50PM -0400, William Mills wrote: > > Not sure that matters much though: if you want to fix it up you would > > arrange for the fixup logic to be part of your initramfs. > > > > Yes, initramfs would be a good place to fix this. But it means firmware > must deal with

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

On Sun, Jul 01, 2018 at 10:37:49AM -0400, William Mills wrote: > All, > > I rely on your greater knowledge to help me understand these questions. > Thanks in advance. > > 1) GPT and block size > 1A) By querying the device > 1B) Some MBR magic? There's some comments in the fdisk man p

Re: [Arm.ebbr-discuss] [RFC PATCH] Fill out the system firmware discussion

On Sat, Jun 09, 2018 at 10:21:58AM +0200, Alexander Graf wrote: > > + Options: > > + > > + - Require ESP and SFPs to be separate > > + - Should a common SFP GUID be defined so a single image can hold > > firmware > > + for multiple platforms? > > + - Don't have to repartition t

Re: [RFC PATCH] Fill out the system firmware discussion

On Fri, Jun 08, 2018 at 08:57:52PM +0100, Grant Likely wrote: > Add some more detail on how to handle system firmware. I'm still > undecided about this, so this patch is more of an RFC discussion than a > serious patch. Please comment. > > Cc: Daniel Thompson > Sign

[PATCH v2] Describe protective partitioning for platforms using shared storage

Currently EBBR contains nothing describing how systems that share storage media between firmware and OS behave. Add a description of how such as system can be robustly pre-partitioned. Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson --- Notes: v2: * Added patch description

Re: [Arm.ebbr-discuss] Notes on "requiring" separate storage

On Thu, May 31, 2018 at 06:08:09PM -0400, William Mills wrote: > Hello, > > My notes on "requiring" (or strongly recommending) separate storage. > > A couple of times we have gone around the issue of "is it reasonable to > require new platforms have separate storage for firmware". > > Pros: > P1

Re: [Arm.ebbr-discuss] [PATCH] Describe protective partitioning for platforms using shared storage

ned to post a github issue and then spin a v2 without mentioning this. Daniel. > > From: Alexander Graf > Sent: Thursday, May 24, 2018 2:00:54 PM > To: Daniel Thompson > Cc: Grant Likely; boot-architecture@lists.linaro.org; arm.ebbr-discuss >

[PATCH] README: Install dependencies on Fedora

Currently the README does not document how to install sphinx and texlive on Fedora. Fix this. Signed-off-by: Daniel Thompson --- README.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/README.rst b/README.rst index 851c078065a9..9eef58805021 100644 --- a/README.rst +++ b

Re: [Arm.ebbr-discuss] [PATCH 1/2] Add revision history table

[RESEND, I accidentally cut the ML from my reply. Apologies to Grant who will have had to read it twice] On Tue, May 22, 2018 at 05:14:00PM +0100, Grant Likely wrote: > Adds the revision history table to the markup. > > Resolves: #4 > Signed-off-by: Grant Likely > --- > source/ebbr.rst | 13 +++

Re: [Arm.ebbr-discuss] [PATCH] Describe protective partitioning for platforms using shared storage

On Wed, May 23, 2018 at 04:08:52PM +0200, Alexander Graf wrote: > > > > +MBR partitioning > > > > + > > > > + > > > > +Protective partitions should have a partition type of 0xF8 unless some > > > > +immutable feature of the platform makes this impossible. > > > I'd like to be rid of

Re: [Arm.ebbr-discuss] [PATCH] Describe protective partitioning for platforms using shared storage

On Tue, May 22, 2018 at 11:12:26PM +0200, Alexander Graf wrote: > > Am 22.05.2018 um 21:17 schrieb Daniel Thompson : > > > > Fixes: #3 > > Fixed: #8 > > Signed-off-by: Daniel Thompson > > --- > > > > Notes: > >This patch tries to capt

Re: [Arm.ebbr-discuss] [PATCH] Describe protective partitioning for platforms using shared storage

On Tue, May 22, 2018 at 09:31:16PM +0100, Grant Likely wrote: > Hi Daniel, > > Thanks for writing this. Good job. Comments below. > > On 22/05/2018 20:17, Daniel Thompson wrote: > > Fixes: #3 > > Fixed: #8 > > Signed-off-by: Daniel Thompson > > Nit: I

[PATCH] Describe protective partitioning for platforms using shared storage

Fixes: #3 Fixed: #8 Signed-off-by: Daniel Thompson --- Notes: This patch tries to capture contributions from a long a varied discussion. I hope I haven't missed anything major. Thanks to all the contributors to this topic so far! source/ebbr.rst

Re: [Arm.ebbr-discuss] [PATCH] Move Scope into About This Document chapter

On Fri, May 18, 2018 at 05:30:09PM +0100, Grant Likely wrote: > On 18/05/2018 16:39, Daniel Thompson wrote: > > On Fri, May 18, 2018 at 02:06:10PM +0100, Grant Likely wrote: > > > Scope doesn't need it's own chapter. Move it into the 'About This > > >

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

ided > > > +to the OS loader. > > > > I think that's a very pleasing shade, thanks! :) > > > > (Sorry, I spent far too long working on interoperability of some > > particularly poorly specified networking standards so now have > > difficulty reading

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

> methods. > > Signed-off-by: Grant Likely Reviewed-by: Daniel Thompson > --- > 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 >

Re: [Arm.ebbr-discuss] [PATCH] Add a note about reading the draft text

On Fri, May 18, 2018 at 02:06:12PM +0100, Grant Likely wrote: > We don't have a CI generating PDFs yet, but interested parties can go > and read the spec in raw form. Mention that in the README. > > Cc: William Mills > Signed-off-by: Grant Likely Reviewed

Re: [Arm.ebbr-discuss] [PATCH] Move Scope into About This Document chapter

On Fri, May 18, 2018 at 02:06:10PM +0100, Grant Likely wrote: > Scope doesn't need it's own chapter. Move it into the 'About This > Document' chapter. Also expand the text to place this document in > relation to the existing SBBR document. SBBR is the stricter of the two, > so EBBR can be considere

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

On Fri, May 18, 2018 at 02:06:09PM +0100, Grant Likely wrote: > Be specific that an EBBR platform must provide either ACPI or Devicetree > data in the EFI configuration table, but not both. Platforms are allowed > to support both ACPI & DT booting as a configuration option, but only > one interface

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

verything in > +the open. > + > +* boot-architecht...@lists.linaro.org That is not how you spell "architecture" (as I just discovered when I copy 'n pasted from the current README). Once that is fixed: Reviewed-by: Daniel Thompson Daniel. > +* arm.ebbr-disc...@arm.co

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

On Tue, May 08, 2018 at 06:25:11PM +0200, Alexander Graf wrote: > >> On 08.05.18 16:38, Daniel Thompson wrote: > >>> On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote: > >>>> Image is dedicated for one machine type (or closely related set). > >

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

On Tue, May 08, 2018 at 05:43:51PM +0200, Alexander Graf wrote: > > > On 08.05.18 16:38, Daniel Thompson wrote: > > On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote: > >> > >> On 05/04/2018 01:03 PM, Andreas Färber wrote: > >>>

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote: > > On 05/04/2018 01:03 PM, Andreas Färber wrote: > > Am 04.05.2018 um 18:50 schrieb Alexander Graf: > >> On 05/04/2018 06:20 PM, William Mills wrote: > >>> On 05/04/2018 11:45 AM, Alexander Graf wrote: > >>> I am missing something.  I

Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

On Sat, May 05, 2018 at 10:25:06AM +, Udit Kumar wrote: > > > > -Original Message- > > From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss- > > boun...@arm.com] On Behalf Of Leif Lindholm > > Sent: Thursday, May 3, 2018 10:20 PM > > To: Chang, Abner (HPS SW/FW Technologist

Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]

On Thu, May 03, 2018 at 09:02:40AM -0500, Rob Herring wrote: > On Thu, May 3, 2018 at 5:13 AM, Daniel Thompson > wrote: > > On Wed, May 02, 2018 at 05:39:02PM -0400, Tom Rini wrote: > >> On Wed, May 02, 2018 at 05:12:03AM +, Chang, Abner (HPS SW/FW >

Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]

On Wed, May 02, 2018 at 05:39:02PM -0400, Tom Rini wrote: > On Wed, May 02, 2018 at 05:12:03AM +, Chang, Abner (HPS SW/FW > Technologist) wrote: > > > > -Original Message- > > > From: Udit Kumar [mailto:udit.ku...@nxp.com] > > > Sent: Wednesday, May 02, 2018 12:26 PM > > > To: Chang,

  1   2   >