Attnedees:  David Brown (Linaro), Thomas Sanderson (Infineon), Kevin Townsend (Linaro), Lionel D (ST), Eric Finco (ST), Andrej Butok (NXP), Dan H (Arm), Antonio (Arm), Bill Peckham (Google), Kevin Oerton (NXM.Labs), Julius Werner (Google), Okash (Google), Matteo (Arm)

Agenda items:

* LTS

* RMM

* FW handoff spec

Recurring:

* OpenCI update won't be held as Glen/Don are not available today. See backup in the redacted board slides sent out by Don for Open CI monthly update.

LTS sum-up from board meeting

* until we start, it's hard to gain momentum and hard to estimate costs in advance.

* TF.org to evaluate direct funding but only from the next financial year

* Proposal: share the burden for 1 LTS release to be maintained for at least one year. To evaluate the effort, gather data, see how it goes, evaluate the engagement, and then have data to propose to the board for long term funding. Share the burden between companies interested.

* Question: which platforms are tested and supported? The baseline is the one tested by the official TF-A releases, with those platforms available in the OpenCI

* Board requests to carefully iron out the messaging to be shared with the community around the announce of the LTS so that expectations are clear in the community

* Tech-wise, the proposal does not seem to have any objection so this is mostly around funding/maintainership topics at the moment

* Companies interested are now to meet and agree next steps

TF-RMM component

* Upstreaming expected November 2022. Plans on integrating TF-RMM in the OpenCI in the longer term as well.

  Is the code already visible? It's still private. Arm Architecture group has some private prototype that was shared with some partners under NDA. But different significantly from what we're planning to upstream.

* Is it completely separate or depends on other TF.org projects? It's coupled with TF-A in the same way as Hafnium is. It implements RMM specification, so Linux and KVM and other clients they need to support the same version of the spec of RMM to be compatible

  Is the KVM counterpart of RMM going to be upstreamed? Yes, but Arm not the maintainer so actual upstreaming will take longer as Arm does not maintain those projects. But there will be public branches with these changes in the meantime

* KVM, EDK2, etc altogether available in November, they will follow their own destiny in each project.

  Is there a plan-B if upstream does not accept them? There is the risk but hopefully we will try to minimize and does not come to upstream maintainers as a surprise (discussions under NDA for years already with non-Arm maintainers). It does not mean it will be quick and easy but confident that it will happen. For example one particular concern is the major work going on in Android pKVM. Might risk some conflicts that slow down upstreaming

FW Handoff spec

* Several discussions around this happened so far. A number of interested parties (e.g. uboot). Quite difficult to accommodate all requirements from different parties. This is a tentative to summarise and centralise the discussion so far to foster further collaboration and evolution of the spec. We start on TF.org then we will re-assess if this the best place (or needs to be moved to GitHub or other places).

* Contribution model: similar to other projects but with indepedent maintainers, no strong links to other projects

* Creative commons license as it's more user friendly.

* Unless a big objection this is what is going to happen in the next weeks

* Is the format not pinned to devicetree? The spec just talks about container format, the actual data can have different practical formats. It tends to accommodate different implementation details. It's more focused on the information itself rather than formats to organize this information (i.e. registers to use, etc). It's quite a simple spec

* The spec will allow to specify different formats for the practical structures that hold the information

  Are there plans to add also tftf-tests for RMM? Yes there are some additional tests that will be upstreamed.

* There are some changes in TF-A for example that are already happening upstream in preparation for November 2022

Agenda items finished, no further objections.

Discussion about what will happen in subsequent meetings.

1. Roadmap sharing: Start again with TF-M (action item: inform Shebu and invite for October (last presentation was in February)

2. Members inform about their usage (e.g. Kevin from NXM did very good presentation last round) of TF.org projects, we believe it can be beneficial for the community. Call to major partners in the call if there is something you might be considering.

   TSC interested especially in hearing about any particular challenge that you need to overcome to use the projects commercially, any suggestions/lesson learnt that can benefit the different projects in terms of technical direction. Not necessarily to public TSC, can be a members only TSC (and share public/open info only)

   Feel free to reach out (directly to us in private if not comfortable)

   STM: We can do that for some of the projects of TF.org (what we use). Some direction, what we think it's difficult, what can be changed in terms of direction.

Is there anything else members would like to have in future TSC?

No particular feedback.

Last clarification about the structure of mailing lists. TSC-Private is the members only invited to the meeting.

TSC is for public attendance (no filter). Don has re-organized recently so hopefully minutes of meetings will have been correctly archived in the list manager now.

No particular other business, meeting close.