- boot-architecture - lists.linaro.org

RE: [RFC] Proposed location to host the firmware handoff specification.

by Jose Marinho

Hi Varun, The intent is for the proposed location (a new repository hosted in tf.org) to be used to review proposed changes to this spec. The details of the contribution and review process will be debated in the ML once we reach consensus on the hosting location. Regards, Jose > -----Original Message----- > From: Varun Wadekar <vwadekar(a)nvidia.com> > Sent: 06 July 2022 12:58 > To: Jose Marinho <Jose.Marinho(a)arm.com>; Simon Glass > <sjg(a)chromium.org>; Rob Herring <robh(a)kernel.org> > Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot- > architecture(a)lists.linaro.org; François Ozog <francois.ozog(a)linaro.org>; > Manish Pandey2 <Manish.Pandey2(a)arm.com>; Joanna Farley > <Joanna.Farley(a)arm.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>; > Matteo Carlini <Matteo.Carlini(a)arm.com>; Dan Handley > <Dan.Handley(a)arm.com>; Harb Abdulhamid > (harb(a)amperecomputing.com) <harb(a)amperecomputing.com>; Samer El- > Haj-Mahmoud <Samer.El-Haj-Mahmoud(a)arm.com>; nd <nd(a)arm.com> > Subject: RE: [RFC] Proposed location to host the firmware handoff > specification. > > Hi, > > My concern with a standalone gitlab project is that it might be treated as an > experiment by the wider community and be neglected. Do we have any > gitlab projects (tf.org or otherwise) that have some "official" value? > > @Jose, do you see the location getting used for all future spec reviews? If > yes, then the gitlab project will acquire some legitimacy over time and we can > start with it now. But if we see this as a one off, then I would prefer the spec > being hosted on tf.org. > > For the actual mechanics, I prefer reviewing docs and later updates as > fragments instead of looking at the file and a separate changelog. So a > platform (gerrit, gitlab, etc) that facilitates the approach would be helpful > IMO. > > -Varun > > -----Original Message----- > From: Jose Marinho via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: Wednesday, 6 July 2022 11:50 AM > To: Simon Glass <sjg(a)chromium.org>; Rob Herring <robh(a)kernel.org> > Cc: tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; boot- > architecture(a)lists.linaro.org; François Ozog <francois.ozog(a)linaro.org>; > Manish Pandey2 <Manish.Pandey2(a)arm.com>; Joanna Farley > <Joanna.Farley(a)arm.com>; Ilias Apalodimas <ilias.apalodimas(a)linaro.org>; > Matteo Carlini <Matteo.Carlini(a)arm.com>; Dan Handley > <Dan.Handley(a)arm.com>; Harb Abdulhamid > (harb(a)amperecomputing.com) <harb(a)amperecomputing.com>; Samer El- > Haj-Mahmoud <Samer.El-Haj-Mahmoud(a)arm.com>; nd <nd(a)arm.com> > Subject: [TF-A] Re: [RFC] Proposed location to host the firmware handoff > specification. > > External email: Use caution opening links or attachments > > > Hi All, > > > -----Original Message----- > > From: Simon Glass <sjg(a)chromium.org> > > Sent: 06 July 2022 09:34 > > To: Rob Herring <robh(a)kernel.org> > > Cc: Jose Marinho <Jose.Marinho(a)arm.com>; > > tf-a(a)lists.trustedfirmware.org; u-boot(a)lists.denx.de; > > boot-architecture(a)lists.linaro.org; François Ozog > > <francois.ozog(a)linaro.org>; Manish Pandey2 > <Manish.Pandey2(a)arm.com>; > > Joanna Farley <Joanna.Farley(a)arm.com>; Ilias Apalodimas > > <ilias.apalodimas(a)linaro.org>; Matteo Carlini > > <Matteo.Carlini(a)arm.com>; Dan Handley <Dan.Handley(a)arm.com>; Harb > > Abdulhamid > > (harb(a)amperecomputing.com) <harb(a)amperecomputing.com>; Samer > El- > > Haj-Mahmoud <Samer.El-Haj-Mahmoud(a)arm.com>; nd <nd(a)arm.com> > > Subject: Re: [RFC] Proposed location to host the firmware handoff > > specification. > > > > Hi Rob, > > > > On Tue, 5 Jul 2022 at 11:27, Rob Herring <robh(a)kernel.org> wrote: > > > > > > On Tue, Jul 5, 2022 at 10:37 AM Simon Glass <sjg(a)chromium.org> wrote: > > > > > > > > Hi Rob, > > > > > > > > On Tue, 5 Jul 2022 at 09:24, Rob Herring <robh(a)kernel.org> wrote: > > > > > > > > > > On Thu, Jun 30, 2022 at 3:24 AM Simon Glass <sjg(a)chromium.org> > > wrote: > > > > > > > > > > > > Hi Jose, > > > > > > > > > > > > I don't think this is correct. TF-A is a project that aims to > > > > > > replace U-Boot SPL (and perhaps other components) with more > > > > > > closed firmware, e.g. the permissive license. > > > > > > > > > > > > This spec needs to be in a neutral place, not captive of one project. > > > > > > > > > > > > Given its close relationship to device tree, I suggest > > > > > > github.com/devicetree-org > > > > > > > > > > The only relationship to DT I see is DT is a payload as is ACPI. > > > > > So I don't think dt.org is the right place. > > > > > > > > Actually I was about to email you about this. Here's how I see it. > > > > > > > > DT is a base structure to allow self-describing data to be stored. > > > > This is in contrast with ACPI where there is just a header, but it > > > > is not possible to read the data without specific parsing code for > > > > the particular table types. Let's ignore ACPI for this discussion. > > > > > > > > Unfortunately DT has an overhead and is too expensive for early > > > > firmware use. It takes 3-4KB of code for libfdt as well as extra > > > > code and data to read properties, etc. > > > > > > > > Transfer List aims to bridge the gap, allowing simple C structures > > > > to be put into a tagged data structure. The intention is that > > > > anything more complex than that would use DT. > > > > > > > > So there is at least some relationship: simple stuff = Transfer > > > > list, complex stuff = DT. > > > > > > That's a stretch IMO. Perhaps if this was a new output (DTB) format > > > for easier parsing, I'd agree. It's related to DT only as much as > > > any other data passed between 2 boot components (remember > ATAGS?). > > > > Yes it is a stretch. I'm just making the case. > > > > > > > > > The Transfer List spec specifies the data format for each entry > > > > type (the analog to the schema). The DT provides the format and > > > > schema for more complicated stuff. > > > > > > > > We could perhaps put it in an entirely separate repo, but to me > > > > there is a relationship with DT. > > > > > > It seems to me that TF is the main driver and user of this, so I > > > don't see the issue with them hosting it at least to start as long > > > as there's not barriers to contributions. It's just a namespace like > > > devicetree-org. Personally, I'd be more concerned on what the source > > > format is (I assume the plan is not to commit PDFs) and what the > > > output generation is. GH has a lot of nice features to support that > > > which we've used for the DT spec and EBBR. > > The default working plan is for the source format to be sphinx. > Other alternatives/suggestions are welcome. > > The output generated should be html (pdf can be supported too for > 0/negligible effort). > This generation process can and will most likely evolve over time, depending > on community direction/desire and the tools we have at our disposal. > The process should be as automated as possible given any practical > constraints 😊 . > > Regards, > Jose > > > > > Yes the DT spec works well and I hope the same thing can be used. > > > > > > > > I'm not saying no to devicetree-org either. If the consensus is to > > > put it there, I really don't care so much as it takes less time to > > > create a new repo there than to write this email. > > > > I do hope that this can become a standard beyond ARM, e.g. with Intel > > and another i can think of. Intel is essentially trying to create a > > different thing independently, although has apparently adjusted to use > > device tree due to its self-describing properties. I suspect that > > having this spec in an ARM site would be a barrier to that. > > > > I am OK with ARM TF being the means to get this into the open, but not > > with it being the final destination. > > > > If we cannot agree on anything better, I am happy with creating a new > > project on github. We'll need to pick someone to own it and make final > > calls when there is disagreement. > > > > Regards, > > Simon > -- > TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an > email to tf-a-leave(a)lists.trustedfirmware.org

3 years, 4 months

1
0
0 0

No EBBR meeting today

by Grant Likely

Hi all, Sorry for the late notice, but there will not be an EBBR meeting today. There hasn’t been any really activity recently. Also, I’m handing over EBBR responsibility to Vincent Stehlé, so I’ve cancelled the meeting series if you were receiving that invite. I’ll leave it up to Vincent on when it would be best to resume meetings (probably after the summer). Let me know if you have any questions Cheers, g.

3 years, 4 months

1
0
0 0

EBBR Biweekly cancelled today

by Grant Likely

I don't have anything for the agenda, so there is no meeting today g. 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.

3 years, 5 months

1
0
0 0

Devicetree call May 16

by Bill Mills

All, On today's call I would like to talk about DT in other contexts: * To describe the contents of a given PCI card (even on a ACPI based system) * To describe what is attached to a given FDTI device (Multiple I2C devices etc) We can open to other topics as well. Zoom: 2PM UTC, 10AM US east https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 5 months

1
0
0 0

Devicetree call today May 2

by Bill Mills

All, On today's call I would like to talk about DT in other contexts: * To describe the contents of a given PCI card (even on a ACPI based system) * To describe what is attached to a given FDTI device (Multiple I2C devices etc) We can open to other topics as well. Zoom: 2PM UTC, 10AM US east https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 6 months

1
1
0 0

No DT meeting April 18

by Bill Mills

All, I am getting a lot of declines for the April 18th meeting. I am going to go ahead and cancel now. For everyone that has a long weekend ahead, enjoy! Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 6 months

1
0
0 0

Call for agenda for the April 4 DTE call

by Bill Mills

All, Do we have any suggested topics for Monday April 4? Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 7 months

1
1
0 0

Re: [EXT] Re: Device Tree call: Define Secure Data Path reserved memory

by Bill Mills

Everyone in the to: list, Are you all free today at 3PM UTC (11 AM US East)? Oliver, See the DTE home page for a description of the meeting, the Zoom link and a google ics file. However I just added you to the invite going forward. Just delete after we are done if you do not want to continue. The meeting is tied to UK time so right now appears 1 hour later than normal as US has done DST and the UK will not until next week. Thanks, Bill On 3/7/22 11:00 AM, Olivier Masse wrote: > Hi Bill, > > Could you send us some pointers to join your call ? > > Sorry for this late request. > > Olivier > > On mar., 2022-02-22 at 15:00 -0500, Bill Mills wrote: >> Caution: EXT Email >> >> 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 -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 7 months

2
2
0 0

SystemReady IR Architect job posting

by Grant Likely

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.

3 years, 7 months

1
0
0 0

EBBR biweekly on today

by Grant Likely

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.

3 years, 7 months

1
0
0 0

DT call today is on at normal time

by Bill Mills

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

3 years, 8 months

1
1
0 0

EBBR Biweekly cancelled this week

by Grant Likely

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.

3 years, 8 months

1
0
0 0

Re: [EXT] Re: Device Tree call: Define Secure Data Path reserved memory

by Bill Mills

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

3 years, 8 months

1
0
0 0

No Devicetree meeting on Feb 21

by Bill Mills

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

3 years, 8 months

1
0
0 0

Re: Device Tree call: Define Secure Data Path reserved memory

by Bill Mills

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

3 years, 8 months

2
1
0 0

DT Call for tomorrow, agenda items or cancel?

by Bill Mills

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

3 years, 9 months

1
0
0 0

Reminder: EBBR Biweekly 31 Jan 2022

by Grant Likely

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)

3 years, 9 months

1
0
0 0

EBBR Biweekly is ON today - 17th January

by Grant Likely

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.

3 years, 9 months

2
1
0 0

DT Evolution call in ~45 min

by Bill Mills

Hello all, We have the first DT evolution call of the year in ~45 min. 3PM UTC, 10 am US East https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 9 months

1
0
0 0

EBBR Biweekly - 6 Dec 2021

by Grant Likely

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.

3 years, 11 months

4
5
0 0

Reminder EBBR biweekly today at 15:00 GMT

by Grant Likely

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.

3 years, 11 months

1
0
0 0

No Devicetree call for Nov 15

by Bill Mills

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

3 years, 11 months

1
0
0 0

EBBR Biweekly - Monday, 8 Nov 2021

by Grant Likely

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.

4 years

1
0
0 0

DTE call today at 15 UTC/UK (US: LOOKS LIKE OLD TIME!)

by Bill Mills

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

4 years

1
0
0 0

SystemReady and OCP Checklist

by François Ozog

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

4 years

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture