TSC Meeting Notes 2021 - OpenAMP/open-amp GitHub Wiki
- Arnaud, Bruce, Ed, Etsam, Loic, Stefano, Tanmay, Tomas, Nathalie, Grant
- Brief working group updates
- All: When/how to begin the master-slave terminology switchover, now that 2021.10 has passed
- (Postponed) All: Discuss WR repo of virtio framework port to Zephyr and decide on what to do with OpenAMP code to submit to Zephyr
- (Postponed) All: Discuss contracting possibilities for docs & Zephyr work
- Ed will make the master/slave terminology changes in the OpenAMP repo
- Nathalie: Post what Bill had sent to mailing list in the Wiki
- Ed: Make the master/slave terminology changes in OpenAMP repo.
- Nathalie: Send poll for OpenAMP Board call for December
- Nathalie: Send poll for OpenAMP January TSC call
- Recording link (download it sooner than later if you need to catch up, not sure how long before it expires)
- Stefano: System DT working group update (next call Dec 8th)
- Have done a bunch of cleanup of spec internally & reflected in Lopper
- New features: Integration w/ OpenAMP remoteproc. Can generate the proper DT binding for Linux.
- Have removed resource groups b/c caused lot of complexity in setting flags & nested domains. Now if resource shared, just repeat. To make it simpler, started using YAML anchors to reference node or key-value pair. Using it a bit too extensively & stretched YAML anchor capability, so Bruce came up with a new way.
- Bruce: Multiple inheritance to merge properties & nodes is not what YAML intended. Now we have an operator that is parsable by YAML, which Lopper can recognize & do rest of node merging and expansions that we need with less complexity. It's all upstream in Lopper now. Long term, we're seeing if there's anything we could propose that's native YAML.
- Loic: Would be good to discuss in next System DT call. Would like to define common access rights for group. If we change that, it's complex to find out what resources are common to what domain.
- Stefano: Maybe we can come up w/ some ways to mark clearly what is shared in nice way. Can also brainstorm if there is better way to do it. We are working to remove resource group b/c of complexity was causing everyone we explained it to to get it wrong at least once.
- Loic: At least we need to have something in Lopper to detect what resources are shared.
- Stefano: Yes, this was important before & even more important now.
- Tomas: System Reference working group update (next call Dec 8th)
- Goal: Put together all the pieces of OpenAMP together from build & config POV, with examples. Using ST & Xilinx platforms. Initial flows up & running and documented. Now working to simplify & remove dependency on vendor SDK, big downloads. Bill maintaining list of what to work on. Have talked to Linaro HPP project group, which will be super set of OpenAMP & has data center folks.
- Master/slave terminology switchover, now that 2021.10 is released
- Ed: Want to make sure we rename the branch to main first. Then, let the dust settle a little bit. Ed will take on the changes in the source code, but may take some weeks to make sure nothing gets mangled.
- Arnaud: Should be part of next release
- Ed: Can start after this next set of pull requests. Issue already filed. Will begin as soon as possible.
- Nathalie: Post what Bill had sent to mailing list in the Wiki
- Ed: Make the master/slave terminology changes in OpenAMP repo.
- Arnaud: Will also need to update documentation. Zephyr has already made the changes & asked them to make the changes related to OpenAMP & they have started to use host/remote.
- When to have next TSC call & next Board call?
- Board: mid-Dec
- TSC: January
- Nathalie: Send poll for OpenAMP Board call
- Nathalie: Send poll for OpenAMP January TSC call
- Postpone the other 2 topics because we don't have everyone we need for those discussions.
- ST: Arnaud, Loic
- Linaro: Bill
- Siemens: Etsam, Jeff
- Wind River: Maarten
- Xilinx: Tanmay, Tomas, Nathalie, Stefano, Bruce
- Nordic: Ioannis
- Have 6 members = > quorum
- Nathalie: Calling for volunteers for OpenAMP code of conduct committee
- Maarten/Dan: Pitch for App-services call coming up next week
- Maarten: creation of a Zephyr repo that we can use for pull requests to zephyr.org that have our reference heterogeneous OpenAMP technologies in it, such as the new virtio framework we are working on
- Tomas: Summarize latest on System Reference project (formerly known as “end-to-end example”)
- Tomas: Revisit spreadsheet of candidates for spending some of the OpenAMP budget (covers docs, app-services, system reference)
- Nathalie: Move App-services call 1hr earlier
- Nathalie: Forward App-services call invitation to Alex Bennee for forwarding to Stratos folks
- Ioannis: See if Carles can join the App-services call
- Maarten: Ask WR team to put virtio framework port to Zephyr into a personal repo and send out to OpenAMP TSC for review
- Nathalie: Topic for next TSC agenda: Discuss WR repo of virtio framework port to Zephyr and decide on what to do with OpenAMP code to submit to Zephyr
- Nathalie: Forward Bill's System Reference checklist as PDF to TSC list. If anyone wants to discuss, they are invited to join the weekly Wednesday call.
- Nathalie: Check with Vicky how the budget calculation for documentation was done
- Maarten: Ask Rob Wooley to ask at Zephyr TSC if they know any contractors with solid Zephyr knowledge who might be available for OpenAMP contract
- Nathalie: Publish code of conduct to OpenAMP website with the 3 committee members
- Bill: Ask Nico about what Yocto Project is doing for documentation
- OpenAMP Code of Conduct committee: Bill (Linaro), Tomas (Xilinx), Jeff (Siemens)
- Review the code for virtio framework port to Zephyr before making decisions on how to handle it
- Bill's proposal (see TSC mailing list) was voted on and accepted by TSC members.
- If TSC members or OpenAMP maintainers want to share documents to the mailing list/publicly, they have write access to OpenAMP Steering Committee > FilesToShareWithMailingList. Then can generate a public share link of the document itself for view/comment/edit, as needed.
- Meeting recording (not sure how long before it expires, so download sooner than later): Here
- Nathalie: Calling for volunteers for OpenAMP code of conduct committee
- Jeff volunteered
- Maarten/Dan: Pitch for App-services call coming up next week
- Initial example was with VxWorks. Open source reference implementation - request was for Zephyr.
- Virtio framework ported to Zephyr -> will discuss in call next week:
- Where to go next
- What device classes to build out
- Who is interested in collaborating
- How to get into overall demo
- Stratos call & Stefano's team meeting is in same slot on Thursday -> Let's make it 1hr earlier.
- Stefano: Alex Benne might be able to point us to the right ppl
- Ioannis: On leave, will see if Carles can join
- Maarten: creation of a Zephyr repo that we can use for pull requests to zephyr.org that have our reference heterogeneous OpenAMP technologies in it, such as the new virtio framework we are working on
- Repository for the Zephyr side of the work
- Bill: Have precedent w/ OpenAMP Libraries that are in OpenAMP project & included in Zephyr. We're not forking Zephyr, but creating an OpenAMP library module.
- Ioannis: Bill is correct. Makes sense to integrate in Zephyr. Be careful creating repos b/c need proper maintainers behind b/c need to make sure won't break the CI. Zephyr > Modules has documentation for requirements for this to proceed. If there is a need, could convince Zephyr guys.
- Maarten: Create the module & get it to some level of maturity. Don't want to engage too early before code is mature.
- Ioannis: TSC call is every Wednesday, Maarten can bring it up for discussion and get feedback.
- Arnaud: Do we need to create new module, or extend OpenAMP library that is already integrated in Zephyr as module to cover virtio?
- Bill: Had same Q. Ed suggested as new libraries so Ed & Arnaud aren't required to be the maintainers. Creating a repo that becomes obsolete later is not the end of the world. Would like to see code first, before making a call. Can we look at the code in personal repo first?
- Maarten: Sometimes have mismatch in values/goals, so hard to have 1 repo (e.g. small size vs features). Sometimes, need to just have good interface. Existing implementation is counting every bit.
- Bill: Also getting requests to update to newer virtio, so may be converging.
- Next step: Put it in a personal repo & then discuss if it should be new module or merge
- Tomas: System reference project update (end-to-end)
- Goals:
- Trying to create multi-vendor (silicon & OS) stable platform
- ST HW, Xilinx HW, simulator. Build OpenAMP in Linux + Zephyr or bare metal w/ Yocto without having to download vendor SDK. Demo.
- Future: add higher level services to open socket or file from Zephyr to Linux
- Future: Demo with system DT, for 1 place to define all the HW & which device/memory goes where.
- Future: Add hypervisors, maybe OP-TEE
- Related to Linaro LEDGE HPP
- Forward the checklist to the whole TSC as PDF. If ppl want to give input, invite to the call.
- Goals:
- Tomas: Budget: Probably about $30K to spend
- Bill: Unless you can spend $50K, it's usually not worth bringing someone in who needs to get up to speed. Different if had someone who is up to speed.
- Tomas: Who might have Zephyr experience that's a contracting house?
- Maarten: Rob Wooley goes to Zephyr TSC. Ask him to bring up if there are any contractor options.
- Stefano: For documentation, Yocto regularly hires.
- Bill: Can ask Nico from Linaro
- Stefano: Testing: e.g. CI loop runner
- Arnaud: Do a build check now with GitHub actions. Doesn't do CI test except on Linux env. Not on HW board. Don't know if there is a big need to perform this test today. Not getting a lot of feedback on OpenAMP library. Maybe can address the CI when have more demos.
- Bill: Hope is that System Reference project, as Xilinx & ST are members, could use Linaro build & lab time for those 2 platforms to run these CI tests on real HW.
- Tomas: Maybe if we need more boards
- Documentation: Check w/ Vicky how she calculated those estimates
- Stefano: events: Venue, food
- Bill: March Linaro Connect is probably virtual. Linaro policy is still virtual conference attendance for the hybrid events later this year.
- Stefano: Getting technical article written to spread the word about why it is useful (e.g. hacker oriented article)
- Tomas: Once we have System Reference further along, maybe
- Bill: Would like to understand how much $ comes in and how much has to go out for existing expenses.
- Nathalie: Bill Fletcher has sent request to finance to get the latest #s
- Arnaud: Where to share documents publicly? Right now just have GitHub repo. Not always simple to comment.
- Bill: Have Google Drive. Could create folder for public docs where ppl could comment.
- Nathalie: Grant has the OpenAMP Google Drive account credentials, but has shared write access with the member companies.
- Put files in OpenAMP Steering Committee > FilesToShareWithMailingList. Then, generate a public share link to the document.
- Bill: Unless you can spend $50K, it's usually not worth bringing someone in who needs to get up to speed. Different if had someone who is up to speed.
- Voting on Bill's proposal
- Is Arnaud OK with this, as library maintainer? Yes.
- Maarten: Does virtio use master/slave?
- Bill: OpenAMP uses those terms when referring to virtio & want to stop & align to virtio spec terminology.
- Maarten: front end, back end?
- Bill: Virtio spec doesn't use those. Ppl use it in conversation, but front/back end not clear. Would like this project to have documentation where we have a table of the official terms & what other terms ppl may see.
- Maarten: Vsock example: Both sides create socket. Can say service is the one that calls "accept" on the socket.
- Arnaud: e.g. RPC speak about server & client. Service & client probably also fine.
- Bill: Will have tweaks as we go forward, but this will be the outline. Intention is if your'e integrating a technology with a precedent on top of this stuff, use that terminology (unless it's master/slave)
- Vote: No objections.
- When to reconvene? ~1 month
- Bill: Code of conduct -> Sent email to list. Work was complete & Bill had action to fill in names of ppl. We have the new set of ppl. Text already approved by board.
- Tanmay Shah
- Nathalie Chan King Choy
- Maartin Koning
- Ed Mooring
- Bill Mills
- Tomas Evensen
- Bill Mills
- Etsam Anjum
- Stefano Stabellini
- Brief update on OpenAMP System Reference (end-to-end example)
- Any interesting topics that came out of Q/A at LVC21F? (https://events.pinetool.ai/2231/#sessions )
- Next steps on replacing master/slave terms in OpenAMP repos
- Getting access to MISRA C checker
- When to schedule next
- TSC call
- App Services call
- Shoot for mid to end of October for next App-services call (Maarten to confirm w/ devs)
- GitHub: Replace master branch with main branch, after 2021.10 OpenAMP release
- Maarten will check with the developers about date for: Demo & discussion of implementation & walk through the public repo
- Tomas, Bill, Kumar: Suggest who might be other key people to invite (e.g. Stratos)
- Tomas, Bill, Kumar, Maarten: Send Nathalie who are the "must attend" people for app-services
- Nathalie: Send doodle poll to "must attend" group
- Maarten: Send out invitation to the app-services mailing list and wider audience
- Bill: Check with Linaro if their discussion on inclusive terminology will expand to be public discussion
- Ed/Arnaud: Rename the master branch in OpenAMP GitHub repos.
- Ed/Arnaud: Discuss who of them will to update the master/slave terms in the code.
- Nathalie: Organize sync w/ Kumar and Kate, Bill, Ed, Arnaud, Etsam on MISRA C checking in Zephyr & what can be leveraged for checking OpenAMP.
- Nathalie: Reconvene TSC in 1 month. Agenda to include: TSC to approve Bill's proposal for master/slave terminology
- Link to recording (please download sooner than later to catch up, not sure how long before the recording link expires)
- Tomas: Brief update on OpenAMP System Reference (end-to-end example)
- Putting it all together. Crawl, walk run
- Step 1: Documentation on how to do Xilinx part & ST part to build Linux kernel and bare metal or Zephyr
- Run on QEMU & real HW
- Next:
- Zephyr
- Want to reduce having to pull in vendor-specific stuff
- Will introduce System DT
- So far contributing: Arnaud for ST, Tanmay for Xilinx, Bill for Linaro, Dan for Wind River
- Maarten: Dan has shared memory communication working now with VxWorks for ZCU102 QEMU. Working on Zephyr.
- Tomas: Benefit of having the group working together is we can resolve vendor issues more quickly
- Think it will be a couple months before we can tie it all together
- When to schedule next App Services call?
- Maarten: Been working on a virtio framework. A few weeks away from getting console working & pushing to public repo. Would like to walk ppl through and talk about the provenance of the code. How will be leveraging the Zephyr code base. Who would like to contribute? The whole group decided that the most important aspects are:
- File access
- VSOCK for IPC
- Remote console
- Network interface.
- Socket based VSOCK smaller & higher performance implementation could be preferable ___
- Maybe mid to end October
- Tomas: Timeline sounds good. Can we target specific ppl and make sure that those ones can make it to the call? Could also help with recruiting contributors.
- Bill: The soonest we could publicly demonstrate the simplest use case that ppl can reproduce is the real start of collaboration. That's when we should target.
- Maarten will check with the developers about date for: Demo & discussion of implementation & walk through the public repo
- Tomas, Bill, Kumar: Suggest who might be other key people to invite (e.g. Stratos)
- Maarten has been giving presentations about auxiliary runtimes for Linux and is getting queries from Arm licensees about using this w/ Zephyr. Think we're on the right track. Would be good to invite some of those folks. One also interested in RISC-V.
- Tomas, Bill: OpenAMP is Community Project, which means can look at non-Arm ISAs as well
- Tomas, Bill, Kumar, Maarten: Send Nathalie who are the "must attend" people for app-services
- Nathalie: Send doodle poll to "must attend" group
- Maarten: Send out invitation to the app-services mailing list and wider audience
- Maarten: Been working on a virtio framework. A few weeks away from getting console working & pushing to public repo. Would like to walk ppl through and talk about the provenance of the code. How will be leveraging the Zephyr code base. Who would like to contribute? The whole group decided that the most important aspects are:
- Any interesting topics that came out of Q/A at LVC21F? (https://events.pinetool.ai/2231/#sessions )
- No discussion
- Next steps on replacing master/slave terms in OpenAMP repos
- Bill: send the email to [email protected]
- Bill, Ed: GitHub: Replace master branch with main branch, after 2021.10 OpenAMP release -> Agree
- Bill: Remoteproc: Uses many terms. Let's try to make it consistent.
- Linux: remoteproc host
- Other end: remote processor
- Virtio: Device & driver could get confusing. Less confusing if prefix w/ virtio.
- Could use virtio nomenclature everywhere, but when move to services, can move to suggestions from Maarten
- Maarten: TCP connections: service & client makes sense
- Bill: Are we missing other context.
- Maarten: Have other suggestions in May email too: e.g. replacing blacklist with forbidden list
- Bill: Having a list is a good plan for the others, which we may use less of. Let's tackle replacing master/slave.
- Tomas: Like to have the bigger list so we know what we want to use in future. Would like to tackle master/slave 1st.
- Maarten: Could larger list be addressed at Linaro or other industry standard level that we can pull from & we can submit our suggestions?
- Bill: Have discussed internally at Linaro. Not sure if a public initiative. Would look to kernel for policy, except where terminology is more specific to OpenAMP.
- Bill: Check with Linaro if their discussion on inclusive terminology will expand to be public discussion
- 2021.10
- Code freeze in about 1 week
- Then probably release last week of October
- Someone can submit pull request anytime, but wouldn't bring in until after the release
- Ed/Arnaud: Rename the master branch in OpenAMP GitHub repos.
- Ed/Arnaud: Discuss who of them will to update the master/slave terms in the code.
- https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
- https://lwn.net/Articles/825319/
- Bill: Received request for libraries to start running MISRA C checks
- Would like our maintainers to be able to run pull requests & our code base through MISRA C checkers
- Thought TF had done it, but actually not the case
- Arm is doing it internally & fixing issues
- Stefano: Xen now has a plan. Making the plan took many months.
- First step is Tailoring. Need to look at the rules & figure out which apply to the project b/c the "advisory" ones are not mandatory & you can decide not to follow these rules. This took Xen the better part of this year. Zephyr also did same & shared effort. Came up with short-list of MISRA C rules to follow.
- Next step is how to check automatically for violations. Inexpensive to give the maintainers access to the rule set. Not enough to spot the violations. Need automatic checks.
- Next: Can we have open source automatic checker? How much does it cost?
- There is an open source checker that covers half to 2/3 of the rules Xen picked in tailoring.
- CPP check + various plug-ins can cover most of the violations. Since open source, can run it in CI loop.
- Multitude of proprietary ones - some are vastly superior to others. Require big budget in tens of thousands of dollars.
- Often have false positives, so need to be able to configure the tool
- Often don't care about absolute # of violations, rather the delta from previous scan, to know if pull request is introducing new violations. Only know of 1 tool that can do that.
- Bill: What is Zephyr doing?
- Stefano: Kate Stewart joins both calls & acts as bridge between Xen & Zephyr. Not sure if going through Zephyr budget or if one of the members is kicking in extra $.
- Stefano: Zephyr has gone through tailoring & looking into auto checking. Think they are talking to same vendor(s).
- Bill: At least OpenAMP code base is not huge. Being able to do it on patch basis would be nice.
- Stefano: Éclair IT MISRA C checker can do it on patch-by-patch basis & is a lot easier to configure
- Stefano: Example of complexity
- First time had tens of thousands of false positives, maybe 90% of errors were false positives:
- Every assembly instruction came up as error
- Inline is considered at every location
- Configuration: Many tools have to specify explicitly. For Éclair didn't have to do these detailed exceptions.
- First time had tens of thousands of false positives, maybe 90% of errors were false positives:
- Stefano: A good first step would be to run CPP Check. If OpenAMP code base is small, maybe it's not that hard to tackle it. Xen & Zephyr code base is huge, so need to plan how to deal with the long list of errors.
- Bill: Part of OpenAMP gets pulled into Zephyr, so maybe can tag along with Zephyr effort. Does Libmetal get pulled into Zephyr?
- Ed: Believe it gets pulled in, but not sure if it's used. If we added CPP check w/ appropriate plug-ins to existing flow, we could get a large amount of benefit for small cost. Maybe that's enough starting point for 2022.04 release?
- Bill: Good start
- Stefano: Coverity is used by many companies & open source projects. Think the corporate paid version can do MISRA C checking. Maybe one of the members could run the checking to get an idea of how many errors. TBD if would be allowed to publish the results of the scans.
- Ed: Agree, could get in trouble for publishing those results.
- Bill: If someone ran the scan, they could submit the fix saying they are fixing a rule violation. But, this means we would need engineering resources to support this.
- Etsam: Would like to explore static analysis locally. Would tailoring happen on patch-by-patch basis?
- Bill: Zephyr already doing work to tailor. Need to figure out who in Zephyr is doing the tailoring. We can buy copies of MISRA C spec for maintainers.
- Stefano: Tailoring is for project as a whole & depends on the use case. Not on patch-by-patch basis. Zephyr has published their list of rules. Xen list is similar. The rules are copyrighted, so might need license to view the list.
- Nathalie: Organize sync w/ Kumar and Kate, Bill, Ed, Arnaud, Etsam on MISRA C checking in Zephyr & what can be leveraged for checking OpenAMP.
- Nathalie: Reconvene TSC in 1 month. Agenda to include: TSC to approve Bill's proposal for master/slave terminology
- Bill Mills
- Tanmay Shah
- Maarten Koning
- Jeff Hancock
- Nathalie Chan King Choy
- Tomas Evensen
- Bruce Ashfield
- Loic Pallardy
- Stefano Stabellini
- Welcome Tanmay, introductions.
- Tomas: Heterogeneous end-to-end example (continued)
- Maarten, Jeff, Tomas: Inclusive terms (continued)
- What's our process to make changes to sensitive terms after deciding?
- Nathalie: Summary of website updates.
- Nathalie: When to have next call?
- Tomas to reach out on the TSC mailing list for who else is interested in going deeper into end-to-end example
- Nathalie: Send a doodle poll for end-to-end example call in 2-3 weeks to Tomas, Tanmay, Bill M, Kumar, Dan Milea, Arnaud, Jeff
- Define the use cases for replacing master/slave terms and post to TSC list for further discussion
- Maarten: app-services
- Bill: Lower-level
- Nathalie: Send Doodle poll for early September call
- Nathalie: Include outstanding governance items on next TSC agenda
- Link to recording. Please download a copy to view it sooner than later, before the recording expires.
- Introductions
- Tanmay will be Xilinx assignee to Linaro
- 8 yrs in embedded
- Previously in multimedia domain
- Recently joined Xilinx platform management team
- Nathalie
- Previously 11yrs at Xilinx in System level testing & System software. Had managed PetaLinux, QEMU & early OpenAMP team.
- Now doing Program management in Xilinx Open Source Program office
- Bill Mills from Linaro
- Currently at Linaro: LEDGE, LITE
- Previous life: 25 yrs at TI
- Bruce at Xilinx
- 3.5 years at Xilinx
- Maintenance work on Yocto project
- System DT: Wrote Lopper
- Jeff from Siemens Embedded (formerly Mentor)
- Started in 90s at Single Step Debugger
- Got acquired by Wind River
- Went to Renesas for Automotive
- Now Product manager for Nucleus RTOS & Multicore Framework (commercial OpenAMP w/ extra features)
- Starting to certify a certifiable version of Multicore Framework
- Maarten at Wind River
- Real-time & Safety runtime integration
- WR Linux, VxWorks RTOS
- Interoperability & resource sharing: Looking to build on top of OpenAMP -> app-services working group
- Stefano from Xilinx
- At Xilinx 4 yrs
- Xen Hypervisor development
- Working on System DT spec -> system-dt working group (call tomorrow)
- Tanmay will be Xilinx assignee to Linaro
- Heterogeneous end-to-end example (continued)
- Similar idea to what Linaro is also working on (Francois, Kumar)
- Will it be 1 project, 2 projects?
- Objective for this meeting: Who are interested in going deeper in what we are going to do?
- Tomas, Tanmay, Bill M, Kumar, Dan Milea
- probably Arnaud (confirm when he's back from vacation)
- Include Jeff for now. Jeff to check w/ Etsam and others.
- Who else wants to be part of core group that defines what we do?
- Who wants to be associated?
- Tomas to reach out on the TSC mailing list for who else is interested in going deeper into end-to-end example
- Tomas shared strawman proposal: Link to PDF snapshot
- Need to understand where we have gaps
- System DT is an important part of it
- Bruce: Lopper/Zephyr collaboration:
- Lopper is embracing some Zephyr tools: Can use their dtlib as pure Python parser, so don't need to use dtc
- Working to pull together reference System DT for various boards
- Having an end-to-end demo will help us reach out to more silicon & RTOS vendors
- Automotive could be interesting: Tanmay's graphics background, Siemens Embedded has Autosar experience
- Bill: Nordic's use case is MCU-MCU, which may be broader use case.
- Tomas: For future: 2 RTOS could be interesting. Most common case is Linux as big OS + RTOS.
- Loic: If can have same system DT configure the 2 RTOS b/c shows w/ same hardware or system config we can generate the right file for the different HW environments, with the same Linux managing the several sources, your co-processor can run different RTOS ecosystems
- Bill: For big demo use case: 1 Linux, 2 control processors with their own RTOS that communicate w/ each other
- Tomas: Could have R5 (split), Microblaze in Xilinx device
- Xen could be good hypervisor starting point: Applications don't change that much - how to build Xen & configure w/ DT. Stefano can help.
- Xilinx QEMU team can help, but probably won't call into the meetings. Will invite Edgar to at least 1 of the calls. Ideally, would like to use upstream QEMU, beyond Xilinx QEMU.
- Bill: When we get into this more, how to execute? e.g. virtual sprints. We're running out of runway to demo at Linaro Connect LVC21F. Shooting for end of year for this. Maybe could sign up for Linaro Connect demo Friday.
- Nathalie: Send a doodle poll for end-to-end example call in 2-3 weeks to Tomas, Tanmay, Bill M, Kumar, Dan Milea, Arnaud, Jeff
- Inclusive terms
- Siemens: haven't blessed everything, but have snip of relevant terms to OpenAMP
- Have been using remote for a while instead of slave but kept using master
- Xilinx focusing on master/slave, whitelist/blacklist, male/female connectors
- WR is mapping terms depending on the context & the guidance is loose. The point is to just remove master/slave.
- App-services very linux-centric w/ the daemon running on Linux as resource owner. The users of the services are the auxiliary doing runtime/safety. Would like to see a term for the host OS where it implies that it's the resource owner. Gets complex when safety OS is the auxiliary, even though it's the resource owner for a firewall, network service. Not sure if lifecycle is the right way to think of it.
- Linaro: No concrete discussion. OpenAMP largely based on virtio, so aligning to virtio should be a consideration
- Driver/device
- Host/guest don't really work great b/c that makes the remoteproc the host which is counterintuitive
- Agree it's context sensitive & main point is to eliminate master/slave
- Virtio & Xen terminology are different - messy
- Xen: Back end owns the resource, Front end connects to it. Clashes with virtio. Resource owner as driver domain b/c is physically driving the device.
- Virtio: Driver for front end.
- In future work (e.g. end-to-end example) we should avoid using terms like master/slave
- For OpenAMP, we should decide what we want to do
- Remoteproc master/slave
- RpMSG who owns buffer is different from primary for remoteproc - can be confusing which is master/slave
- Xilinx, WR no strong preference
- Resource owner
- Lifecycle instantiation
- Remote doesn't make sense in System DT b/c remote compared to what? Primary/secondary works better here.
- Maarten: Server as bigger/provider/owner. Client as user/smaller. Works for file system.
- Bill: I2C device on remoteproc is not intuitive. Prefer front end/back end for device sharing model, similar to Xen.
- With front end & back end you have to define it, so that can be a good thing.
- Bill: In OpenAMP, that would be remoteproc as server
- Tomas: App services using virtio - could use server/client there. For remoteproc to start up something else could use a different term.
- Bill: Leaving remoteproc out for now. Looking at device sharing. Remoteproc as back end works well & shows difference in use case.
- Linux + RTOS
- Do we need name for primary OS & secondary OS? Will really need to define.
- Maarten: Thinking of RTOSes as auxiliary OS for Linux, rather than primary OS b/c amt of SW that ppl don't want to port to RTOS. Linux-first approach: OK to call Linux the primary. RTOS vendors might not like their product being called secondary all the time.
- Bill: Depends on context and on role. System init vs device sharing: Who's primary & secondary changes.
- Tomas: Could use different words for big OS & small OS vs. providing of services.
- Maarten: e.g. Publisher/provider, subscriber/user
- Bill: Provider & user are more clear than front end/back end. Initiator, responder for communication links.
- Maarten: Provider suggests you own the resource & you provide it to users.
- Bill: Boot flow: Initiator & responder
- Next steps:
- Here's a starting list of use cases:
- What we call the operating systems (Candidate: primary/secondary)
- Communication (Candidate: Instantiator/responder)
- Services (Candidate: Server/Client)
- Define the use cases and post to TSC list for further discussion
- Maarten: app-services
- Bill: Lower-level
- Here's a starting list of use cases:
- Siemens: haven't blessed everything, but have snip of relevant terms to OpenAMP
- Next TSC call: Early September
- Nathalie: Include outstanding governance items on next TSC agenda
- Tomas Evensen
- Nathalie Chan King Choy
- Dan Milea
- Arnaud Pouliquen
- Jeff Hancock
- Loic Pallardy
- Stefano Stabellini
- Etsam Anjum
- Tomas, Dan, Jeff: Inclusive terms
- Tomas: Standardization
- Maarten sent to list what WR has
- Mentor Embedded (-> Siemens Embedded since January) is working on a document of recommendations
- Various LF members are part of https://inclusivenaming.org/
- Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit? Deadline is July 13, 2021
- Event is Sept 8-10, virtual
- Kumar, Stefano will try to join last 15 minutes: Tomas, Kumar: Heterogeneous end-to-end example
- Jeff to send Nathalie the Siemens logo [DONE]
- Nathalie: Check w/ Stefano if anything related to DT could make sense to present
- Tomas, Nathalie: organize a kick-off meeting for end-to-end example project
- Tomas: Call for interest to see if can harmonize virtio (both leadership, resources).
- Loic & Stefano to discuss virtio & Stratos alignment further.
- Nathalie: Schedule next OpenAMP TSC for end of July
- Link to recording: OpenAMP TSC - June-20210615 1706-1
- Not sure how long before it gets auto-deleted, so please download the recording in the next few weeks if you want to get caught up
- Inclusive terms
- Tomas: OpenAMP uses master & slave in different ways, so might have different end states for the different use cases
- Remote proc
- Who owns the buffers
- Maarten had sent to the TSC mailing list w/ different use cases for master/slave & what to replace
- For high availability: active/standby
- For clocks: primary/secondary
- For virtualization: host/guest
- For services: server/client
- For notifications: publisher (or provider) / subscriber
- For other scenarios: initiator/responder
- Xilinx: Trying to change forward-looking things
- Need to align w/ Arm for AXI
- At this point, have suggestions & not implemented yet
- Wind River
- Would be using "main context" (instead of master context) and keep "remote context"
- Siemens
- We have been giving guidance
- Siemens as a whole is going through the endeavor. A lot of products, so taking longer than originally hoped. Waiting for 1st draft to give feedback on.
- Would like to follow industry terminology
- Looking at enabled/disabled b/c disabled has negative connotation
- ST
- Waiting for some change from IEEE to change I2C spec which has master/slave before we change
- Starting to change some vocabulary, but don't have guidelines to share today: Main/secondary, Initiator/responder
- Also have to look at French inclusive language
- One good proposal for OpenAMP: main/remote instead of master/slave
- Are any OpenAMP participants taking part in https://inclusivenaming.org/ ?
- Tomas: OpenAMP uses master & slave in different ways, so might have different end states for the different use cases
- Linaro Connect LVC21F CFP
- Not sure if we will have enough on the end-to-end topic by September
- Last LVC21, we covered 4 perspectives on DT (Bill, Kumar, Andre, Stefano)
- Nathalie: Check w/ Stefano if anything related to DT could make sense to present
- End-to-end example
- New assignee b/c Ed left Xilinx. Maybe can get going w/ the project in July.
- Would like to move from Xilinx to upstream QEMU for CI loop & end-to-end - can get some help from a Xilinx QEMU maintainer
- Lopper: working on converting to what Zephyr needs
- Figure project could get started in July
- Open area where we could use resource w/ Zephyr expertise: Would like to get Zephyr up & running on various boards + KVMtool from WR
- Some work done by WR for serial IO, virtio
- Tomas, Nathalie: organize a kick-off meeting for end-to-end example project
- ST has some development working w/ Zephyr RTOS. Some customers who use Zephyr on ST platform.
- How to harmonize virtio in original OpenAMP under rpmsg + what came in via WR app-services contribution (BSD) + others working on
- Stratos project doing some work with Zephyr for hypervisor for automotive/embedded w/ security properties
- Some ppl, incl Arm, working on in Xen community
- Fair to have 2 communities/groups, but right now we have a dozen
- Default: Type 2 hypervisor: Virtualbox, kvm
- Other: Type 1: OpenAMP in this category
- There are some deep technical questions & unclear how to align. Complex.
- WR implementation based on memcopy by guest to/from pre-shared memory region
- Stratos aiming for memcopy into larger ring itself. Virtio ring to be expanded. No pre-shared region.
- Xen looking at enabling, but 3 virtio talks at Xen summit a month ago: Radically different approaches
- The commonality is that they're all trying to re-use most of the drivers. Maybe small changes to spec or bus driver/layer.
- Options: Could create group for all virtio. Could create group for embedded use case & hypervisor discussed in Linaro. Too hard & punt.
- Expect there will be 2
- Hypervisor based, but not Type 2. Not likely to work for OpenAMP.
- Memcopy based & almost no hypervisor. Hypervisor neutral & may work for OpenAMP -> Could make sense to unify these efforts across domains.
- Stratos
- WR
- Qualcomm posted some pre-shared memory approaches to LKML
- WR interested in aligning to a standard. Right now, still exploring & created POC. Trying to get the changes into a spec or align to an existing spec. Currently, no spec to align to.
- Vision of OpenAMP is to standardize at different levels. Becomes harder w/ different implementations.
- Siemens look at virtio for multi-OS offerings. Makes sense to have standardized back-end implementation w/ proper porting layer.
- Using with OpenAMP
- With I/O virtualization
- Automotive use cases (AutoSAR)
- Not sure if can do portable implementation w/ Linux, but with virtualization
- Even if we couldn't share entirely the approach (think we can), there is benefit to push forward virtio model that doesn't require Type 2. Causes problems in Linux kernel that is hard to fix. If could at least make the use case more widely understood, would be easier to upstream bug fixes to Linux.
- ST platform is smaller, so not targeting virtualization. Following the discussion on virtio though. Services need to share between main & secondary processors on top of virtio that we don't have on top of rpmsg. There is work to do for standardizing services to be able to multiplex on top of other things. Need to consider multiprocessor systems w/ limited memory. When to move on top of virtio & when on top of rpmsg.
- OpenAMP really looking into resource constrained devices.
- Hypervisorless virtio, embedded hypervisors
- Next: Consider starting working group on this topic. Would need someone who can drive it. Let's start with a call for interest to see if we can harmonize it.
- Tomas: Call for interest to see if can harmonize virtio (both leadership, resources).
- Loic's concern is that what gets merged in the kernel is only based on 1 use case, which would create a legacy and then redesign would be complicated. Good to discuss w/ Linaro & see if they want to extend scope of Stratos.
- Loic & Stefano had to stop attending Stratos calls since beginning of this yr b/c of meeting conflict.
- Loic & Stefano to discuss virtio & Stratos alignment further.
- OpenAMP is an important context b/c also get perspective of RTOS vendors.
- Next meeting: We will have the new Xilinx assignee & can talk more about the end-to-end example. Target end of July.
- Stefano Stabellini
- Arnaud Pouliquen
- Bill Mills
- Ed Mooring
- Etsam Anjum
- Grant Likely
- Ioannis Glaropoulos
- Loic Pallardy
- Maarten Koning
- Tomas Evensen
- Nathalie Chan King Choy
- 1 min: Maintainer news
- 10-15 min: Tomas, Kumar: Heterogeneous end-to-end example
- 3 x 5 min: Stefano, Bill, Maarten: working group updates
- 5 min: Nathalie: LVC21F CFP - Does OpenAMP Project have topics to submit?
- 10 min: Maarten, Jeff, Tomas: Inclusive terms
- 10 min: Tomas: OpenAMP resourcing needs for various upcoming initiatives
- Stefano & Nathalie: set up next System DT call (aim for mid-June)
- Stefano: Send out slide from today Slide here
- Maarten: Send out slide from today Slide here
- Maarten: Schedule meeting on the Zephyr work
- Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week)
- Nathalie: Set up follow-up TSC call in a couple weeks
- Link to recording (Not sure how long before it gets auto-deleted, so please download the recording in the next few weeks if you want to get caught up)
- Congratulations to Ed on retirement. Last day at Xilinx this Friday & has offered to continue as a maintainer.
- Xilinx is discussing internally to determine LITE assignee successor
- Stefano: System DT update (slide here)
- Did March LVC21 presentation on DT state of the union, including System DT
- Had System DT call earlier this month
- New developments
- Remoteproc
- Made sure the plumbing works from system DT
- System DT description is smaller b/c multi domain & multi cluster
- Lopper plug-in to generate traditional remoteproc binding from System DT info
- Biggest new development: Hierarchical domains & access flags
- There can be many domains (e.g. on different processors, with hypervisor). Best way to describe is in a hierarchical way. (e.g. VMs as domains under Hypervisor domain)
- Benefits:
- Closer representation to reality
- Access flags are domain specific b/c depends on the technology (e.g. flags on Xen domain different from flags for FreeRTOS running on Cortex-R)
- Remoteproc
- Lopper updates
- YAML as way to express info as input to Lopper
- Easier for humans to read/write than System DT format
- New DTS parser coming from Zephyr
- More lops & hooks for adding plugins
- Backends (incl. YAML)
- ReST API so you can invoke Lopper programatically
- Plugin for Xilinx CDO generation as example of plugin for generating other boot-time scripts
- YAML as way to express info as input to Lopper
- Stefano & Nathalie: set up next System DT call
- Bill: What's plan for System DT spec?
- Stefano:
- For now, we're putting the description we have in the Lopper repo in .rst files (similar to DT spec)
- Some changes (not many) will need to go to main DT spec. Small but impactful.
- Domains could be in main DT spec or could go elsewhere. Self-contained & a bit separate.
- Loic: SystemDT & Zephyr?
- Stefano
- Bruce & Kumar have a plan
- We sent a small system DT example with a couple domains (one of which is Zephyr) to Kumar for him to try to integrate it
- Lopper adding alternative DTS parsing: Pulling the Zephyr parser in Lopper. Idea is to merge the 2 efforts.
- Loic: So, no firm commitment from Zephyr community to move on System DT?
- Stefano: Not sure. Kumar is main point of contact.
- Loic: Now is currently more evaluation & no strong decision?
- Tomas: More similar to Linux, DT is not changing for that. Start state: Can use Lopper & create a DT for Zephyr. Optional if you don't have multiple clusters.
- Loic: Even without multiple clusters, you can use Lopper to transform DTS file to avoid duplicating different tools. MCU boot & TF-M, with Cortex-M with Secure/NS have problems describing the IP. Know Linaro working on TF-M integration w/ Zephyr. Would be good to have common system descriptions for the different SW components. Difficult for SoC system to embed DT, so if Zephyr is moving on that, can see others to move.
- Tomas: Would be ideal. Intent is to have 1 way of doing it.
- Bill:
- Break into 2 problems:
- System DT part.
- Whether you are consuming system DT and know which node you are, or you generate a node-specific DT & how do you update code to match.
- Today, can do System DT processing & deliver DT to Zephyr
- How do we do same thing with Trusted Firmware or OP-TEE, etc?
- Zephyr looking at how to make what they do more portable to other projects, whether or not the input is System DT is orthogonal
- Break into 2 problems:
- Stefano: Right now more looking at reusing Lopper to manipulate DT. Lopper as a framework, can add a lot of value. Lopper is more flexible than what Zephyr currently has.
- Maarten: App-services update (Slide here)
- Goal: Enable multi-OS systems to achieve Linux-based application-friendly resource sharing & IPC on multi-core HW.
- Approach:
- Want to reduce learning curve: use existing APIs, drivers, etc.
- Provide unifying way to share resources across different deployment architectures & do IPC across
- Path for mixed criticality & safety
- Decisions & Next steps (refer to the slide)
- Tomas: Ties in well to end-to-end example
- Bill: You ran demo with RTOS + Linux. kvmtool up on OpenAMP GitHub. RTOS not yet visible to everyone?
- Maarten: We implemented it with VxWorks & Linux.
- Bill: Can I do it without paying a VxWorks license?
- Maarten: There are non-commercial offerings from labs.vxworks.com.
- Demonstrated initially with VxWorks
- Want to get the Zephyr part done, so that others can contribute. Did BSD virtio port. Open sourced the user level daemon based on lkvm. Demonstration & validation activity with VxWorks to prove it out & show the value. Understand that we need to get it onto Zephyr so that others can contribute.
- Would like to try to get some OpenAMP reserve funds to accelerate the Zephyr aspect.
- Loic: New virtio framework for Zephyr instead of reusing virtio framework in OpenAMP library? Both are based on FreeBSD implementation. Zephyr has virtio framework, but it's already part of OpenAMP library.
- Maarten: Not aware of other Virtio framework for Zephyr before the one that we did.
- Maarten: Researcher in Japan did some work based on Linux GPL implementation of virtio and did some tests, but can't release on Zephyr b/c license used for that code.
- Bill: True. OpenMAP has been part of Zephyr for several years. Virtqueue is part of the rpmsg stack. With your contribution, there is a duplication of the virtqueue level.
- Maarten: If derived from BSD, would be great to reuse that code. We took FreeBSD virtio code & built it for Zephyr on framework side. We didn't look at optimization/duplication & that work hasn't happened yet. Would be great to have some work on optimization.
- Loic: OpenAMP virtio will require some modification of virtio service layer in OpenAMP. Would be good to port on several OS with OpenAMP library used for virtio instead of duplicating virtio in each project.
- Maarten: We should have meeting on the Zephyr work
- Tomas: Potential task could be to harmonize the virtio solution in end-to-end example
- Bill: Need to discuss scope of app-services
- Good to focus on: Using hypervisorless virtio as a transport
- Some of the other parts intersect rpmsg, remoteproc & system DT
- Still have yet to demonstrate the full flow in a truly open source manner.
- Concern that scope is starting to encompass the other parts of the project & not fully open source yet.
- Maarten: Agree. We should be focusing on the all open source implementation w/ Zephyr
- Have been leveraging some efforts at WR
- Demo would be contingent on dependency of Zephyr investment. Would like this group to see how we can resource the open source demo.
- Bill: Engagement on proprietary is perfectly fine. But want to enable community to measure what you're demo-ing. When at TI, didn't use OpenAMP, but invested in the open source to prove out concept. Would like to understand what remains to be resourced.
- Maarten: We did the framework and console. You need the 9p filesystem protocol and you need the vsock: those are both virtio-specified drivers that don't exist for Zephyr that need to be ported from another runtime. We were focusing on the user-level daemon based on lkvm to terminate the hypervisorless virtio and open sourced that. We did the framework for Zephyr & open sourced that and been contributing into Zephyr as well.
- Bill: Can we run a fill demo with just console today with Zephyr and Linux?
- Maarten: No hypervisorless virtio yet in Zephyr. There's just Zephyr virtio framework. Need MMIO driver & interrupt going across to Linux.
- Bill: openamp-rp update has been posted to list
- New openamp & libmetal library versions released
- Significant progress on kernel upstreaming. Slowed down a bit b/c have worked through backlog of high-priority stuff. Xilinx R5 stuff important & still outstanding.
- Starting discussion on some PRs pending with big changes w/ wire protocol changes
- Thinking about namespace 2.0 proposal, future proof & backward compatible
- Resource tabling enhancements that Arnaud is working on, but need to define current spec for resource table, so can make proposal for the enhancement.
- Negotiating message size dynamically at startup time
- Future work:
- We don't have a good spec for what the wire protocol is & need one
- Right now we just look at what Linux is doing & be compatible
- Once we have the spec, then we can have wire protocol spec changes
- At the same time, want to tackle the OpenAMP doc infrastructure. Will be Sphinx-based. Won't be as fancy as Zephyr or Yocto Project, but they are good examples to look at. Would like to have demo of the doc infrastructure by next TSC (e.g. top level table of contents, how to generate PDFs).
- Low hanging fruit w/ CI
- Demo: Rpmessage with 2nd virtqueue doing a mainstream virtio protocol. I2C is a decent example in upstream kernel.
- Different from Maarten's primary use case for remoteproc (them using services from Linux), this would be Linux using services provided by remoteproc.
- But there's a lot of commonality, so would be good to collaborate w/ app-services
- We don't have a good spec for what the wire protocol is & need one
- Tomas: End-to-end example (covering all the OpenAMP sub groups)
- Link to strawman proposal in Google Docs
- Linaro LITE have been talking about heterogeneous example which is very aligned with what we are trying to do
- Running Linux on Cortex-A cluster, maybe add Xen later. Cortex-R or M cluster with Zephyr as RTOS.
- Initial platforms to consider:
- Ultra96 or Xilinx SOM (A53 + R5)
- ST stm32mp1 (A7 + M4)
- QEMU
- Want to be able to measure throughput & latency
- Would like to show configuration w/ System DT, lifecycle using remoteproc, low-level messaging, app-services
- First: Enumerate the tasks, then look at resourcing.
- Would be great if LITE can do the project management, if aligns sufficiently
- Still at concept level & invite others to chime in
- Maarten: Like resourcing app-services so we can have OSS implementation
- Bill: Timeframe?
- Tomas: Hope for end of year, but depends on what resources we can get.
- Bill: Linaro Connect, ELC, Plumbers would be good place to show subset of progress in fall
- Tomas: Plan to discuss more with Kumar
- Tomas, Bill: discuss resource plan in another meeting soon w/ Kumar (this week)
- Nathalie: Set up follow-up TSC call in a couple weeks