Hi all,
Normally this isn't the right place for job postings, but in this case it is directly relevant to EBBR and Arm's SystemReady program. Arm is looking to backfill my position with someone who can be responsible for the SystemReady IR program long term direction. If an of you are interested, or can think of someone who would be a good candidate, then please pass this link on to them.
Thanks,
g.
https://experienced-arm.icims.com/jobs/5461/director---technical-lead/job?m…
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.
Hi everyone,
It has been many weeks since the last EBBR biweekly, so even though I don’t have much of an agenda, I will hold the call today in a little under an hour. If we don’t have enough to fill an hour then it can just be a short call.
Dial in details are below
Agenda:
- EBBR maintainership
- Restricting console on secure boot
- other business
—-
Join Zoom Meeting
Date: 14 Mar 2022
Time: 15:00 GMT
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511<tel:8136%205511> Password: 490324
One tap mobile+14086380968<tel:+14086380968>,,92081365511#,,#,490324# US (San Jose) +16465189805<tel:+16465189805>,,92081365511#,,#,490324# US (New York)
—-
Grant Likely
Senior Technical Director, Arm
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.
All,
We will have the Devicetree call today.
As normal it is at 15 UTC / 10 AM US Eastern.
(One hour from when I send this.)
Today we have several topics:
* a specific reserved memory use for OP-TEE
* a general discussion of memory and the spec.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi all,
I’m cancelling this weeks EBBR biweekly as I wasn’t able to send out a reminder and agenda last week. Next meeting is 14th March 2022.
As always, email me if you have a topic for the agenda.
g.
—-
Grant Likely
Senior Technical Director, Arm
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.
Oliver,
On 2/22/22 7:36 AM, Olivier Masse wrote:
> Hi All,
>
> Could we postpone to the next call ?
>
Yes we can discuss on March 7.
However I think you need to define what you want to discuss.
First of, there is nothing in your suggested DTS that tells Linux (or
other OS) that it should not map the memory area. It looks to me as
you should include the "no-map" property in your node.
How will the Linux video/graphics drivers refer to this node? I presume
by phandle, right?
Are you setting any suggested naming convention for the node name (after
you fix the node name to include @address)?
You are defining a compatible string in the node. The current
suggestion is not in the spec. It could be "optee,sdp" if you get optee
stakeholders to agree. What should be the definition of "optee,sdp".
I presume it means secure data path but that could mean a ton of things.
Will sdp always mean DRM protected media playback or could it include more?
Thanks,
Bill
> BR / Olivier
>
> On mar., 2022-02-15 at 13:46 -0600, Rob Herring wrote:
>> Caution: EXT Email
>>
>> On Fri, Feb 11, 2022 at 8:21 AM Bill Mills <bill.mills(a)linaro.org>
>> wrote:
>>>
>>> Rob,
>>>
>>> Can you confirm for the DT call on Feb 21?
>>
>> I'm on holiday on the 21st.
>>
>>>
>>> Oliver,
>>>
>>> On 2/11/22 4:54 AM, Olivier Masse wrote:
>>>> Hi Bill,
>>>>
>>>> NXP had a discussion with Linaro about this optee os issue:
>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
>>>>
>>>> Which is implemented by this first draft here:
>>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
>>>>
>>>> Could we be part of the next Device Tree call to discuss about
>>>> adding
>>>> a reserved memory in optee os embedded DT ?
>>>>
>>>
>>> Thanks for bringing it up.
>>> I have skimmed the PR threads and the discussion seems to be:
>>> 1) OP-TEE internal issues
>>> 2) DT standards questions and issues
>>>
>>> For the DT call we need to focus on #2 above.
>>> We will definitely need Rob for this discussion so we need to do it
>>> when
>>> he can join. (If we don't resolve the question in this email
>>> thread
>>> before then.)
>>>
>>> Context for all:
>>>
>>> SDP here is related to DRM protected playback of media streams.
>>>
>>> Jens comment in PR:
>>> > So far we have managed to avoid defining our own bindings in OP-
>>> TEE,
>>> > instead we've been able to reuse already established bindings.
>>> With
>>> > this you're proposing something new. I'm not sure of the best
>>> way of
>>> > doing such a thing. Are we sure there is nothing to reuse?
>>> > If not: How should it be reviewed? Who should review it?
>>>
>>> DTS in PR:
>>> /*
>>> * Copyright (c) 2021, NXP. All rights reserved.
>>> *
>>> * SPDX-License-Identifier: BSD-3-Clause
>>> */
>>>
>>> /dts-v1/;
>>>
>>> / {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> reserved-memory {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>>
>>> sdp_mem {
>>> compatible = "optee-sdp";
>>> reg = <0x3E800000 0x00400000>;
>>> };
>>> };
>>> };
>>>
>>> However it was modified after that.
>>>
>>> Oliver: please reply to this thread (on list please) with the final
>>> DTS
>>> you are proposing. fix DT conventions and what are you doing with
>>> the
>>> no-map property if anything.
>>>
>>> Is the memory above meant to be visible to NS world AND S
>>> world? Or is
>>> just for secure world.
>>>
>>> Thanks,
>>> Bill
>>>
>>>> Best regards,
>>>> Olivier Masse
>>>
>>> --
>>> Bill Mills
>>> Principal Technical Consultant, Linaro
>>> +1-240-643-0836
>>> TZ: US Eastern
>>> Work Schedule: Tues/Wed/Thur
>>> _______________________________________________
>>> boot-architecture mailing list --
>>> boot-architecture(a)lists.linaro.org
>>> To unsubscribe send an email to
>>> boot-architecture-leave(a)lists.linaro.org
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
There will be no DT meeting tomorrow Monday Feb 21.
It is a holiday in the US and others have declined as well.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Rob,
Can you confirm for the DT call on Feb 21?
Oliver,
On 2/11/22 4:54 AM, Olivier Masse wrote:
> Hi Bill,
>
> NXP had a discussion with Linaro about this optee os issue:
> https://github.com/OP-TEE/optee_os/issues/5133
>
> Which is implemented by this first draft here:
> https://github.com/OP-TEE/optee_os/pull/5149
>
> Could we be part of the next Device Tree call to discuss about adding
> a reserved memory in optee os embedded DT ?
>
Thanks for bringing it up.
I have skimmed the PR threads and the discussion seems to be:
1) OP-TEE internal issues
2) DT standards questions and issues
For the DT call we need to focus on #2 above.
We will definitely need Rob for this discussion so we need to do it when
he can join. (If we don't resolve the question in this email thread
before then.)
Context for all:
SDP here is related to DRM protected playback of media streams.
Jens comment in PR:
> So far we have managed to avoid defining our own bindings in OP-TEE,
> instead we've been able to reuse already established bindings. With
> this you're proposing something new. I'm not sure of the best way of
> doing such a thing. Are we sure there is nothing to reuse?
> If not: How should it be reviewed? Who should review it?
DTS in PR:
/*
* Copyright (c) 2021, NXP. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <0>;
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
sdp_mem {
compatible = "optee-sdp";
reg = <0x3E800000 0x00400000>;
};
};
};
However it was modified after that.
Oliver: please reply to this thread (on list please) with the final DTS
you are proposing. fix DT conventions and what are you doing with the
no-map property if anything.
Is the memory above meant to be visible to NS world AND S world? Or is
just for secure world.
Thanks,
Bill
> Best regards,
> Olivier Masse
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
I have no agenda for tomorrow's DT call. Does anyone want to bring up
something?
If I have not heard anything by noon UTC tomorrow (3 hours before the
meeting) I will cancel the call.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi everyone,
Just a reminder that the EBBR biweekly is on today at 15:00 GMT. I've
got the following agenda items:
- Disable U-Boot console for secure boot (Ilias)
- SystemReady IR 2.0 draft requirements
- Any other business
Here are the conference details:
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 490324
One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346
248 7799 US (Houston)
Hi all,
Just a quick note that the EBBR meeting scheduled for today is indeed
on. Ilias and Jose will be presenting the work done on A/B updates which
should be interesting to the EBBR audience.
Here's the agenda and dial in details:
Agenda:
- A/B Update Presentation (Ilias & Jose)
- Requirement to disable or remove command line when secure (Ilias)
Zoom details:
17th Jan 2022, 15:00 GMT
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 490324
One tap mobile +14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
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.
Just a reminder, the EBBR biweekly is on today (about 15 minutes from
now). I try to send these reminders out the week before, but it fell off
my radar last week. Here is what I have on the agenda for today:
Agenda
* Requirements on A/B update (Ilias)
* Can the OS be responsible for firmware update? (Ilias) - e.g., via
fwupd or similar to stage UpdateCapsule()
* Requirement to disable or remove command line when secure (Ilias)
---
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Password: 490324
One tap mobile
+14086380968,,92081365511#,,#,490324# US (San Jose)
+16465189805,,92081365511#,,#,490324# US (New York)
Dial by your location
+1 408 638 0968 US (San Jose)
+1 646 518 9805 US (New York)
+1 346 248 7799 US (Houston)
Meeting ID: 920 8136 5511
Password: 490324
Find your local number: https://armltd.zoom.us/u/adYiWaDyys
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.
Hi everyone,
This is just a reminder that the next EBBR biweekly is today at 15:00
GMT. Zoom details are below, and here is today's agenda:
Agenda:
- UEFI EBBR Conformance profile (Jose)
https://bugzilla.tianocore.org/show_bug.cgi?id=3591
- Requirements for measured boot (Ilias)
- Any other business
I'm also keeping track of agenda items on the EBBR wiki which you can
find here:
https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511 Password: 490324
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.
All,
Sorry but I have to cancel the call for tomorrow.
See you in two weeks.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi all,
EBBR Biweekly meetings will resume next week on Monday at 15:00GMT. This
is a new time to line up with the same slot as the Devicetree Evolution
meeting being run by Linaro. Details for joining are below, and can also
be found on the EBBR wiki.
https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
Here is the agenda so far:
- Update on Arm's SystemReady IR program
- Issue review
- Plans for next iteration of EBBR
- List of potential new requirements
- Other business
As always please email me if you want to add items to the agenda.
---
Topic: EBBR Biweekly
Time: This is a recurring meeting Meet anytime
Join Zoom Meeting
https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
Meeting ID: 920 8136 5511
Passcode: 490324
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.
All,
We have our normal DTE call today at the new time of 15 UK.
HOWEVER, the UK has come off daylight savings time while the US and
others have not.
This means that in the US it looks like the old time.
11 AM Eastern
10 AM Central
9 AM Mountain
8 AM Pacific
This is a single week issue that occurs once in the fall and in the once
spring.
It _should_ appear correct on you calendar.
We said we would discuss devicetree lifecycle at the source level.
We will use the second half of the slides from last time:
https://fileserver.linaro.org/s/FqT2JcTxCWStTNY
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
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.ozog(a)linaro.org | Skype: ffozog
Hi Tom
Le lun. 25 oct. 2021 à 18:59, Tom Rini <trini(a)konsulko.com> 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 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
> > > > > >
> > > > > > 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."
> > > >
> > > > The GNU GPLv2 "mere aggregation" language must also be mentioned when
> > > > looking at the license effects here.
> > > >
> > > > If TF-A and u-boot were merely aggregated together on the same
> storage
> > > > media then the license of one would not influence the licensing of
> > > > the other.
> > > >
> > > > I am doubtful that one component being responsible for copying the
> other
> > > > into memory would change this.
> > >
> > > Think of U-Boot's UEFI variables managed by an OP-TEE module
> (Standalone
> > > MM), or U-Boot (or Linux) invoking PSCI. These are not cases of mere
> > > aggregation but come close to the operating system case. But TF-A is
> not an
> > > operating system.
> >
> > This is very much an example of "each case turns on its own facts".
> >
> > PSCI is a generic protocol. It is based on traps. Its primary purpose is
> > to decouple components that run at different trust levels. TF-A is not
> > the only implementation. U-boot is not the only client.
> >
> > Such facts make it unlikely that TF-A would become a derived work of
> > u-boot simply because u-boot gets PSCI services from TF-A.
> >
> > To be clear I agree there are definitely circumstances that could lead
> > an OP-TEE TA, OP-TEE itself or TF-A being combined with u-boot (rather
> > than aggregated alongside). A OP-TEE TA to assist with variable storage
> > could certainly reach this level, especially if it's interfaces were
> > specifically designed to match the u-boot driver model (although this
> > still may not impact TF-A).
>
> So, this might be an unpopular opinion here, but perhaps the Canonical
> or Linaro lawyers could chime in with some non-binding thoughts?
> Engineers arguing about the law tends to not be productive.
i agree. From my standpoint, there are products on the market that assemble
firmware components such as TF-A , U-Boot and OP-TEE in various ways : so
lawyers have done their job and it is possible.
My question is: can we further characterize the distributed firmware with
regards to parameters described in the checklist?
If there are binary components in the mix, how much a platform owner (in
the checklist sense) can rebuild the open source portion, include the
binaries and redistribute the result?
>
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
All,
We have our DT evo call today one hour earlier than normal.
2 PM UTC / 3PM UK / 10 AM US East (NY)
(in 48 min as I write this.)
Today we will talk about DTB life cycle in firmware at run time.
We might get an update from Simon of DTB signatures.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Yep I see your info. Thanks for the bug report :)
-- Bill
On 10/5/21 12:02 PM, Simon Glass wrote:
> OK that worked, I think.
>
> - Simon
>
> On Mon, 4 Oct 2021 at 19:19, Bill Mills <bill.mills(a)linaro.org> wrote:
>>
>> Sorry wrong link.
>> Please try this one:
>> https://doodle.com/meeting/participate/id/mepQEZNa
>>
>> On 10/4/21 6:19 PM, Bill Mills wrote:
>>> All,
>>>
>>> If you normally attend the Devicetree evolution call,
>>> Please fill out this poll:
>>> https://doodle.com/meeting/organize/id/mepQEZNa
>>>
>>> Thanks,
>>> Bill
>>>
>>> --
>>> Bill Mills
>>> Principal Technical Consultant, Linaro
>>> +1-240-643-0836
>>> TZ: US Eastern
>>> Work Schedule: Tues/Wed/Thur
>>
>> --
>> Bill Mills
>> Principal Technical Consultant, Linaro
>> +1-240-643-0836
>> TZ: US Eastern
>> Work Schedule: Tues/Wed/Thur
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
If you normally attend the Devicetree evolution call,
Please fill out this poll:
https://doodle.com/meeting/organize/id/mepQEZNa
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
I have recordings and automated transcripts of all the meetings in 2021.
So far I have not made these public.
*** Is there any objection to making them public? ***
I don't imagine many people will go back and look but it is sometimes
nice to know that you could.
Please let me know if you have any concern. I will take no action until
next week.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
Today we discussed Simon's slides [1] about DTB signatures.
Simmons points (as I understand them)
* U-boot has used signatures in FIT format for years
* The technique used for FIT is actually generic to any DTB
* Such a signed DTB could still be passed to kernel
* even an old one like 4.4
* Suggest we adopt this for signing individual DTBs
Discussion:
* General interest in idea, no strong objections
* multiple people want to see the worked example to know for sure
* Which nodes do we want to sign?
* Should we sign in a way that allows the kernel to recheck
the signature?
* would require we exclude from hashing anything that will get fixed
up by u-boot at run time, such as mac addrs and chosen
* If u-boot applies any non-trivial DTBO's, the kernel won't be able
to check the result, is it worth the effort for the simple case?
* If we really want the kernel to verify, we should pass on a set of
dtbs: a base and set of overlays, one overlay would be the fixup
data. kernel could check each dtb and then verify that fixup data
only touches the stuff that it should
* Joakim worked with a student to do things very similar to what Simon
is talking about. see [2]
Other comments:
* verifying 10 rsa signatures on 10 hashes is more expensive than
verifying 1 rsa signature of 10 strong hashes. (RSA signatures on the
actual data itself would be VERY expensive.)
* We should be careful about boot time in all these discussions.
* If all the DTB data is internal to u-boot, just use FIT and have
one signature for all the various hashes.
* Is it OK to use the "exploded" rsa public key data in all cases?
* Is the exploded for faster or just less code?
* Can we supply the plan/std pub key AND the exploded version?
* implementations that care about speed and code size can use the
exploded ver, while things that need to standard key structure
can use that. We would need a offline tool to verify both.
* UEFI secure boot will have public keys installed.
Can we explode the key on install for internal storage?
Actions:
* Simon to work up an example of signing just one dtb
We also introduced the topics of DT lifecycle at firmware level:
A) Source level lifecycle, keeping things in sync
A1) Golden source repo
A2: Golden source for platforms that opt-in
A3) auto checker but manual fixup
A4) remove DT from sub projects and rely on B2 model
Pretty sure this is a NOPE!
A5) do nothing and trust platforms maintainers to do the right
thing (despite evidence that many are not currently).
B) runtime life-cycle
B1) each component has its own DTB
B2) DTB is only present in "first" firmware and is
passed along from there
B3) mixture of B1 & B2 at different firmware stages
Actions:
* Bill to make slides so we can discuss properly on Oct 18.
[1]
https://drive.google.com/file/d/1PA5aQ2rISOrdNbqElfIWXaSrCG28Rqx4/view?usp=…
[2]
https://github.com/marianomarciello/Device_Tree_Verification/tree/e0b2fc989…
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hello,
We have our DT evo call in just a bit.
Today I would like to talk about DT lifecycle and flow "with in" firmware.
Up till this point we have focused on firmware to "OS layer" hand off.
That topic is not done but I think we need to start exploring the flow
within firmware as people seem to have very different views.
We need to figure out what models are valid (2 seems plenty) and how we
can talk about them.
I don't have slides today but we can start the discussion.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
Following the EFI capsule revert, here* is a contribution to
understand the context in which we designed the patch set. (everyone
is a commenter, please be mindful).
The presentation explores booting, with more details for the Arm
context, pre and post U-Boot. On Arm, pre-U-Boot is shaped after
Firmware Framework-A and other interfaces. There is a similar approach
in RISC-V with OpenSBI.
There is nothing to agree on: many elements of the presentation are
specifications for the Arm ecosystem. The purpose is to reach common
understanding of those for rest of the journey.
Careful reading is required because as we all know very well the
topic, we may skip over stuff and miss key elements that may have
changed since you last checked. So I'll attract your attention on:
Slide 9: there can be multiple device trees in a Trusted Firmware FIP
(nothing to agree on...)
Slide 11: roles and responsibilities of firmware go far beyond booting
and OTA. CoreBoot and SPL will have to take those into account in the
future.
Slide 17: there is a new boot flow based on "give-me-my-initrd" UEFI protocol
Slide 24: when the firmware is stored on Secure Storage which is a
common case for products, U-Boot/Linux have absolutely no means to
perform the update (see notes for details).
Slide 28: there are plenty of keys needed, the U-Boot and U-Boot
updater can be different; as well as all firmware components.
I acknowledge that the presentation is hard to read without enough
speaker notes or myself talking to it. Let's say that I prefer to keep
the ball rolling before we can actually program a call: could you send
me in private message your preferred day of the week and best time
(with TZ) for such a thing?
Cordially,
--
François-Frédéric Ozog
*) https://docs.google.com/presentation/d/1AHTf9xMNqPXbiDLkBpoKt45UTjV8s34Jdtm…
