TSC Meeting Notes 2019 - OpenAMP/open-amp GitHub Wiki
- Formalizing OpenAMP project – recently we have been working on investigating different approaches on how to set up an open-source project. In this presentation, we would like to present a few approaches, pros and cons - Felix, Stefano
Members will go over the presentation another time and will brainstorm offline. We will have a follow up meeting and will try to make a decision jointly
- Come up with agenda for Linaro Connect
- Welcome session during Linaro Connect to demo OpenAMP
- Webex session to demo OpenAMP (a few weeks later)
- Lazy evaluation of new time (as more and more companies are interested in joining OpenAMP meeting)
Attendees: Bill, Loic, Arnaud, Felix, Stefano, Wendy and Ed.
- Agenda for Linaro Connect:
- Formation of the OpenAMP
- Buffer sharing and/or big data
- dma_buf import (in Linux kernel)
- shared mem api update
- CI loop
- System device tree update
- Organizing meeting
- Welcome session during Linaro Connect to demo OpenAMP – Ed Mooring (from Xilinx) works on presentation. Ed has already got a Linaro template presentation and works on it.
- Lazy evaluation of new time – no objections if it would be applicable.
OpenAMP Relaunch
- Intro to OpenAMP
- Intro to new organization
- Call to action
Attendees: Jean Labrosse (Silicon Labs, Micrium), Bill Mills (Linux strategy at TI), Clement Leger (Kalaray), Danut Milea (Windriver), Maarten Koning (Windriver), Etsam Anjum (Mentor Graphics, Co-authored 1st version OpenAMP with Wendy), Loic Pallardy (ST Micro), Arnaud Pouliquen (ENEA), Patrik Stromblad (Green Hills), Tim Reed (Green Hills), Tomas Evensen (Xilinx), Felix Rubinstein (Manager of OpenAMP team at Xilinx), Ed Mooring (OpenAMP maintainer at Xilinx), Stefano Stabellini (Xilinx), Bruce Ashfield (Xilinx), Nathalie Chan King Choy (Helping Xilinx on various open source efforts)
- OpenAMP has been around 4 years
- Looking for founding members
- Vision statement
- Something like what's in this slide, which Tomas came up with. New OpenAMP steering committee can refine it.
- Open Source is the fastest way to standardize something these days
- Business-friendly license
- Even proprietary implementation is OK (e.g. safety certified)
- Reference platform
- Heterogeneous Embedded System
- Need to communicate & configure across ELs, Security env, OEs
- How to integrate Linux, baremetal, commercial RTOS?
- Simplifying SW for Heterogeneous env
- No questions from group
- OpenAMP initiative
- Non GPL cleanroom implementation: BSD license
- MCA not very active these days, so want to start an independent org
- Lifecycle Management
- Messaging: Master/Remote IPC with RPMsg
- A lot of people have their own client rpmsg code
- Transport over shared memory
- Messaging: VirtIO
- Hypervisors used it for sharing networking, filesystems, etc.
- Low level abstraction: Libmetal
- Why libmetal?
- In Linux user space it provides API that looks like a baremetal API
- Gives you access to low-level primitives
- Lets you have RPMsg running in user space, using VirtIO -> Gives you VirtIO from userspace
- Risk of abstraction layers: Overhead. Working on it the past year
- Why libmetal?
- Proxy operations: Share resources
- e.g. printf to serial port or read/write file on the Linux partition
- Proxy process handles requests from RTOS
- Baremetal on another core can be managed like a process in Linux
- Want to do more of as we go forward
- Resource configuration
- e.g. MPSoC: How to configure all this?
- Has been done pretty ad hoc
- Want to standardize
- Looking into device trees as one way to standardize
- OpenAMP is a group that's interested in embedded systems, so is the right group of people to have these discussions, along with devicetree.org
- Can use for verification: Make sure that 2 things aren't using the same device or memory area
- Tools to "prune" system device tree into a regular device tree
- For internal baremetal & FreeRTOS, drive
- Do it on host
- Populate .h & .c files from DT
- Want to encourage ppl to adopt a common format to get this info -> interop would be a benefit
- No questions from group
- Creating new OpenAMP project org
- Need governance & formalization
- Mailing list
- What are rules to become maintainer?
- How to check in?
- How often to release?
- Linaro Community Project
- Important: Will be independent group. Just using Linaro's mechanism & infrastructure to get going.
- Finance: Linaro will manage the bank account
- Vision: Want it to be a low fee organization - just enough to keep the lights on
- This makes it a no-brainer & reduces barrier to joining
- Goal: 10 founding members
- Future: Can consider improving website, add a CI lab, hire a project manager
- Then could discuss if need to increase fee a little
- Need governance & formalization
- Next steps
- Project structure
- Linaro has templates for how you can organize your project
- We will start very simple
- Discuss fees & budget
- $2500 is just a suggestion right now
- In the past, had f2f meetings at Linaro Connect
- Legal: Should be pretty low-touch b/c not very complicated docs
- Proposing to change weekly OpenAMP meeting to bi-weekly
- Can have specialized topic meetings aside
- Would talk about project structure here
- Project structure
- Bill: Looks good. Let's do it.
- Clement: Regarding funding
- What do you expect founding members to bring to the group?
- Tomas: Keeping it low key.
- Vision: People will find value great enough that will contribute to the OpenSource project
- To-date:
- Nordic, ST, Linaro, Mentor, Xilinx contributed
- Additional other companies have been using it
- Yearly member fee
- Come to the regular meetings as much as you can (1hr, probably bi-weekly)
- Contribute to Linux kernel? OpenAMP?
- Tomas:
- Could be to Linux kernel, System DTs, port your OS to OpenAMP & upstream when possible
- Bjorn Anderson is part of the group
- Want to make sure new features are compatible with Linux kernel
- Collaboration on discussions (e.g. adding zero copy)
- Loic
- When have list of features to develop kernel side, propose to review with Linaro
- Need more review of patches. Was hard without mailing list
- Tomas
- Would like discussion of industry-wide issues
- e.g. Wouldn't it be great to standardize configuration?
- Would like to have different companies describe their use cases b/c can be big eye-opener/learning experience
- Would like discussion of industry-wide issues
- Loic
- ST: OpenAMP is not 1 unique product. You must customize to your architecture. We have different needs, different SoC architecture.
- Would like to see goal to make OpenAMP scalable, so you can choose to take 1 feature or full set of features
- Tomas:
- Would like to minimize differences between vendor systems
- Make it easier for RTOS vendors to deal with all the SoCs out there -> Add to future slides
- Call to action
- Anyone on the fence or have questions - feel free to reach out to Tomas
- Share with anyone in your company, or outside your company - we want to be as inclusive as possible
- Tomas will send out the paperwork & initial template from Linaro in about a week
- Maarten: Can you share the slides?
- Tomas will send
Attended: Tomas E., Tony McD., Mark G., Arnaud P., Bruce A., Clement L., Dan M., Etsam A., Felix R., Loic P., Maarten K., Nathalie CKC
- Nail down the details for the new OpenAMP organization. I have sent the templates to the people who have expressed interest in being a founding member.
- Linaro LITE coding days - any OpenAMP activities? (Not covered)
- Topics for future meetings
- Bill can’t make it today but is working on logo
- Have openampproject.org & .com, No longer have openamp.org & .com
- AMP -> Audio equipment
- AMP -> Google Accelerated Mobile pages
- Reviewed & discussed Linaro project templates for Membership Agreement and Charter. Nothing really to change for the Anti-trust agreement.
- Next call will be next week, due to holiday in France in 2 weeks
- Finalize open items in the membership agreement
- System Device Tree update – if time (Not covered)
- How to get good publicity and attention for the OpenAMP Project re-launch?
- Best timing would be to align with a big event like Linaro Connect or ELC because the press will be paying attention then. Have signatures/endorsement by all the Platinum Members.
- Discussed open items in Membership Agreement and Charter
- Removed General membership
- Deferred a number of decisions to the Governing Board. Idea: Keep things as simple as possible for launch.
- Bill showed us his ideas for possible logos
- Action items
- Bill: Concern about Charter requirement for all new inbound code contributions having to be BSD-3. Bringing in other modules (e.g. on host) may be of other permissive license types. Bill has action item to look at what Yocto charter has done.
- Bill: Send out logo drafts for everyone to review & think about.
- Nathalie: Clean up Membership Agreement and Charter doc and send out clean version
- All: Have their Legal teams review Membership Agreement and Charter doc + Anti-trust doc
- Tomas: Ask Linaro to review changes we made to their Membership Agreement and Charter template. Also ask them about how they get their project logos designed.
- Next meeting: June 6th
Attended: Arnaud P., Azzedine T., Bill F. (Linaro), Bill M. (TI), Bjorn, Bruce A., chenroid, Clement L. (Kalray), Dan M. (Wind River), Don H., Ed M., Eric F. (TI), Etsam A. (MGC), felix, Joakim B. (Linaro), Kumar G., Loic P. (ST), Maarten K., Mark G. (TI), Nathalie CKC, Rob H., Saravana K. (Google), Stefano S., Suman A. (TI), Tomas E., Tony McD. (Xilinx), Trilok S.
- Tomas: System Device Tree presentation
- Bruce: Lopper demo
- Kalray: Suggestions for OpenAMP Project membership agreement additions, if time. (Ran out of time, didn't cover)
- Tomas' presentation about System Device Trees, may be familiar to some. Sets the context for Bruce's Lopper demo.
- Tomas sent out the slides to everyone. You can find them here.
- OpenAMP Project re-launch is planned as a Linaro Community Project & will include AMP aspects of System Device Trees. Contact Tomas if you're interested in being a founding member - 8 so far. $2500/yr membership to "keep the lights on" (e.g. mailing list, webpage, etc.).
- Lopper:
- Term from gardening - cutting tool for pruning trees.
- The inputs are known files. The tools are open source.
- Questions after demo:
- Saravana K. (Google): You're not actually transforming the address? e.g. 0 vs. all Fs
- Bruce: Correct, not currently. Next, will implement ranges.
- Stefano: Should be able to handle your case using ranges.
- Rob H.: Presentation says the tool is open source, but is the code available?
- Bruce: Not ready yet. Planned. Still in early prototype phase.
- Tomas: Need to add documentation. Bruce is full time on this and Stefano is working on spec.
- Bjorn: Couldn't you implement this with platform dtsi and domain-specific and board dts? Why use superset dts?
- Stefano:
- Still need ranges property under CPU cluster & need to be able to prune
- See value in describing full platform. Some customer personas do want this info.
- Demo is showing just 1 file, for simplicity. Can still use include files.
- Kumar: With a full platform described, can do error checking/validation, and other tools can have access (e.g. Xen at runtime), can see what resources are secure vs. not
- Tomas: In future (not implemented yet) could have wildcards. Could build whitelists of what can be included.
- Stefano:
- Saravana K. (Google): You're not actually transforming the address? e.g. 0 vs. all Fs
- Action items
- Tomas, Bruce, Stefano: Give a progress update to the larger audience in a couple months
- Azzedine: Host a deep dive technical discussion at Linaro Connect in September (perhaps day before or after)
- Tomas agrees we should do this & maybe even have some coding
- Nathalie: Poll to see who will be at Linaro Connect, ELC, ELC Europe, Linux Plumbers
- Goal is to make sure to have discussion opportunities available to those who are not Linaro members
- F2F at Linaro Connect
- Update on OpenAMP org
- We have a final member agreement for the founding members to sign
- Let's discuss next steps
- Attended: Tomas E., Dan M., Stefano S., Maarten K., Arnaud P., Suman A., Ed M., Loic P., Nathalie CKC
- F2F at Linaro Connect
- Linaro Connect schedule was posted this week
- Monday: DT talks
- Wednesday: Hacking day, DT project meeting
- Thursday: Propose to have OpenAMP meeting during the usual Thur call time slot
- Propose to have separate System DT meeting, hosted by OpenAMP group
- Want to have the right people (e.g. Rob, Grant, Steve)
- 6 hour LITE sprint: People hoping to get the minutes
- Stefano captured some of the key points
- Updated his examples based on that feedback
- Plan to kick off another round of reviews
- Loic will try to share view on how would like to see file delivered to customer & used by customer & with build system. Think it's not too far from what Stefano proposed.
- Stefano captured some of the key points
- Yesterday's Linaro Device Tree Evolution meeting
- Did not cover what to do at Connect
- Stefano gave update
- Steve McIntyre to create Jira tickets
- DT specification
- Stefano has proposals on what needs to be added
- 2 sets of bindings needed to make SystemDT work
- 1: OpenAMP stuff doesn't require changes to core bindings. Can discuss in OpenAMP group.
- 2: Changes required to core DT spec (e-paper). Needs to be discussed on DT spec mailing list.
- Not everyone on DT spec mailing list has been following SystemDT discussion
- OpenAMP should discuss & get alignment internally first, before going to DT spec mailing list. --> Host System DT meeting at Connect & get alignment there
- Stefano to continue working on examples & hold off on contacting DT spec mailing list until we get better alignment in OpenAMP group
- Tomas to check w/ Bill Fletcher about list of emails for who to get alignment with
- Devicetree.org steering committee stopped about 1 year ago (led by Grant)
- Qualcomm, ST, ARM trying to revive community via Linaro
- Linaro Connect will be a good place to discuss with Grant & Rob
- Typical open source projects do 1 thing. Device Tree spans many projects.
- Not obvious on which mailing list to discuss what
- Cross-functional means creating new ways of working
- Linaro has started a new project "Device Tree Evolution" with 6 different sub topics
- Looking for places to lead those topics
- OpenAMP is willing to lead 2 of those topics
- System DT
- How to create RTOS bindings
- Make sure you don't have to be a Linaro member to be part of these dicussions
- All open source
- Any change to DT spec has to go through devicetree.org
- The sub groups would drive discussions on devicetree.org to ensure progress
- Maarten trying to talk to ARM about what we're doing with System DT
- They weren't aware & pointed to Device Tree Evolution
- Have we invited ARM? Yes, but they aren't necessarily discussing it internally. Talk to James King & Mark.
- DT has at least 2 places for discussion
- Device Tree spec where core changes submitted
- LKML where device bindings are submitted
- Envisioned System DT initially
- Wouldn't change Linux
- Do pre-processing on host to create "traditional" DT for Linux, so no need to discuss with Linux
- But then it is useful to Linux, so some ppl think maybe we should change Linux
- Some Linux maintainers don't have global view of system, so may not be in agreement. Will need to have discussion with maintainers.
- Can't keep the kernel guys out too long, will not go well. Get the discussion started with kernel after we get definitions figured out
- Open AMP project re-launch
- Nathalie to follow up with founding members who haven't replied to email on signing member agreement
- To prepare for press release, Tomas recommends targeting end of August for signature (maybe +1 week). Tomas to find Marketing person to help us write a blurb.
- ST: Loic agrees should announce at Connect. Concern about vacation period in France -> 1st week Sept more realistic for signature. Also concern about # ST depts that need to review press release.
- Tomas & Nathalie to find out if we can get openamp.org domain back
Tomas E., Maarten K., Dan M., Bruce A., Stefano S., Ed M., Bill M., Nathalie CKC
- Nathalie: Check with Vicky about:
- Community Project & non-Linaro member attendance to OpenAMP & SystemDT (hosted by OpenAMP) meetings. Also meeting space (with dial-in capability). Ref. community project slide deck.
- If Linaro Marketing helps draft the press release, or if we need to have OpenAMP group draft the release
- Nathalie: Make a final call for logo proposals & announce we'll vote at next call. Send out logos that we have so far.
- Bill: Send his logo candidates to Nathalie
- Tomas: Send Arnaud's logo to Bill & Nathalie
- Tomas: Get Marketing help for press release
- Tomas: Sync up with Bill Fletcher & Steve McIntyre to align with DT evolution meetings
- Tomas & Stefano: Sync up with Steve McIntyre to align presentations
- How to ensure non-Linaro members can attend the meetings that happen during Linaro Connect? Some of them might not be attending the conference.
- Maarten asked Linaro if he could join as a Community member
- 2.2 Anyone may apply to be a community member
- VP of Member Services (Scott Bambrough) wrote back
- Linaro is not set up to handle individuals as members.
- Welcome to attend Connect & participate.
- Stefano: There is a Linaro Community Projects slide deck
- Linaro may make available some passes, team building, meeting space/hacking room
- Stefano had seen at previous Connect - Community day doesn't require full week ticket
- $750 for 1 day pass. Maybe discounted rate for Members. What about community project members?
- Maarten asked Linaro if he could join as a Community member
- Update on founding member status
- 8 companies on board
- Only NXP has not replied to the emails. Tomas spoke to Rob last week in Cambridge.
- Xilinx & Wind River have signatures
- Bill: Confident that TI will sign & pay eventually. Shooting for the end of Aug goal.
- ST also has concerns about end of Aug due to vacation period in France. Shooting for early Sept.
- Need to prepare for press release & announcement at Connect in September
- Logo
- Need to choose logo for press release & announcement
- Bill thinks it would be helpful to round the corners on Arnaud's proposal
- Press release
- Tomas will ask someone at Xilinx for Marketing help
- Does Linaro help with drafting the press releases?
- OpenAMP Meetings at Linaro Connect
- Proposal: 12-2pm on Thursday, so that it's at the normal dial-in time for those who can't be there in person
- SystemDT & RTOS meetings hosted by OpenAMP group would be separate
- SystemDT
- At the Wednesday DT call, Stefano suggested to for OpenAMP group to organize SystemDT meeting and we work together with them to create the stories. They were open to the idea.
- Bill M. asked Steve about his role in DT -> Expects to be spending 60-80% of his time on it
- SystemDT
- Next, need to come up with agenda
Tomas E., Stefano S., Nathalie CKC, Dan M., Tony McD., Maarten K., Ed M. A lot of people are away on vacation this week.
- Email Tomas & Nathalie if your company has a page related to OpenAMP that we need to link to, for the bare-bones site
- If you want to volunteer to design the webpage, email Tomas & Nathalie
- Nathalie ask Jessica if they want to do separate press release too
- Let us know if your company also plans to do a separate press release
- Nathalie to ask Vicky if it's possible to get a couple discounted 1-week passes for the non-Linaro members to attend the meetings
- Update on creation of OpenAMP organization - Tomas/Nathalie
- Who has signed so far: Wind River, Kalray, Xilinx
- Checking with Vicky about Linaro, but she is on vacation this week and next
- Mailing list & web site
- We don't have openamp.org back, so will launch with openampproject.org in the mean time
- Domain has been transferred to Linaro IT
- Fall-back plan: Tidy up existing bare-bones webpage. Will remove link to MCA.
- Ideally, get help with a nicer website
- Email Tomas & Nathalie if your company has a page related to OpenAMP that we need to link to, for the bare-bones site
- If you want to volunteer to design the webpage, email Tomas & Nathalie
- Press release
- From previous meeting, sounded like ST might need at least a week to approve press release. Nathalie asked Linaro if they could draft it by Sept 6 & have not got confirmation yet if that is feasible.
- Would like to have quotes from some of the founding members
- Maarten to prepare a quote from WindRiver
- Email Nathalie & Tomas with quote from your company by early next week, if you would like one included in the general project press release (assuming company signs Membership Agreement in time)
- We will decouple choosing the logo from approving the press release, to give more time for tidying up logo
- What's everyone's press release approval process?
- Common for the project to announce & the members to also announce, so there's more press coverage. Xilinx will prepare a Xilinx press release.
- Wind River -> Jessica Miller
- Nathalie ask Jessica if they want to do separate press release too
- Let us know if your company also plans to do a separate press release
- Asked Linaro if CEO can include the launch announcement in his keynote. Waiting on response.
- Who has signed so far: Wind River, Kalray, Xilinx
- Update on System DeviceTrees, including kick-off meeting next week
- Linaro doing Device Tree Evolution & there are several areas they are looking for teams to drive
- OpenAMP will lead 2 areas
- System DT
- Generating RTOS info from DT
- Tomas will call 1st meeting next week & then ask about what time works for participants
- Wed AM California time (in anti-phase timeslot of DT Evolution bi-weekly meetings)
- Will invite OpenAMP & DT folks & ppl can forward to others who may be interested
- Stefano has SystemDT proposal for next week's meeting
- What needs to change in devicedree.org spec: CPU Clusters
- AMP: How to specify what goes into different domains
- Meetings at Linaro Connect
- Who's coming to the conference for sure?
- Who's only able to come for the OpenAMP meetings if they can get day pass?
- DT Evolution: Wed afternoon, Thur morning
- OpenAMP meeting: 12-2pm on Thur
- Monday DT & OpenAMP talks at the conference
- WindRiver, Mentor & Kalray are active in OpenAMP & not Linaro members
- Maarten tried to register as a community member with Linaro to try to get member discount
- He was not able to get the community membership as an individual. Paid the full price for Mon-Thur.
- Nathalie to ask Vicky if it's possible to get a couple discounted 1-week passes
- Maarten tried to register as a community member with Linaro to try to get member discount
- Go over logo proposals and decide/vote.
- Would it look good on a T-shirt?
- Readability
- Showing topology
- Self-explanatory
- Eliminate the abstract ones
- Maarten retracts 2A
- Don't like lowercase mp in AMP & don't want to confuse with open amplifier spec
- 5B is a great watermark for slides
- Do we have to only pick 1? Many projects have both a logo & a word mark
- 6 would be a great word mark if you fix MP
- 6 could be combined with logo from 5-series
- Maybe some circles where they touch P
- Kalray also voted for 5C by email
- Felix suggested O with AMP written inside
- Can tell Ebba we'll ask the 5-series designer to give us the proper file formats, so the Linaro designer doesn't have to
Tomas E., Bill M., Stefano S., Arnaud P., Loic P., Etsam A., Manju M., Mark G., Nathalie CKC., Ed M.
- Update on OpenAMP organization - Nathalie
- Who has signed, who is in the queue, …
- Last chance to get into the press release (this Friday!)
- Announcement at Linaro Connect
- Website, mailing list
- Decide/vote on logo, see:
- Face-to-face meeting at Linaro Connect
- Will go from 12:15 – 2pm to allow people to grab lunch
- It will be possible to call in, even though experience says that it is sometimes hard to hear everyone. Will have at least two microphones this time.
- Discuss agenda for face-to-face
- Update on OpenAMP organization
- Members who have signed on: Xilinx, Wind River, Linaro, Kalray, Mentor
- Very close with ARM & ST. Shooting for end of this week to get into the press release.
- TI is shooting for before Connect.
- Tomas will follow up with NXP
- We have a website in progress that's going to have consistent look & feel with the other community projects, like trusted firmware's
- TSC mailing list has all the members of this call invitation. Will use it to send out the notes & invite people to opt out or let us know if anyone else needs to be added.
- Logo discussion
- If red line is too high up, it looks like spell check error
- Want to see a circuit-style connector to emphasize the red line's role as a connector
- The vertical line of the "P" dropping down so low looks a bit strange
- Consider how the logo looks when you zoom out a bit (e.g. when it's in the corner of a website or slides)
- We mocked up some variations to see how they looked
- Nathalie to bring group's feedback to designer and finalize the logo with him
- System DT F2F at Connect will be 9-10:30 am on the Thursday
- OpenAMP F2F at Connect will be 12:15-2pm on the Thursday. Who wants to present on future/current ideas?
- Ed & team are doing a talk on Monday on their work
- Prototype
- Can have some discussion on alternatives
- PR has been sitting on Github with various discussions
- Those ppl were at BKK, not sure if they will be at SAN
- Loic: Remoteproc & rpmsg evolutions
- Bjorn & Vincent
- Vincent tech lead of kernel working group
- 1hr open discussion w/ Bjorn & kernel working group about kernel evolutions
- Want to involve OpenAMP group
- Don't know when it is on Wednesday
- Could give an update during OpenAMP meeting
- Will help Bjorn in patch review
- Will share email on the new mailing list
- Bjorn & Vincent
- Big buffer
- Wind River - Tomas to reach out if they want to present their topic
- What meetings to have & who to drive them
- Ed & team are doing a talk on Monday on their work
- Send any additional topics to the tsc mailing list
- Arnaud on OpenAMP library
- No release in April
- Will you have a release openAMP library this year October?
- Ed: We probably should. Had not thought of it yet.
- Features waiting on for next release
- Some bug fixed
- Zero copy
- Controversial
- Cadence was every 6 months with Wendy in April & October
- Ed & team to discuss resuming this pattern
- Arnaud: What regular meetings should we have on technical topics?
- System DT?
- OpenAMP technical discussions instead of this "steering committee" meeting
- Won't be same people involved
- Kumar used to have a Wednesday OpenAMP technical call for Linaro LITE
- OpenAMP should drive the OpenAMP technical meeting
- Clarifying terminology: Re-launched OpenAMP is not a "Linaro project" but rather hosted by Linaro Community Projects
- Want people to know that they are welcome to participate in OpenAMP without having to be part of a Linaro member company
Clement, Dan (Mentor), Etsam, Manju, Tomas, Maarten, Bruce, Stefano, Nathalie, Reid, Kumar, Ben, Ed, Dan (Wind River), Keerthy, Bill, Grant
- Clement: 64-bit resources
- Maarten: What forum for communication & sharing
- Board meetings to do list
- How to become maintainer
- Code of conduct
- Ed's list of governance items
- Budget
- Document guidelines for what is a mergeable change
- Ed: Project update
- Tentatively scheduling next release for mid-October to go back to April/Oct lifecycle
- Working on CI loop both at Xilinx & with LAVA
- Going through pending Github contributions
- Maarten: Upstream support for commercial OSes
- We can hold patches, or push them upstream. Maybe they can help others. Is it appropriate?
- Ed: Don't have experience with it, but know who can ask about it
- TO DO: Guidelines: What is a mergeable change?
- License is reasonably permissive
- Just don't want to cloud things up with ifdefs
- Maarten: If OS vendor has a patch & no one else can test, then that doesn't work b/c can't maintain
- Stefano: are you thinking changes to libmetal as example? To run on top of proprietary OS in user space.
- Maarten: Yes
- Tomas: Want to encourage upstreaming, if has binding to Nucleus or other, then can help lift abstraction
- Kumar: As long as it's testable & can run in some QEMU environment
- Kumar: What working groups?
- Tomas:
- System DT
- If we have enough energy around proxies b/c stack around OpenAMP makes it more compelling
- e.g. eRPC
- Tomas:
- Clement: 64-bit
- Agree on proxy with __ forwarding
- Resources are described using 1st to bits address
- Our processor address space is mainly accessible in 64-bit, so above 1st 2 bits will vary
- Need to do aliases
- Have Linux + custom OS on OpenAMP, so have to do some stuff that's not native
- Ed: We need a way to recognize a 64-bit resource table that won't be confused with a 32-bit resource table
- Will need changes to kernel implementation of remoteproc
- How to version resource table to recognize this
- DT - what if 64-bit & 32-bit processor with different mapping needs to share resource
- Clement: This can be done with remapping function in libmetal side. OS will populate 64-bit resources & the other system can remap them.
- Ed: The other system can't physically map 64-bit addresses
- Stefano: Can specify a cluster is only able to address 32-bit or less. That's as far as DT goes & doesn't tell you what to do about it
- Clement: Have mapping from 64-bit to 32-bit & have some limitations with it, purely in DT. Then in OpenAMP side have a little trick to work around - maps 64-bit physical address, truncated & device address computed correctly with DMA remapping. Some custom code also involved, on OpenAMP side.
- Ed: Next step might be documentation on OpenAMP list on how it works. Don't see any reason not to support it. Xilinx parts could have this issue w/ 64-bit APU & 32-bit RPU. Think it's well worth pursuing.
- Kalray to take lead to provide some architectural thoughts
- Tomas: Could be topic for working group with remoteproc
- Need to have Bjorn b/c he's the Linux maintainer
- Maarten: Are you happy with state of crash/restart resilience?
- Ed: No, this has been open issue since before my time at Xilinx. Crash/restart resilience needs to be addressed.
- Kumar: Agreed. We talked about a lot of issues over the years & try to prioritize. Want to get traction & closure on a problem. Can regenerate the laundry list & how we want to run the project & take it from there (e.g. Github issues)
- Maarten: If we can get the backlog up there, some new participants in projects might want to pick things off
- Tomas: Felix posted a list of things ppl talking about but hadn't had resources to work on. Mainly Xilinx. Mentor hasn't had chance to upstream.
- Dan: We have commercial solution, so haven't been involved in open source side. Rebasing commercial solution on the latest OpenAMP. Have some feature sets that only exist in proprietary. No plan right now to upstream, but it makes sense to upstream them. e.g. Zero copy & large buffer support. Other ppl in
- Etsam: Rebasing code to latest version of OpenAMP. Then will add new features that we added to old code base. Zero copy & large.
- Using virtio chaining feature so application can send buffer larger than shared memory buffer size
- Then transmit them under 1 notification to improve throughput & data rate w/ rpmessage
- Probably take that up in next release. Current release in progress.
- After it's working with latest code base, then can upstream it.
- Stefano: Remoteproc & rpmessage
- Loic was driving most of the discussion
- Flow control
- Tty over openamp & tty comes with flow control
- Can we make the flow control generic for everyone to use, not just tty
- Bjorn was interested in that
- Xon, xoff could become a rpmessage virtio transport thing
- Problem statement: Memory management
- Passing buffer in memory but you don't know the real address. It's translated & you don't know physical
- e.g. you are in VM, but many other cases
- Loic proposed if we can expose an API to retrieve real address of a buffer, so you can pass the real value
- There was no conclusion. Needs deeper dive to see what we can do there
- Passing buffer in memory but you don't know the real address. It's translated & you don't know physical
- Problem statement: Transport
- Today's virtio queue doesn't fit
- Non-coherent memory
- OpenAMP over PCI
- Not discussing how to fix it, but gathering list of cases to consider when trying to fix
- Bill: rpmessage specific or general level at virtio?
- Stefano: Not clear
- Bill: Virtionet is virtio but way virtionet is not a good candidate b/c of how it works. It passes any memory from host to node. Not a good model for certain use cases
- Stefano: exactly. No clear solution on how to do it, but agreement that we have a problem & need to find way forward. Virtionet was mentioned in context of PCIe problem. In non-coherent, need to think of something else entirely underneath rpmessage.
- Ed:
- Restart survival
- Improved debugging: e.g. rpmessage trace like Wireshark or TCP dump
- Action item: Clean up wiki backlog & make sure to capture these things, then groups can prioritize based on interest
- Bjorn's schedule has change & can attend OpenAMP meeting timeslot
- Action: set up meeting on transport & on memory management so he can attend
- Tomas: Challenge - bit tricky to solve w/ multiple code bases to co-ordinate the changes
- Maarten: Wind River interested in other transports. We like to run over hypervisor without shared memory. Would like to participate & maybe contribute.
- Will use mailing list to send out the meetings.
- Tomas: Update bi-weekly TSC invitation to use the mailing list
- Bill: want to avoid double efforts.
- Tomas: How can we bring other things related to virtio?
- Ed: User space applications on Linux to use virtio so don't have to change kernel
- Etsam: We need a coding standard for OpenAMP project, so it is scattered
- Virtio, virtqueue - Free BSD
- OpenAMP - some K&R
- Ed: In my list for governance. Don't care which one, we just need one.
- Ben & Ed: Big buffer implementation. Ben implemented.
- Etsam: Not aware of it. Would like to know more.
- Maarten: Did you change any of underlying code?
- Ed: No.
- Tomas: Can be library that's on top. OpenAMP was a blob before. Assumes 1 side owns buffer & get message back when it's done.
- Manju: We have a mailing list. Can we send an RFC patch series to this effort & architecture doc? Then ppl can give feedback
- Tomas: Yes
- Etsam: This has to be implemented on both master & slave? Does other side need changes if on 1 side?
- Ed: Requires additional code on both master & slave. No changes to OpenAMP or kernel, just additional code.
- Etsam: What about zero copy?
- Ed: No, both sides need to agree on the protocol. It's implementation of simple protocol with shared memory pool.
- Etsam: In Linux, how things were done?
- Ben: We're not copying over the application data, we're just sending pointers across virtio & rpmessage. They agree on the pointers & not the data.
- Tomas: not a one sized fits all, this is a simple non intrusive implementation. We have customers & they like being standardized. They think rpmessage not that great b/c have to chop up big buffers. This is simple solution that worked for them.
- Maarten: Real-time island & safety island
- These are painful areas to be in b/c limited
- Want to leverage OpenAMP to have Linux & Vxworks better together
- Have more on Linux, less on Vxworks
- Leverage the best effort OS (aka Linux)
- Lots of issues around that
- Did a bunch of work to make remote file systems work
- Did support over multiple transports -> If OpenAMP could support multiple transports, then could use that
- File system is a service
- Console is a service
- TCP forwarding a service - use OpenAMP w/ client debug agent instead of network stack, which is smaller & faster
- Call it "isled" b/c it's a daemon for islands
- Could be of general utility to sit on top of OpenAMP
- Also did an OpenCL RPC service over OpenAMP
- Accelerated YOLO running on VxWorks but GPU running Linux
- Interested to learn about ERPC this week
- Would like to enable app developers
- Could see other services loading into isled
- Could be a sit on top activity, like zero copy library layer
- Ed: Should we organize as overall application stack, or separate them? It's starting to look like the beginnings of an application stack for heterogeneous
- Tomas: Original implementation from mentor had some system calls w/ proxy that was simple & similar. Makes life easier for lifecycle management - RTOS managed more like Linux & looked like a process you're starting. Have stdin/stdout connected.
- Kumar: ERPC - has idl & various backends & rpmessage lite & been looking at adding an OpenAMP one, number of transports. See it could play on top. Have not looked at proxy stuff.
- Maarten: Just being able to read/write pseudo devices on Linux - can open /linux/dev file and get data that way from the RTOS. That was helpful.
- Tomas: remote proxy, eRPC, islet. Don't want too many ways to do it. Seems like there is something there to work on if can collaborate in open source.
- Clement: Kalray interested too
- To discuss at future TSC meeting: Do we have enough energy around this to create a working group?
- AMP & hypervisors
- Xilinx has R5 and A53/A72
- Customer has to decide if should run on R5 or in VM on A53
- Don't want customer to have the 2 options more similar to each other
- This is 1 reason to have system DT - more consistency
- Messaging
- Rpmessage also on top of XEN
- Safety, mixed criticality -> Need commercial solution
- Want to get started with Open Source
- If we can make it easy for customer to switch, then people can get started with Xen (static, dom0less)
- Stefano driving documentation of Xen interfaces. What's minimal set you need.
- Want to work with hypervisor vendors
- Been talking to Charles at ARM
- OpenAMP have semi vendors, RTOS & hypervisor vendors in same room. If ppl interested, can have discussions more as an interest group. Collect the requirements.
- Dan: Mentor definitely interested. We are looking for a spec. Should be decent overlap. ARM has some standards around SMC calls, I think.
- Stefano: ARM starting to look at it for another vertical. Want to make it easier to safety certify & will take time. We picked up docs b/c key for both safety & having good interface & security support. Enables a community around it. Someone should be able to start from scratch & do a clean room implementation with whatever license they want. Today, that's not possible.
- System DT interfaces
- Interfaces to virtual machine
- Memory maps
- UART exposed to VM & location
- PSCI
- Stefano: 1st set of interfaces is essential to have a working system. 2nd set on top of that.
- Dan: Guest to guest?
- Stefano: yes
- Dan: We found peer to peer to be problematic b/c master slave normally
- Stefano: One size doesn't fit all
- Dan: Is this focused on safety/mixed criticality where some features won't be allowed?
- Stefano: 1st step: What is minimal set of interfaces to get up & running. Memory hypercalls not part of that set. Then discuss what on top of minimal. Today, some things can't be kconfig'd out of Xen & would be good if they become configurable.
- 1st set: Configuration
- 2nd: What is Xen/hypervisor exporting to guest
- Wind River & ARM interested in this discussion
- Grant: Need to get KVM folks in room too
- Tomas; Should reach out to Jan from Jailhouse, TI
- Grant: Worth asking Microsoft if they care. Can help us reach out to them.
- Xilinx has R5 and A53/A72
- System DT
- Missing ST & TI right now
- Want to generate all the info in a DT that you need from OpenAMP point of view
- Kumar: Standard bindings for OpenAMP resources
- Stefano: Very interesting. Didn’t get to it in the System DT meeting. Need to do better at unifying. Need to come up with single spec that is common enough that can offer flexibility to vendors
- Stefano: Trying to allow for vendor specific flag field to mapping
- Meaning of flag depends on resource & vendor
- Everything else is completely identical
- This flag field will allow Lopper to translate
- Kumar: Can see from SystemDT perspective
- Stefano: Doesn't take away reason for having better DT remoteproc node
- Kumar: Let's try to define standard based on commonality we see
- Stefano: If we had a common spec, Lopper would be much easier. Bjorn the one to talk to?
- Kumar: Post on the DT list & hash through it. Whoever has remoteproc upstream already (ST, TI, etc.)
- Bruce: Lopper
- Commented out chosen node b/c can use include, or chosen
- Tool doesn't re-invent anything that CPP or DTC does.
- Have lop files of lopper operations in DT format
- Takes inputs of System DT, rules files, transforms & knows how to output them
- Need to sync up with Kumar to look at more complicated structures
- Grant: Want to look at dtc tooling with proper python bindings that work with schema checker
- e.g. keep track of type
- Bruce: Yes, inferring type takes pain & suffering.
- Kumar: Take from DTS so get semantic info & can propagate through. It's useful for others to look at.
- Kumar: What does the OpenAMP output "today's" remoteproc node look like?
- Stefano: mbox issue
- Kumar: Easy enough to deal with & rectify
- Kumar: Memory region
- Stefano: Not sure. For lack of better info, thought would be specified in flag. Compromise: Don't want to make this a dumping ground, but maybe just 1 vendor flag to allow vendor specifics.
- It feels like you're doing this b/c want the transform to represent something that's consistent across any SoC and transform translates to SoC.
- Think you're trying to do too much
- Whatever you need to do for translating the Xilinx the
- Grant: Or, teach the driver to understand b/c want to minimize transforms
- Etsam: Mailbox comment: Those are standard bindings. Refer to vendor-specific IPI device. What is your concern with mailbox?
- Stefano: Look at remoteproc bindings
- Etsam: Agree remoteproc has no standard bindings, but mailbox does have standard bindings. So think we are good there.
- Stefano: Will give it another look
- Kumar: Memory regions for this case
- Ed: Describing R5 & depends on if you are in lockstep or not if the regions are shared or not
- Etsam: Mailbox comment: Those are standard bindings. Refer to vendor-specific IPI device. What is your concern with mailbox?
- Kumar: Is this binding upstream for ZynqMP?
- Stefano: Yes
- Kumar: Do think we should take action to come up with standard remoteproc binding
- Stefano: Would love it
- Grant: Should do it in OpenAMP instead of DTE
- Kumar: Is this binding upstream for ZynqMP?
- Board meetings to do list
- How to become maintainer
- Code of conduct
- Ed's list of governance items
- Budget
- Document guidelines for what is a mergeable change
- Wind River could push changes upstream for support for commercial OSes
- Tomas: Want to encourage upstreaming, if has binding to Nucleus or other, then can help lift abstraction
- Kumar: As long as it's testable & can run in some QEMU environment
- Wind River could push changes upstream for support for commercial OSes
- Clement: Send documentation to OpenAMP list on how 64-bit works. Kalray to take lead to provide some architectural thoughts.
- Consider if we should have a working group around remoteproc
- Need to include Bjorn b/c he's the Linux maintainer
- Etsam: Rebasing code to latest version of OpenAMP. Then will add new features that we added to old code base. Zero copy & large. Probably take that up in next release. After it's working with latest code base, then can upstream it.
- Clean up wiki backlog, then working groups can prioritize based on interest
- Set up meeting on transport & on memory management so Bjorn can attend
- Tomas: Update bi-weekly TSC invitation to use the mailing list
- Ben & Ed: Send an RFC patch series on big buffer work & architecture doc? Then ppl can give feedback
- To discuss at future TSC meeting: Do we have enough energy around Real-time island & safety island to create a working group?
- Safety, mixed criticality: 1st step: What is minimal set of interfaces to get up & running. Memory hypercalls not part of that set. Then discuss what on top of minimal. Make sure to invite: Wind River, ARM, KVM folks, Jan from Jailhouse, TI, Microsoft
- Grant can help invite Microsoft
- Let's try to define standard bindings for OpenAMP resources. Post on the DT list & hash through it.
- Bruce sync up with Kumar to look at more complicated structures for Lopper
- Stefano: Look at mailbox standard bindings
- Future work: Come up with standard remoteproc binding
- TSC, Board & subgroups meeting scheduling
- Starting up the subgroups & determining who will drive each
- OpenAMP: rpmessage & remoteproc, big buffers
- Higher level services: Proxy, eRPC, WindRiver islet
- Standardizing hyper calls, hypervisor interfaces
- System DT (invite also the DT people)
- Interim release process until we have the working group going for remoteproc, rpmessage
- System DT
- Logo
Dan M. (WR), Nathalie CKC (X), Mark G. (TI), Tomas E. (X), Arnaud P. (ST), Bruce A. (X), Etsam A (MGC), Ed M. (X), Stefano S. (X), Grant L. (Arm), Bill M. (TI), Suman A. (TI), Loic P. (ST), Manju (X)
- Bill & Loic: Find owner for rpmessage, remoteproc subgroup
- Tomas: Reach out to NXP about Membership Agreement & about leading higher level services sub group
- Dan: Talk to Maarten about leading higher level services sub group
- Tomas: Proposing Thur 8am Pacific - 5pm France, 4pm UK.
- Propose next week is TSC and clears up who is owner for the subgroups. Please send other agenda items.
- Ed: ask Wendy how previous releases worked.
- Ed: Reach out to mailing list & work with Arnaud on what to go into release
- Nathalie: Send out Github link to logos (Done: see links here below)
- Tomas/Nathalie: Set up next System DT call with DTE, RTOS & OpenAMP folks. Co-ordinate with Steve.
- Board meeting, Governance, etc.
- Once we have TI & NXP signed up, we will have 1st board meeting
- Will talk about Governance
- Ed has made a document of the things we need to figure out for Governance
- Decide what the Board should decide & what should be deferred to TSC to decide
- Budget
- Subgroups
- Proposal: Let's have a rotating schedule in fixed timeslot each week
- 4 subgroups + TSC -> Every 5 weeks each meets
- Rest of time talk over mailing list
- Bill: 1 topic every 5 weeks may be too far apart.
- If subgroup needs a topic-specific meeting, can set up special call for that
- Traditional OpenAMP: rpmessage, remoteproc, big buffers, Loic's list, both cleanroom & for Linux kernel
- Higher level services: Proxy, eRPC, WindRiver islet
- Standardizing hyper calls, hypervisor interfaces
- System DT (invite also the DT people)
- Could make sense to have this aligned with Steve's DTE meetings
- Could then have Thur rotate thru 4 topics instead of 5
- Who would like to be owners?
- Tomas volunteered to continue to drive TSC
- Stefano volunteered for hypervisor & hyper calls
- OpenAMP rpmessage, remoteproc
- Tomas suggests Kumar, but he is not here
- Loic: Kumar has good view from Zephyr, RTOS, baremetal. What about Linux kernel?
- Need alignment between Linux kernel & OpenAMP
- Do we want to influence kernel frameworks?
- Bill: Not saying Kumar isn't a good owner, but some discussions are happening with Linaro, so there may be someone else.
- Bill & Loic: Find owner for rpmessage, remoteproc
- Tomas: We appreciate when Bjorn calls in. He is interested when it's kernel.
- Loic: Discussed with Vincent. Although no cards, there is 1 Linaro guy starting to have a look at rpmessage, remoteproc & he may be a good candidate.
- Higher level services
- NXP not on call
- Reach out to NXP
- Dan: Think WR interested. Will talk to Maarten about it.
- NXP not on call
- System DT
- Tomas can continue driving it with help of Stefano & Nathalie, if no other volunteers
- Loic: Would be better to have earlier than 9pm France time so we can get more ST participants. Before 6pm.
- Tomas: Proposing Thur 8am Pacific - 5pm France, 4pm UK.
- No objections
- Propose next week is TSC and clears up who is owner for the subgroups. Please send other agenda items.
- Proposal: Let's have a rotating schedule in fixed timeslot each week
- Grant: Devicetree.org
- Doesn't have very many member companies
- It's a small amt of $ and not much activity at that time & other distractions
- It could make sense to kick-off again as DTE gets momentum
- DTE predominantly Linux
- Ed: Release
- What do we want to do for an interim release process until we have Governance in place?
- What outstanding PRs/features need to go into this release before we freeze?
- Last release was before Ed joined, so not sure how it worked. Ed: ask Wendy how previous releases worked.
- Would like inputs from those who have stake -> Loic, Arnaud
- C++ related PR that fixes something that broke but have not tested yet
- Ed: Reach out to mailing list & work with Arnaud on what
- Loic: Could we have several maintainers to have review of code b/c different use models?
- Ed: Think decision for board
- Tomas: Think good idea to have additional maintainer.
- Ed: Good to have at least a backup. Kumar & perhaps others may have commit rights.
- Tomas: Formality would be to define roles & have board decide that. In the mean time, Ed & Arnaud can work together to make sure what needs to get done happens & can engage others on mailing list.
- Etsam: What is tentative timeline for next OpenAMP release? MGC have been rebasing.
- Ed: Want a list of what is outstanding that should go in. Don't want have large pile of new stuff at last moment. That should go into Q1 2020 release.
- Etsam: No well-defined coding standard. Should pick one. No preference which.
- Ed: No preference which. It's in list of Governance items to figure out.
- Loic: Where to find OpenAMP logo? Would like to use in presentation for ELCE.
- Nathalie: Send out Github link to logos
- System DT
- Tomas/Nathalie: Set up next System DT call with DTE, RTOS & OpenAMP folks. Co-ordinate with Steve.
- Topic to discuss: Should we have a separate mailing list?
- Tomas: Concern to have to explain OpenAMP specific needs in great detail to regular DT folks.
- Loic: Explain the need & that should give good context
- Tomas/Nathalie: Set up next System DT call with DTE, RTOS & OpenAMP folks. Co-ordinate with Steve.
Tomas E. (X), Maarten K. (WR), Mark G. (TI), Wes S. (X), Etsam A. (MGC), Nathalie C.K.C. (X), Stefano S. (X), Clement L. (Kalray), Bruce A. (X), Loic P. (ST), Ed M. (X)
- Close on owner to drive each of the sub-groups
- OpenAMP: rpmessage & remoteproc, big buffers --> Bill & Loic had action item to find owner
- Higher level services: Proxy, eRPC, WindRiver islet --> Do we have interest from NXP or Wind River to be owner?
- Standardizing hyper calls, hypervisor interfaces --> Stefano volunteered
- System DT --> Tomas volunteered if no one else wants to take it
- Decide on order for cycling sub-groups (i), (ii), (iii), and TSC meetings through this timeslot. (System DT calls will be in a different slot, because also inviting the DT people)
- Tomas & Stefano: will lead the meetings for System DT sub-group
- Nathalie: Follow up with Steve so we don't clash with DT meetings
- Stefano: will lead the meetings for Hypervisor sub-group
- Tomas: will lead the meetings for TSC
- Loic: will send email to Matthieu about leading OpenAMP rpmessage, remoteproc sub-group & CC Tomas and Nathalie
- Matthieu: Lead 1st OpenAMP rpmessage, remoteproc sub-group call during next Thursday's 15:00 UTC slot
- Sub-group leaders: We have this timeslot once a week & groups can feel free to use it. If leader wants to reserve a slot, send Tomas & Nathalie email
- All: If you want to propose other topics for discussion, can update the relevant sub-group wiki page:
- Nathalie: Ask Linaro about Google Doc area for OpenAMP project
- Membership status:
- TI: Legal is done, circulating for signature
- Tomas followed up with Rob for NXP
- Mailing list/website
- Nathalie: Clement had issue with CC on his RFC. Bill F. helping us based on experience setting up Trusted Firmware. He had not seen similar issue with CC. Will have to check with Linaro IT.
- Nathalie: Web designer added top nav bar that links to Linaro & other projects, similar to what the Trusted Firmware & other sites have.
- System DT: Will schedule sub-group meetings in another slot, not the Thur 15:00 UTC
- Nathalie: Follow up with Steve so we don't clash with DT
- Hypervisor: Stefano will lead the meetings
- TSC: Tomas will lead the meetings
- Traditional OpenAMP: Loic & Bill M. had action to find owner
- Loic discussed with Vincent G. Proposed Mathieu Poirier from Linaro, in kernel working group to lead OpenAMP remoteproc, rpmessage sub-group. Mathieu is interested.
- Although Mathieu's role is with kernel, Loic mentioned both kernel & other side.
- Loic can help Mathieu with the different topics we want to address
- Main list of topics is what we discussed during Connect
- Some additional topics from Bjorn
- Loic shared with Bill M. Bill thinks it's a good possibility.
- Vote: Any reservations with asking Mathieu to lead this subgroup? None.
- Tomas proposes that this topic starts next week
- Clement had proposed 64-bit support for topic
- Wes: lifecycle management of accelerators
- Beyond CPU heterogeneous targets, with remoteproc
- What should we call this subgroup? Will decide next week in the group
- Higher level services
- Dan suggested Maarten may be interested last week
- Tomas reached out to NXP & got no response
- Maarten OK to drive it
- Vote: Any reservations? None
- Should we have fixed rotating schedule + side meetings on different timeslot? Or, on as-needed basis?
- Loic: Would be good to have groups running in parallel that can have own periodic meeting schedules
- Tomas: Proposal - we have this timeslot once a week & groups can feel free to use it
- Hypervisor, TSC & services maybe
- Need to decide early what next week's topic will be
- If leader wants to reserve a slot, send Tomas & Nathalie email
- Stefano: Sounds good
- If you want to propose other topics for discussion, can update the relevant sub-group wiki page:
-
https://github.com/OpenAMP/open-amp/wiki#Future_topics
- Loic: Think Linaro could provide Google Doc area
- Nathalie: To ask about Google Doc area
- Maarten: Scope
- For higher level services, discovery is important
- One of the topics in higher level services subgroup would be about message passing
- But someone mentioned RPC & that's on top of send-receive-reply
- So, should RPC be in higher level services, or in rpmessage group?
- Loic: Agree
- Previously had discussed at Connect layer called Services
- Will need to have sync meeting between the groups
- Tomas: Also depends where we have the energy & where we start to see overlap. Bubble those overlaps up to the TSC.
- Maarten: What if I want to discuss a topic that really belongs in another group? Can I be free to make that mistake for now & we figure it out later?
- Tomas: Low likelihood of too many overlaps. Harder problem is getting enough energy on a topic. Better to err on the side of taking initiative & we figure out overlaps later.
- For now, will use the TSC mailing list. If we see that there is too much traffic, can look into creating other mailing lists.
- Loic: will send email to Matthieu about leading OpenAMP rpmessage, remoteproc sub-group & CC Tomas and Nathalie
- Calendar invitation from Ed for Saturday - accident -> Please disregard it. He sent out cancellation.
- Vote on the items deferred by board to TSC
Note: Invitation list for today's administrative call was reduced to voting members of TSC, 1 per OpenAMP member company.
- Tomas (Xilinx) - voting member, Chair
- Loic Pallardy (ST) - voting member
- Clement Leger (Kalray) - voting member
- Bill Mills (TI) - voting member
- Etsam Anjum (MGC) - voting member
- Ioannis Glaropoulos (Nordic Semi) - voting member
- Vicky Janicki -> Kumar Gala (Linaro) - voting member
- Nathalie Chan King Choy (Xilinx) - project manager
- Action: Tomas & Nathalie to pull additional items from Ed's doc to add to agenda
- Action: Nathalie to get a TSC-voting list created for the voting TSC members
- Action: Nathalie to co-ordinate next TSC call date over email
- Who can be part of TSC?
- Distinction was made between voting & general participation
- Distinction was made between TSC & work group responsibilities:
- TSC: Policies (e.g. how we do releases, coding guidelines)
- Work groups: Specific technical areas (e.g. how we do big buffers)
- Bill, Vicky, Etsam: OpenAMP Board member companies should each get a vote
- OpenAMP Board membership fee (currently $2500) is so low, it's not viewed as a barrier to companies joining if they want a vote
- Tomas: OpenAMP has historically encouraged inclusive participation - "more the merrier". Participation helps to build engagement & can be a path to membership.
- Possibility of nominating non-members with significant prior contribution to OpenAMP to also have a vote
- Bill & Maarten: Can start with open participation & if have a problem later, can take corrective action then.
-
Motion: 1 vote per OpenAMP board member company. Participation is open.
- Seconded
- No objections
- How to select/elect maintainers?
- Possibilities from other projects: TSC, working group, current maintainers
-
Motion: TSC votes on maintainers of the repositories that OpenAMP owns. TSC should to pay attention to the contributions that the person has made to the project
- Seconded
- No objections
- Loic: Arnaud worked a lot on OpenAMP w/ Wendy & Kumar over the years. Good candidate to be a co-maintainer for libopenamp & libmetal. Virtio, RPmsg, remoteproc, ELF loading. Less the QEMU part, which Ed is working on.
- Bill: We should also officially bless Ed as co-maintainer
- Tomas: Is Kumar currently a maintainer on OpenAMP?
- Loic: Think Kumar has write on Github for integration w/ Zephyr. Wendy had delegated him some activities for OpenAMP integrations.
- Kumar just joined call - perfect timing!
- Kumar: Primary maintainers should be Ed & Arnaud. I can be in supporting role.
-
Motion: Libopenamp & libmetal have Ed & Arnaud as co-maintainers.
- Seconded
- No objections
- Coding style guidelines:
- Beginning the discussion today & will defer decision on which to choose until we include the maintainers & other interested parties
- Style guidelines are a bit more urgent, as people want to commit things & it's a bit all over the place right now. Then will have to clean up the current code.
- Should we have common coding standard across OpenAMP, or per repo?
- Maarten: OS adaptation code: there may be some convention for the OS we are adapting to. Suggest flexibility there.
- Etsam: Mostly for applications or thin porting layer in libmetal. Suggest should not enforce convention on application code or porting layer.
- Bill: Suggest to look at Zephyr. Wouldn't apply this to non-C code, e.g. Python should follow Python conventions. If we adopt eRPC, we should not change. Apply convention to the ones we create
- Kumar: Disagree, even if it's OS adaption, should be consistent across a code base. If someone is creating an API, it's a big burden to know all the different standards. Different if you're importing an entire HAL.
- Clement: Agree w/ Kumar. e.g. In Linux, arch part must still conform to checkpatch
- Tomas: Depends how much code it is & who will be maintainer of that code
- Maarten: Don't expect ppl to change OS-specific code if they can't test it. They would be familiar with that operating environment & code, so they would not be disoriented.
- Kumar: Raises a different question of code that you can't test. Libmetal & libopenamp can't accept core code that the maintainer can't test b/c leads to bit rot. e.g. If WR wants to submit feature, then need to provide some way we can test, otherwise it's not part of this git repo proper.
- Maarten: Agree. That's why WR has SDK anonymous download that community can use to support
- Tomas: Should encourage our OS partners to put code in common place + test suite
- Tomas: I'm hearing adaption code that's part of OpenAMP project, it should follow OpenAMP standard. If pulling in something whole cloth (e.g. HAL), then we can have exception.
- Kumar: That summarizes my take
- Maarten: Sounds good
-
Motion: We should have a uniform coding standard for all the OpenAMP projects. Can have discussion for totally new projects that come in. Exceptions allowed for things that come in whole cloth.
- Seconded
- No objections
- Which coding standard?
- Tomas:
- Don't want to vote on this today.
- What does Zephyr do?
- Kumar:
- There is a standard. Trying to expand to deal with things like MISRA & JPL rules. Commercial tools for checking MISRA compliance have hefty license fee. Asking Xen folks how they do it.
- Mark Grosen from TI has been trying to have similar conversation w/ Trusted Firmware project & leverage some of their activities.
- From Bill: https://docs.zephyrproject.org/latest/contribute/index.html
- Ioannis:
- Coding guidelines that are coming now in process will be agreed by project members based on certifications. These will have to be enforced by static analysis.
- Will be a separate doc & will be public.
- Etsam:
- Suggest to decouple coding style from coding guidelines for OpenAMP.
- Coding style easy to enforce & verify (e.g. CI script).
- Coding guidelines for certification w/ static analysis need commercial tools.
- Ioannis: What has TF-M done?
- Kumar: Think TFM TSC is later today. Know Mark has been trying to pull what we did w/ Zephyr into TFM.
- Tomas: What is OP-TEE using? Is it part of TF-M?
- Kumar: Don't know what OP-TEE is doing. Mark probably starting with Microcontroller project b/c history w/ certification.
- Tomas: Should put proposal for next TSC meeting with the broader community to adopt what Zephyr is doing & not vote on this today. Want their input.
- Tomas:
- Should notes from today's TSC call be public or just sent to voting TSC members?
- Motion: TSC notes should be made available to OA-TSC list (effectively everyone on the old OpenAMP invite meeting list) & keep this list open
- Seconded
- No objections
- Agenda for next meeting (include maintainters & rest of OA-TSC list):
- Zephyr coding style, open to suggestions
- Release frequency
- Naming convention
- Release process
- How we deal with patches
- Testing
- Action: Tomas & Nathalie to pull additional items from Ed's doc to add to agenda
- Action: Nathalie to get a TSC-voting list created for the voting TSC members
- When should we have the next TSC call?
- Target end of Jan
- Action: Nathalie to co-ordinate next TSC call date over email
- Ed should not wait on TSC governance decisions for this upcoming release. TSC decisions on governance will be for future.