ivasakthivel Nainar
> ; Samer El-Haj-Mahmoud mahm...@arm.com>; nd
> Subject: RE: [TF-A] [RFC] Proposed location to host the firmware handoff
> specification.
>
> Hi Julius
>
> > -Original Message-
> > From: Julius Werner
> > Sent: 06 December 202
Hi Julius
> -Original Message-
> From: Julius Werner
> Sent: 06 December 2022 04:18
>
> It seems like some of us still have very different opinions about how this
> handoff structure should and shouldn't be used, which I really think need to
> be worked out and then codified in the spec
It seems like some of us still have very different opinions about how
this handoff structure should and shouldn't be used, which I really
think need to be worked out and then codified in the spec before we
can call the document final, because otherwise no firmware project can
trust that it is safe
ose Marinho ; t...@lists.trustedfirmware.org;
> > u-boot@lists.denx.de; boot-architect...@lists.linaro.org; Manish Pandey2
> > ; Joanna Farley ;
> > Ilias Apalodimas ; Matteo Carlini
> > ; Dan Handley ; Rob
> > Herring ; Harb Abdulhamid
> > (h...@amperecomputing.
; boot-architect...@lists.linaro.org; Manish Pandey2
> ; Joanna Farley ;
> Ilias Apalodimas ; Matteo Carlini
> ; Dan Handley ; Rob
> Herring ; Harb Abdulhamid
> (h...@amperecomputing.com) ;
> Sivasakthivel Nainar ; Samer El-Haj-
> Mahmoud ; nd
> Subject: Re: [TF-A] [RFC] P
Hi,
On Wed, 30 Nov 2022 at 16:48, Julius Werner wrote:
>
> Okay, FWIW I created a pull request with my suggestions here:
> https://github.com/FirmwareHandoff/firmware_handoff/pull/4
>
> That should make it easier to discuss specific details, hopefully. As
> I was looking at the header size and fo
Okay, FWIW I created a pull request with my suggestions here:
https://github.com/FirmwareHandoff/firmware_handoff/pull/4
That should make it easier to discuss specific details, hopefully. As
I was looking at the header size and format more closely I noticed
that the checksum calculation and some d
Hi,
On Wed, 30 Nov 2022 at 14:52, Julius Werner wrote:
>
> Hi Jose,
>
> Apologies for the late response, I had to find some time to dig back
> into this topic first.
>
> > The proposal is that the tag assignments are handled via a PR to [1].
> > A PR should provide reasoning for the proposed entr
Hi Jose,
Apologies for the late response, I had to find some time to dig back
into this topic first.
> The proposal is that the tag assignments are handled via a PR to [1].
> A PR should provide reasoning for the proposed entry layout as well as a
> description of the use-case being serviced.
>
Hi Julius,
Thank you for the comments!
As mentioned yesterday, the FW Handoff document is now publicly accessible from
[1] -- note that this does not constitute a full document release.
Hopefully we'll be able to use that repo to agree on the open items before we
do an initial full release of t
> That draft is the DEN0135 document [2].
> I realise that I haven’t made it sufficiently explicit in this thread that
> the DEN0135 document [2] is still at draft quality (see ALP maturity called
> out in the title page and footers).
> Please do not consider this a finished document 😊. We’ve bee
Hi Julius,
Thanks for reviewing the draft proposal, and for your comments.
Last year’s discussion concluded with the agreement that, as a next step, we
would draft a proposal of the data structure [1].
That draft is the DEN0135 document [2].
I realise that I haven’t made it sufficiently explici
Hi Jose,
Can you provide a bit more background on where this proposal suddenly
came from and what considerations went into its design? The mailing
list discussion from last year sort of petered out without much
concrete agreement, and now you're here with a full specification.
It's hard to provide
13 matches
Mail list logo
