OpenAMP System Reference Working Group Meeting Notes
Nathalie Chan King Choy edited this page Jan 12, 2024
·
83 revisions
OpenAMP System Reference Meeting Notes 2024
To avoid breaking 2022 links & going past max page length: OpenAMP System Reference Meeting Notes 2023
- Tammy, Tomas, Arnaud, Tanmay, Nathalie, Dan
- Key learnings / retrospective on Tuesday’s webinar
- Next steps for System Reference WG
- Call frequency going forward for System Reference WG
- Webinar outcome positive & lays a good foundation to seek more involvement
- (OBSOLETE) Nathalie: Ask Linaro Events what attendee info is possible to share with us, if we are interested in making contact
- (DONE) Nathalie, Tanmay: Check if YouTube comments are enabled for our webinar video
- Yes, they are enabled
- Tammy: ask Marketing manager to see what he thinks about Nucleus binary download for demo (NOTE: Nucleus is using proprietary MCF)
- (IN PROGRESS) Dan: ask WR about binary SDK support for smaller target like R5 on ZCU102
- (DONE) Nathalie: Compile brainstorm ideas for next steps into a Google Doc and share for adding to it & discussing in January
- Doc is here (access limited to WG members)
- Retrospective: What went well?
- Nathalie: Good attendee turnout & interest.
- Dan:
- Editing: Flowed & was easy to watch
- Questions: Good that we were able to steer towards OpenAMP, instead of niche technical deep dive
- Tomas: Can we find out more about the ppl who were engaged & asked lots of Qs?
- Nathalie: Can ask Linaro Events what is possible to share with us to make contact. GDPR may limit.
- Tomas: One did join mailing list
- Nathalie: Some joined Discord
- Arnaud: Someone also looked at docs & gave some feedback. Expect will see some more feedback over next few weeks.
- Tanmay: Do we keep the YouTube comments enabled/disabled?
- Had received no questions/comments in the YouTube livestream chat
- Tanmay: Thanks to Tammy. Docs really well indexed, easy to list everything in a standardized way
- Arnaud: Agree. Thanks to Tammy.
- Retrospective: What could have gone better?
- For a couple of us: remembering to turn on camera
- Destination of messages in Zoom chat sometimes got mixed up (DM vs. everyone)
- Tanmay: What is the cadence of presentations?
- Nathalie: Have targeted Linaro Connects before, this year we had a one-off b/c no event.
- Arnaud: Should ask Bill if he has any HPP objectives in Linaro for presenting
- Next steps for System Reference WG
- Tomas: Device Trees: Bruce discovered ways we can use it better in Yocto. There's some cleanup to do around that to make it more usable for non-Xilinx folks.
- Tanmay: Would like to provide steps to run on KV260. The images are tested on KV260, but not documented. Not sure where the images should be provided - can discuss when Bill is available.
- Tomas: How much have we done with Zephyr on R5 on Xilinx boards?
- Tanmay: Zephyr basic demo hello world is working. RPMsg not there. Internal to Xilinx, we just have FreeRTOS & bare metal. Remoteproc part of driver is upstream. Once RPMsg part of driver is upstream, that will provide standardized way for us to port to Zephyr.
- Tomas: Would be powerful to be able to demo same on ST & Xilinx boards. If we can get renewed engagement by NXP, maybe their HW.
- Arnaud: No blocking point to have my system reference demo on ST, Xilinx & NXP. Just need to implement machine part in Zephyr. Can advise on how to achieve.
- Dan: Infrastructure for notifications on ZCU102 is in hypervisorless virtio setup in Zephyr. Had to support some functionality of mailbox IPI controller. Part of that is reusable & in our fork of Zephyr.
- Tomas: Would be cool to show it's not just for OSS, but also VxWorks & Nucleus. VxWorks has open download. Does Nucleus have open download?
- Tammy: We don't have a binary download, just an evaluation via sales channel. Could ask Marketing manager to see what he thinks.
- Tomas: Even if it was binary for a couple boards & binaries for libraries, then with open source
- Tammy: We do use our own tools in the packaging of ELF & DT, so might require distributing the tool.
- Dan: VxWorks has binary SDK. Could try to talk them into supporting a smaller target (e.g. R5 in ZCU102 board) and make part of similar setup that Bill showed with PetaLinux on A53, that could be showed on its own on ZCU102 board or QEMU. Could pitch it to them.
- Tomas: Think it could be good PR for both OpenAMP & the respective operating systems
- Tomas: When is a good time to get a Xen example? Think this can also help us uncover issues on the big cores.
- Tanmay: Demo to confirm someone has ported OpenAMP to their platform correctly. Same sources, except for platform-specific info.
- Nathalie: Create a Google doc & share
- Call frequency going forward for System Reference WG
- Cancel next week
- Let's pick up on 18th - single meeting & we can discuss the series at that time
- Congrats on a productive several months, really great work!
- Tammy, Bill, Tomas, Dan, Nathalie, Arnaud, Tanmay, Bruce, Ben
- We've still got a few open items in the tracking sheet to discuss: https://docs.google.com/spreadsheets/d/1SkQvq34NJBjJM56T6nm9fknJGTHutfV-LJd9oEKtiGs/edit?usp=sharing (I added the to do items from Bill's email)
- Brainstorm some backup questions if Q/A is quiet
- YouTube channel that would be appropriate to moderate questions from
- Webinar dry run Thur 16:00 GMT with Events team?
- Any specific topic requests?
- OK to update OpenAMP website blog when the webinar materials are finally posted
- Aim to finalize documentation locations/links & "try it on your own" slides by end of this week, so we can send the PDF to Sabrina on Monday
- Currently, the doxygen HTML is going to the openamp.github.io because of the GitHub automation. We realize that is the dead website repo, but the functionality is handy.
- (DONE) Tammy: Combine doxygen & markdown docs into same doc folder. OK to rename to "doc" to match libmetal.
- (DONE) Dan to try out demo4 shortcut in demo-lite
- (DONE) Dan to split out demo-lite instructions from build instructions in https://github.com/danmilea/hypervisorless_virtio_zcu102/blob/openamp-demo/README.md and submit PR so each is linked to show up in the docs for demo.
- (DONE) Tammy will pull in Bruce's README as Markdown https://github.com/devicetree-org/lopper/tree/systemdt-linaro-demo/demos/openamp
- https://github.com/devicetree-org/lopper/pull/136 (merged)
- https://github.com/OpenAMP/openamp-docs/pull/4 (pending Ed's review)
- (DONE) Tammy will pull in System Reference repo into the docs, which will automatically pull in Tanmay's standalone instructions
- (DONE) All: Try things out today or tomorrow & let Bill know feedback
- (DONE) Arnaud to merge https://github.com/OpenAMP/openamp-system-reference/pull/5
- OpenAMP repo PR for doxygen to build into HTML file
- Tammy disabled the warnings
- Arnaud prefers not to duplicate documentation folder for .md or doxygen. Prefer to combine.
- Tammy: Combine doxygen & markdown docs into same doc folder. OK to rename to "doc" to match libmetal.
- Bill can publish HTML for Sphinx to link to, as long as it's not too many times
- Whenever we merge, it rebuilds everything. Then we have to push the HTML manually. Is there a way to automate?
- Bill: Future work. Would require to change how old website stuff publishes to github.io
- Using github.io b/c of GitHub automation
- Could spin up another server at docs.openampproject.org, like Zephyr does, but can think about that later
- Just want 1 version to be published by webinar & will be manual, so will use github.io for simplicity
- Docs to pull in the demos for webinar
- Tanmay pushed README to openamp-system-reference that shows how to execute demo. It's linked by linking, not in Sphinx table of contents.
- Arnaud made his documentation appear in the Sphinx documentation
- User can also go directly to system reference to look at demo instructions & be in the Sphinx TOC. Just requires a PR in both. Need to add to sphinx file in index.rst
- Bill would like to see each demo as a separate page, instead of all in one page (demo/index.rst & link to the README, which is already pulled in)
- Dan has instructions in his hypervisorless virtio build environment repo for building. Also includes instructions on how to run the demo in demo-lite setup.
- Dan to try out demo4 shortcut in demo-lite
- Dan to split out demo-lite instructions from build instructions in https://github.com/danmilea/hypervisorless_virtio_zcu102/blob/openamp-demo/README.md and submit PR so each is linked to show up in the docs for demo
- Bruce has README in demo branch
- Tammy will pull in Bruce's README as Markdown https://github.com/devicetree-org/lopper/tree/systemdt-linaro-demo/demos/openamp
- Tammy will pull in System Reference repo into the docs, which will automatically pull in Tanmay's standalone instructions
- Bill update
- Integrating Bruce's stuff into the Docker container today
- Dan's demo is integrated
- Split demo has been fixed
- Crashing fixed
- Known issue: No support for Arm Macbooks. Won't be fixed by webinar day. Future work.
- Can work around by X86 emulation
- All: Try things out today or tomorrow & let Bill know feedback
- Brainstorm questions?
- If we have ~100 attendees, we probably don't have to. How many registrants?
- We can check w/ Events team tomorrow
- Nathalie to merge slides, but need Try it on your own finalized. Shoot for end of week.
- Check w/ Sabrina who will present the live slides.
- Arnaud to merge https://github.com/OpenAMP/openamp-system-reference/pull/5
- Tomas, Bruce, Bill, Tammy, Arnaud, Dan, Tanmay, Nathalie
- Is KV260 supposed to be part of webinar demo?
- Do we need to record transitions?
- Any issues found in video reviews?
- Does Tanmay's section look OK resized to 1080p from 720p?
- Resize Arnaud's slides to full screen?
- NXP
- Do we need to shorten the "dead air" sections of demo?
- Confirm Discord channel on Linaro's Discord
- KV260 not part of webinar demo. Stretch goal to provide image.
- The sections flow well, don't need to record transitions.
- No issues found in video reviews
- Tanmay's section looks OK resized
- Arnaud re-recorded with slides as full-screen
- Keep NXP on the slides
- Shorten the dead air sections
- We will post link to #openamp-community channel on Linaro's Discord so that ppl can ask questions when they try stuff out
- These will finalize by Dec 7: Docker image, Wrap-up slide, Docs
- Let's use 1 word for devicetree
- Can cancel Wednesday sync
- (DONE) Tomas will try to get hold of Rob from NXP to ask about their membership in OpenAMP
- Rep from NXP has set up a call w/ Tomas
- (DONE) Bill: Add to live slides: slide to mention all the mailing lists (OpenAMP, Linux RP?), Discord link
- (DONE) All: Send Nathalie your head shot or add it to the wrap-up slide
- (DONE) Nathalie: Add employers to Q/A slide
- (DONE) Bruce will send Bill the branch on Lopper GitHub repo
- (DONE) Bill: Let Nathalie know which slide deck & slide # to fix in editing of video
- KV260 platform
- Don't need to put it into the recording
- Stretch goal to provide image for ppl to try on KV260 for 13th. OK if we don't get there.
- Should not be too hard to get there.
- Can use same image as QEMU, build it & put it in boot partition. Just need to adjust boot source to pull from FAT filesystem instead of TFTP.
- Need RPU FW binaries for KV260 b/c different serial port (Tanmay has provided). Can build on host to have unified CPIO to use on board.
- Recording transitions between section
- Bill introduces Arnaud
- Arnaud & Tanmay introduce themselves
- Dan: They work together as-is, b/c either ppl are introduced or introduce themselves
- Issues
- None really, besides value of pi ;)
- Timing: 93 min is good, plenty of time for Q/A
- Should we keep NXP in the slides?
- Previous NXP reps in OpenAMP left NXP. Have been having difficulty to reach someone to participate.
- Tomas will try to get hold of Rob from NXP to ask about their participation in OpenAMP
- Meanwhile, let's err on inclusivity & keep them in the slides.
- Let's shorten some of the dead air spaces & can annotate the screen with 2x or something for transparency
- Typing
- System boot
- Bill: Add to live slides: slide to mention all the mailing lists (OpenAMP, Linux RP?), Discord link
- Dan uploaded hflip video
- Channel in Linaro Discord
- Bill sent invitation link to us
- Can we later revoke an unlimited invite? Yes. Also, can always kick-off malicious actors.
- Arnaud:
- Who can be moderator?
- GitHub discussions may be an alternate method. 1 channel per project repo. More latency, but nice to have trace of the discussion.
- Discord is not great for history
- Bill: Discord may be good for hands-on demo support. Similar expectations as with IRC, user can try mailing list if they don't get a reply.
- Bill upgraded our Docker Hub account
- Free version was 100 pulls in 6 hours. Upgraded is many more per day, so should be OK if everyone from webinar tries demo at the same time.
- Can add 1 more person as a collaborator, possibly even with free tier. Level that allows formal team on DockerHub costs $300/yr. Can discuss later if that's needed.
- Might be OK to go back to non-paid tier after a while
- Do we still want Wednesday sync up? Can cancel.
- All: Send Nathalie your head shot or add it to the wrap-up slide
- Nathalie: Add employers to Q/A slide
- Bruce's demo
- Bruce will send Bill the branch on Lopper GitHub repo
- These will finalize by Dec 7: Docker image, Wrap-up slide, Docs
- Let's use 1 word for devicetree. Devicetree.org is not consistent either >_<
- Let's edit the slides for PDF to 1 word, no capital T
- Bill's recording is 2 words w/ capital T
- Bill: Let Nathalie know which slide deck & slide # to fix in editing of video
- Trying to explain in webinar has been valuable pipecleaning exercise
- Tammy, Dan, Tomas, Bruce, Nathalie, Arnaud, Bill, Tom
- Discuss template
- Logistics for Review demo steps
- Finalize how we want to incorporate key takeaways summary -> Due 11/28 or record 11/29?
- Individual updates
- Convergence
- We'll keep the red for the takeaway line in the template, for now
- Let's have faces on the demo part, where possible
- Material for attendees will be at one landing page in read-the-docs
- (DONE) Bill will post the wrap up slides & share. Add something about CI
- (DONE) Tomas: Leave out the specific URL in the System DT slides & we'll punt where to find instructions to the wrap-up
- (DONE?) Tomas & Bruce come up with What's next bullets for System DT
- All:
- (DONE) Fine tune your key takeaway message in the 1st col of the webinar plan before Friday (when Bill will record)
- (DONE) Put the documents from personal Google Drive areas & Google Slides version of our final presentation in the OpenAMP System Reference Google Drive folder so that we can re-use the content for future presentations
- (DONE) Bruce to hand off content to Bill to put in the main demo Docker container
- (DONE) Bill to accept Arnaud's doc PR
- (DONE) Bill to provide the additional tasks either in the Task Tracking sheet or send to Nathalie
- (DONE) Bill: OpenAMP DockerHub needs to get upgraded to $8/mo version from free version
- Bill will look into: Is there a way to allow other ppl to log into that account?
- (DONE) Nathalie: Consolidate the decks once final. Make sure to include the live slides. Check w/ them if they need a version before the presentation. Delete the face rectangles.
- (DONE) Nathalie: Check w/ webinar team about how we make sure the live parts get included in the posted recording
- They will post the Zoom recording of the whole thing (editing, if needed)
- Template:
- Red for key messages -> Does it imply issue? Should we choose different? Matches logo.
- Cyan for emphasis?
- Recording:
- Let's have faces on the demo part, where possible
- Introduction section:
- Bill shared Introduction slides
- 2015 was OpenAMPproject start. Multi-core association press release was 2016
- "Wrap up" section:
- (DONE) Bill will post the wrap up slides & share. Add something about CI
- All: Fine tune your key takeaway message in the 1st col of the webinar plan before Friday (when Bill will record)
- What's next should go in this section. May need 2 slides to fit everything
- Dan: Virtio part looks good
- Tag lines
- How to try on your own
- Live slide to leave up during Q/A
- Pictures, names & roles of everyone in the Q/A (due 12/13)
- Directing attendees to supporting materials
- Bill proposes that we have 1 landing page on read-the-docs
- (DONE) Tomas: Leave out the specific URL in the System DT slides & we'll punt where to find instructions to the wrap-up
- (DONE?) Tomas & Bruce come up with What's next bullets for System DT
- Recording plan
- Bill is recording on Friday, so can take feedback prior to then
- Arnaud will review Bill's slides tomorrow
- Tomas will probably record on Sunday
- We adjusted the times in the plan
- How to try it on your own will be live
- Nathalie: Check w/ webinar team about how we make sure the live parts get included in the posted recording
- Bill is recording on Friday, so can take feedback prior to then
- Arnaud update
- Docs done
- Bill to accept Arnaud's doc PR
- Bruce to hand off content to Bill to put in the main demo Docker container
- Docs done
- Bill update
- Bill to provide the additional tasks either in the Task Tracking sheet or send to Nathalie
- Bill: OpenAMP DockerHub needs to get upgraded to $8/mo version from free version
- Bill will look into: Is there a way to allow other ppl to log into that account?
- Slides
- Nathalie: Consolidate the decks once final & send to Linaro on 12/13. Make sure to include the live slides. Check w/ them if they need a version before the presentation. Delete the face rectangles.
- All: put the documents from personal Google Drive areas & Google Slides version of our final presentation in the OpenAMP System Reference Google Drive folder so that we can re-use the content for future presentations
- Tammy, Arnaud, Dan, Tomas, Tanmay, Nathalie, Bill
- Catch everyone up on the new plan for recording (since webinar is 2h but our 29th Nov slot is only 2h), as several presenters couldn’t join when we discussed last week
- Add elevator pitch/key takeaway for each section of webinar plan to make sure that it comes out clearly in each presentation.
- Slides creation
- Webinar promotion
- Individual updates
- Let's use Google Slides. 16:9
- Each person creates their own deck, then can merge after the recording for posting.
- (DONE) Nathalie: Look into making a section separator
- (DONE) Arnaud: Check that the pulled doc is accurate for ST & create Sphinx page that could be pulled in
- Catch everyone up on recording plan
- Because of 2hr webinar & 2hr recording slot
- Deadline: 28 Nov at 8am Pacific Time: Each presenter should record their presentation & demo on their own & send to Nathalie.
- What tool? Can use Zoom or others
- Will the faces be part of the webinar? Faces. Nathalie added a keep-out on the slides template for where the face will go.
- How to organize slides?
- Each person can create own deck
- Can merge after recording for posting
- Let's all use Google Slides
- Nathalie: Look into making a section separator
- Tomas update
- Tomas & Bruce had 1:1 yesterday & started to put things together for presentation
- Arnaud update
- Started to create slides for ST & slides to propose for Bill
- Started to update the demos documentation in system reference wiki & modify README of Zephyr sample, so demo will be in 2 parts
- How to build ST image
- How to load FW, RPMsg demo in Zephyr
- So there will be wiki page & README .RST file
- Tammy: STM demo doc is being copied from wiki manually
- Arnaud: Check that the pulled doc is accurate for ST & create Sphinx page that could be pulled in
- https://openamp.readthedocs.io/en/latest/demos/system_reference.html#multi-rpmsg-services-demo
- https://openamp.readthedocs.io/en/latest/demos/system_reference.html# should match content from https://github.com/OpenAMP/openamp-system-reference/wiki/Samples-and-demos
- Bill update
- Pulling together Docker images for demo
- Working on Yocto build infrastructure
- Met with Dan on how to get things into Docker container
- Met with Bruce & Tanmay on System DT stuff & will meet again today
- Struggling to get upstream kernel to work reliably on Xilinx QEMU. Works ~80% of the time…
- Tanmay has been helping & have got 6.0 kernel working on QEMU & KV260. Have not tried on ZCU102 board. Building Linux OpenAMP staging branch from Bill's defconfig. Including the drivers so don't have to install modules. Not doing Xilinx config.
- We haven't officially tried 6.0 kernel at Xilinx.
- Michal might be a person to reach out to for Linux & OpenAMP would be Ben.
- Tanmay can test images.
- Next: Will back out of 6.07 + cherry pick patch on top of 6.00
- Working on Mark's meta-open-amp PR
- Dan
- Looking into aligning demo with structure Bill uses for his. Not sure how big the container images will get. ETA end of week.
- Status of PR for hypervisorless virtio is a bit fuzzy. Found breakage in validation scripts for OpenAMP pull requests. Arnaud will have to fix.
- For demo, will use the virtio-exp branch in our Zephyr fork with a clone of Dan's OpenAMP fork b/c not sure when the latest PR will get merged.
- Tanmay
- Have been testing Bill's docker images. Working fine. QEMU working fine.
- Haven't tried latest. Will try latest.
- 6.0 kernel up & running on KV260. Haven't tried Bill's rootfs, just what Yocto is building (Xilinx Petalinux).
- Have prepared slides. Split up lockstep & split into 2 slides & we can get rid of 3rd slide explaining the demos.
- Tammy
- Will everyone post their instructions to our docs?
- Bill: That is the plan. We have time after recording day
- Tammy, Bill, Tanmay, Arnaud, Nathalie
- Because Doxygen doesn't convert well to markdown or RST, we will generate an HTML snapshot, host it somewhere & hard-code the link.
- It's OK if ppl submit PRs for docs, we don't have to discuss beforehand
- (DONE) Tammy: Hide any items that need to be hidden from the Sphinx file
- (OBSOLETE) Tammy: Generate HTML tarball for OpenAMP & libmetal doxygen
- (DONE) Bill: Post the HTML & notify of the URL
- (OBSOLETE) Bill will create initial spreadsheet w/ TOC with hide/not hide & owners
- (DONE) Tanmay to review the Xilinx demos & advise which to hide
- Bill's feedback
- See email that he sent just before this meeting
- Would be good to have the libmetal API
- Tammy: Hide items from the Sphinx file
- OpenAMP API comes from link to OpenAMP repo markdown, which isn't including Doxygen
- Doxygen format doesn't convert well to markdown or RST
- Bill: What's in there now is a good start. If could do same for libmetal, that would be great. If markdown doesn't exist for libmetal though…
- Tammy: No equivalent markdown in libmetal to what we have in OpenAMP
- Arnaud:
- Perhaps simpler to maintain: Generate Doxygen for API b/c it's inline in the code
- Downside is need to have a GitHub action to generate each time & updater/maintainer needs to remember
- Arnaud: What about having a dated snapshot & disclaimer to check code for latest?
- Bill: What was issue w/ Doxygen
- Tammy:
- Did get it built, but can't just include HTML with Sphinx. It has to come from Markdown or RST.
- Investigated a tool, but it generated XML that wasn't clean & needed hand-mods, which doesn’t fit into automation flow.
- Had looked at tool Bill suggested, but nothing promising.
- Bill:
- Suggest to have a placeholder for libmetal API & put "coming soon"
- Could generate HTML once & put in a link to the HTML somewhere (maybe github.io?) & automate it later. Can look into automating after the webinar.
- Zephyr was generating HTML. They run their own readthedocs server, so could have a mix of Sphinx & HTML.
- Tammy:
- Minimum would be "coming soon"
- Could put instructions for how to generate doxygen from your local branch
- Bill: That could go in the readme of the doc.
- Decision: Generate the HTML that we host somewhere & hard-code the link. Discuss offline
- Tammy: Generate HTML tarball for OpenAMP & libmetal doxygen
- Bill: Post the HTML & notify of the URL
- Tammy: OK if ppl just submit PRs, don't have to discuss everything beforehand.
- Arnaud: Skeleton as first step & then fill in part by part
- Bill: Rather show smaller set of stuff that ppl should be paying attention to now as a first-time user (don't need to worry about how the group is organized). Rather have quality before more content.
- Need to enumerate the samples & demos
- This will result in more owners to scrub
- Some of the demos won't be part of the demo - can choose to hide those
- Tanmay: Let's hide the demos that aren't part of demo b/c not tested
- Tammy: Hide all the items that we agree upon
- Bill will create initial spreadsheet w/ TOC with hide/not hide & owners
- Tanmay to review the Xilinx demos & advise which to hide
- Scrub owners:
- Project overview: Bill
- Docker images: Bill
- Ben, Tanmay, Arnaud, Tammy, Bill, Nathalie
- Ben & Tanmay had to drop for a conflict
- Bruce & Tanmay updates so they can drop for the AMD all-hands
- Rest of individual updates
- Go over purposed outline
- Discuss recording (our webinar slot is 2 hours and we only have a 2
- hour recording window)
- RFC docker demo prototype
- Slides
- Assigning convergence tasks to owners
- Advertising
- Deadlines:
- 14 November EOD: Submit pull requests for documentation
- 18 November EOD: Slides draft deadline + draft demo walkthrough (in text form)
- 22 November EOD: Give feedback on slides
- 28 Nov at 8am Pacific Time: Each presenter should record their presentation & demo on their own & send to Nathalie.
- 29 Nov 10am Pacific Time: Nathalie will mock-up the combined video so we know what needs discussion/re-do during 29 Nov recording session
- Last slide that is on during Q/A should point to the resources, in case viewers don't stick around for end of Q/A
- (DONE) Bill: schedule meeting for Bruce/Tanmay/Ben on Lopper demo
- (DONE) Bill: schedule meeting with Dan on virtio demo
- (DONE) Tanmay: Will provide slide to Bill to explain the Xilinx platform & another slide that explains the demos
- (DONE) Nathalie: Confirm that Bruce will also present the demo for System DT in addition to the slides
- (OBSOLETE) Nathalie: Put on next week's agenda: Let's have questions prepared in case no Q/A from audience (Nathalie/Tomas can ask)
- We have a good qty of registrants, so should be OK on questions
- (DONE) Nathalie: Check with Tomas if he can help look through the questions in chat or if he wants to be a speaker?
- Tomas will be a speaker
- (DONE) Bill: Find out if we would we be able to answer chat Q/A while the webinar video is playing
- We can answer questions while the webinar is playing
- (DONE) Bill, Arnaud, Dan, Tanmay, Bruce/Tomas: Send out draft slides + text of demo walkthrough by 18 November
- (DONE) All: Give feedback on slides by 22 November
- (DONE) Bill, Arnaud, Dan, Tanmay, Bruce: Send Nathalie the recording of your part by 8am Pacific on 28 November
- (DONE) All: Try docker demo prototype (should be able to try in 10 min if you already have Docker installed on your system) Let Bill know if anything is not clear.
- (DONE) Bill, Arnaud, Tanmay, Dan, Bruce, Tammy, Mathieu: Send to Bill & Nathalie the photo that you would like in the speaker slide, unless you are OK with us using your LinkedIn photo
- (DONE) Nathalie & Bill to coordinate offline about LinkedIn post for Monday.
- (DONE) Arnaud: Post questions to Dan about PR & see if need a live sync
- (DONE) All: send pull requests to OpenAMP docs by EOD Monday 11/14
- (DONE) All: review the PRs on docs before Wednesday's call 11/16
- (DONE) Nathalie: Add 30 min prior to next week's call for doc scrub
- Tanmay update
- Addressed most of Arnaud's comments. Few minor ones remaining to address today. Then can get into system reference repo.
- Ed & Arnaud reviewed. Bill to review also.
- Could do Zephyr + Latest kernel on QEMU
- Tried Bill's docker image, will work with Bill on getting items into the image
- Tanmay: Will provide slide to Bill to explain the Xilinx platform & another slide that explains the demos
- Bill: Has Tanmay been able to test 6.0 on KV260?
- Tanmay:
- Need to update firmware, but board has some issues. Recovery tool not working. May try to revert patch & try new kernel.
- Unable to do tftpboot on KV260. Will have to replace image on SD card or other hack like putting 6.0 kernel on WIC
- Bill will try testing with KV260 + Prod SOM (able to update FW a bit easier)
- Bill cherry picked Michal's patch & put on top of Tanmay's & Arnaud's patches on top of 6.0.0 -> Could run on ZCU102
- Bill wants to rebase branch to 6.0.7 which has fix in it, then only will have 2 patches on top
- Tanmay:
- Tanmay: Bruce is able to boot System DT flow
- RPMsg in user space
- Not sure about kernel space
- Able to run demo
- Bill will schedule time with Tanmay & Bruce & Ben
- Bill: Would like to build off a tag
- Arnaud: Last tag not integrated into Zephyr. Need to upstream. How to integrate openamp & libmetal in Zephyr? Maybe postpone to next release & do legacy way. Can try to send Pull Request to Zephyr tomorrow.
- Bill: Need custom West manifest anyway
- Arnaud: 3-4 patches in Zephyr
- Bill update:
- Tested 6.0 images on ZCU102 HW
- Was testing with Zephyr SDK version of Xilinx QEMU. Made wrapper script to make it easier to run. Put into a Docker image - goal is to use this as the "take home".
- Would like the Docker image to contain all the demos from the webinar & rebuild Zephyr example and get it to run in Xilinx QEMU
- Put together outline
- Dan thinks he doesn't need 30 min
- Remoteproc & RPMsg will be tight in 30 min, so can use Dan's extra time
- Nathalie: Confirm that Bruce will also present the demo for System DT in addition to the slides
- Nathalie: Put on next week's agenda: Let's have questions prepared in case no Q/A from audience (Nathalie/Tomas can ask)
- Webinar Q/A at the end
- We're in Zoom & can chat to each other in Zoom chat
- It's going to be cast to YouTube livestream. Participants will submit questions to YouTube chat & moderator will read them out.
- Nathalie to read the questions to the panelists from the chat
- Bill: Would be good to have 2 ppl looking at questions
- Nathalie: Check with Tomas if he can help look through the questions in chat or if he wants to be a speaker?
- Bill: Find out if we would we be able to answer chat Q/A while the webinar video is playing
- We have a webinar 2hr slot - 2hr recording window
- Could we each record on our own & send to Nathalie? Should be able to merge them together
- Arnaud: Demos often don't work the first time
- Let's submit recordings by AM on 28th & Nathalie try to mock up before 29th
- 29th can be discussion & cleanup
- Slides
- Bill: Last 3 yrs have done a lot of work to get things upstream. Why did we choose Zephyr as an example?
- Arnaud: Also cover what's next
- Slides draft deadline + draft demo walkthrough (in text form) 11/18
- Give feedback on slides by 11/22 EOD
- Docker
- Would like everyone to try & think should be able to try in 10 min if you already have Docker installed on your system. Let Bill know if anything is not clear.
- Additional improvements planned but it is usable now
- Q/A: Could we have photos of the panelists who will be answering questions?
- Last slide: Where to get the stuff & show it when we start Q&A
- Advertising
- Let's aim to push to OpenAMP linked in on Monday. Nathalie & Bill to coordinate offline about LinkedIn post for Monday.
- Notify everyone to re-share to their networks.
- Linaro made a blog post
- Arnaud
- Dan's PR: Merge or discuss more to understand what he's trying to do? Prefer to wait before integrating. Do we need to integrate it for the webinar & demo?
- Bill: It's on experimental branch.
- Arnaud: Post questions to Dan about PR & see if need a live sync
- Doc scrub
- All: send pull requests to OpenAMP docs by EOD Monday 11/14
- All: review the PRs on docs before Wednesday's call 11/16
- Nathalie: Add 30 min prior to next week's call for doc scrub
- Tammy, Dan, Tanmay, Bill, Tomas, Bruce, Nathalie
- Planning for next week's call
- Schedule recording date(s) – Nov 28 or 29?
- Did everything targeting 10/28 milestone complete?
- Value of keeping System DT standalone example, even if Yocto build is possible
- Who are the speakers?
- Start planning for slides & assigning convergence tasks to owners
- Individual updates
- LinkedIn post draft
- Let's keep next week's call & Tanmay/Bruce will give updates at the beginning before dropping to All-hands
- KV260 will use same rootfs as QEMU
- System DT demo needs more discussion: Yocto and/or standalone?
- Nov 29 is the preferred recording date
- Individuals will prepare slides & we'll refine by committee
- Speakers
- Bill, Arnaud, Tanmay, Dan
- Mathieu for Q/A, not slides or demo
- Bruce TBD - Xilinx to discuss in meeting Thur morning
- (DONE) Bill will provide kernel config to Tanmay today
- (DONE) Arnaud: Send Bill your work title that should be in the speaker credits
- (DONE) Tanmay: Send Bill your work title that should be in the speaker credits
- (DONE) Dan: Send Bill your work title that should be in the speaker credits
- (DONE) Bruce (if decision is to have as speaker): Send Bill your work title that should be in the speaker credits
- (DONE) Tanmay can help Bruce change vrings size or location for System DT demo
- (DONE) Tammy: Send Bill instructions for doxygen.
- (DONE) Nathalie: Send calendar invitation for recording day
- (DONE) Nathalie: Send guidelines for recording (e.g. Audio) - DONE it's in the calendar invitation
- (DONE) Bruce/Tanmay to discuss tomorrow who will present System DT & Lopper and notify Bill ASAP
- Next week's call
- Potential conflict with All-hands on 11/9 for Tanmay & Bruce: Suggest to keep System Reference call slot & Tanmay+Bruce give update at the beginning before jumping to all-hands?
- Tanmay & Bruce: OK
- Bill will provide kernel config to Tanmay today
- Did everything targeting 10/28 milestone complete?
- Tanmay's demos are tested on Xilinx QEMU
- Default kernel was 5.15. Replaced kernel image w/ 6.0.
- Ref directory has script, which was tested.
- Modules are being built in the kernel image
- Tanmay should try to use Xilinx QEMU in Zephyr SDK, but not wait on docker image b/c docker image will come last
- KV260 will use same rootfs as QEMU
- QSPI image comes from Xilinx
- SD card image (includes kernel & file system) comes from OpenAMP
- Bill will re-test when we have the images
- Tanmay
- DT source for lockstep & split comes from upstream Yocto.
- Firmware images for R5 getting built by default in Yocto build for lockstep.
- For Split mode have downstream binaries
- Printing messages from console, RPMsg is not there.
- Arnaud OOO so review of Dan's last item is pending
- Bill: System DT simple version (no Yocto)
- Appealing b/c can download image in 30s and play with it in 2 min & doesn't require any knowledge of Open Embedded
- Yocto will either be long build time or big docker image
- Bruce:
- Was able to build with Yocto off Xilinx GitHub & boot. Haven't tried the OpenAMP demo yet.
- Think OK to have just the System DT part as well
- Bill: For whole Yocto flow, is this "decoupled flow" model?
- Bruce: Yes
- Bill: What's the plan for the hands-on demo in webinar? Sstate?
- Bruce: Was trying to build & boot. Haven't thought about that yet.
- Tomas:
- Outside of Yocto, could be something you download & try out.
- Or, you could show, how in OE/Yocto world, you can run and build everything. We can speed up the build process or do cooking show click over in editing.
- Then how to have ppl replicate?
- Good to be able to do everything in Yocto, so you can do the new flow.
- Bill: Concern - the message may get lost in the noise. Yocto does a bunch of magic stuff, which the casual observer may not understand.
- Tomas: Suggested demo sequence:
- Here's how DT looks for Linux & here's how RTOS config file looks.
- Edit YAML & do build/Lopper.
- Won't put any emphasis on the build
- Either way, the message still works.
- Have value in Yocto, so it's real thing
- Valid point to have standalone option. Can discuss more.
- Bill: Will tweak YAML live & then how does the edit & rebuild work in Yocto flow?
- Tomas: System DT & YAML file are input to Yocto build
- Bruce: Local.conf points to it
- Bruce: Do we edit the file & show it do something different, or just show the output files?
- Bill: Original config can be pre-built & show output files. Then change YAML & see the difference.
- Bruce: Don't know what are valid edits
- Bill: Can change amt of memory to R5
- Tanmay can help Bruce change vrings size or location for System DT demo
- Tammy: Sent a link to Bill for Doxygen config so he could reproduce
- Bill: Think we can focus on Markdown for demo
- Tammy: Easy once installed.
- Tammy: Send Bill instructions for doxygen.
- Scheduling the recording date
- Tanmay travels on 28th. 29th works better.
- 11/29 is Yocto summit, which is over at 1pm Eastern/10am Pacific.
- Dan: 29th Should be OK
- Arnaud joined meeting later (NA/Europe daylight savings change mismatch): 29th Should be OK
- Nathalie: Send calendar invitation for recording day
- Nathalie: Send guidelines for recording (e.g. Audio) - DONE it's in the calendar invitation
- Who are the speakers? Full name & title & company as you want it to be listed.
- Bill: Intro:
- Progress over the last few years/months.
- Bill or Arnaud: Upstream RPMsg slides
- Arnaud: ST platform demo - will need a couple slides on what you will see
- Tanmay: Xilinx platforms demo - will need a couple slides on what you will see
- Matthieu listed for Q/A but not have to present any slides
- Dan: Hypervisorless virtio
- Bruce/Tanmay to discuss tomorrow who will present System DT & Lopper and notify Bill ASAP
- Tanmay: OpenAMP demo on Xilinx platforms
- Docs can be mentioned at the end for reference, in "try this at home" section. Docs won't be a section of the presentation.
- Bill: Intro:
- Need to still scrub the docs
- Arnaud back in office tomorrow - maybe we can scrub next week?
- Bill: Next week, let's put together rough slides & how to documentation. Then can collectively polish it up in week of Nov 14.
- Slides to be done by individuals & we clean up by committee
- Blog post draft is missing info from Events team on how audience should either sign-up or join the webinar + the speaker names & titles
- Bill, Dan, Tomas, Arnaud, Tammy, Tanmay, Tom, Nathalie, Bruce
- Webinar blurb
- Merging pull requests
- Individual updates
- We will go with 6.0 kernel unless we decide otherwise
- How to decide on merging PRs for System Reference?
- Can have reviewer ack patch or indicate they don't have time to review
- You can ask Arnaud or Bill to add other reviewers to the group if your desired reviewer is missing
- Let's keep demo small for upstream. For Dan's we'll have QEMU. Dan's stuff on HW: nice-to-have rather than POR.
- Felipe's stuff similar to Dan's. TBD next week if Felipe's stuff is in or stretch goal.
- Let's work on final blog post next week
- (DONE) Bill: Have been experimenting on Zephyr sample. Will send suggestions later today.
- (DONE) Bill: Will look at RPMsg util PR today
- (DONE) Arnaud to resend GitHub group invitation to Tammy
- (DONE) Arnaud: Have documentation from sprint for demo. Can update. Demo is on 6.1 RC1 today.
- (DONE) Arnaud will send ST patch that's needed for demo
- (DONE) Bill: Will push to repo what Tammy already has
- (DONE) Dan to add bit more info on hypervisorless PR to help Arnaud's understanding
- (DONE) Tammy to look out for GitHub group invitation & join
- (DONE) Tammy will schedule a call to scrub the docs
- (DONE) All: Connect to Bill or Nathalie & Join the LinkedIn group
- Nathalie: Does Bill want to mention the webinar blurb?
- Bill: Blurb is for Linaro newsletter, not the real announcement. We can modify it for blog post for seminar
- Arnaud: Pull request for system reference: Should we start to merge, or anyone else wants to look at them?
- Bill: Have been experimenting on Zephyr sample. Will send suggestions later today.
- Arnaud:
- RPMsg echo test from Tanmay approved by Arnaud & Ed - candidate for merge
- RPMsg in kernel space is not ready - some comments to address
- Zephyr example
- RPMsg util binary approved by Tanmay & Ed - candidate for merge
- Tanmay: Tested yesterday with 6.0 kernel & RPMsg echo test. Need to make some modifications.
- Arnaud: Who should decide to merge for system reference? e.g. 2 approvals? everyone approve?
- Bill: We can have a rule now & a rule going forward.
- Arnaud: Can have reviewer ack patch or indicate they don't have time to review
- You can ask Arnaud or Bill to add other reviewers to the group if your desired reviewer is missing
- Bill: Will look at RPMsg util PR today
- Arnaud to resend GitHub group invitation to Tammy
- Tammy to look out for GitHub group invitation & join
- Arnaud updates:
- Pushed on system reference the RPMsg utils - tools for Linux to be able to access the RPMsg char device. Has been forked from __.
- Able to on STM31 to load Zephyr fw to Linux from u-Boot. Can show capability to attach, which Mathieu added a couple yrs a go to kernel.
- Nathalie: Include in scope or stretch goal?
- Arnaud: It's simple. Take ELF for my demo, put in boot FS & just get to U-Boot console & load it.
- Bill: We can include this in ST demo. Not sure if Xilinx config has this.
- Arnaud: Shows capability from Linux to attach to running firmware.
- Tanmay: Look at if the config is available
- Bill: U-boot has rproc subsystem that can be configured in
- Arnaud; You need driver enabled
- Bill: Some versions of Xilinx U-boot have it, but don’t' know if today have it
- Tanmay: We don't test in U-boot, just in kernel. Even if there, think it's not maintained.
- Bill: Not sure if Michal might test it for upstream. Let's leave it out for Xilinx fw.
- Nathalie: Sounds like technical side for ST is working. Additional task is to have it documented.
- Arnaud: Have documentation from sprint for demo. Can update. Demo is on 6.1 RC1 today.
- Bill: Would 6.0 work? Xilinx is on 6.0
- Arnaud: Just added patch to fix something in Linux. Can also be solved by RPMsg control, so put on hold. Need it for demo. Today, Linux can't bind both endpoints together. Small patch 3-4 lines.
- Bill: that patch could apply on 6.0 or 6.1 RC?
- Arnaud: Applied on ST Yocto layer on 6.1 RC1. It's not upstream yet.
- Bill: Was going to carry Tanmay's patches. Could also carry Arnaud's patch. Would be nice to build same kernel version. 6.0 or 6.1 RC?
- Arnaud: 6.1 RC contains beginning of rework of remoteproc virtio. Both OK for me. Don't need this rework for demo.
- Arnaud will send ST patch that's needed for demo
- We will go with 6.0 unless we decide otherwise
- Bill updates
- Finalized webinar date. Need video Dec 5, or maybe Dec 6.
- Nathalie: OK to target Dec 5.
- Found some Zephyr-specific issues when duplicating Dan's stuff. Zephyr assumptions a little fragile. Only using 64K of memory, so can run out & don't get warning.
- Tanmay: Think can update DT to expand it to 256K
- Dan: Doc states can use 128K for A TCM or 128K for B TCM, not sure if can lump all . If you link your binary properly, you can use DRAM like regular system memory. MPU setting in Zephyr is 1 think. Address map is something else. R5 cores can access system memory, so it is up to you to link & deply ELF file accordingly.
- Bill: Flash defined for R5 use already. Currently, how we build program we don't use it. Prefer to expand into DDR than constrain to always be in lockstep.
- Tanmay: Agree, in split will divide mem again.
- Dan: Quick hack is to move the data to DRAM. If you move text section or something more serious, hit issues (e.g. interrupt handler mapping).
- Bill: Even in split, have 64K it's in 2 chunks. Could put code in 1 in data in the other. Would make it less fragile. If in lockstep, then have double of each of those. Eventually, we need to solve code in DDR issue.
- Bill will try out one of the quick fixes. We can demo without it if we just do hello world.
- Is Dan going to do demo on real HW?
- Dan: Not sure, gave back the ZCU102 b/c decided that platform didn't make sense, so some hoops to get it on desk.
- Let's keep demo small for upstream. For Dan's we'll have QEMU. If Dan also has on HW that's great.
- Felipe's stuff similar to Dan's. TBD next week if Felipe's stuff is in or stretch goal.
- Pushing things to OpenAMP repo
- Want to get into best shape as possible by end of this week & then push. Can adjust after it's there.
- Docs
- CI builds
- Linux staging
- Need to figure out where to put the pre-built binaries. Aiming for end of week. Have several candidates.
- Want to get into best shape as possible by end of this week & then push. Can adjust after it's there.
- LinkedIn group & organization are different and we have both
- Created a group, which is useful for having a badge on your profile to say who's a member. Only group members see the post.
- For general parties following, need an organization. Yocto & Zephyr have both group & organization. They are like companies that can be tagged & followed. Set that up too.
- Would like everyone involved here to become a member of the group
- The organization is where we will but the blog post
- All: Connect to Bill or Nathalie & Join the LinkedIn group
- Let's work on final blog post next week
- Finalized webinar date. Need video Dec 5, or maybe Dec 6.
- Bruce updates
- Trying to get a build to work with the instructions
- Dan updates
- Going through Arnaud's comments
- Hypervisorless PR will come after 1st one done for regular virtio
- Arnaud: The PR for the virtio device commit is pretty nice. Can merge it. Commit for hypervisorless, need more documentation to help understand what you are doing.
- Dan: Similar to demo before. Still requires physical machine monitor. Doesn't work on its own. e.g. need A53 on PetaLinux.
- Dan to add bit more info on hypervisorless PR to help Arnaud's understanding
- Update to Zephyr 3.2 is ongoing
- New commits with OS-specific stubs to align work with openamp library
- Nathalie updates
- Sent the template for the slides & shared access with this group. Let Nathalie know if you have any access issues.
- Tammy updates
- Doxygen
- Would like to come up with consistent template
- If we just want to publish what we have, Doxygen can couptu as HTML, XML, or LaTeX. Sphinx can't take any of those 3 formats. Must convert to either markdown or RST.
- Breathe program can convert Doxygen XML to Markdown. It looks like it requires a lot of hand-mods to the generated XML. It's a lot of XML, which we don't want to do every time we regenerate.
- To integrate the current version of Doxygen, would have to host the HTML someplace & link to it
- Also looked into Exhale
- https://rgoswami.me/posts/doc-cpp-dox-sph-exhale/
- Bill: Agree, don’t want manual steps.
- Tammy: Doxygen is optimized for C++. XML files that get generated are not what a human would write, so finding where to do the hand-mods is hard & would need restructuring.
- Bill: Surprised no one has a python parser
- Tammy: Or doxygen outputting MD or RST
- Arnaud: Zephyr also has this problem. Wonder if they have a solution.
- Tammy: Some other projects use both together, but haven't found their configuration files for Doxygen. There are a lot of options.
- Tammy/Arnaud: Zephyr also just link to doxygen HTML. https://docs.zephyrproject.org/latest/doxygen/html/index.html
- Bill: Will push to repo what Tammy already has
- Tammy will schedule a call to scrub the docs
- Zephyr actions to generate doxygen documentation:
- https://github.com/zephyrproject-rtos/zephyr/tree/main/.github/workflows
- there are some doc files which seems to generate and publish documentation.
- Doxygen
- Tanmay updates
- Posted System DT on openamp system ref, haven't created PR yet
- Have Xilinx driver ported on 6.0 kernel. Made some fixes yesterday & will post patches for demo
- Tammy, Dan, Tomas, Tanmay, Nathalie, Bill, Arnaud, Bruce
- Convergence on 10/28 milestone items
- Bruce will also be joining us to discuss System DT.
- Should I add Bruce to the meeting series?
- Status of any required discussion with respective Marketing departments
- Continue documentation discussion, which we ran out of time for last week
- How to prepare presentation slides, coordination (push to after 28th)
- Tanmay to make the pieces available to Bill. Final image will come from Bill.
- Tanmay can switch DT at boot
- System DT scope will be for user to be able to quickly try updating the YAML file and see the result in the Linux DT & RTOS header files. Defer working on Yocto instructions.
- OK to not check in HTML documentation if Readthedocs will automatically render everything for the user
- (DONE) Bill to highlight to Tanmay: Dan's example in Discord where he delivers DTS Instead of DTB
- (DONE) Nathalie: Add Bruce to meeting series
- (DONE) Tanmay: Point Bruce to materials for getting started
- (DONE) Nathalie: Set up internal 1h call on what parts to bring into System DT demo mid-next week (Stefano, Ben, Bruce, Tomas, Tanmay, Arun)
- (DONE) Tammy: Commit the ugly stuff to the doc repo now so Bill can start looking at mechanics
- Other actions captured as tasks in the tracking sheet (access limited)
- Milestones for 28th
- Updated statuses of tasks in the tracking sheet
- Arnaud has delivered PR for implementing demo of Zephyr project
- Duplicating hello - almost done
- Almost done these ones. Working on the PRs. Development done, just bureaucratic part remains.
- Create OpenAMP library virtio MMIO drivers for network, entropy, console
- Define OS independent hooks for connecting to runtime (e.g. network packet ingress)
- Tanmay: Will we do SCP on QEMU or board? How to provide the binaries?
- Bill: Make the pieces available to Bill. Final image will come from Bill. Have to figure out where to publish the artifacts (e.g. GitHub? Linaro file server?)
- Tanmay: Device tree will switch at runtime?
- Bill: Can just switch at boot. Prefer if you check in a DTS instead of delivering DTB & can create with DTC, similar to Dan's example (Bill will highlight in Discord)
- System DT
- Bruce might have some time to get engaged
- Tomas: What do we hope to be able to demo for System DT?
- Bill:
- Setup (e.g. Docker image) where you start with System DT & deployment files. You build it 1 way & then you change the deployment & you build it again. You can see Linux DT changed & RTOS header files also got updated.
- How? Update the YAML file => build => new outputs that reflect the change
- Make the image available for ppl to try
- Docker image doesn't need to be able to build the whole thing
- Setup (e.g. Docker image) where you start with System DT & deployment files. You build it 1 way & then you change the deployment & you build it again. You can see Linux DT changed & RTOS header files also got updated.
- Tomas: Yocto build?
- Bill: Would like user to be able to try out without big time/network/storage investment. Could also provide instructions on how they could do the Yocto flow if they have more time & interest.
- Tomas: Punt on Yocto instructions
- Demo sharing page for RPMsg or Virtio?
- Bill: Already in there w/ reserved memory sections
- Tomas: Think so for standalone
- Bill: e.g. ZCU102 model w/ UART assigned differently via YAML file
- Bruce: Makes sense
- Tomas: We have all of that working, just need to make example?
- Bill: Example & readme needs to make sense and have no pitfalls
- Bruce: I can do that
- Tomas: Once we get this working, then we can worry about if it works in Yocto environment
- Tomas: Would be nice if could get Stefano's team involved to show how it generates stuff from Xen b/c was super hard before. Tomas to ask Stefano. Let's note it as stretch.
- Bruce: Do we have chicken scratch notes, blessed binaries to get started with?
- Tanmay: Point Bruce to materials for getting started
- Nathalie: Set up internal 1h call on what parts to bring into System DT demo mid-next week (Stefano, Ben, Bruce, Tomas, Tanmay, Arun)
- Nathalie: Add Bruce to the meeting series
- Bill: We have 3 topics & 2 hours. Max 20 minutes of slides per topic (i.e. max 10 slides).
- Status of any required discussion with respective Marketing departments (e.g. if some need to give blessing)
- Arnaud: Loic hasn't had a chance to sync up. Will need webinar skeleton to present to Marketing.
- Bill's brief write-up to Linaro Events team:
- We have 3 topics we want to talk about
- Upstream remoteproc / rpmsg & rpmsg tty shown on multiple vendor's SOC
- Hypervisor-less virtio
- System DeviceTree Example System (Stretch goal, Xilinx may not make it in time)
- Each topic will have some slides and a demo
- Each topic should have links for info about how attendees can try things on their own after the seminar.
- We have 3 topics we want to talk about
- Documentation
- Bill:
- Readthedocs doesn't need GitHub actions - you can just point it at the repo and it will take care of building & publishing everything. Can look at rendered version of any branch/tag, so do we need to check in HTML?
- Tammy: That sounds fine if user doesn't have to build the HTML themselves
- Bill may need to put something in the repo to make it work with Doxygen. Not sure what else is required to make that work. Build VM may need some configuration, but should be straightforward.
- Tammy: Didn't check in the Doxygen stuff yet. May need to update dependencies. Holding off until can fix formatting.
- Bill: OK to check in ugly version so we can work on the mechanics.
- Tammy: Will have to fix formatting in OpenAMP repo
- Assuming index & module index will update when we get doxygen content
- Python module index shouldn't be there? Red herring?
- Readthedocs doesn't need GitHub actions - you can just point it at the repo and it will take care of building & publishing everything. Can look at rendered version of any branch/tag, so do we need to check in HTML?
- Tammy: Commit the ugly stuff to the doc repo now so Bill can start looking at mechanics
- Arnaud: openamp doc is in markdown, libmetal is doxygen. What's status for libmetal docs?
- Tammy: Haven't looked at libmetal yet. TBD if want all in 1 document.
- Arnaud: TBD if want to make documentation generation consistent between the 2.
- Bill:
- Tom Gall, Tomas Evensen, Tammy Leino, Arnaud Pouliquen, Dan Milea, Tanmay Shah, Bill Mills, Nathalie Chan King Choy
- Discuss December date proposal for webinar
- Discuss milestones for webinar
- Any feedback on first pass of converting OpenAMP docs to restructure text/Sphinx?
- Targeting Tue Dec 13
- Let's get OpenAMP channels set up on Linaro Discord
- (DONE) Tom to set up Discord & send invitations
- (DONE) Bill to find out how far in advance the Events team wants the pre-recorded materials
- Other actions tracked in the webinar tracking spreadsheet
- December date proposal for webinar
- Bill:
- Discussed during RP call on Thur. Risk of not being ready in Nov anyway.
- Event team OK with: Dec 13, 14, 15 or Dec 6, 7, 8
- LF has RISC-V summit on Dec 13-15, which may be a conflict for target audience
- Suggest start at 9am Pacific & go for 2-2.5hrs. Will record to cover other time zones. Then have live Q/A.
- After considering time needed to dry run, record & edit, better to go with the later options. Shoot for Dec 13.
- Tom: Is there any public Slack or Discord that people could ask Qs on? We have a Linaro Discord & could create an OpenAMP channel.
- Bill, Arnaud: OpenAMP does have an internal Discord. Could be good to use the Linaro one.
- Bill: Could consider moving OpenAMP team channel on the Linaro server too
- Bill: Advertising: Linaro events will advertise & then the project participants to re-tweet/re-share
- Bill:
- Prelim webinar outline:
- Each topic will have some slides and a demo + have links for info about how attendees can try things on their own after the seminar.
- Upstream remoteproc / rpmsg & rpmsg tty shown on multiple vendor's SOC
- Hypervisor-less virtio
- System DeviceTree Example System (Stretch goal, Xilinx may not make it in time)
- Each topic will have some slides and a demo + have links for info about how attendees can try things on their own after the seminar.
- Milestones
- Bill: What do we target for 10/28? No slides yet, focus on code first. Let's focus on docs in Nov.
- Dan's work is based on Zephyr from spring 2022. Might be 2.7? Can worry about updating to 3.2 closer to December. For now, focus on completion with current Zephyr version.
- Tammy: Do we want a deadline for outline & slides to make sure we're cohesive?
- Tomas: Good idea
- Bill: Shoot to have slides pretty done by 11/16
- Docs
- Bill: Previously, had GH Action that pushes to github.io. Hoping to get that done by next week.
- Tammy: Created docs in Sphinx from what was in wiki - first pass
- https://github.com/tammyleino/openamp_docs
- Tried to stay true to the formatting except where it's not possible
- OpenAMP API links to OpenAMP repo, without any mods
- Next: Would like to pull in Doxygen. RPMs interfaces seems to be missing some things & doesn't quite look right. Missing doxy file config.
- Pulled in some samples & demos
- Can add webinars section. Structure can be defined by this team.
- Bill: Suspect no one has build the doxygen in a few years
- Tammy: May need some mods & pull request. There will be some warnings when you build.
- Presentation
- Is there a slides template?
- Nathalie will send it out
- Tom, Bill, Tomas, Dan, Arnaud, Nathalie, Tammy, Tanmay
- What was outcome of System DT discussion last week?
- Let’s try to close on how the repos & docs should be organized so that the files can be moved into place.
-
Tracking sheet
- What you just finished
- What you’re working on next
- Any points needing discussion/clarification
- Any blockers
- Can probably get mid-Nov webinar date from Linaro Events team. Fall-back is early Dec.
- System DT demo is stretch goal unless Tomas can recruit more help for Tanmay
- Docker image is stretch goal, which won't go into the tracking sheet until we decide to do it
- Should add a top level documentation repo
- License for openamp-system-reference repo should be same permissive license as OpenAMP library. Put top-level license file + SPDX in the files.
- Dan's demo on HW is stretch goal. If going for it, should consider KV260 if Dan can get one.
- (DONE) Arnaud to add comments to Bill's repos spreadsheet
- (OBSOLETE) Bill to share the repos spreadsheet with Ed & ask him to provide comments
- (DONE) Tanmay will include license file in next pull request
- (DONE) Nathalie: Look at website to see what I did about the openamp.github.io
- (DONE) Bill: Send examples of good, simple Sphinx-based projects
- (DONE) Bill to look for example of how to extend West manifest & send
- Tanmay: System DT discussion
- Discussed current status in Yocto: Still internal. Steps not completely ready.
- Demo: Show functionality of Lopper & System DT
- e.g. show memory region change from 4MB to 8MB or add more memory regions: How lopper will handle
- How generated DT can be used by remote processor & Linux kernel
- Bill: The System DT demo is kind of a stretch goal. Tanmay has a lot of other work. Make go/no-go call on System DT in mid-Oct.
- Tanmay: Agree
- Tomas: Try to find out if can get some help for Tanmay (e.g. Mark, Bruce)
- Bill: They were in the call last week & didn't volunteer
- Bill: Found https://github.com/Xilinx/workflow-decoupling-docs, which describes a lot
- Tanmay: Still see that branch is experimental beta. Could show this.
- Bill: The experimental stuff is public & was updated yesterday
- Bill: Had talked about Docker image - stretch goal
- Build it & see it 1 way
- Tweak configuration, build it & have pre-built staging already configured to match that configuration
- Docker-based playground
- Input DT
- Lopper
- Script you could run that would produce Linux DT & some header files, without whole OE
- Nathalie: Should we add to task tracking, or wait?
- Bill: Let's wait & see if it's likely to happen. Then can go into more detail.
- How the repos should be organized
- Bill created this spreadsheet listing & categorizing repos + proposal
- Arnaud to add comments to Bill's repos spreadsheet
- Bill to share the repos spreadsheet with Ed & ask him to provide comments
- RP call decided we would re-purpose openamp-system-reference repo for demo
- Tanmay's Linux-based demos
- Tanmay: What license for openamp-system-reference?
- Bill: OpenAMP library is permissively licensed. Should use same.
- Tanmay: If we put license at top level, do we need to put in each demo?
- Bill: Put SPDX
- Tanmay will include license file in next pull request
- Arnaud: What if demo is based on code w/ existing license?
- Bill: At that point, we put GPLv2 in the root & SPDX to make it clear which license for which file
- Bill: Have list of repos to deprecate, which would be nice to do before the demo so our project is cleaner
- Can mark as "deprecated" in GitHub UI so visitors have a hint that this is no longer maintained
- Nathalie: Look at website to see what I did about the openamp.github.io
- Bill created this spreadsheet listing & categorizing repos + proposal
- How the docs should be organized
- Bill:
- Some docs aren't associated w/ 1 repo. e.g. can use OpenAMP without library. So, need a top level docs repo.
- Can't move the doxygen generated docs from the library
- Docs specific to library can stay in library
- Should favor openamp-docs for documentation
- Tammy: Had researched to see if we can link folder in another repos: Not possible. Can only link repos together, but not at folder level.
- Bill: Being able to read doc live from repo is nice, but would like to be able to generate the whole set of documentation in read-the-docs. Can use git sub-projects to
- Tammy: As long as remote repo structure doesn't change from what Sphinx is based on
- Bill: Can use symbolic links to give some flexibility
- Tammy: Just got started with Sphinx research
- Tammy: Where does the current documentation live besides the repos? No one replied
- Bill: Some stuff in wikis, library uses doxygen
- Tammy: What is target?
- Generate PDF with usable table of contents
- Link all documentation that we can
- Convert some of the documentation & get it stored globally
- Presentations?
- Bill: Presentations out of scope for Nov demo, unless something really needs to be pulled out
- Bill: Send examples of good, simple Sphinx-based projects
- Bill:
- Arnaud: Tanmay demo w/ rpmsg char device. We need something on the other side to answer. Remote part is in openamp lib but it only works on Xilinx platform. May need something more generic. What would be alternative? Propose something on Zephyr? Baremetal-compatible?
- Bill: Baremetal has build headache. Prefer to lean on Zephyr. Can have Zephyr-based demos that don't have to go upstream to Zephyr. Should have some examples in Zephyr, but not all have to go up. Can use West manifest that uses your repo as base.
- Arnaud: So, we would have our own Zephyr repo?
- Bill: You can have West manifest in your project: include your parts & pull rest from upstream Zephyr.
- Arnaud: Reference co-processor Zephyr?
- Bill: Let's start there
- Nathalie: When is this applicable? Tanmay's demo?
- Tanmay: Baremetal -> don't need West
- Bill: If we try to reproduce Arnaud's demo on another platform, then West makes sense
- Arnaud: Does Bill have example on how to extend West manifest?
- Bill to look for example of how to extend West manifest & send
- Arnaud: First step to get example in Zephyr, integrate into system reference, update to extend the features
- This is part of Arnaud's task to get the demo out of his repo
- Tanmay update:
- Working on rpmsg demo not using library to openamp-system-reference repo. Arnaud has reviewed. Need to address & update the PR.
- Bill update:
- Don't have finalized date yet from Events team. Events was OOO until recently. They didn't reject our request, likely possible. Fall-back plan would be early December.
- KV260 LAVA integration weird problems
- Have workaround for 1st issue
- 2nd seems to be inherent in meta-trusted-substrate. May have to use FSBL instead.
- CI build & CI testing
- Would like to get what Arnaud has working on KV260
- Will be OOO this week
- Arnaud update
- Not much bandwidth recently
- Trying to review patches from Tanmay & Tammy
- Plan to rebase Zephyr demo during next month. When release OpenAMP library will use the demo to test the library.
- Connected the openamp-system-reference to the RP mailing list
- Dan update:
- Almost there w/ network & entropy code w/ opeamp library
- Need to figure out how to split the console. More entangled w/ Zephyr than expected. Lower priority.
- Bill: Think not a lot of ppl have ZCU102 b/c they are $3K
- Dan: Easier for me to get than a KV260
- Bill: We already have Zephyr working on KV260. Have not tried on ZCU102.
- Dan: Expect should be similar
- Let's make ZCU102/KV260 a stretch goal
- Tammy update:
- Update covered during docs discussion
- Nathalie:
- OOO: Will miss next week's call
- Tammy, Tanmay, Arnaud, Dan, Mark, Nathalie
- Discussions related to new task tracking sheet
- (DONE) All: By next Tuesday: Please go through Task tracking sheet and update your task status (e.g. what's In Progress) so that the burn-up chart can give us a sense of our trajectory to reach the finish line
- (DONE) Tammy: (added as a task to the sheet) Research if linking subdirs of another repo into doc repo could work in GitHub
- (DONE) Arnaud: (added as a task to the sheet) Connect openamp-system-reference repo to RP mailing list for automated notifications
- (DONE) Tanmay will write to mailing list about moving source code from meta-openamp layer to open-amp library repo
- (DONE) Tanmay write to mailing list about: Will the openamp-system-reference repo contain bitbake recipes and what else would live there?
- (OBSOLETE) Bill: Update Task tracking sheet with any specific tasks for "Upstream builds & CI demo" category
-
Task tracking sheet
- Any other tasks/categories to add? Added a few
- Assign owners to tasks with no owner: Discussed some TBDs which went to Bill & noted Arnaud to help
- Status of tasks: Can update what's in progress offline.
- How to organize the documentation?
- Docs in each repo so you pull down the relevant documentation when you pull the repo?
- If the document refers to multiple repos, then would make sense to have a top level repo
- Is it possible to have a top level repo that links to the other repo-specific docs?
- Purpose of this exercise is to consolidate the documentation that is scattered
- Long-term for all OpenAMP, scope of this effort is just for this demo
- Open-amp is the unifying factor across all these, so maybe open-amp repo makes sense as the top level
- If can't link, maybe a script to pull regularly from other repos?
- Tammy: Research if the linking is possible
- Tanmay will write to mailing list about moving source code from meta-openamp layer to open-amp library repo
- https://github.com/OpenAMP/meta-openamp/tree/master/recipes-openamp/rpmsg-examples/rpmsg-echo-test
- Not using open-amp but using Linux devices to interact w/ RPU FW
- Meta-open-amp layer should only contain recipes, not sources
- Arnaud agrees
- Tanmay: Will the system-reference repo contain bitbake recipes?
- Arnaud: Your Linux example might live there. Today, we only have documentation there. This is a point we need to clarify with Bill. This repo may be removed & replaced by something else. You can propose e.g. adding a sub-folder for Linux examples with source code & README on how to build. Then we can discuss on mailing list.
- Nathalie: Add task for Arnaud: System-reference repo: Link it to the rp mailing list to send some discussion message automated email on PRs
- Tom Gall, Bill Mills, Dan Milea, Arnaud Pouliquen, Tanmay Shah, Tammy Leino, Nathalie Chan King Choy
- Should we have a sprint in preparation for the webinar?
- Planning: Does anything else need to go in the plan? (access limited, let Nathalie know if you need access)
- Discuss work breakdown. Flesh out the tasks & owners.
- Insufficient team bandwidth for a focused sprint prior to the webinar. Let's meet weekly to ensure momentum.
- (DONE) Nathalie: Update the meetings to weekly until Nov (Dan has conflict in 1st half hour in alternating weeks)
- (DONE) Tanmay: Set up a call with Bill, Tanmay, Bruce, Mark, Ben on System DT for Nov webinar
- (DONE) Tammy to do a quick survey of existing documentation & start email thread on what could go into read-the-docs format prior to November webinar
- Should we have a sprint?
- October 26 & 27 is Arm Dev Summit, we should sprint before then
- October is time for OpenAMP 2022.10 release
- Arnaud: Hard to commit 1 week. Will be able to update previous sprint’s work (kernel version, etc.). No specific week preference
- Dan: Can be available around juggling other things
- Tanmay: TBD - Manager & System DT discussion
- Tammy: In 2 other sprints, help would have to be bounded in scope to know if can commit.
- State of virtio content for demo?
- Dan: Have prototype. Would like to refine before sharing. Networking outstanding
- Updated the plan with more details in work breakdown & scope
- Tomas Evensen
- Arnaud Pouliquen
- Ben Levinsky
- Bill Mills
- Tanmay Shah
- Dan Milea
- Nathalie Chan King Choy
- Discuss November Demo webinar plan
- Still looking OK for November demo webinar
- Is 1st half of November still looking good for a demo? Still looking OK
- November demo:
- What to convey? OpenAMP has demos & docs. It’s easy to try on virtual platform or these 2 low-cost reference platforms. Building from upstream/soon-to-be-upstream, without need to install vendor SDKs.
- What should it include?
- Arnaud’s demo on ST platform based on Linux & Zephyr (with some extra patches on top of Zephyr to extend the sample). If using upstream Linux (6.0?) & Zephyr, can demo rpmsg tty & rpmsg char.
- KV260 starter kit: Not sure if decoupling flow will be in upcoming release. Can do with upstream kernel.
- Remoteproc & rpmsg patches (hopefully those get into next tree by Nov…)
- Upstream kernel
- FW can be pre-built binaries
- Lockstep mode, 2 FW for split-mode, print to UART
- Try for: System DT + Lopper plug-in to build RPU FW, Linux DT. TBD if this is a separate demo, or integrated.
- KV260 with Zephyr (Felipe’s work)
- Xilinx QEMU
- Same as KV260 demo: Lockstep mode, 2 FW for split-mode, print to UART
- Hypervisorless demo with minimal Zephyr code, in the new OpenAMP structure
- What should the presentation include? See below
- What work needs to happen to support that? Continue that discussion over email (see Work Breakdown task categories below) & in next call. Please give feedback on the task categories & what you would populate in those categories.
- Who is our target audience?
- System architect
- Embedded open source developer
- RTOS/Operating system project
- Semi vendor
- How could they benefit from OpenAMP?
- All:
- Minimizes development for IPC.
- Community-maintained project.
- Common architecture across semi vendors & OSes.
- Embedded open source developer
- Avoiding vendor kernel, SDK, FW. Able to use upstream.
- RTOS/Operating system project
- Standardized way to connect in heterogeneous systems with other OSes.
- Option to re-use OpenAMP library (not RTOS-specific).
- Modular: Can use parts or all of the OpenAMP library (e.g. remoteproc, virtio w/o RPMsg).
- Semi vendor
- Community-driven standard to connect your heterogeneous cores
- All:
- What is their alternative to OpenAMP?
- All:
- Ad-hoc solutions.
- NXP RPMsg lite solution for systems with low memory for MCU-MCU communication.
- RTOS/Operating system project
- Per-RTOS solution
- Semi vendor
- Per-semi solution
- All:
- Webinar plan
- What is expected state of audience coming into the webinar?
- Audience will know about embedded AMP.
- Can point to elevator pitch slides in the invitation, so they may have read those.
- What is desired state of the audience after viewing the webinar?
- Will understand the benefits of OpenAMP & want to try out the demos for themselves.
- They will feel confident about the maturity of the project (compatibility w/ Zephyr & Linux upstreams)
- What are the sections of the webinar?
- Intro (Why OpenAMP slides) + what’s in today’s demo
- System DT Intro
- Roadmap, current status, near-future
- Demos (Order TBD), make sure to cover:
- RPMsg-focused on QEMU Xilinx & HW (live, pre-recorded?)
- Co-processor attachment on ST HW + RPMsg
- Virtio
- System DT
- CTA:
- Try it out, here’s where to find the stuff & how to give feedback
- Summary of takeaways/Conclusion
- You can get involved today & here’s how
- Repeat benefits from elevator pitch
- What is expected state of audience coming into the webinar?
- Work breakdown
- Getting the webinar scheduled/advertised
- Slides
- Demo 1
- Demo 2
- Demo N
- Repositories
- Documentation
- Any other top level tasks to break down, or better way to categorize the tasks?
- Bill
- Tanmay
- Dan
- Tammy
- Arnaud
- Nathalie
- Individual updates
- Should we target a fall webinar?
- Early November seems reasonable to shoot for a demo webinar
- Next call:
- Let's discuss what demo will be shown at the webinar
- What tasks need to get done prior to webinar?
- Confirm it still makes sense to plan the webinar for November
- (DONE) Arnaud: Check if ST has parts w/ hard-wired Ethernet. -> Yes, it's available. But don't think it's possible to have co-processor manage. The ethernet is managed by Linux.
- Bill: ask if others in Linaro know more on Zephyr certification project status.
- (DONE) Nathalie: Send email to Board when we should meet again & put social channels on the agenda
- (DONE) Dan: The required mods to use UART for R5 are in one of our Zephyr repos. In a DT overlay somewhere. Can check & share.
- Bill update
- Working on CI, targeting to have results in 1-2 weeks
- Dan update
- Moving bits & pieces from Zephyr virtionet driver to OpenAMP
- Need to figure out what kind of network stack to put on top
- Today, depend on host OS network stack - future work to figure that out
- Bill: Isn't goal to connect to host network stack?
- Dan: Want to make sure no host-specific API, or at least have a documented placeholder for it. Still talking guests, not host w/ back-end.
- Bill: Could it be interesting to look at vendor-specific __ for Ethernet?
- Dan: On to-do list
- Arnaud: Zephyr-specific APIs?
- Dan: There are a couple Zephyr-specific function calls. Driver needs to implement send API, which is Zephyr specific
- Bill: Vendor HAL trying to target multiple RTOSes
- Arnaud: Not sure if ST has an abstraction layer for ethernet
- Bill: Are there ST parts w/ hard-wired ethernet?
- Arnaud: Check if ST has parts w/ hard-wired Ethernet.
- Tanmay update
- Working w/ Yocto team to resolve problem in 2022.1 release w/ KV260 starter kit
- Minimized manual modifications. Expecting in next update of 2022.1 (mid-August). Then just 1 manual config to be done before building Yocto & OpenAMP should be available in Yocto. Will have optimizations for ZCU102 & KV260 boards.
- When that is available, will create new instructions for CI
- Arnaud update
- Next: to address OpenAMP & Linux upstream backlog
- Saw in remoteproc openamp meeting notes that Ben Levinsky spoke about capability to be able to load FW from U-Boot & use RPMsg from U-Boot. Not sure if this could be part of demo feature list?
- On ST side, we can load FW w/ U-Boot but not sure if we can address on RPMsg side. Baremetal system, so adding RPMsg tricky.
- Bill: Told Ben similar. Know several vendors have support for loading FW w/ U-Boot, think RPMsg not done previously. Could do commands to send/receive messages for a given txn, like would do w/ IIC device, but then have background thread always listening for messages which U-Boot doesn't do well b/c network only running during given command.
- Arnaud: Tricky to start RPMsg in U-Boot, using resource table to discover & then start Linux w/ RPMsg already started. May have to start RPMsg for U-Boot, stop & restart RPMsg for Linux
- Bill: U-boot doesn’t do git submodule. Would probably require putting copy of openamp lib in U-Boot.
- Arnaud: Xilinx multi-platform demo?
- Tanmay: If we add this functionality to U-Boot, can someone from Linaro or OpenAMP help w/ review the code?
- Bill: Should sketch out the concept to make sure U-boot maintainers would accept before spending effort. Remoteproc part has precedent, but RPMsg not. Would not want to spend lot of effort if it can't get upstream.
- Tanmay: FSBL for ZU+, but it's first stage
- Bill: FSBL not scriptable.
- Bill: Would be good to have Ben give motivation - what he's trying to accomplish by putting this in U-Boot?
- Tammy update
- Thanks for Arnaud's comments on PRs, will work to resolve this week
- Have small side project to get familiar w/ Zephyr. Saw safety cert work is going on, but not much info about where that is. Does anyone know status? Would like to experiment with that.
- Bill: MISRA C rules got implemented a couple years ago. Code base should slowly be conforming to those.
- Tammy: Figured that was prep to make the code certifiable & which modules. Didn't see anything past 2019 on it.
- Bill: There is a sub-committee that is looking at this, but has changed leaders 3 times. That may be reason for slow progress. Only Platinum members can participate in discussion & they would get cert docs. Have loosened that a bit to more open participation - probably still need to be a member. Trying to keep tight rein on certification assets w/ membership. Bill can ask if others in Linaro know more on Zephyr certification project status.
- Tammy: Would OpenAMP get access, or Siemens have to get Platinum membership to get access?
- Bill: OpenAMP not expected to get access to cert docs. However, to make code base compliant, the documentation around the rules to follow would have to become public. OpenAMP adopted Zephyr coding standards.
- Does a fall demo webinar make sense to shoot for?
- Bill:
- ELCE Sept 12 is a good forum, but won't be ready by then
- Arm Dev Summit Oct 26-27, have chance to be ready by then, but not sure what it takes to get in & how much impact we could make there
- Linaro webinar could be done anytime we want. Just need 1-2 months notice to book it. December not a good time, but maybe November?
- Original scope: Here's the tech, here are demos on 2 boards + QEMU. Look, it's doable & you can try it hands on.
- Tanmay: Same demo on all boards?
- Bill: yes
- Tammy: New demos? Target market?
- Bill: Arnaud did demos at end of Feb sprint. Would like to integrate virtio demos. Would like to be in state where we are ready for a big audience to kick tires.
- Bill: Early November?
- Dan: Nov gives good amt of time to do cleanup & be really ready.
- Tammy: How to advertise to get out of our closed group?
- Bill: Linaro marketing channels: email, LinkedIn, Twitter. Members could try to cross promote via their Marketing depts, but usually Marketing wants to see polished demo before scheduling.
- Tammy: Siemens might not market something like that b/c Zephyr-Linux & Linux-Linux isn't what we sell.
- Nathalie: We could share to our own networks
- Bill: e.g. we could re-tweet, re-share on LinkedIn
- Bill: Do we have OpenAMP social media accounts?
- Nathalie: Think we don't
- Tammy: We could publicize the releases & share the papers
- Nathalie: Send email to Board when we should meet again & put social channels on the agenda
- Tanmay: Before webinar, do we want to host the demos on OpenAMP system reference github?
- Bill: Yes, posting in OpenAMP Project GitHub would be part of getting ready for the demo, but not necessarily system reference repo
- Tanmay: Have to figure out how to compile for Xilinx platforms without Xilinx-specific tools
- Bill: CI flow isn't using Xilinx-specific tools. Only build kernel & use Zephyr on R5. So, don't need Xilinx tools to do those.
- Bill:
- Bill: Another Linaro engineer in LITE team has been trying to get Zephyr running on R5 HW "hello world" via semi-hosting JTAG. Trying to figure out how to get it on UART. Had Zephyr on R5
- Dan: The required mods to use UART for R5 are in one of our Zephyr repos. In a DT overlay somewhere. Can check & share.
- Bill: Once the LITE engineer gets it working, will try to reproduce
- Tanmay: Can discuss internally if could eventually target for Xilinx SDK or wiki
- Arnaud: There is alternative for Zephyr for UART. ST uses RAM console, which can be redirected to remoteproc __.
- Bill: Think we're close. KV260 has multiple UARTs on the USB connector. Tanmay's upstream work is only remoteproc, so having hello world run independently when you load could be a demo once Tanmay's patches are upstream.
- Arnaud: RAM console in Zephyr only requires to declare in resource table w/ associated buffer. No impact on Linux side.
- Bill: Who reads the RAM console?
- Arnaud: You read the buffer which Zephyr has written.
- Bill: No vendor-specific hooks?
- Arnaud: No, already upstreamed example for ST in lib openamp. Uses generic resource table in Zephyr.
- Bill: hello world on ram console, on rpmsg tty?
- Arnaud: Not rpmsg tty
- Bill: Could be interesting to demo all the ways we can get debug output
- Next call:
- Let's discuss what demo will be shown at the webinar
- What tasks need to get done prior to webinar?
- Confirm it still makes sense to plan the webinar for November
- Tammy, Tanmay, Dan, Bill, Nathalie, Arnaud
- Meeting scheduling
- Individual updates
- (DONE) Nathalie: Cancel July 20 call
- Let's cancel July 20 & then resume on Aug 3.
- Let's NOT shift by a week because that would produce a recurring conflict on Dan's side
- Tanmay update: Posted v9 driver & waiting for comments
- Tammy: What are the current outstanding projects for this working group?
- Dan's virtio work
- CI work
- Arnaud's work for enhancements to RPMsg w/ flow control
- Tanmay working on driver upstreaming
- Arnaud started on restructuring of remoteproc virtio driver
- No other individual updates
- Bill, Tammy, Tanmay, Arnaud, Nathalie
- OpenAMP integration in Zephyr
- Individual updates
- Next call: Keep, move, cancel?
- Arnaud can try to modify his CI to try submodule, to see how easy to work with it
- Bill will experiment Zephyr integration idea with West
- Bill to post comments to mailing list on rpmsg flow control, probably next week
- OpenAMP integration in Zephyr
- Marti Bolivar email
- Libmetal has a lot of Zephyr specific stuff in it (Kumar had done previous integration)
- Arnaud would like to avoid the same scenario in openamp. Would prefer if could re-work libmetal to be more independent.
- Arnaud would like to avoid dirty copy
- How to unblock CI?
- Bill will switch to virt_exp branch
- Will new things from main get merged into virt_exp, or is base frozen?
- Arnaud: There is sub-manifest in Zephyr to overwrite the West YAML. Can add some new remote modules in it. Not sure if can overwrite the existing.
- Bill: Think you can overwrite the existing.
- Bill: Maybe we can have the submodules & ignore them in new manifest for CI. Official releases could use the submodules & moving branches use different technique.
- Bill: Don't know if Zephyr will be OK with git submodules to avoid Zephyr subdir.
- Arnaud can try to modify his CI to try submodule, to see how easy to work with it
- Arnaud would like a solution before next OpenAMP release
- Bill's proposal could be used without needing Zephyr to adopt it. Similar to Arnaud's idea, but using mechanism in West instead of script
- Bill will experiment Zephyr integration idea with West
- What if we get adopted by many RTOSes? Rather have many directories than repos.
- Bill update
- Talked to LAVA ppl at Linaro All-hands about integrating Xilinx platforms. Got concrete feedback.
- They prefer a methodology that isn't compatible w/ starter SOM. Requires production SOM. Got some push back on ZCU102. Can discuss in Linaro/Xilinx call.
- ST MP1 platform is already in LAVA & they have a way to update all the SW on the platform via boot switches & JTAG
- Conferences
- Caught Stefano & Bruce's session on System DT & Lopper. Slides are posted. Video soon.
- Want to catch up on Mark's ELC session.
- Dan presented at Zephyr dev summit in virtual. In general, virtual sessions didn't get a lot of audience interaction at hybrid conference. ~30ppl in the room.
- Zephyr dev summit outro interesting: survey result
- Showing Zephyr as the major player for usage or thinking of using
- NuttX was a serious 2nd place
- Mbed was a tiny sliver
- Arnaud: Zephyr previously more focused on platform, looking to support more on application
- Bill: Many of the platforms supporting Zephyr just support timer & UART. Need to get a list where we can tell which are well supported.
- Talked to LAVA ppl at Linaro All-hands about integrating Xilinx platforms. Got concrete feedback.
- Tanmay update
- How to represent TCM in System DT: Rob gave some suggestions & started working on that. SRAM node for R5 subsystem.
- For upstreaming, we are hard-coding address in driver. Rob would like to see in driver & bindings.
- Arnaud: DMA range usage - see post in Discord. ST uses DMA range & translate in remoteproc driver, with some helpers in U-Boot. Use DMA range to be compatible w/ both U-Boot & Linux.
- Saw similar in TI, will work with Stefano to use range/dma range
- Arnaud: Rob suggested bus to be able to use dma range b/c need parent device.
- Tanmay: Ranges vs. DMA range?
- Arnaud: Think range property is to concatenate non-continuous memory. DMA range is specific to address translation for device memory (not DMA peripheral).
- Will post v9 addressing Mathieu's comments
- Arnaud update
- Integrated Dan's first step of work in OpenAMP virtio_exp branch for libmetal & openamp
- Said to Mathieu P. not to have deep look at rpmsg flow control b/c had discussion on improvement w/ Bill
- Bill to post comments to mailing list on rpmsg low control, probably next week, so that Arnaud has some community feedback to move forward on
- ST found RPMsg limitation last week: I2C virtualization to use Linux I2C driver - saw a lot of Linux drivers perform I2C access during driver probe phase (e.g. try to read device version). RPMsg I2C device is co-processor - have to handle ACKs by interrupt, which is a big limitation. Use RPMsg to mux lots of RPMsg services. Virtio I2C has just 1 channel per virtqueue set, so no muxing.
- Tammy:
- Did anyone attend EW? No.
- Worked on the demo that was at EW. Jeff did a session on OpenAMP.
- AutoSAR offering + FlexOS
- Seat heater demo
- Linux was main, Vstar was
- Multicore framework (OpenAMP)
- No lifecycle mgmt, just RPMsg
- Got really good response. Hopefully will get ppl interested in OpenAMP.
- Using safety certified ISO26262
- Mixed safety criticality system
- Tammy to share link/slides if available
- Next meeting: Move 7/6 call to 7/13
- Bill can't make 7/20
- Tanmay, Tammy, Bill, Ben, Mark, Arnaud, Jaxson, Nathalie, Dan joined at half-past
- If Arnaud, Dan, Bill & Jaxson want to meet to discuss virtio, they can set up a topic-specific call that is more friendly to China time zone & omit the Pacific time zone folks
- (DONE) Nathalie: Need to check lead time for expedite on KR260
- (DONE) Nathalie: Check w/ Michal about if ZCU102 vs. KR260 makes more sense
- Jaxson: Check w/ manager if have bandwidth to work on block device.
- Bill to start an email thread w/ Jaxson & Arm folks, and Jaxson will drive discussion on Arm side
- (DONE) Nathalie: Push next call to 29th
- Meta-openamp
- Mark looked at it quickly - no obvious problems. Hopefully next week between ELC sessions to look in more detail. Otherwise after ELC. Stretch goal: Friday
- Ben: Looks fine, unless there's any underlying Yocto problem.
- If Mark & Ben review, Bill can push
- Are Linaro OK to receive Production SOMs before KR260?
- Yes, would allow Bill to get caught up to Ilias on KV260
- 2022.1 KV260
- Issue in Yocto layer causes read-only file system after booting board
- Bill: KR260 looks well positioned to do networking tests planned for ZCU102 b/c has SFP. Should we put ZCU102 on hold?
- Nathalie: Need to check lead time for expedite on KR260
- Nathalie: Check w/ Michal about if ZCU102 vs. KR260 makes more sense
- Virtio
- Arnaud: Dan pushed some updates today, which Arnaud hasn't had a chance to look at yet
- Dan's work is probably mature enough to merge for others to contribute on top
- Dan has pushed Virtio MMIO back-end support
- Service part is not integrated yet & still in Zephyr
- Nothing that would block merge in main branch in short to middle term
- Jaxson: Implementation already pushed into OpenAMP repo?
- Arnaud:
- Today it's a pull request https://github.com/OpenAMP/open-amp/pull/397
- Pull request for libmetal is already integrated virtio-exp branch https://github.com/OpenAMP/libmetal/tree/virtio-exp
- Dan has pushed to OpenAMP Zephyr repo directly in branch https://github.com/OpenAMP/zephyr/tree/virtio-exp
- Arnaud: Just the first step. Device part, not driver part, for virtio MMIO
- Bill: Expect more will come into library & out of Zephyr
- Jaxson: Our requirement it that Zephyr can use the virtio devices provided by the __, like a board w/ set of HW implemented as virtio devices.
- Need front-end driver of the virtio
- Zephyr can't tell difference if device is backed by HW or hypervisor
- Bill: Dan's work not focused on back-end, just front-end. Someday later we have goal to expand to back-end.
- Dan had 2 branches
- Traditional virtio (what Jaxson is interested in)
- Hypervisorless virtio
- Dan had 2 branches
- Bill: What devices is Arm interested in? Dan had virtio-net & console. In another branch they had rng.
- Jaxson: Virtio-net is first priority, then block
- Bill: Virtio-net is aligned. No one has worked on block, so you could help with that.
- Jaxson: Check w/ manager if have bandwidth to work on block device.
- Bill: What is Arm's timeline, when in 2nd half? Is there a demo date? July 1 is too soon, Sept? Oct? Nov?
- Jaxson: Demo. Need to check details w/ manager & architect. Only received this requirement recently.
- Bill to start an email thread w/ Jaxson & Arm folks, and Jaxson will drive discussion on Arm side
- Jaxson: OpenAMP has Zephyr fork & Zephyr has OpenAMP?
- Arnaud: If you clone Zephyr from OpenAMP & then check out virtio-exp and West will work
- Arnaud: Started a West discussion in Zephyr to find a way to point directly to openamp & libmetal instead of having copy in Zephyr. They don't like to have another remote URL than Zephyr. Not sure if will be able to directly integrate OpenAMP in YAML
- Bill: Upstream they don’t, but for our work our West manifest can point to the library. They only want to integrate release points. We care about nightly.
- Arnaud: To avoid the copy, it's upstreamable in Zephyr, but need the virtio-exp work to have the OpenAMP & libmetal Zephyr modules. That's why Bill's method works better.
- Arnaud: Could we find a solution with Zephyr to avoid having openamp & libmetal module, or have update to point using GitHub submodules?
- Bill: Think what I did can go upstream, discussed w/ Kevin Townsend (on Zephyr TSC). Objection was Arnaud didn't like having the Zephyr directory.
- Arnaud: In OpenAMP this is specific to Zephyr integration. Moves the glue. Don't want to set this precedent.
- Bill: OpenAMP community has accepted Zephyr as primary integration point, so special.
- Arnaud: NuttX would then try to push some glue & could become OS-dependent. Zephyr is already quite dependent.
- Arnaud: Simplifying the fork for user is not sufficient justification
- Bill: It's to make CI work b/c CI tools understand West manifest.
- Arnaud: Git submodule works w/ West
- Bill: That will not check out the latest on our branch
- Arnaud: Today, you have to specify version for Zephyr openamp module & modify the module to point to the last version of OpenAMP
- Bill: Want to avoid custom script in every CI
- Arnaud: Just run West init. In OpenAMP submodule, do git checkout of what you want. You have git project for OpenAMP submodule & access to the whole tree. Can cd to this folder & checkout.
- Bill: Clunky to tell every user
- Arnaud: Zephyr aligned to releases
- Bill: To make Zephyr a first class citizen in CI, should test every commit against known good Zephyr
- Dan: Latest PR is fixes to checkpatch & build checks
- Arnaud: What we have is mature enough to merge
- Dan: Latest status: Basic virtio & MMIO framework in openamp in good enough shape to be consumed by drivers. Next: Start moving drivers from Zephyr to openamp. Will start with something simple like entropy or console & see how it fits within the openamp ecosystem.
- Nathalie: Is block considered simple, to align w/ Jaxson's request?
- Dan: We don't have block support. Just network, entropy & console. Not sure if Zephyr is the right place to do that.
- Jaxson: First interest is virtio-net. Second is virtio-block that we could help implement.
- Dan: Sounds like a great plan. Need to decide what source to base the work.
- Jaxson: 397 is just initial PR? No devices, just framework?
- Dan: Yes
- Bill: Think console more interesting than entropy, but whichever one. Then net after that. Does that align w/ Dan's interest?
- Dan: It does, need to figure out schedule.
- Dan: Goal of starting simple is to identify APIs needed in OpenAMP & if any pieces missing. Network has some Zephyr specific stuff, so not an easy target.
- Dan: Have samples for the 3 virtio devices in the Zephyr fork. They use the virtio API from OpenAMP (old virtqueue + new virtio MMIO).
- Dan: Zephyr repo is not for upstreaming, it's for experimentation. Not meant to stay as a standalone Zephyr fork. Virtio implementation would move to lib openamp.
- Arnaud: Dan pushed some updates today, which Arnaud hasn't had a chance to look at yet
- This time is late for Jaxson
- Let's add Jaxson to the Discord & mailing list
- If topic doesn't require the Pacific time folks (Tanmay, Ben, Nathalie), the rest can feel free to meet earlier on Jaxson-specific topics
- Tanmay: Updating Yocto layer to make all OpenAMP binaries by default in rootfs for all the boards. Targeting 2022.2 release. This would reduce # steps to get up and running.
- Mark: Need to look at what we have staged for 2022.2 release & start getting that pushed to the other layers. Hoping to get better at contributing to tip, just haven't had time.
- Bill: Not Kirkstone?
- Mark: Correct, will be Honister. For 2023 will be Langdale. No hard plans for Kirkstone.
- Bill: Use cases for
- Using Xilinx SDK
- Using full layer stack, starting from scratch
- Using meta-xilinx by itself w/ different distro & now need meta-som?
- Mark: meta-som wasn't supposed to go out with that name. Expect we will rename it, but we didn't know what to call it b/c were getting acquired by AMD when it got pushed.
- Mark: meta stuff repo what you need…
- Intention for arbitrary distribution in 2023 w/ Langdale: Meta-xilinx repo, meta-openamp repo, If need custom boards: meta-xilinx tools.
- Intention: In 2023, should be all you need
- Sticking point now is BSPs, very PetaLinux-specific. Working on machine side.
- Gaps on deployment to QEMU Xilinx, which aim to be closed in 2023 release
- Bill: In OpenAMP, FW built to System Ready standards & we're just building generic kernel & file system that should run on multuiple boards
- Mark: Don't intend to do anything xilinx-specific on meta-openamp that would affect generic side of things
- Nathalie: Push next call to 29th
- Bill, Dan, Tanmay, Nathalie, Tammy
- Any updates on Arm's timeframe & requirements for virtio?
- Discuss Arnaud’s proposal to have pre-integration of Dan’s work first before calling meeting with Xiaomi
- Individual updates
- Arm never came back with specific requirements and their implied deadline is approaching, so we will just proceed with our original plan
- We will have pre-integration of Dan’s work first before calling meeting with Xiaomi
- (DONE) Tanmay: Will share link to Tammy with carveout example
- (OBSOLETE) Tammy: Check w/ folks in openamp-rp call about carveout/trace naming and channel name re-use
- Any updates on Arm's timeframe & requirements for virtio?
- Haven't heard back from them yet, so it's probably not that urgent
- Let's just proceed with our plan
- Discuss Arnaud’s proposal to have pre-integration of Dan’s work first before calling meeting with Xiaomi
- Bill & Dan OK with that
- Dan
- Pushing bunch of changes to OpenAMP GitHub Zephyr & openamp & libmetal repos to virtio_exp branch (without west updates)
- Most code for virtio mmio to openamp, somewhat generic. Only deals w/ virtio devices as they are defined in openamp + config structure which can be passed
- Kept just 1 Zephyr-specific API call in Zephyr, which probably could be replaced eventually. Meant to be generic.
- We can use virtqueue API as defined by OpenAMP with minimal changes and virtio mmio framework can be moved to OpenAMP
- Drivers may need additional work. Seems do-able b/c Zephyr simple.
- All work branched off of main fairly up to date version for each of the repos
- Arnaud said to go ahead w/ Bill's for virtio_exp & we'll figure out what we want to do with main branch
- Bill will send PR to libmetal & openamp on virtio_exp branch for libraries
- Bill
- Made PRs for meta-openamp: Ben reviewed. Need Mark's review on at least 1, ideally all 3.
- 1 PR dependent on the others, pending these being accepted.
- Did west Zephyr integration experiment
- Have been updating Xilinx vendor build script: building KV260 as Tanmay outlined + ZCU102 with older technique on 2022.1
- Sent Mark email on race condition in Xilinx layers
- Filipe Neves in Linaro is starting to look at KV260 (picked up from Cambridge).
- One of his tasks: Trying to get Zephyr hello world running on R5 w/ Zephyr R5 build
- Bill was helping him to get started
- Tanmay can help if need for building RPU FW with Yocto
- Filipe is OK to use the SDK first & then use the Zephyr build
- Has lots of RTOS & SoC experience
- Has Dan tried his SW on real HW?
- Not yet
- Tanmay
- Driver upstreaming: Got comments on V5. Will post V6 end of this week.
- Created patch in meta-openamp layer with openamp dtsi included by default, for 2022.2 Yocto build, so don't have to modify DT
- Not sure what will be in Mark's back-ports to 2022.1, if this comes over will let this group know b/c will need to remove steps that pull in openamp nodes
- Bill: ZCU102 procedure uses devtool & modify is more difficult
- Tanmay: Will include for all ZynqMP boards, so think should help ZCU102 as well
- Bill: In 2022.1, the PMU ROM is fetched automatically by the layers. So, disabled that step.
- Tammy
- Still working on certification efforts that go until fall
- Working on complete code coverage
- Carveout & trace in resource tables: Couldn't specify a name for the trace & memory carveout. Works fine if don't populate name field.
- PetaLinux would reject the name
- Has that code been tested, or are there any examples? Are names not supported yet? Is this petalinux-specific?
- Tanmay: Memory carveouts are hard coded in openamp side. Using same DT node included with PetaLinux.
- By default there is no carveout section in resource table, just the address. This is for setting up a separate memory carveout region w/ resource table. FW resource carveout structure.
- Tanmay: There may be limitation in driver or userspace, may need to check w/ Ben. Not sure if need to add to DT b/c driver checking carveout & may not allow
- Modified the driver. Weird that it's not accepted if there is a name.
- Tanmay: Checking if name is available in list or not & then failing.
- Tanmay: Will share link to Tammy with carveout example
- Tammy: Should be allowed to create 1151 endpoints but max out at 512. Does each endpoint need to have unique channel name?
- Bill: assuming that name & local port number is unique tuple. Destination number (can have multiple destinations)
- Tammy: Code will let you create multiple tuples of same name, but Linux will only communicate with the last one created. Can create multiple endpoints under same channel name. Think shouldn't let you do it if not usable.
- Bill: good topic for openamp-rp call when the library maintainers are there. Different libraries have different policies. Sounds like undefined behavior that kernel doesn't need to adapt to.
- Bill: Server example: Give it name & local source & leave destination as end - multiple endpoints can connect to that service. That is a legal pattern, but you should only need to create that server once. Reusing name or local source port should be an error. Question is if openamp tracks it to give an error.
- Tammy: Libmetal kills thread in a few places where think shouldn't (e.g. recoverable cases). Waiting for ppl to weigh in before file bug. Also, certification is against 2020.04.
- Tammy: Check w/ folks in openamp-rp call about carveout/trace naming and channel name re-use
- Bill, Tammy, Ben, Nathalie, Arnaud, Tanmay
- Dan is OOO this week
- Openamp and libmetal implementation for Zephyr: integrate similarly to MCU boot in Zephyr or branch?
- Any updates on Arm's timeframe & requirements for virtio?
- Would be good time to involve Xiaomi in virtio work
- Bill prototyped implementation similar to MCU boot for Zephyr & if it works, will send PR to virtio-experiment branch at openamp & libmetal
- (DONE) Arnaud: Set up call with Bill, Dan & Xiaomi when Dan is back in office about virtio work -> Discussed via OpenAMP GitHub issue
- Bill: Need to figure out where to put DTSI stuff in CI.
- Bill: Suggest to call submission openamp-ci-builds & mark the other CI stuff obsolete. Will propose in email to TSC.
- Bill to post a link to the Google Doc into https://github.com/OpenAMP/open-amp/issues/390
- Openamp and libmetal implementation for Zephyr: integrate similarly to MCU boot in Zephyr or branch?
- Arnaud hasn't had a chance to look at it. Pinged a guy in Zephyr who works on OpenAMP services to highlight a discussion. No feedback yet.
- Bill prototyped implementation similar to MCU boot for Zephyr & if it works, will send PR to virtio-experiment branch at openamp & libmetal
- Added Zephyr directory & cmake file
- Adjusted Zephyr YAML file to point at that one instead of root
- There's nothing to do in Zephyr, it's all inside the library. We can use this technique, regardless of what Zephyr does.
- Any updates on Arm's timeframe & requirements for virtio?
- Bill added Arnaud to the thread & Arm just replied today that they will get back to us
- Arnaud's email on Xiaomi being involved in virtio development on OpenAMP
- https://github.com/OpenAMP/open-amp/issues/390
- They have same requirement & propose to be involved in implementation
- Arnaud: Set up call with Bill, Dan & Xiaomi when Dan is back in office
- Arnaud added Dan & Bill as assignees to the issue, to track the discussion
- Xiang Xiao from Xiaomi has been a good contributor to OpenAMP, he's also a maintainer of NuttX RTOS. OpenAMP has some integration into NuttX, for Xiaomi use cases
- Dan's update by email:
- I merged the code from the Vincent Guittot’s SCMI branch with the WR virtio Zephyr virtio
- Most of the framework virtio MMIO code is using standard OpenAMP library virtio API
- I’ll complete the cleanup and try to do an end-to-end validation of the SCMI setup with the new branch before committing the code to the repos Arnaud created when I get back to the office next week.
- Arnaud: This will be a good starting point to involve Xiaomi in the discussion
- Bill to post a link to the Google Doc into https://github.com/OpenAMP/open-amp/issues/390
- Tanmay update
- Created document on how to bring up KV260 with Xilinx Yocto. These steps can be automated into a script.
- Issue with DTSI in meta-som layer. Documented fix. Worked for Tanmay even on VirtualBox. Need this so that remoteproc driver can probe.
- Tried different SD cards but still get read-only issue. Notified Yocto team.
- Arun sent steps to Tanmay to check board Rev. Think have RevB (pre-production).
- Nathalie: Suggest to Tanmay to get a Rev1 (production) board to match Bill's HW rev.
- Bill update
- Mark submitted his work as PR to meta-openamp. Bill will review & accept at OpenAMP.
- Have some commits in personal GitHub & then will submit as PRs for Mark or Ben to review & accept
- Published work in personal Open CI builds repo. Will want to push this to OpenAMP soon
-
https://github.com/wmamills/openamp-ci-builds/blob/main/ci/xilinx-vendor.sh is automation of Tanmay's instructions
- Tanmay: This is for QEMU, what will we do when we have SOM?
- Bill: Will run generic ARM64, will build firmware through Zephyr. On ST will run generic ARMv7a
- Plan to do the Zephyr integration on libmetal & OpenAMP
- Going to send PR to virtio experimentation branches for Zephyr fork to build with
- Arnaud: Bill should have permissions for Zephyr. Friday will give Bill permissions on whole project, based on email to OpenAMP TSC - no one raised concerns so far & has until Friday to do so.
- Bill: We have a lot of stray CI & test scripts & repos & Docker image.
- Arnaud: Need to do some cleanup
- Bill: Suggest to call submission openamp-ci-builds & mark the other CI stuff obsolete. Will propose in email to TSC.
- Arnaud update:
- Starting to look at CI in Bill's repo. Hit package installation issue with Python.
- Bill: Needs a Python to be python. Bare Ubuntu has no python command. You can install package & set preference for 2 or 3, you can use python3. Intended to run this in a clean VM.
- Bill: Had been using git protocol, which GitHub shut down at the end of Feb. Updated to resolve. Make sure to have those changes.
- Focused on flow control patches in Linux & OpenAMP to be able to propose something to community
- Starting to look at CI in Bill's repo. Hit package installation issue with Python.
- Tammy update
- Have some issues that might result in PRs
- Some internal work from certification process may result in additional issues/PRs. No major serious issues.
- Tanmay: OpenAMP DTSI with Bruce sync up on Lopper
- Decoupling flow: is only available for SOM. Will send patches in meta-openamp. Will be available for all boards in 2022.2 Yocto release.
- Tanmay: Where to put patches to include in CI?
- Bill: Need to figure out where to put DTSI stuff in CI.
- Have a layer Meta-openamp-bsp. Could do some DT stuff there… Preference is upstream kernel version & add overlays.
- OK if Tanmay's stuff is a little different from upstream for now b/c using the vendor file
- Bill: Need to figure out where to put DTSI stuff in CI.
- Tanmay, Arnaud, Dan, Bill, Nathalie
- Updates on repository-related tasks from last call
- OpenAMP & libmetal implementation for Zephyr
- Virtio re-work in light of Arm desires/requirements
- HPP goals for May
- Individual updates
- What to work on prior to next sync up?
- Agreed not to fork openamp and libmetal implementation for Zephyr. (Bill suggests to integrate similarly to MCU boot in Zephyr, but we didn't close on that vs. branch yet - Arnaud still to take a look at MCU boot.)
- Need to understand Arm's timeframe & requirements better to know if what we could do by July would be sufficiently aligned. We don't want to make the work Zephyr-specific.
- Arnaud: To take a look at how MCU boot is integrated into Zephyr
- (DONE) Bill: Add Arnaud to the Arm Virtio thread & ask more Qs, clarify timeframe of H2CY22.
- (DONE) Bill: Publish updates to repo (just got ST part working today)
- (DONE) Tanmay: Write up which layers are included & which machine name & target
- (DONE) Arnaud: Look at Bill's repo w/ different manifests.
- (DONE) Tanmay: Check w/ Bruce if should sync w/ Lopper or do interim integration
- Updates
- Arnaud will grant permissions to Mark, Bill, Ben & enable them to add collaborators
- Done for meta-openamp
- Arnaud will create Zephyr repo & give Dan maintainer access
- Created Zephyr repo
- Missed giving Dan access (no notification received)
- Arnaud will check w/ Ed if can grant Bill core maintainer access to OpenAMP org
- Still open
- Bill will start email thread on cleaning up OpenAMP repo memberships
- Still open
- Arnaud to create virtio-exp branch for Dan to target in openamp & libmetal repos
- Waiting on discussion about duplication about openamp & libmetal
- Will create branch tomorrow
- Arnaud will put patches in OpenAMP Zephyr repo & update ST meta-layer, but Bill can get started with what's in Arnaud's repo
- Still open
- Arnaud will grant permissions to Mark, Bill, Ben & enable them to add collaborators
- OpenAMP & libmetal implementation for Zephyr
- Dan: Agree to use CI/CD method w/ branches instead of forking
- Bill:
- Agree w/ not duplicating. Would take it further.
- Talked to Kevin Townsend (Linaro rep for Zephyr) that it's sad to have to reformat our repo so much to be Zephyr module. This is old policy & there are new ways so that we wouldn't have to do that. Looked at MCU boot & TF-M integration in Zephyr. TF-M puts modules in main Zephyr repo & it references the TF-M repos. MCU boot has a zero diff between tip of Zephyr & the MCU boot upstream that they're based on - managed by putting Zephyr dir into upstream & declaring what they need & making sure it works, which conforms to Zephyr policy.
- Suggest to leave as-is on main (don't need another branch) with Zephyr subdir that makes it work in Zephyr. Need a West manifest that clones our repo. Want Zephyr to use that as import methodology.
- Then we ask Zephyr to import our upstream as-is
- Arnaud:
- Posted discussion about this in Zephyr but didn't receive any comments. Would like to get some help from Zephyr devs. Saw different approaches based on submodule, fork, etc.
- For next rebase for next release in May, would like to see how to do this in better way
- Bill:
- We can make our stuff work that way regardless of if they adopt that way
- Thinking to try to prototype before next call
- Best to look at MCU boot
- Arnaud: To take a look at how MCU boot is integrated into Zephyr
- Bill: Virtio re-work in light of Arm desires/requirements
- Dan was in the messages
- Arm has volunteered one of their Zephyr devs to help out
- Concern: They are hoping for Zephyr upstream solution in 2nd half of this year. Does that mean July 1 or Dec 31?
- Dan:
- Believe they are in a hurry. Pros & cons
- Prefer to do it the way we decided w/ OpenAMP virtio library that is not just Zephyr-specific. If can squeeze enough time, I can get the technical POC ready.
- They want to have it as official upstream implementation - not sure what their constraints are.
- Arm wants it to be part of upstream Zephyr.
- Bill:
- Don't know what their constraints are. Nov/Dec may be possible to support.
- Arm just interested in basic Virtio, not hypervisorless. Think they are trying to enable their fast models.
- Arnaud:
- How to clarify the Arm target?
- Bill: July? Could prove out some stuff in our forks, then work out upstreaming separately.
- Dan: Some of our goals may be achievable by July 1, but not sure how that aligns with Arm roadmap. They were supposed to have more internal discussions w/ Andy W.
- Bill: Not sure if the call happened yet. Andy inherited everything Grant was working on, so he is a bit overloaded right now. Don't want to get stuck in Zephyr only implementation.
- Bill: Add Arnaud to the Arm Virtio thread & ask more Qs, clarify timeframe of H2CY22.
- HPP goals for May
- For end of April, we were supposed to have
- Upstream builds completed (In progress)
- CI running so pushes to OpenAMP would automatically build & test on ST board & QEMU
- User documentation (Wiki is done, Sphinx yet to do)
- Accelerated KV260 board CI & worked on ZCU102, so when CI comes up, hopefully will have 3 boards running
- Tanmay: KV260 board support is enabled in Yocto & can boot w/ OpenAMP examples. Tested last week but hit a snag on login.
- Tanmay: Write up which layers are included & which machine name & target
- Bill: Would like to reproduce eventually. This goal is upstream Poky + OpenAMP, which is limited amt of stuff for KV260 b/c not upstream. In-scope to include Tanmay's patches.
- Goal for end of May (ambitious)
- Complete user builds
- Complete CI 1.1 w/ KV260
- Think not much will happen in June (3 weeks of conferences)
- Arnaud: So, we could be able to have manifest w/ different platforms in 1 OpenAMP repo? So, we could mix ST & Xilinx in 1 manifest & just build depending on platform?
- Bill: In OpenAMP CI, assuming f/w gets built separately & not trying to roll that in. Can build ST or Xilinx config, but OpenAMP CI doesn’t use any ST or Xilinx repos & that works OK for ST so far.
- Bill: Publish updates to repo (just got ST part working today)
- Arnaud: Look at Bill's repo w/ different manifests.
- For end of April, we were supposed to have
- Zephyr dev summit
- Dan will be participating virtually
- Individual updates
- Tanmay:
- Posted Xilinx remoteproc driver V4 on remoteproc list
- Can boot KV260 with 2022.1 release.
- Bill:
- Had a plan to get Mark's & Bill's changes to meta-openamp & Bill had action to test results on ST board. Bill's plan to use QEMU Arm as stand-in for generic ArmV7 platform didn't work. Had to create a generic ArmV7A machine. Added a meta-openamp-bsp layer specific to the CI builds. Can now build something that works on ST board. ST is target b/c building upstream Linux w/ no patches, which doesn't work for Xilinx yet.
- Arnaud:
- Cleaning backlog on actions
- Open tasks for release & upstream
- Bill: If I prototype direct Zephyr integration, will send pull request
- Dan:
- Not much news
- Tanmay:
- Nathalie: Xilinx 2022.1 release is now out
- For next call
- Tanmay
- Will document the steps & how to run echo test demo OOB on KV260.
- Xilinx modifying DT manually & adding remoteproc nodes manually. Would like to make those nodes available by default. Until upstream, can do some scripting to make the nodes available. Can start on that after documentation.
- Bill: Ultimate goal is to demo Lopper also. Maybe we should do interim solution before that, unless Bruce has something already working.
- Tanmay: Check w/ Bruce if should sync w/ Lopper or do interim integration
- Bill
- Start prototype building direct from OpenAMP, libmetal forks & go on to Zephyr & Zephyr forks
- Arnaud
- Limited bandwidth in coming months: no new development, just support & review
- Will do branch creation tomorrow
- Dan
- Coming back to merge. Hoping to have something shareable next week, to align w/ creation of the branches
- Tanmay
- Mark, Tammy, Nathalie, Dan, Arnaud, Ben, Bill, Tomas
- Tanmay is OOO this week
- Next steps for meta-openamp
- Meta-openamp: Ben, Mark intros, if haven’t met the rest of the group yet
- Questions for Arnaud related to OpenAMP repo: Members, permissions, etc.
- Approval from TSC to proceed with virtio proposal. I think Dan has most of the tasks for the first phase. Anything to discuss with the group?
- Individual updates
- What to work on leading up to next System Reference WG call?
- Meta-openamp:
- Mark will do the PR, Bill can do the merge in the actual tree.
- Let's classify Versal & ZynqMP machines as best effort
- Bill will test on HW on ST 32-bit platform
- For now, Arnaud's repo will be the upstream for the rpmsg Linux examples.
- (DONE) Arnaud will grant permissions to Mark, Bill, Ben & enable them to add collaborators
- (DONE) Arnaud will create Zephyr repo & give Dan maintainer access
- (DONE) Arnaud will check w/ Ed if can grant Bill core maintainer access to OpenAMP org
- Bill will start email thread on cleaning up OpenAMP repo memberships
- (DONE) Arnaud to create virtio-exp branch for Dan to target in openamp & libmetal repos
- Arnaud will put patches in OpenAMP Zephyr repo & update ST meta-layer, but Bill can get started with what's in Arnaud's repo
- Bill: Next steps for meta-openamp
- Building upstream kernel, so no remoteproc for Xilinx QEMU
- Will test on 32-bit platform (ST platform)
- Who should do the PR?
- Mark will do based on his tree
- Bill can do the merge in the actual tree
- Hopefully Mark was able to extract the Xilinx-specific items in the subdir, so it shouldn't interfere with the non-Xilinx HW testing
- How much testing on ZynqMP & Versal to do? How to test it?
- Xilinx builds pulls from Xilinx meta-openamp. Could be pointed to this repo, but may have other ties.
- Mark: That's probably the easiest way to do it. No date yet for internal move to Kirkstone, depends on toolchain interactions.
- Let's classify Versal & ZynqMP machines as best effort
- CI is building for generic Arm64 machine w/ upstream kernel + everyone's remoteproc. Xilinx doesn't have remoteproc upstream yet (Tanmay's work in progress)
- Generic 32-bit build includes ST, which can be tested on HW
- Intros for Ben & Mark
- Tammy: Siemens since ATI, MGC - Nucleus RTOS. Historically involved in networking & middleware. MCAPY. Recently took over multicore framework group in Siemens.
- Dan: WR tech office for long time. Working w/ Maarten on high level framework for app services.
- Ben: Working on Xilinx port of OpenAMP for a few years, plus kernel & baremetal drivers for Xilinx. Ramping up on Yocto for meta-openamp.
- Mark: Before Xilinx, was at WR & MontaVista. YP integration, OS integration. Not an OpenAMP person, so leave OpenAMP details to this group & will contribute on YP layer maintenance.
- Arnaud: At ST long time, multi-core framework since 4-5 years. STM-32 MPU & MCUs. Maintainer of openamp & libmetal libraries.
- Who has permission to grant Mark, Bill & Ben the access in OpenAMP GitHub for meta-openamp maintainership?
- Arnaud will grant permissions to Mark, Bill, Ben & enable them to add collaborators
- We need to create Zephyr repo in OpenAMP GitHub w/ Dan having write access
- Arnaud will create Zephyr repo & give Dan maintainer access
- Arnaud will check w/ Ed if can grant Bill core maintainer access to OpenAMP org
- Bill will start email thread on cleaning up OpenAMP repo memberships
- Approval from TSC to proceed with virtio proposal. I think Dan has most of the tasks for the first phase. Anything to discuss with the group?
- Dan: It's pretty clear
- Dan update:
- Working on virtio framework merge into 1 repo. Target merged within a few weeks, max.
- Bill: Dan can do locally & send PRs. Should we test this in a branch before merging?
- Arnaud: Yes, branch would be first step.
- Vincent's changes affect both libmetal & openamp. Everything would need to be in sync to use openamp virtqueue impl in zephyr. Would need branch in each project, then should be easy to sync.
- Dan will get it working locally first.
- Arnaud to create virtio-exp branch for Dan to target in openamp & libmetal repos
- Bill update:
- Xilinx board automation
- Testing out merge of Bill's work with Mark's work, then will give Mark go-ahead to do PR
- Next:
- More of that.
- Want to start building Arnaud's rpmsg Linux examples in common CI (in Arnaud's GitHub repo)
- Arnaud will put patches in OpenAMP Zephyr repo & update ST meta-layer, but Bill can get started with what's in Arnaud's repo
- Where to put Arnaud's rpmsg Linux examples upstream?
- Arnaud: No plan to upstream. Started by a fork of utilities created by Bjorn Anderson. Doesn't make sense to propose to Bjorn.
- Bill: Would like those to be part of OpenAMP CI & meta-openamp
- Arnaud: Can just have in OpenAMP CI for testing platform target. For now, Arnaud's repo will be the upstream for the rpmsg Linux examples.
- Tammy: No update
- Arnaud: Working on RPMsg flow control for Linux & OpenAMP to prototype use of dedicated rpmsg for flow control for endpoint to stop transmission & restart it. Proposed by Qualcomm for their rpmsg backend & trying to adapt for virtio backend.
Special meeting to discuss meta-openamp.
Bill Mills (Linaro), Mark Hatle (Xilinx/AMD), Ben Levinsky (Xilinx/AMD), Tanmay Shah (Xilinx/AMD), ckohn@xilinx.com (Xilinx/AMD)
We had general agreement of the approach. No proposed changes will interfere with Xilinx SDKs or community meta-xilinx builds.
All discussion here needs to be ratified by OpenAMP TSC.
- We purpose that Bill, Ben, and Mark be made the maintainers of: openamp/meta-openamp.
- https://github.com/mhatle, https://github.com/wmamills, https://github.com/bentheredonethat
- all previous maintainers have left Xilinx)
- Xilinx will continue to maintain it's xilinx/meta-openamp and figure out how to align to openamp/meta-openamp over time.
- Bill would like to act on this now and then get TSC's official approval.
- The three maintainers will integrate their own work as PRs with cross review as well as accepting and reviewing PRs from others.
- Mark will take the first shot of merging what Bill has done with the most recent Xilinx work on the honister branch. He will then submit that as a PR to openamp/meta-openamp.
- Mark Published an initial version 3/31 and Bill is reviewing
- Ben & Mark should subscribe to openamp-system-reference-list:
- https://lists.openampproject.org/mailman3/lists/openamp-system-reference.lists.openampproject.org/
- Please self subscribe with whatever email you wish.
- Ben & Mark to be added to biweekly system reference meeting. Done
- Mark is optional and we will give him a heads up if we need him.
- Tammy, Dan, Bill, Tanmay, Arnaud
Individual updates
- Tanmay:
- V4 start now
- Arnaud:
- fixes for rpmsg for next for rc1
- missing CONFIG enable for ARM64 etc
- look at flow control for virtio (similar to QC )
- Tammy:
- Did first PR, Arnaud accepted
- More coming
- Dan:
- Abstract for Zephyr summit approved
- Outlook for something shareable?: not clear at this time
- Good first goal:
- being able to include a common base for virtio plus add Vincent's mmio
- Bill:
- continue to work on board automation. zcu102 is going well, need to get back to kv260 and ST mp1
- goal for 2 weeks is to power on and board will tftp what it needs and run the demo Arnaud documented in Feb
- AP: should update both Zephyr and Linux of Arnaud's work
- AP: 5.18-rc1 would be a good kernel target
- Tammy, Dan, Bill, Stefano, Nathalie, Tanmay, Arnaud
- Google Doc: https://docs.google.com/document/d/1hoMpIfgUEEQQMK3_64COSr0IGGYvDWFDIHjK4i_fAeM/edit?usp=sharing
- Prepare proposal for OpenAMP TSC call on 4/12
- Bill: Webinar may get pushed into June.
- Dan's Zephyr dev talk would be early June, if accepted & WR agrees to send him
- Nathalie OOO next Wed, team will still meet. Tomas & Tanmay are alternate hosts.
- (DONE) Dan: Ask WR if can change license from Apache to BSD to match OpenAMP
- (DONE) Bill will summarize the plan for OpenAMP TSC
- Bill: Had good discussion in the comments.
- Arnaud would like to see 1 library instead of 2.
- Vincent wants to make sure we include virtio-mmio layer.
- If we have this big of a library, we may need more advanced build-time config + some library logic to not pull in unnecessary stuff
- Dan:
- 1 library would be better
- Have quick & dirty prototyped switching from virtqueue definitions to standard OpenAMP virtqueue. It's feasible.
- OpenAMP & Libmetal are entangled. Makes solution more complex. Should discuss this at some point.
- Rest of virtio stack as defined by Vincent: Routines wh/ parse device header. Duplicated, but functionally identical in both Zephyr stacks.
- Trying to figure out how to detect/remove any Zephyr-specific artifacts in virtio drivers themselves. In the framework, easy-ish to use only OpenMAP primitives. But b/c entanglement w/ libmetal only used enqueue/dequeue.
- Possible to merge, matter of doing the work.
- Then need to make it possible for Zephyr to use without too many dependencies.
- Dan: Wanted to call out the explicit dependency on libmetal.
- Want to preserve alignment to Zephyr device driver model, even if it will be abstracted in this library - that is missing in the other virtio implementation. Zephyr-specific device structure & APIs to interact w/ Zephyr & show up in device list - Vincent's implementation doesn't include that.
- Arnaud: Some APIs will need wrapper in Zephyr to port virtionet API from OpenAMP.
- Bill: Reasonable for library to support "when in Zephyr" context. If doing baremetal/other RTOS could that go away?
- Dan: Ideally, not there yet.
- Clear: We want to shoot for 1 library
- Arnaud: Good starting point would be to have MMIO transport layer in OpenAMP library. 1st step driver could indirectly use virtqueue in Zephyr, then move generic part of protocol in OpenAMP lib. Then just Zephyr driver update & no impact for user. So, effort would be to integrate MMIO in OpenAMP & keep Dan's Zephyr driver as-is, relying on OpenAMP virtuqueue.
- Dan: Think it's do-able. Don't know the effort yet. Need to start digging into OpenAMP library.
- Arnaud: MMIO transport would be at same level as rproc virtio. Top level API would be virtio dispatcher that provides the ops to get/set status, send/receive notification. Can help for this.
- Bill: Agree w/ Arnaud we should pull Zephyr fork into OpenAMP repo to show multiple ppl interested
- Arnaud: Also relevant to OpenAMP demo.
- Dan: Spending some cycles to try to get this to a usable state.
- Bill: OK if the 2 source bases evolve together: Zephyr fork & OpenAMP library branch. Would want to avoid PRs into Zephyr before we have the whole story worked out.
- Bill: When would make sense to have official PR to Zephyr?
- Dan: Under 3 mo if we agree that initial version of virtio-mmio transport in OpenAMP would be limited to virtqueues + device API. Then on top, have Zephyr drivers (e.g. virtionet) that would use this API from OpenAMP.
- Bill: Think that's a good interim step. Would like virtionet driver that could work w/ other OS.
- Bill: Interim step: Can WR change license from Apache to BSD?
- Dan: Not sure. Apache license was inherited from Zephyr.
- Dan: Ask WR if can change license from Apache to BSD to match OpenAMP
- Bill: Google Doc good for starting the conversation. The body will need to be re-worked.
- Zephyr fork in Dan's will move to OpenAMP repo
- Dan will investigate changing to BSD license
- Arnaud & Dan to look at virtio-mmio in library as interim step
- Arnaud: Merge in Vincent's work too, can be in dedicated branch of our Zephyr fork
- Dan: Should be easy-ish to unify layers dealing with queues & device headers. Then have to adapt Vincent's work (whole layer) to be OpenAMP-friendly
- Bill: Where would bounce buffer handling go?
- Dan: Took some shortcuts in Zephyr. Some shared structures go to shared memory automatically. Moving from that to generic mechanism would require OpenAMP-ish work
- Bill will summarize the plan for OpenAMP TSC
- Bill: Webinar may get pushed into June.
- Dan's Zephyr dev talk would be early June, if accepted & WR agrees to send him
- Nathalie OOO next Wed, team will still meet. Tomas & Tanmay are alternate hosts.
- Bill, Tanmay, Dan, Arnaud, Nathalie
- Virtio proposal status (Google doc)
- Individual updates. From last meeting: What to work on before next call?
- Tanmay: In sync w/ Mathieu on what needs to happen next. Will post v4 for upstreaming Xilinx remoteproc driver in next 2 weeks.
- Arnaud: Try to upstream work to close to mainline repositories (Zephyr & Linux)
- Bill: Add staging kernel into builds. Try Xilinx KV260.
- Tammy: Have to finish current project before can address the changes in the outstanding tickets (so not in the next 2 weeks)
- Did Arnaud hear back from NXP?
- Next call: Nathalie on vacation. Tanmay & Tomas are alternate Zoom hosts
- (DONE) Nathalie: Set up a call for next week to discuss & send out to System Reference alias
- (DONE) Bill will add a discussion section to the Virtio Google Doc to capture the tradeoffs from the comments
- Virtio proposal status (Google doc)
- Bill & Arnaud made some updates
- Dan will be looking at it this week
- Next OpenAMP TSC is April 12. Would like to have a bit more concrete of a plan by then.
- Nathalie: Set up a call for next week to discuss & send out to System Reference alias
- Bill will add a discussion section to the Virtio Google Doc to capture the tradeoffs from the comments
- Tanmay update
- Sync'd with Mathieu on V4 and need to do about 30% work left
- Internal Xilinx release is taking a lot of bandwidth at the moment
- Kria board is now working with Yocto flow for kernel & DTS for 2022.1. TLM & __ firmware will be binaries, but that is OK for OpenAMP.
- Bill: Should be fine.
- Tanmay to test Yocto flow on Kria board & post V4 next month. This month is busy with release, will make up for time in April.
- Arnaud update
- Good news: Discussed w/ Bjorn about RPMsg restructuring. It is integrated in next branch of remoteproc. Should be able to probe from remote side the RPMsg & create local channel on Linux side. Hoping for 5.18, maybe 5.19 kernel.
- Bill update
- Worked on builds locally, yet to publish
- Did prep work for CI on boards (work for next month)
- Got firmware from Michal for KV260 for TFTP-based test
- Received ZCU102 at home & trying to do some pre-work for lab team
- Have ST board as well
- Started poking at remote LAVA workers (rPi paired with board you want & it can sit anywhere like Bill's office). Might defer this task to next month. Expect boards to be available in main LAVA.
- Worked on Virtio proposal
- Dan update
- Submitted abstract for hypervisorless virtio for Zephyr developer summit
- Pushed changes to ZCU102 build infrastructure to account for updates in Zephyr project modules
- Pushed updates to Zephyr fork for configurable zero-copy for TX & RX for virtionet driver
- This is just for Zephyr virtio
- Planning on prototyping Virtio "framework" merge with OpenAMP to see what kind of effort would be required, for upcoming discussion
- Nathalie update
- Bruce & Stefano did get their System DT abstract submitted for ELC NA
- Bill: Linaro seminar targeting last week of May
- In April, we'll have to make go/no-go decision. Create outline & slides.
- Think we have disjoint demos already that people would be excited about
- Arnaud: Reached out to NXP, but no answer
- Arnaud: Git submodule would allow to reference another git repository
- Looked into: Instead of making fork of OpenAMP in Zephyr, wonder if could get Zephyr to reference OpenAMP, but don't think can make a submodule of a Zephyr module. Will submit an issue to Zephyr to get discussion going on this.
- Bill: Could do same with west? Could have OpenAMP Zephyr integration repo & an OpenAMP repo listed separately within west
- Arnaud: Perhaps
- Bill: QEMU uses git submodules quite a bit, but isn't in west manifest
- Arnaud: West integrates submodule, but it's a direct reference
- What to work on before next System Reference call?
- Arnaud will try to get discussion going w/ Zephyr on submodule usage
- Dan will focus on Zephyr integration
- Tomas, Bill, Arnaud, Tammy, Tanmay, Nathalie, Dan
- Bill: Virtio proposal
- Recap of overall project status
- Bill: Community outreach updates
- Nathalie: Update on Xilinx plan for ELC NA CFP
- Dan: Update on Zephyr Developer Summit CFP (March 4 deadline)
- Individual updates
- What to work on for next call?
- When to have next OpenAMP TSC
- Virtio proposal: Collaborate on it in OpenAMP Google Drive
- Next TSC call: early April
- HPP homepage lists Jira cards related to this project
- (DONE) Tomas give Bruce a heads up during 1:1
- (DONE) Bill will start an email thread with Bruce to get his access re-activated in the Linaro system
- (DONE) Bill: Send out the Google Drive links for commenters & editors for the virtio-related proposal
- (DONE) Nathalie: Start email thread w/ Arnaud & NXP folks
- Bill: How to progress the proposal?
- Dan: Depends who we want to invite to contribute. Google doc can track changes & have revision.
- Nathalie: Can put in the Share With Mailing List folder, so we know that it has wide open access. You still need to set up the desired share when generating the link.
- Dan, Arnaud: Collaborating on the Google Doc will be a good way to proceed on the Virtio topic
- Bill: Once it's done being edited, we can move it elsewhere.
- Recap of where we are
- Virtual sprint got log jam unblocked
- We have instructions for all the platforms (reproduced by Tammy & her feedback incorporated)
- Dan's work has a public page on how to do hypervisorless virtio on Xilinx QEMU
- Arnaud's work is mostly there to build from upstream. Still ST-specific.
- Tanmay has done Xilinx instructions
- Yet to put them all together in 1 place
- Xilinx HW status
- Tanmay: Kria: Build issues w/ Yocto in PetaLinux. Not in open source Yocto layer yet. Team is working on that.
- Bill: Wes & Michal will give Bill a binary copy of FW to load on board for doing TFTP. Instruction to build upstream kernel to work on board.
- Bill: Baremetal R5 to build has a lot of hooks into Xilinx stuff. May want to build Zephyr for R5 on Xilinx HW. May be some hiccups to go from QEMU to HW.
- Bill: Community outreach updates
- Published to system reference mailing list: HPP homepage (HPP is how Linaro resources get assigned to OpenAMP)
- Bill & Francois presented what we're doing here + Stratos to AGL virtualization working group. Renesas was expressing most interest. Audience was very interested in being users. Bill will try to recruit developers.
- Bruce as member engineer
- We may need to get him re-activated in Linaro system, so we can put him as assignee of some of the Jira cards
- Tomas give Bruce a heads up during 1:1
- Bill will start an email thread with Bruce to get his access re-activated in the Linaro system
- Nathalie: Update on Xilinx plan for ELC NA CFP
- Mark: Yocto + System DT for heterogeneous
- Stefano: How to use System DT (includes intro to System DT)
- Dan: Any update on Zephyr Developer Summit CFP? (March 4 deadline)
- Have prepared abstract on Zephyr virtio & hypervisorless. Need to check with management if OK to submit it.
- Bill: You might be able to submit a provisional abstract & withdraw if needed. Easier than trying to get it in if approval goes past deadline.
- Individual updates. Objectives from previous call:
- Tanmay: Post RPU binaries for Bill to try.
- Posted the link to Discord yesterday
- Binaries on Drive, along with instructions
- Bill: Reproduce Dan’s work
- Still open
- Arnaud:
- Started to push patches on Zephyr to announce the resource table sample & echo to rpmsg tty
- Others want to enable this on eMX platform. Maybe someone from NXP might be interested. Close to ST implementation & so should work.
- Nathalie: A few NXP folks who were previously on the mailing list left NXP. Not sure how many of the OpenAMP mailing lists the new guys signed up for.
- Nathalie: Start email thread w/ Arnaud & NXP folks
- Tanmay: Post RPU binaries for Bill to try.
- ZCU102 vs KV260 for OpenAMP?
- KV260 has multi-stage boot
- Underlying SoC is same. Once it's up & running, the systems are fairly similar.
- Kria is expected to grow a bigger community b/c lower cost
- ZCU102 has more features on board
- Up to Bill what makes sense
- Bill pulled in KV260 onboarding in, to July from September
- What to work on before next call?
- Tanmay: In sync w/ Mathieu on what needs to happen next. Will post v4 for upstreaming Xilinx remoteproc driver in next 2 weeks.
- Arnaud: Try to upstream work to close to mainline repositories (Zephyr & Linux)
- Bill: Add staging kernel into builds. Try Xilinx KV260.
- Tammy: Have to finish current project before can address the changes in the outstanding tickets (so not in the next 2 weeks)
- Let's shoot for early April for OpenAMP TSC
- Dan, Tammy, Arnaud, Bill, Nathalie
- Keeping Discord going
- Bill's suggestions to re-organize wiki & publishing output of the sprint
- Submit to ELC NA CFP? Deadline is March 14. Event is June 21-24 Austin, TX and Virtual.
- Submit to Zephyr Developer Summit CFP? Deadline is March 4. Event is June 8-9 Mountain View, CA
- Individual updates. Objectives from previous call:
- Tanmay: Post RPU binaries for Bill to try.
- Bill: Reproduce Tanmay's work. If time, reproduce Dan's.
- Dan: Virtio discussion prep.
- Tammy: Can support, not enough time this week for independent tasks.
- OK to keep the Discord chat going
- Openamp-system-reference repo: Let's go with what we have & we'll restructure as we go along
- Event Submissions:
- This group: Linaro webinar
- Xilinx: Consider submitting for System DT at ELC NA
- WR: Considering submitting for Zephyr Developer Summit
- (DONE) Arnaud to split it out instructions to its own page in the wiki & reference Dan's & Bill's pages
- (DONE) Nathalie: Suggest to Stefano & Bruce to submit something about System DT to ELC NA
- Keeping Discord going
- We can continue with Discord
- ST: Can't use the app, but can use on web. Unfortunately, the notifications don't pop up right away.
- Bill's suggestions to re-organize wiki & publishing output of the sprint
- We have collection of good instructions scattered around
- Arnaud's notes are in System Reference wiki
- Dan has notes in his GitHub
- Bill has a README
- Arnaud to split it out instructions to its own page in the wiki & reference Dan's & Bill's pages
- Also have notes on future projects
- We have collection of good instructions scattered around
- What do we want to do with openamp-system-reference repo?
- Arnaud: Would be good to integrate Bill's CI work
- Bill's meta-openamp -> OpenAMP meta-openamp?
- Xilinx builds seem to point to the Xilinx fork
- Xilinx also not building from master
- Will have meeting w/ Xilinx about it to double-check
- Bill: CI could go into here or into another CI repo
- Arnaud: Would be good to have document structure that we can point to the website
- Bill: Long-term: Sphinx instead of wiki
- Nathalie: Would there be sample applications that could go into openamp-system-reference?
- Arnaud: meta-openamp might also be the base for system reference
- Bill:
- Some examples sit in OpenAMP repo. Arnaud has applications we need to inherit somewhere.
- Openamp-system-reference is a good project & document, but don't think it will be a long-term code repo
- Let's go with what we have & we'll restructure as we go along
- Bill: Goal: Trying to get message out about the project, so any of the options listed next would be good.
- Bill: No Linaro Connect in spring. Linaro Tech Days are 1 day or 2 half days on a theme with multiple things. Probably too big for us. Thinking a webinar could make sense (1-3 hours).
- Presentation on what we're trying to do w/ system reference
- Remoteproc & RPMsg updates
- Hypervisorless virtio background & making it real
- Demo
- Timeframe: Late May, early June
- Submit to ELC NA CFP? Deadline is March 14. Event is June 21-24 Austin, TX and Virtual.
- Bill: Maybe System DT. Organizers don't know yet if can present virtually, but guidance is that we should submit & they will figure it out.
- Nathalie: planning to organize a call with the usual Xilinx submitters in week of 2/21 or 2/28
- Submit to Zephyr Developer Summit CFP? Deadline is March 4. Event is June 8-9 Mountain View, CA
- Bill: WR could talk about adding virtio to Zephyr
- Dan: We are looking into submitting something for Zephyr Developer Summit. To be confirmed, still in early stages.
- ELCE in Sept/Oct: would be more convenient for ST, they aren't planning to submit to ELC NA
- Event Submissions:
- This group: Linaro webinar
- Xilinx: Consider submitting for System DT at ELC NA
- WR: Considering submitting for Zephyr Developer Summit
- Individual updates. Objectives from previous call:
- Tanmay: Post RPU binaries for Bill to try.
- Bill: Reproduce Tanmay's work. If time, reproduce Dan's.
- Bill published work to reproduce Tanmay's instructions in a script. Haven't tested his remoteproc driver w/ upstream kernel yet. Didn't get notice from Tanmay about split & lockstep RPU binaries.
- Haven't had a chance to reproduce Dan's.
- Dan: Virtio discussion prep.
- Looking forward to tomorrow's discussion.
- Some misconceptions to clear up. Think there is more alignment than ppl think.
- Arnaud: Focused on virtio implementation from Dan & Vincent.
- Trying to have overview of the architecture & find synergies and differences between the different approaches.
- Tammy: May have some more issues to file against OpenAMP library. Have some questions on opening PRs for this project.
- Arnaud: There's info in the README of https://github.com/OpenAMP/open-amp and the CI checks that the contribution is aligned to the rules.
- Bill, Dan, Tanmay, Tammy, Nathalie
- Virtual sprint wrap-up
- Key takeaways
- Next steps
- What to work on prior to next week's call?
- Keep the Discord chat & continue to work async towards possible tech day in mid-May
- (DONE) Discuss w/ Arnaud next week: Discord & Bill's suggestions to re-organize wiki
- (DONE) Bill: Send share link to sprint notes in OpenAMP Google Drive to the team
- Arnaud is OOO this week. See Feb 3 in Bill's notes for Arnaud's status.
- Bill:
- Updated sprint notes document & captured everyone's detailed status updates from today
- Would like to move it from Bill's Google Drive to OpenAMP Google Drive. Will send out new share links.
- Bill: Have been cleaning up meta-openamp in a fork. ST has not been able to use meta-openamp, so guessing others can't as well (points to Xilinx stuff). Want to ensure doesn't break anything for Xilinx, though Xilinx does have their own fork.
- Nathalie: Mark H would probably be the Xilinx person to talk to for meta-openamp
- Tanmay: Sergei K is maintaining the Xilinx version of libmetal for userspace on OpenAMP
- Tanmay: Updated instructions for 2021.2 Xilinx release.
- Next: Will post v3 to public list, including updates for additional feedback from Xilinx.
- Share RPU firmware binaries for lockstep & split mode for Bill to use. This doesn't need to be shared to public for final publish.
- Dan:
- Published build instructions for hypervisorless virtio w/ PetaLinux and Zephyr. Fixed issues reported by Tammy. Tested on clean install of Ubuntu 20.04. Notified app-services mailing list.
- Started looking at SCMI virtio framework published by Vincent G. Full info will be presented when we meet for virtio framework sync next week.
- Tammy:
- Reproduced Dan's work & reported issues.
- What is future purpose of the content?
- Dan: It is a reference for hypervisorless virtio. Then will build upon for OpenAMP demos. Will include RPMsg next to regular virtio queues.
- Bill: For the CI build, will translate this info into OE recipes.
- Dan: Goal is for end-result to be usable as a development environment. e.g. Installing the SDKs in good locations.
- Bill: Think should be able to use Dan's mailbox driver for ST HW platform.
- Dan: Sure, it's meant to be plug-and-play to replace the notification framework with anything else.
- Dan: Info to buy ST HW platform?
- Bill: The ST platform can be bought from DigiKey. STM32157f-DK2. All the builds we work on today work on the "f" version. Bill has "f" version.
- Nathalie: Target is mid-May for a tech day. Do we need another virtual sprint to get there, or will async work be sufficient?
- Bill: Milestones in HPP Jira outline & backlog list. Kicking off virtual sprint was good for getting log jam unblocked. Can continue async work. Would like to keep the Discord til end of April.
- Tanmay: The Discord was very helpful
- Bill: What to publish as output of sprint?
- Make a wiki page for the sprint that covers what was accomplished & next steps for next few weeks
- Bill: Wiki recommendations:
- Make home page more generic. Move Arnaud's stuff to another page.
- We can look at this next week when Arnaud is back.
- What to work on before next week's call?
- Tanmay: Post RPU binaries for Bill to try.
- Bill: Reproduce Tanmay's work. If time, reproduce Dan's.
- Dan: Virtio discussion prep.
- Tammy: Can support, not enough time this week for independent tasks.
- Bill, Dan, Arnaud, Nathalie, briefly Jeff & Tomas
- Individual updates. Objectives from 1/5 call:
- Dan: Targeting to make what is in progress more shareable
- Bill: Reproducible builds
- Tanmay: Continue efforts to upstream Xilinx driver
- Should we use Discord for the Virtual Sprint?
- What to work on prior to the Virtual Sprint in week of 1/31? Any sprint pre-work?
- HPP: Jira tracking of System Reference work
- Is this timeslot still ok with everyone for 2022?
- We will use the Discord server for the Virtual sprint
- Sprint objective: Have documentation available on OpenAMP wiki or doc to reproduce the demo. Start to try to integrate Xilinx, WR & ST demo, or at least come up with a plan for integration.
- (OBSOLETE) Tanmay: Send status update by email
- Reference
- Medium-term outlook: March/April demo goal
- User-consumable instructions for Xilinx QEMU and ST HW
- Automated build in VM with at least 1 test passing, from staging kernel & OpenAMP libraries main branch
- Hypervisorless virtio demo on Xilinx QEMU with some OpenAMP attached + instructions/scripts to reproduce
- Stretch: Outline of official OpenAMP documentation
- End of year goal proposed by Bill:
- Generic heterogeneous version of QEMU that is not tied to any hardware. Linaro will focus on Arm CPUs. e.g. Mix and match your own combo of Cortex M, R, etc.
- Medium-term outlook: March/April demo goal
- Dan:
- Hypervisorless virtio code has all been pushed to GitHub
- Kvmtool virtio back-end on OpenAMP project (believe master branch) + Dan's fork of Zephyr repo in a separate branch (hvlvirtio.0)
- Kvmtool: Have copy of kernel module that provides support for IPI
- https://github.com/OpenAMP/kvmtool/tree/master/user-mbox-rsld
- To do: Need to create the instructions to reproduce
- Kvmtool virtio back-end on OpenAMP project (believe master branch) + Dan's fork of Zephyr repo in a separate branch (hvlvirtio.0)
- Hypervisorless virtio code has all been pushed to GitHub
- Bill:
- Working on reproducible builds today & tomorrow
- Was able to build what Dan & team had published for basic virtio
- Zephyr on A53 w/ virtio front-ends & QEMU w/ back-ends
- Looked over the patches
- Will start with ST upstream
- Vincent from Linaro has an SCMI server running in Zephyr. Would like to reproduce that.
- He's taking a different approach to virtio, re-using OpenAMP virtio layer
- Want to look at both to see how they differ
- Need to check w/ Vincent if OK to share to this group
- Working on reproducible builds today & tomorrow
- Arnaud:
- No new updates
- Focused on some ST work
- Need to have deeper look at Vincent's patch for virtio SCMI
- Have not seen PR yet
- Had some discussion when he started this work, about OpenAMP virtio
- Following this b/c interesting if we can have something in common between virtualization & multiprocessor systems approach
- Arnaud is more focused on IPC than virtualization
- Discord
- Nathalie, Bill, Tanmay, Dan have been able to join
- We can re-use this Discord channel for the virtual sprint
- What to work on prior to the Virtual Sprint in week of 1/31? Any sprint pre-work?
- Bill wants to get the reproducible builds done before we start
- Sprint objective: Have documentation available on OpenAMP wiki or doc to reproduce the demo. Start to try to integrate Xilinx, WR & ST demo, or at least come up with a plan for integration.
- OpenAMP wiki could be first step, before Sphinx
- Requires all the code to be public - we think we're there. Xilinx ELF is published. ST is pretty close to upstream. Dan has pushed.
- Requires Dan's instructions.
- HPP: Jira tracking of System Reference work
- Think not all ppl on this call have access to Linaro Jira
- Why Jira? Bill has to justify Linaro resource expenditure & want to get more members involved. Will be formalizing over next few weeks.
- Bill will initially define work items through late-March/early-April is what we have defined in our medium term outlook for demo goal. See above for Bill's proposal for long-term goal.
- Arnaud: Someone in Zephyr wants to implement sample using three processors, more realistic
- https://github.com/zephyrproject-rtos/zephyr/pull/41908#issuecomment-1015658997
- RPMsg only, no remoteproc framework nor resource table
- Bill: circle w/ host/remote dependencies wouldn't really work w/ remoteproc loading
- Arnaud: Not a real use-case, more to show capabilities.
- Is this timeslot still OK for 2022
- Dan, Arnaud, Bill: Yes
- Virtual sprint planning
- Nathalie will join on Monday to help get organized
- Team can ping Nathalie to join one of the other syncs (except Tuesday have a conflict)
- Dan & Arnaud can't join on Friday, so we will push out the 2/2 OpenAMP System Reference bi-weekly sync meeting to 2/9 and cover the wrap up then. Arnaud will provide his wrap up by email.
- Bill, Tomas, Nathalie, Dan, Arnaud, Jeff, Tanmay
- What could be feasible for March/April demo?
- Virtual sprint – checking month-by-month: Could sometime in January make sense?
- Who is new Zephyr point of contact?
- Individual updates. Objectives for 1/5 call were:
- Dan: Targeting to make what is in progress more shareable
- Bill: Reproducible builds
- Arnaud: Document how to build using upstream SW
- Tanmay/Nathalie: Get the PMU ROM ELF posted for wget
- Tanmay: Continue efforts to upstream Xilinx driver
- What to aim to complete prior to next call?
- Virtual sprint in week of Jan 31
- March/April demo goal
- User-consumable instructions for Xilinx QEMU and ST HW
- Automated build in VM with at least 1 test passing, from staging kernel & OpenAMP libraries main branch
- Hypervisorless virtio demo on Xilinx QEMU with some OpenAMP attached + instructions/scripts to reproduce
- Stretch: Outline of official OpenAMP documentation
- Zephyr points of contact: Start with Kevin Townsend & Bill Mills & they may loop in others.
- (DONE) Jeff: Once Tammy joins, send Nathalie her email address.
- (DONE) Nathalie: Add Tammy to relevant OpenAMP mailing lists & calendar invitation for this working group.
- (DONE) Nathalie: Try setting up a Slack channel using Xilinx Slack w/ external ppl
- (DONE) Nathalie: Set up the daily meetings for 1hr during week of Jan 31, 2022
- (DONE) Bill, Dan, Tanmay, Arnaud: Block off 4h/day during week of Jan 31, 2022
- (DONE) Tanmay: Send instructions to download the ELF with the steps
- Jeff: Etsam has left Mentor Embedded. Brought back a former Nucleus dev, Tammy, and she'll join next week. She'll take up Etsam's role with OpenAMP.
- Jeff: Once Tammy joins, send Nathalie her email address.
- Nathalie: Add Tammy to relevant OpenAMP mailing lists & calendar invitation for this working group.
- What could be feasible for March/April demo?
- Platforms: Xilinx QEMU, ST HW
- User-consumable instructions for these platforms
- Build from a staging kernel at OpenAMP (TBD if Xilinx patches will get in by then, or else RFC patches) & OpenAMP libraries from main branch
- Automated builds, at least 1 test passing
- Build in a VM. Options: GitHub actions, EC2, Linaro Jenkins
- Hypervisorless Virtio demo on Xilinx QEMU with some OpenAMP attached with instructions/scripts to reproduce
- Currently uses pre-built SD card image from Xilinx release, to get QEMU for ZCU102. Maybe could integrate w/ the PMU firmware stuff that Tanmay made available.
- Stretch: Outline of official OpenAMP documentation
- Vincent's work might have some overlap
- Platforms: Xilinx QEMU, ST HW
- Hypervisorless virtio
- Followed the instructions to boot QEMU with ZCU102 as target. Uses whatever Xilinx kernel is there in the release & other components.
- Nothing that hypervisorless virtio introduces
- Xilinx has quite a bit of patches
- Dan: Figure out which Xilinx patches are needed, so we can know what needs to get upstream for this demo to work with upstream kernel.
- Currently using hack w/ a char device that supports select
- Virtual sprint
- What would it look like? 1 week. 1hr sync/day. Carve out good chunk of that time this week to work on OpenAMP. Could set up a group Slack.
- Nathalie: Try setting up a Slack channel using Xilinx Slack w/ external ppl
- Arnaud: First step could be to get the staging kernel together. Not sure if January is too early. We have to try to merge in the non-upstream patches.
- Bill: So we don't start out too ugly, could start with a personal repo first & get something working.
- Tanmay: Last week of Jan can work.
- Arnaud: Would depend on the week. May have to shift workday to be more aligned.
- Bill: Jan Linaro members meeting is week of 24th
- Dan: Could make end of Jan work
- Week of Jan 31: Bill, Tanmay OK. Arnaud, Dan: can't make the Friday, rest OK. 9am PT daily calls.
- Nathalie: Set up the daily meetings for 1hr
- Bill, Dan, Tanmay, Arnaud: Block off 4h/day during that week
- What would it look like? 1 week. 1hr sync/day. Carve out good chunk of that time this week to work on OpenAMP. Could set up a group Slack.
- Zephyr point of contact
- Kevin Townsend will take over the Zephyr TSC role. Bill will also have an expanded role in Zephyr. Some others will be involved too.
- Individual updates. Objectives for 1/5 call were:
- Dan: Targeting to make what is in progress more shareable
- Cleaning up. Getting close, no commit date.
- Bill: Reproducible builds
- Shooting for 2 weeks from now
- Want to build Xilinx & ST builds that are already documented. Might switch to upstream ST configuration. Script to EC2 instance.
- Arnaud: Document how to build using upstream SW
- https://github.com/STMicroelectronics/meta-st-stm32mp-oss
- Gets updated every 1-2 weeks
- Manual setup would be of interest to us
- Yocto layer: ST is based on dumfel but meta-layer is based on easter. May need 2 different environments for Linux & Zephyr part. Can try to set up a staging w/ everything on easter.
- Arnaud: https://github.com/STMicroelectronics/meta-st-stm32mp-oss/blob/honister/doc/oss_zephyr.md dead link in in README should be https://github.com/STMicroelectronics/meta-st-stm32mp-oss/blob/honister/docs/oss_zephyr.md - the maintainer has been notified & will fix soon
- Tanmay/Nathalie: Get the PMU ROM ELF posted for wget
- It's available now in public download area for wget with the license file in a zip
- Will make the QEMU process very easy
- Tanmay: Send instructions to download the ELF with the steps
- Tanmay: Continue efforts to upstream Xilinx driver
- Still addressing Mathieu's comments
- Will have 1 round of internal review before posting next patch set. Aiming to post in 2 weeks.
- Dan: Targeting to make what is in progress more shareable
- What to aim to complete prior to next call?
- Dan, Bill, Tanmay: Continue on above
- Arnaud: Nothing additional planned
- Tanmay, Tomas, Arnaud, Bill, Dan, Nathalie
- Reminder on poll for virtual sprint
- Ask Arnaud about docs to post on website
- Individual updates
- Should System Reference group write up a proposal for possible OpenAMP contracting $ for board to vote on?
- What to work on for 12/31 milestone?
- Should we reconvene on 12/15?
- When to reconvene in new year?
- Next call in early January, every 2 weeks
- What to target for 1/5?
- Dan: Targeting to make what is in progress more shareable
- Bill: Reproducible builds
- Arnaud: Document how to build using upstream SW
- Tanmay/Nathalie: Get the PMU ROM ELF posted for wget
- Tanmay: Continue efforts to upstream Xilinx driver
- (DONE) Tanmay & Nathalie to discuss offline how to post the PMU ROM ELF to be able to wget
- (DONE) Arnaud, Bill, Dan, Etsam, Tanmay: estimate what you could have working for demo by March/April
- (DONE) Dan: Early 2022 provide walk through of how to reproduce hypervisorless virtio on ZCU102 with the GitHub published virtio infrastructure
- (DONE) Bill (was Dan): Discuss virtio (was app-services) work for Zephyr with Kevin Townsend
- (DONE) Nathalie: Set up series for every 2 weeks starting 1/5
- Tanmay:
- Tanmay & Nathalie to discuss offline how to post the PMU ROM ELF to be able to wget
- Posted v2 and getting feedback from Matthieu
- Bill needs to catch up on the v2 status
- Arnaud:
- Still working on ST layers to be able to use mainstream SW
- Have green light to share and there is an integrator working on the meta layer. Will send mail on list when it's ready to share.
- Dan:
- Have working prototype of Zephyr doing hypervisorleess virtio on ZCU102 with the GitHub published virtio infrastructure
- Targeting more shareable state by end of year
- Early next year, we can look at how to use it in end-to-end demo
- Bill: Would be great to get a walk through on how to reproduce that
- Bill:
- Working on automating the builds that we already have. They take about 1h on decent HW.
- Would like to see if can automate publishing of shared state, so that it's quicker to reproduce by new ppl. Will hopefully work on for end of year.
- Nathalie: Should System Reference group write up a proposal for possible OpenAMP contracting $ for board to vote on? Or, should we go with Maarten's proposal?
- Tomas: We could see what Maarten writes up & build upon that.
- Arnaud: Documentation for OpenAMP library. Have re-worked code. Not getting time to work on the docs.
- Tomas: Need to specify which documentation: User POV, Adding own OS. System reference will help us understand what's missing from docs. This group should have input to what we need for docs.
- Arnaud: System reference will have integrated platform. Seeing that ppl are misunderstanding how to use openamp library & libmetal, how to install on platform, etc.
- Dan: Challenge of ramp-up for Zephyr help. Biggest challenge is documenting & preparing for upstream Zephyr.
- Arnaud: Are you discussing app-services Zephyr work with Kumar?
- Dan: No, will do. Thanks for suggestion.
- Arnaud: Would be good to make sure our integration proposal is feasible from Zephyr POV.
- Ed's proposal: https://github.com/OpenAMP/open-amp/wiki/Technical-Writer-RFI
- Tomas: This is more about organizing & finding gaps. Can be done by someone without in-depth knowledge. Then would be next phase of work to gather the information from the developers and put it all together.
- Arnaud: Part of the documentation could be auto-generated from the code itself, so we would not have to maintain. e.g. API doc. Could have someone put infrastructure in place that could be filled by SME.
- Tomas: Layouts of memory areas & structures could also be auto-generated.
- Arnaud: Discussed in openamp-rp about generating a spec document. Today there is only a 1st draft.
- Bill: It definitely needs to be there. What Arnaud wrote up + what existed was an outline of a spec. Supportive of spending $ on docs if we think we have a plan of what might work.
- Bill: Was Ed a tech writer previously?
- Tomas: Yes, and he proposed fixed price.
- Tomas: Should we set up a goal for Linaro Connect Virtual, or demo someplace?
- Bill: https://www.linaro.org/blog/reimagining-linaro-virtual-events/
- They will be creating topic-specific events instead of a Connect week, without fixed date.
- We could try to have a mini event around heterogeneous processing or OpenAMP. Good/bad news: We could set our own timetable.
- Targeting for around when Connect would normally happen seems OK
- Tomas: If everyone could estimate what they could have working for demo by March/April, we can discuss at our next call
- Bill: https://www.linaro.org/blog/reimagining-linaro-virtual-events/
- Should we reconvene on 12/15 or 12/22 or 1/5?
- Tomas, Nathalie OOO on 12/22
- Bill: 1/5 makes sense
- Nathalie: Set up series for every 2 weeks starting 1/5
- What to target for 1/5?
- Dan: Targeting to make what is in progress more shareable
- Bill: Reproducible builds
- Arnaud: Document how to build using upstream SW
- Tanmay/Nathalie: Get the PMU ROM ELF posted for wget
- Tanmay: Continue efforts to upstream Xilinx driver
- Bill, Tomas, Dan, Nathalie, Etsam
- Tanmay: Update on upstreaming
- Nathalie: PMU ROM & KV260 updates
- Other individual updates
- 12/1 or not 12/1? Is much progress expected by 12/1 call if US folks are the ones with tasks in flight & US Thanksgiving is end of this week?
- Continue with weekly sync, or change to every 2 weeks?
- Objectives to complete before next meeting?
- Reminder to please respond to the poll for which weeks would be best candidates for a virtual sprint in ~Q1CY22: https://doodle.com/poll/n4wb9698y8748c76?utm_source=poll&utm_medium=link
- Let's move to meeting every 2 weeks. TBD if after 12/8 or in January.
- (Obsolete) Nathalie: Find out what the meta-xilinx PR is & follow it.
- (DONE) Nathalie: Cancel 12/1 call.
- (Obsolete) All: Fill in the Doodle poll for virtual sprint: https://doodle.com/poll/n4wb9698y8748c76?utm_source=poll&utm_medium=link
- Nathalie: PMU ROM & KV260 updates
- PMU ROM ELF has approvals needed, so Tanmay can file the request for posting to Xilinx open downloads area, which is used
- KV260 - have the orders in w/ 60 week lead time. Meta-xilinx SW support without PetaLinux is needed before we want to try to get the board.
- Nathalie: Find out what the meta-xilinx PR is & follow it.
- Bill: How big is the gap & can it be fixed from the outside? What is the timeline for fixing?
- Tomas: Beyond the SOM board, there's something Yocto vs. PetaLinux that is incompatible that needs to be fixed & trying to put pressure on it. Need to get clarity on what's going on and remind the tech leads to keep applying pressure.
- Bill: Saw Tanmay's patch series hit the list. Have not had a chance yet to review it.
- Etsam: Spent few hours this week on enabling OpenAMP on RPU cluster. Started with pre-canned IPC RPMsg application. Then started looking for ZCU102 board port in Zephyr & couldn't find. Want to use ZCU102 b/c have been using extensively internally & want to be able to leverage that driver work.
- Dan: Running Zephyr kernel on R5 on simulated ZCU102. Works with QEMU R5 config. Tweaked it to use 2nd serial console. No special config to do. You just build Zephyr w/ hello world for qemu_cortex_r5. Using remoteproc to load it. PetaLinux on A53. Can run RTOS or Zephyr on one of the R5s using remoteproc. Should be possible to start both R5 but haven't tried.
- Bill: https://docs.zephyrproject.org/latest/boards/arm/qemu_cortex_r5/doc/index.html
- Etsam: This had been a blocker. Now unblocked: Can continue w/ the QEMU model.
- Dan: Pushed some more virtio updates for Zephyr in the Zephyr fork on GitHub. Now have support for virtionet console __ device. 9p is work in progress.
- Tomas: What's missing now from Zephyr port?
- Dan: Hypervisorless adaptations are ongoing. In macro hell b/c that's what Zephyr uses. Hope to get it done soon.
- Bill: Is the R5 work on QEMU related to this?
- Dan: Yes, goal is to use ZCU102 board emulated.
- Should we have 12/1 meeting?
- US folks OOO for Thanksgiving
- Dan OOO on 12/1
- Nathalie: Cancel 12/1 call.
- Every week or every 2 weeks?
- Bill: Things are slowing down. In favor of 2 weeks.
- Dan: Agree
- Tomas: Agree
- Etsam: Agree
- Maybe starting in January. We'll start with 8th & TBD if we meet 15th Dec. Likely last 2 weeks of Dec won't have much progress, so probably will cancel those.
- Objectives to complete before next meeting?
- Nothing specific
- Reminder to please respond to the poll for which weeks would be best candidates for a virtual sprint in ~Q1CY22: https://doodle.com/poll/n4wb9698y8748c76?utm_source=poll&utm_medium=link
- Nathalie: If you don’t know what would be best weeks, at least mark what weeks would not be bad weeks (bad weeks = release crunch, OOO, or when you will be very tied up)
- Bill, Dan, Tomas, Nathalie, Arnaud, Tanmay
- Tomas, Bill: Update from presentation at HPP call
- Individual updates
- What to work on before next Wednesday’s call?
- HPP is a project getting kicked off within Linaro, which is a super set of what OpenAMP is doing. Initial scope is the OpenAMP System Reference work.
- We should try to have a 1 week virtual sprint in the new year
- (DONE) Tomas: Add to slide 7: Want to showcase proprietary RTOSes
- (DONE) Tomas: Send Nathalie the latest slides after update
- (DONE) Nathalie: Update to new WR logo in the slides
- (DONE) Nathalie: PDF-ize & post & share the sharing link
- (DONE) Nathalie: Post the PPT template and presentation & share the sharing link to members
- (DONE) Nathalie: Poll this group for what week might be best to have a virtual sprint in the new year.
- (DONE) Nathalie: Find email from whoever else in Arun's team was having similar IT mailing list issue & send to Tanmay
- Tomas, Bill: Update from presentation at HPP call
- Could use these slides as a starter when telling ppl about OpenAMP System Reference project
- Tomas: Add to slide 7: Want to showcase proprietary RTOSes
- Tomas: Send Nathalie the latest slides after update
- Nathalie: Update to new WR logo in the slides
- Nathalie: PDF-ize & post & share the sharing link
- Nathalie: Post the PPT template and presentation & share the sharing link to members
- Bill: HPP = Heterogeneous Processing/Platform Project in Linaro
- We're using this work to kick-start things
- Francois started a working doc that Bill M has added to that
- Initial scope: OpenAMP System Reference, next steps + what server ppl interested in
- Tomas: HPP is a super set of what we're doing here, not separate, will complement. There are data center ppl involved too.
- Bill: Things we heard yesterday:
- We had proposed VM, but there is interest in getting it to work in container. Using containers to make this easier to use, similar to how RunX makes Xen easier to use via container life cycle management tools on top.
- How would this work in EDK & ACPI? Would need more info on their use cases.
- Not everything in HPP would be in scope for OpenAMP, but a broad cross-section.
- Bill: Sent pull requests for Dan to look at. Not sure if applicable.
- Dan: Looks like we're not duplicating work.
- Arnaud: No update. Blocked in Legal review. ETA mid-December.
- Bill: Assuming for mid-Dec the target will be documenting in a shareable way the things we've already shown working. Can show MCU-MCU on QEMU. ST dual MCU platform would be nice.
- Arnaud: Interesting to have virtual sprint next year to find way to integrate in common distribution to merge everything in 1 manifest repo.
- Bill: Think virtual sprint is a good idea.
- Nathalie: Has Bill organized one before & could offer guidance.
- Bill: Kumar may have. Could be as simple as 1hr meeting every day for a week w/ assumption that participants are working on this for most of the rest of the week.
- Nathalie: Poll this group for what week might be best to have a virtual sprint in the new year.
- Tanmay update
- Tried to post patches upstream. Looks like our internal IT has firewall that's delaying. Have an open ticket with IT. First time posting on patchwork using Xilinx email ID.
- Nathalie: Find email from whoever else in Arun's team was having similar IT mailing list issue & send to Tanmay
- What to work on before next Wednesday’s call?
- Tomas: Should we have next Wednesday's call? Will people be around?
- People will be around, let's have the call.
- Tanmay: Hoping to get comments & post new patch set. Once patch series merged, can start working on RPMsg framework.
- Bill: Not sure
- Arnaud: Busy on ST stuff
- Dan: Nothing planned
- Tomas: Should we have next Wednesday's call? Will people be around?
- Tanmay, Dan, Tomas, Nathalie, Arnaud, Etsam, Bill M
- Arnaud: SDK to use upstream versions.
- Individual updates
- What to work on before next Wednesday’s call?
- (DONE) Bill: Will dig up that post b/c may be interesting for Dan to talk to him & see if there's overlap in their work.
- (DONE) Bill will send info to mailing list on MCU-MCU.
- (DONE) Nathalie: Ping the TSC list for feedback on Bill's checklist
- (DONE) Nathalie: Dig up the OpenAMP slides template
- (DONE) Bill will check if Dave is OOO or ping him about the rest of the attachment
- Arnaud update
- Delivery to use mainstream for Linux is still in Legal review.
- Etsam update
- Started to look at Zephyr & learned ropes of Zephyr build system and runtime components. Working on building OpenAMP library with Zephyr in Master mode.
- Dan update
- Colleague working on virtio for Zephyr got virtio net & entropy(?) device support. Trying to figure out how to push that out for review.
- Link to the repo: https://github.com/danmilea/zephyr
- Bill: Dev outside Linaro posted on one of the internal Jira cards was working on Zephyr as Xen guest + virtio. Will dig up that post b/c may be interesting for Dan to talk to him & see if there's overlap in their work.
- Zephyr PR for xen: https://github.com/zephyrproject-rtos/zephyr/pull/39960
- Colleague working on virtio for Zephyr got virtio net & entropy(?) device support. Trying to figure out how to push that out for review.
- Bill update
- MCU-MCU: Arnaud pointed Bill to some rpmsg based samples in Zephyr code base w/ QEMU. Was able to reproduce that & verify it works. Might be useful for Etsam to take a look at. It also works ona physical ST MCU. Will try when that board arrives. Bill will send info to mailing list on MCU-MCU.
- Tanmay
- Internal reviews still going on for driver development. Sent v2 to address the comments. Got some more feedback & aim to post to upstream by end of this week.
- Tomas:
- Presenting at HPP call next week. Will explain OpenAMP System Reference project to them.
- Looking for Bill's HPP document & will make slides.
- Also looking for Bill's checklist
- Nathalie: I sent out Bill's checklist to TSC list and didn't hear back from anyone. Did Bill get any other feedback on the checklist?
- Bill: Francois is organizing some meetings w/ Linaro members to define what's needed for HPP. We should get some input that way.
- Nathalie: Ping the TSC list for feedback on Bill's checklist
- Nathalie: Dig up the OpenAMP slides template
- Etsam: What is intersection of OpenAMP with HPP?
- Bill: HPP is a collection of Linaro members who will decide how to apply resources. Contributions will be in context of OpenAMP.
- Nathalie
- For KV260 board order for Linaro, got back 1st page from Dave but rest didn't come through.
- Bill will check if Dave is OOO or ping him about the rest of the attachment
- What to work on before next Wednesday’s call?
- Tanmay: Working on upstreaming the driver
- Tomas: System Reference slides to present at HPP
- Bill, Etsam, Tanmay, Paul, Nathalie, Arnaud
- Individual updates
- Tanmay: KV260 BSP Yocto flow status.
- Nathalie: KV260 ordering, PMU ROM ELF updates
- What to work on before next Wednesday’s call?
- Put on next week's agenda: Arnaud: SDK to use upstream versions.
- (DONE) Bill: Milestones draft.
- (DONE) Arnaud: Cross check on loading of remoteproc before kernel
- (In progress) Tanmay: Focus on remoteproc & RPMsg driver development.
- (DONE) Etsam: Start on RTOS-RTOS communication on RPU cluster
- (DONE) Tomas: Follow up on PMU ROM ELF approvals by VP during 1:1 this week
- Etsam: Planning to resume work on this project starting today
- Tanmay: KV260 BSP Yocto flow status.
- Previously, was stuck at U-Boot prompt
- There's a gap between what PetaLinux configures & pure Yocto configures. QSPI & other board-specific configurations not available in Yocto. Supposed to have all the configuration in Yocto & PetaLinux as wrapper of Yocto, but it's not the case. There is plan to move the configuration, but it is not there yet. So, SOM boards cannot work with pure Yocto flow.
- If we want to use SOM board, we can use it with PetaLinux to develop demo activity. Currently, OpenAMP is not available for SOM yet. They are enabling it now. We can use it for demo development on the HW, but can't use pure Yocto flow yet.
- Bill: Is including meta-petalinux enough, or you have to download the SDK & BSP?
- Need SDK & BSP.
- Bill: So, this board is not usable by this project at this time.
- Nathalie: 2022.1 probably ~late spring time. SOM release is staggered after Vivado release.
- Bill: Wonder if we could talk to Michal about what could be done w/ upstream kernel + some patches
- Arnaud: Hope to have something in coming weeks for SDK to use upstream version to show
- Can share it when it will be available publicly
- Paul: No active tasks right now. Following the project's progress.
- Bill: Until HPP gets kicked off & officially resourced, probably won't get time from Paul yet. Depends on getting more member interest.
- Bill: Trying to automate KV260 board on weekend. Looks workable, but may move out in our timeline b/c Yocto. For OpenAMP CI, may have to stop U-Boot at prompt & give it commands to boot something else. Not ideal.
- Nathalie: KV260 order has been logged, but to ship it we need the end user statement from Dave on Linaro letterhead. Should try to get that in while we have the Singapore team's attention & then can worry about order prioritization later.
- Bill: End-Jan/Mid-Feb would likely be the earliest we could likely make good use of these boards.
- Nathalie: PMU ROM ELF: Tomas & I have been pinging the VP. Hopefully Tomas can follow up again during their 1:1 tomorrow.
- Bill: Milestones: Thinking Mid-Dec, Mid-Feb, a few weeks before Connect
- Focus on: Xilinx QEMU & ST board
- Mid-Dec: Automated builds & running on those platforms w/ vendor kernel, vendor U-Boot, vendor OpenAMP library. CI-ready. Documentation on how you can reproduce these platforms.
- Etsam: System DT & Lopper?
- Bill: Not yet. Will need to define a milestone for the intersection of that.
- ~January: Doing same w/ upstream kernel + maybe a few carried patches + libraries from OpenAMP git repo
- Dependency: Need a patch series that does remoteproc & RPMsg for Xilinx QEMU isolated. Could use patch series from Ben for this, but if Tanmay has a re-based set of patches for upstream
- Tanmay: Draft 1 base patch is ready w/ remoteproc & in internal review. Then need DT bindings. After that, should not take long)
- Bill: Prefer adding RPMsg
- Tanmay: Next: Introduce mailbox & use RPMsg in kernel. RPMsg patch set targeting internal review by early Dec. Target mailing list mid-Dec.
- Bill: Don’t need to get accepted for this project. Just need what's on public mailing list that we can integrate & prove. Will measure when Tanmay's patch hits mailing list.
- Increasing # tests that run
- What else could we do before Connect (~April)?
- Arnaud: What is the message we want to share?
- Bill: OpenAMP is accessible & easy to get started without too much bound up in vendor SDK. So, should spend time on documentation. Would be great if we could have another vendor or with hypervisorless virtio. VxWorks demo is nice, but don't see how System Reference can engage yet.
- Arnaud working on upstream kernel, OP-TEE, U-Boot. No SCMI yet b/c some blockers there.
- Tanmay working on remoteproc & RPMsg patch series for submitting upstream.
- Arnaud: Showing OpenAMP in Linux user space would be interesting on Xilinx QEMU. Nothing working like that on ST side.
- Bill: Believe what hypervisorless & user space need from kernel are similar. Would be great if we could align those.
- Bill: If we could show platform loading remoteproc before kernel, would be interesting
- Arnaud: Think that's possible on ST, would need to cross-check.
- Mid-Dec: Automated builds & running on those platforms w/ vendor kernel, vendor U-Boot, vendor OpenAMP library. CI-ready. Documentation on how you can reproduce these platforms.
- Bill will take a shot at drafting the milestones
- We'll bring in KV260 later
- Focus on: Xilinx QEMU & ST board
- What's on deck for the coming week?
- Bill: Don't have much bandwidth this week. Will work on milestones draft.
- Arnaud: Will share what is planned for upstream stuff
- Tanmay: Since KV260 effort is a bit blocked, will focus on remoteproc & RPMsg driver development.
- Etsam: Will resume work on RTOS-RTOS communication on RPU cluster. R5_0 as master. Bring up another instance of RTOS on R5_1. Will use upstream OpenAMP.
- Bill, Tanmay, Dan, Nathalie, Tomas
- Individual updates
- Did anything interesting come out of OpenAMP System Reference presentation to LEDGE HPP group?
- Any updates on recruiting TI or NXP to System Reference working group?
- What to shoot to accomplish before next Wednesday’s call?
- Let's look at KV260 recovery program & figure out how to script it.
- Correction on wanting to use same kernel for everything. Not expecting to mix ArmV7 and ArmV8 (32 & 64 bit).
- (DONE) Tanmay will try PetaLinux boot script with Yocto flow images - Using Petalinux boot script won’t help to boot because other configurations are missing in Yocto flow for SOM as well.
- (DONE) Bill will try automation with recovery image (will involve soldering on a relay)
- (DONE) Bill: Send Nathalie email of who to share Drive with - Bill added them.
- (DONE) Nathalie: Follow up on ELF approvals
- (DONE) Tomas & Nathalie: Try ordering the boards for LAVA again
- Tanmay update
- Ethernet is not up on U-Boot yet, not even in internal SW stack. Still To Do even on PetaLinux side.
- Bill: Works on ZCU102?
- Tanmay: Yes
- Bill:
- We can try to automate recovery image app, but user guide assumes a human is looking at web interface. Need to figure out the HTTP request that actually gets things done on the board. Would be nice if there was a document that describes the requests. Or, maybe can look at the code that's public.
- For ST board, will set up SD card with U-Boot with TFTP to fetch a script & execute it (fetch kernel, initramfs w/ firmware). Could also test mode where U-Boot loads M4 first, then Linux.
- Tanmay: After rootfs, the ethernet is up. Then, can TFTP kernel image & replace it into /boot section if we want to try multiple images without loading/unloading SD card. Am doing this.
- Bill: Trouble if you load a kernel that doesn't work. That's why prefer U-Boot based TFTP or using recovery image.
- Conclusion: Let's look at KV260 recovery program & figure out how to script it.
- Bill: Works on ZCU102?
- Was facing issues to boot images built with pure Yocto flow. Checked w/ Yocto & boot team: lot of PetaLinux overlays are missing from pure Yocto flow. Working with them to figure out what PetaLinux configurations are & will include in pure Yocto flow.
- Bill: Are there other problems besides just the script? If you bring the PetaLinux script over, can you make it work, or are there problems underneath? Can hack use the boot script that we want
- Tanmay: Bring the PetaLinux script over & try it out with images built.
- Sent the boot.bin documents
- K26 vs KV260
- K26 is SOM module
- KV260 is Starter Kit
- Whatever configuration in Yocto is for KV260 board and not SOM alone
- soc_variant: K26 + board_variant: KV = KV260
- Ethernet is not up on U-Boot yet, not even in internal SW stack. Still To Do even on PetaLinux side.
- Bill: Haven't had a chance to work on this project this week
- Dan:
- Focusing on tomorrow's app-services meeting. Preparing updates on Zephyr virtio, which is public.
- Hypervisorless virtio setup on Xilinx ZCU102. Most of the code is public & will take it from there tomorrow.
- Tomas: LEDGE HPP call is only once a month, so hasn't happened yet
- Bill: How best to share WIP with other folks in Linaro? Add them to the drive, or send PDFs? e.g. Francois, Joachim are probably OK with read-only
- Tomas: Fine to open up to ppl who are generally interested in it.
- Nathalie: Fine to add ppl who we know. Think the original idea was to just be careful about random ppl on internet accessing. Grant gave member reps initial access, then some folders (e.g. System Reference) I added more ppl to the access.
- Bill: Send Nathalie email of who to share Drive with
- Tomas: What is the status on PMU ROM ELF?
- Nathalie: Need to follow up w/ VP approvals during meeting this week. Think the other pieces needed for Legal to give green light are in place.
- Any updates on recruiting TI or NXP to System Reference working group?
- Bill: Will mention it in next Linaro-NXP call, which hasn't happened yet. Have bugged John H at TI about being more involved in OpenAMP, but that is not on their radar right now.
- Tomas: Think it will be easier to convince ppl once we have System Reference on 2 platforms. Then can do a big push.
- Bill: Originally, had said same kernel on all platforms, but that was before realized that was an Armv7 and Armv8 platform. Not expecting 1 kernel for 32-bit & 64-bit.
- Tanmay: Initially, thought building Yocto on SOM would be same as ZCU102. Looks like PetaLinux overlays are way ahead on SOM board. Is it OK if we start developing demos on QEMU so we have something to show & then can port demos once the HW is up?
- Bill: Important to keep KV260 going in the background. But, since long lead time for public, not urgent. Would like to keep uncovering issues & trying to fix them.
- Tanmay: RPU talking to R5 core 0 talking to R5 core 1
- Bill: These are all use cases & will have several in flight. At next Connect, we should demo the best stuff we have working at that time. Currently focused on what we can accomplish by end of 2021. Was hoping for automated CI for whatever state we're in, even if vendor kernels & stacks. Want to be able to build & run tests nightly.
- Tomas: Having trouble ordering on behalf of someone else b/c all the declarations about intermediaries. Can Linaro order for themselves & we'll figure out a way to cover the expense?
- Bill: May be tricky
- Tomas & Nathalie: Try 1 more time & then maybe ask Sales for help
- For next time:
- Tanmay will try PetaLinux boot script with Yocto flow images
- Bill will try automation with recovery image (will involve soldering on a relay)
- Nathalie: Follow up on ELF approvals
- Tomas & Nathalie: Try ordering the boards for LAVA again
- Bill, Tanmay, Dan, Tomas, Etsam, Arnaud, Nathalie, Paul
- Individual updates
- Tanmay’s experiments w/ SOM board and boot images I had built with openamp-image-minimal target
- Bill posted initial version of KV260 notes in Google Drive
- Arnaud update on sharing repos
- Paul update on patches submitted to Zephyr
- Arnaud: All Scenarios OS project
- Tomas: How do we relate to LEDGE heterogeneous project (HPP)?
- (DONE) Tanmay: Check w/ Yocto team about "K26" vs "KV260"
- (Obsolete) Tanmay: Set autoboot to no & see if DHCP gets an IP address
- (DONE) Nathalie: Find out if we document that info someplace (SOM schematic won't be published, just carrier card)
- (DONE) Tanmay: There is user guide on how to create boot.bin. Will find it & send out.
- (DONE) Paul: Send link to wiki page
- Tanmay tried SOM Getting Started on MacOS
- Not gunzip, had to install xz utilities
- Used "screen" and it worked
- Bill: Just use the screen command from MacOS & it should work on Linux
- Once booted up, think we can do the OpenAMP stuff
- Tanmay: HW bring-up for KV260 Google doc
- Facing issues during boot with the images
- It's not getting beyond U-Boot
- Boot.scr is not same as what we have in PetaLinux BSP, which is different from ZCU102. For ZCU102 the boot.scr are same.
- Nathalie: Your document says KV26, did you use KV260 BSP or K26 BSP? These are different. Starter kit is KV260, whereas SOM alone without carrier card is K26.
- Tanmay: Check w/ Yocto team about "K26" vs "KV260"
- Facing issues during boot with the images
- Bill: KV260 notes:
- Listed issues & questions that came up
- Copy/pasted some diagrams from documentation that's helpful to non-Xilinx folks
- Using pre-built images for KV260
- Can stop it at U-Boot & play around with it, but if try to do anything w/ Ethernet that doesn't work yet. Need Ethernet support in U-Boot.
- Tanmay: Have seen TFTP boot working for internal SOM boards
- Tanmay: Set autoboot to no & see if DHCP gets an IP address
- Vision CC schematics available but no SOM schematics available
- It would be good to document QSPI & eMMC part #s & TPM part #s and maybe DDR part # so you can calculate fit & longevity
- Nathalie: Find out if we document that info someplace
- Surprised that boot mode is locked down to QSPI on starter kit
- Think we can work with A/B update mechanism
- Would like to be able to automate the interaction w/ recovery program, using curl to program slot B & set it active, or something like that
- Assuming 100K write cycles, like what's on ZCU102, think it could last ~7yrs in LAVA lab
- Chatted w/ Michal & think could use JTAG boot
- How to use JTAG boot? Do we need Xilinx tools, or can we use openOCD? Saw there is a ZynqMP target in upstream.
- Has anyone used OpenOCD w/ this SOM?
- Bill: Does SOM work w/ the free tools?
- Nathalie: Should qualify for webpack free edition of tools
- Where does the bitfile get loaded? Where is FSBL getting it?
- Tanmay: BIF is not supplied with PetaLinux BSP
- Bill: If we need to recreate boot.BIN, how do we?
- Etsam: Can do from Vitis or PetaLinux w/ BIF. Still need to know where the FPGA .bit file lives.
- Tanmay: There is user guide on how to create boot.bin. Will find it & send out.
- Nathalie: dfx-mgr loads when you pull in the smartcam application. Not sure if a bitstream is needed for the default.
- Arnaud
- Discussed w/ project to know if possible to put as external the repo to be able to run kernel mainstream & u-boot for the ST M32MP1. Think it should be possible. Need to find the proper way to disclaim the support first. Hope to share in a few weeks.
- This looks interesting: https://git.ostc-eu.org/groups/OSTC/-/wikis/home
- Project to harmonize distribution independent from HW & be able to support different OSes
- They seem to support Zephyr, FreeRTOS & Linux
- Ultra96 boards
- Bill: Is this coming out of Open Harmony work?
- Arnaud: Yes. Just got this link ~1h before meeting, so have not looked in more detail. Some guys from this project were Linaro members before.
- Bill: Open Harmony is Huawei project & some Open Harmony work is happening in Linaro (Davide)
- Arnaud: Might meet some of our needs. Not sure if should fork. Multi firmware, multi image.
- Bill: Nice to have unified build instructions
- Arnaud: Guarantees that everything is working together
- Saw OpenOCD for Zephyr, but have to look into more
- Paul
- Kumar asked to look what it would take to run ZCU102 w/ openAMP build for this project w/ Xilinx QEMU in Zephyr SDK. Was old Xilinx QEMU, so updated to latest and submitted patches for updating Zephyr & Microblaze. Was accepted - would go into next Zephyr SDK. Still requires PMU ROM, which requires big download
- Tanmay: Waiting for final approvals. Not sure on the timeline. So far haven't seen objections to make it available on xilinx.com for public download with binary-only license.
- Done w/ tasks for this project for now
- Tanmay: Is there instructions for upgrading SW stack?
- Paul: Updated Xilinx QEMU should be available in the next release.
- Paul: Send link to wiki page
- Bill: If you look at Zephyr docs for how to debug, tells you to download Linux SDK to get OpenOCD that works with ST board, which is very large download. Suggested to Kumar & Paul to see if can make Zephyr version of OpenOCD work with MP1 platform. Would that be positive for ST?
- Arnaud: Wrote this documentation 1-2 years ago. Since then, have upstreamed a lot of things. Have to check that it's fully compliant to use the OpenOCD main project instead of the one containing SDK. Have to discuss w/ Paul & Kumar how we connect to the right target to debug when there are multiple targets.
- Bill: Sounds like a lot of deltas have been closed
- Arnaud: Think should not be big delta. Can't yet use OpenOCD for Zephyr, but can specify that you don't want to use the default one.
- Paul: Would like to look into it. Don’t have MP1 board yet - stuck in customs for a long time. Think they lost it.
- Arnaud: Think same for Avenger96. Same processor & way to debug. Could look at both.
- Bill: Can you still order Avenger96?
- Nathalie: 96boards.org sends you to page that says datasheet only available https://www.arrow.com/en/products/avenger96/arrow-development-tools
- Tomas: LEDGE HPP has overlap w/ this group. Think they want to do some higher level stuff.
- Volunteered to present to LEDGE about what our group is working on
- This group is coming from Device Tree world. Lot of those guys are PCIe/data center. Are we trying to bridge?
- Bill:
- If data center evolves to look like us.
- If remote processor is on PCI card, that falls into our domain & we can deal with that.
- Arm has a lot of interest in automotive & they are interested in big automotive case w/ big server chip and will want to augment that. What if we took a big data center board & put it into industrial or automotive setting. They probably don't want to change from ACPI to Device Tree.
- But once we don't have DT & connection is on PCI and not same chip, then resolve those differences, then it looks like what we are doing.
- Tomas: Xilinx POV: Have been in embedded but getting dragged into SmartNICs, which is a very different world.
- Tomas: How to make sure OpenAMP System Reference is aligned with HPP
- Bill: OpenAMP is lightweight community project w/ no engineering resources, just volunteers. HPP has actual resources (infrastructure, people time). HPP mission is to provide real engineering support to the relevant parts of OpenAMP that further the goals of HPP.
- Tomas: HW is so far for System Reference ST & Xilinx. What about NXP & TI?
- Bill: have poked NXP. Would like to see both, but TI is not a Linaro member, so can't spend Linaro resources on TI.
- Nathalie: NXP & TI haven't come to the last few OpenAMP TSC meetings.
- Bill: TI does come to OpenAMP RP calls. Maureen left NXP, so some handoff there.
- Tomas: Important that we keep HPP updated on what we are doing here. Maybe HPP will also be a place to recruit participants to OpenAMP System Reference.
- Bill: Don't know if HPP will become project that RTOS vendors could join standalone, or if will require full LEDGE membership.
- Tomas: Who else in RTOS or hypervisor might be interested?
- Bill: Think group we have is good b/c small but have variety
- Jeff
- Etsam
- Tanmay
- Nathalie
- Tomas
- Arnaud
- Bill
- Dan
- Kumar
- Paul
- Etsam
- Zephyr or Nucleus for RTOS-RTOS
- RPMSg in user space complications
- What goes on Google Drive & what goes on Wiki
- Any discussion points from Bill’s notes on ST build steps?
- Any update on PMU ROM ELF?
- What to shoot to accomplish before next Wednesday’s call?
- (Obsolete) Bill: Want to get to point where we have 1 kernel image for all the platforms. Need to add that to checklist.
- Tanmay: Once both kernel & user space configurations up, measure & compare performance
- (DONE) Nathalie: Work w/ Arnaud to get docs page on OpenAMP Project website
- (DONE) Nathalie: Add note to Wiki that the Google folder is just accessible by members of the working group.
- (DONE) All: Please review the updated checklist & come prepared to discuss it next Wednesday
- Measure performance before deciding how to deal w/ RPMsg limitations in user space
- Think we can demo user space application, but it's not stable right now. Need to put in effort in these areas. This is not most critical though, so can back burner.
- Google Drive for drafts, Wiki for more finished work, until we get Markdown docs in place. Then Markdown will be official docs.
- Jeff: Zephyr or Nucleus for RTOS-RTOS
- Jeff is Product Manager for Nucleus.
- Would love to have Nucleus as an option, but it's a proprietary (with source) commercial offering. Can make eval license available.
- What is the guidance for the reference system? Does Nucleus meet the criteria of being really low barrier?
- Tomas: Project is OSS focus, but would love to see commercial link to it as compatible. Adjacent. Shows the standardization.
- Bill:
- Agree. Wholly appropriate for our project to say "If you want to see it work with Nucleus, go here & can require login/license". Same for VxWorks and other.
- RTOS-RTOS could also be bare metal-bare metal
- Would you disengage if Zephyr was the lead?
- Jeff: No, we are happy to help promote OpenAMP & be a part of it.
- Tomas: Suggest to get up & running w/ bare metal & Zephyr. Then next step of proprietary b/c there is always a need (e.g. safety cert). Encourages standardization.
- Etsam: OK to start w/ Zephyr & move to Nucleus w/ eval license.
- Tanmay: RPMSg in user space complications
- QEMU bring-up: RPMsg in kernel working fine.
- Needs separate DT to run demo in kernel space vs user space b/c OpenAMP framework only supports 1 IPI for channel.
- User space is using same IPI interrupt b/c they are hard-coded at compile time in Xilinx platform files for OpenAMP framework. Single interrupt can't have 2 ISRs.
- For now, decided to use different interrupt for kernel space & user space, but problem is still there in OpenAMP reop & and described as known limitation in README, that have to recompile, including DT
- Think we should allow 2 channels in OpenAMP framework: 1 for kernel space & 1 for user space.
- Arnaud: Do you use resource table in RPU firmware. You should be able to define 2 virtio resources with separate mailbox. Could have 1 dedicated for kernel & 1 for user space side.
- Tanmay: We are only using 1 device name and it is shared between user & kernel space.
- Tomas: Xilinx specific?
- Tanmay: Think it is Xilinx specific, but need to explore more on OpenAMP side.
- Bill:
- It's not a showstopper if we need different kernel & firmware to demo at first.
- Are you suggesting 2 separate vdev? Yes. This is a nice capability to demonstrate.
- Another thing we could do is unbind the driver before we start the app.
- Think the way you're going is a nice thing to demo. But, if it gets hard, there are other options.
- Tanmay:
- Will continue pursuing this as a background activity
- Customer might expect kernel driver separate from user space
- Bill: Want to get to point where we have 1 kernel image for all the platforms. Need to add that to checklist. May take some time to get there.
- Bill: Know Xilinx uses RPMsg in user space. Does anyone else?
- Tanmay: Was looking at TI page for PRU. Otherwise don't know who else.
- Bill: When I left TI, this config was about doing firmware loading from user space. PRU is tightly constrained co-processor, so it's a little challenge to use.
- Tomas: Think Cyril started doing in user space b/c of performance to avoid trapping all the time. Does it improve?
- Tanmay: If we want to transfer large buffer, user space RPMsg is really helpful. RPU & APU share same memory.
- Bill: If you're transferring 16K at a time, you're not making a 16K message. That's normally done via pass-by-reference. Put pointer into message & send.
- Bill: But, Tomas' Q is still valid - which is better performance? Once we have both configurations up, let's measure what we're getting.
- Tomas: Throughput with small packets & latency test would be good to have application do (on real board)
- Etsam: Do we want to simultaneously use RPMsg form user space & kernel space. If yes, need Tanmay's changes. If won't be used simultaneously then probably no change is needed.
- Tomas: Would like to avoid recompiling kernel. Changing DT is easier to scale.
- Tomas: Big question: Is user space RPMsg faster? If it's not, why bother?
- Bill: Having movable virtual devices will come up. Even if we don't put RPMsg in user space, Dan's stuff will need signaling & notifications, which is similar to what we're doing. These capabilities are important.
- Bill: Limitation of putting RPMsg in user space, only 1 process. In kernel, have multi=process capability.
- Bill: If big performance improvement, could see
- Etsam: Arnaud's suggestion of separate IPI channels if there are channels available.
- Tomas: If you change in kernel, harder to change b/c have to upstream. Can move much faster w/ user space on RTOS side, to add features & try them out. Then can consider adding in kernel.
- Arnaud: We had such problem in co-processor example. Solution we found is to choose configuration in U-Boot.
- Bill: Agree, can have both residing on platform & then choose.
- Conclusion: Let's measure the performance & see where to go from there
- Bug in driver: Can't load RPMsg user space firmware from remoterpoc sysfs
- Have to use xsdb debugger to load RPU firmware
- Getting help from Ben in Xilinx OpenAMP team
- RPMsg User space demo doesn't work on QEMU, just ZCU102 HW
- Will get help from Xilinx QEMU team
- After assigning separate channels, after booting board, only 1st demo works
- Need to investigate more
- Conclusion: Think we can demo user space application, but it's not stable right now. Need to put in effort in these areas. This is not most critical though, so can back burner.
- Starting to work on KV260 SOM bring-up. Will share instructions w/ Bill when ready.
- What goes on Google Drive & what goes on Wiki?
- Bill: The wiki is a stop-gap. Would like to see this get into .rst or .md to go through Sphinx.
- Arnaud: Need somehwere on GitHub or someplace to put docs that we want to share, instead of Google Drive. Google Drive is good for drafts.
- Nathalie: Work w/ Arnaud to get docs page on OpenAMP Project website
- Paul: Was trying to figure out what is the latest work in progress, but not visible on the Wiki. Thinking to put the notes in the Wiki instead of private notes. Or, can collect project notes someplace.
- Bill: Can use Google Drive as the staging area. Paul can put docs in that folder.
- Suggestion: Google Drive for drafts, Wiki for more finished work, until we get Markdown docs in place.
- Nathalie: Add note to Wiki that the Google folder is just accessible by members of the working group.
- Bill: Spent time w/ ST board
- https://docs.google.com/document/d/15Rdcg71ZZy8teZjLZqNpgwNocMQIwGKNr_55BSzY9SY/edit#
- Had some network issues, but everything else went pretty well
- Never tried working with meta-zephyr before. It's reasonable.
- Think we need to discuss if want to use meta-zephyr as a process.
- ST has nice set of demo images already & works pretty well
- Tried the bare metal demo. Have not tried the FreeRTOS demo yet.
- Working through questions with Arnaud.
- SCMI
- Arnaud: Some differences between upstream & ST kernel b/c some blocking points. Have to discuss w/ Loic & project manager how to handle this.
- Bill: Would require changing low-level firmware?
- Arnaud: Don't know if our support team is OK to make this a supported flow. Right now, it's an internal image.
- Bill: Can't use M4?
- Arnaud: You can't use the A7 b/c can't enable some clocks. Fixed by an add-on to change the DT for phandle of clocks & some resets.
- Bill: Would be good to know how long to resolve the upstreaming blockage to determine path to take.
- Arnaud: Customer wants us to support the legacy. Upstreaming the SCMI will break the legacy.
- Demo w/ RPMsg char driver
- Arnaud: Don't have demo using old version. Not compatible. Can use RPMsg char but need to create specific endpoint on your side & co-processor side & each have to each other's address.
- Arnaud: Pushed RPMsg TTY last week. Perhaps could make demo w/ TTY console.
- Bill: Good candidates for OpenAMP staging kernel b/c expect them to go in.
- Arnaud: A while ago, created Zephyr serial driver over RPMsg. But probably not up-to-date.
- Bill:
- If we will continue using OE, want CI loop that publishes shared state, so ppl can get up-to-speed faster. Maybe even publish some of the daily builds.
- For CI on HW, expect board will boot, U-Boot will fetch uenv text file and execute. Fetch kernel, initramfs & start kernel with these parameters.
- For QEMU, could try to make it work the same way.
- Nathalie: PMU ROM ELF - meeting w/ Xilinx Legal today
- What to shoot for next week?
- Please review the updated checklist & come prepared to discuss it. (put link in notes)
- Tanmay: KV260: Need to try the built images on HW. If they work right away, will send steps to Bill to try next week.
- Bill
- Dan
- Arnaud
- Tanmay
- Tomas
- Nathalie
- Jeff -> Etsam
- Bill's notes on Xilinx instructions
- Etsam: What Mentor will work on
- Tanmay: Spreadsheet of SW components for Xilinx example
- Xilinx topics: PMU ROM, meta-som
- Wind River timeline
- Per platform checklist
- What to target for next week?
- (DONE) Tanmay to share the link to the spreadsheet of SW components needed for example
- (DONE) Tanmay: Will ask Xilinx Yocto team about meta-som for KV260. PetaLinux BSPs are released for KV260. PetaLinux overlays are all on top of Yocto. Will ask when that will go out in Yocto release instead of PetaLinux BSP. --> 2022.1
- (DONE) Nathalie: Ping Maarten for confirmation on date for app-services call
- (DONE) Nathalie: Save a V0 of per-platform checklist and then this one can be the working copy
- (DONE) Bill will add some more structure to per-platform checklist Google Doc
- Would be great if Etsam can look into RTOS-RTOS
- Bill published raw notes & started summary section
- https://docs.google.com/document/d/1PJz1Dv1fEZE12tljVj8GUNdmgSeVdHiFtGk64Ht59Sc/edit?usp=sharing
- Tanmay has updated doc to work with server image to cover the missing dependencies
- Would like to test with a Docker image b/c has even less stuff in it
- Trying to automate the procedure so that it could go into CI
- Bug?: If you build successfully, then clean the DT or kernel, change & build again, you get a new WIC image but doesn't build a new QEMU boot conf, so 'run qemu' picks up the old conf
- Bill:
- Was wiping /tmp and building from sstate & that works
- But if you're just hacking the DT, you want that to work
- Tanmay: "clean all" wipes everything on the particular package & openamp image minimal
- Bill: That is a workaround, but OE isn't supposed to work that way. If it rebuilds the image, it should rebuild the QEMU boot conf.
- Bill:
- Pain point: Creates WIC image & have to round up to a power of 2, which is an awkward manual step
- Tanmay: This is handled by PetaLinux overlays. Documented the step b/c allows us to see.
- Bill: Would think WIC should let us do it in WIC configuration, but haven't investigated
- Tanmay: We can probably put that command in bitbake recipe of QEMU
- Bill: Can be automatable, but would be good if built-in instead of fix-up
- Bill: Is this general QEMU requirement, or Xilinx QEMU requirement? Xilinx QEMU is using SD card peripheral. If it's upstream QEMU, then there should be a fix we can pull in.
- Next: Bill will finish automation script, then we can iterate on enhancing it
- Etsam: Need to solidify on ideas on what would like to work on. Would like to focus on RTOS on remote & host config. If there are things that are higher priority, could try to contribute on those.
- Tomas: Bill has been interested in having Linux -> RTOS as host for another remote, so it is on the radar
- Etsam: Chain configuration is important. Should have 2 RTOS working together first.
- Bill: Would be great if you could look at RTOS-RTOS.
- Etsam: Can maybe have something to share in a few weeks.
- Arnaud:
- Zephyr w/ RPMsg using multicore instance for core 1 to talk to core 2 & core 3 using OpenAMP. Not yet mature.
- Using 1 core in master mode discussing w/ 2 cores in slave mode. Trying to make it more flexible to have 2 instances of RPMsg with 1 in master and 1 in slave.
- Using virtio back-end without remoteproc. Based on Kumar's work ___. Should be able to adapt to have resource table to define resources.
- https://github.com/zephyrproject-rtos/zephyr/pull/38734
- https://github.com/zephyrproject-rtos/zephyr/pull/38328
- Tanmay: Have created spreadsheet of OpenAMP SW components needed for end-to-end example to boot to rootfs & run the application
- Tanmay to share the link to the spreadsheet of SW components needed for example
- Raw components to flash on the HW
- Bill: Would like to build the kernel & OpenAMP repo every CI step
- Bill: Will want to tweak DT as part of step. OK if start with a DT & add overlays, or generate w/ Lopper. Don't want to start with TCL & XSCT.
- Arnaud: Should we have an SD card image? Then provide info on how to update the SD card image, to ensure compatibility between binaries. Each company could provide an image/loader and document how to update everything w/ Yocto bitbake or other environment.
- Bill: Prefer individual files
- Arnaud: For ST would provide FIP with several binaries (Trusted Firmware standard, not U-Boot standard)
- Tanmay: PMUFW, FSBL, TF & U-Boot could be in BOOT.bin, which would boot to U-Boot & let U-Boot boot the kernel & rootfs eventually.
- Bill: Let's discuss when we have the candidate code to build the images b/c will know the pain points
- Bill: Is there any more clarity on PMU ROM. What's progress to distribute? Currently, we need it for QEMU. Do we actually need it?
- Nathalie: Legal is backlogged with end of quarter. Trying to figure out what license it would have to be distributed under if not in BSP.
- Tanmay: Need to sync w/ PMU FW & QEMU team to ask if we need to call into ROM
- Etsam: PMUFW provides system-wide services. If you pull that out, some updates will likely be needed in other parts of code, likely TF.
- Bill: PMUFW is solved - can be built from source easily. The question is the PMU ROM for QEMU. Real HW has ROM already. But, it doesn't seem to run through it, throws into memory.
- Tomas: Don't think there are callbacks into ROM, but should verify that.
- Etsam: Think the PMU ROM could be eliminated, but best to check w/ Xilinx QEMU team.
- Post-call update: Tomas: Edgar indicated we can run without PMU ROM, but then can't use PMU FW. Other option is to emulate the FW calls in QEMU. Edgar will discuss w/ Tanmay.
- Bill: Have received KV260 board. Want to look at ST board next.
- Meta-xilinx & meta-som doesn't seem to have what I need to build for KV260. No machine called KV260. Think there's a release upcoming that will solve that. Is that statement true?
- Tanmay: Will ask Xilinx Yocto team about meta-som for KV260. PetaLinux BSPs are released for KV260. PetaLinux overlays are all on top of Yocto. Will ask when that will go out in Yocto release instead of PetaLinux BSP.
- Bill: meta-petalinux is being pulled into the build. When used Tanmay's instructions, did see meta-som. Wondering if internal version has more stuff in it.
- Etsam: Does Xilinx QEMU contain CSU ROM? Will we have same issue with CSU ROM?
- Bill: Don’t think so. QEMU command line is short-circuiting some of the 1st stages of the boot procedure. Today, we're not loading CSU ROM.
- Etsam: So, authenticated boot not supported with QEMU…
- Bill: What does WR timeline look like?
- Dan: Publishing binaries is still under debate. Virtio Zephyr work is under way. Aiming to be public by end of October in prototype form. Would open the door for hypervisorless virtio with full open source stack. Platform: Xilinx QEMU ZCU102.
- Nathalie: Ping Maarten for confirmation on date for app-services call
- Per-platform checklist: Did anyone get a chance to tweak it?
- Nathalie: Save a V0 of per-platform checklist and then this one can be the working copy
- Bill will add some more structure to per-platform checklist Google Doc
- For next week:
- Bill: ST platform hands-on & similar notes to Xilinx one
- Etsam: Will start on RTOS-RTOS configuration & loop in Jeff to discuss Zephyr vs Nucleus.
- Arnaud: Priority for next month is OpenAMP release 2021.10 & supporting Bill
- Bill
- Kumar
- Tomas
- Jeff
- Tanmay
- Nathalie
- Individual updates
- Make checklist of features per platform
- What to shoot to accomplish before next Wednesday’s call?
- (DONE) Nathalie: Move the Wednesday call to 1hr later because of Kumar recurring conflict
- (DONE) All: Please review & tweak the checklist before we turn it into a 2-D table: https://docs.google.com/document/d/1Y3fpQV8A9CQD1ye5YYX4Gyi80f1VTHo892zJv64ZzMg/edit?usp=sharing
- Push the Wednesday call later by 1hr to avoid conflict with Zephyr TSC weekly call
- Tanmay update
- Working on user space demo: exploring SW stack
- Linux user space can directly communicate with RPU
- Trying to understand: What does it actually mean when we say "user space demo"?
- Working on open sourcing remote proc device driver, as part of Xilinx effort separate from this effort, so don't need to discuss it here.
- Working on user space demo: exploring SW stack
- Tomas: do you have trap to OS up & running?
- Tanmay: That's what is already documented. Now going over to the virtio and user space.
- Tomas: Used to be that when you trapped through kernel you did reads & writes & with user space you did RPMsg calls. Would like to have shim layer so those interfaces can be identical & you don't have to change the code.
- Tanmay: Don't know yet, still exploring the code.
- Bill: Identical is a high bar. Most important is that bulk of app is the same. If init sequence is a little different, that's OK.
- Tomas: Right, that difference is all in 1 place.
- Kumar: We need to make a checklist of the different features
- Configuration: Testing the R/M core, communication to Linux on A core
- Can you show Linux kernel to remote side, user space to remote side
- What are the features we're trying to show?
- Where are we with the build system?
- We can figure out which are checked off for each vendor, so we know the state from week to week
- Tomas: Like a dashboard of what works in the various configurations
- Kumar: Let's take a stab in this meeting to make the list
- Checklist
- Please review & tweak the checklist before we turn it into a 2-D table: https://docs.google.com/document/d/1Y3fpQV8A9CQD1ye5YYX4Gyi80f1VTHo892zJv64ZzMg/edit?usp=sharing
- Once we have the list, can flesh out the next level of detail of what this means
- Can number them and make it easy to refer back to the verbiage (need to make sure that doesn't get out of sync when we add bullets…)
- Kumar: Would we have kernel git tree hosted by OpenAMP? Vendor branches?
- Bill: Staging kernel like Linux-next. Gets rebuilt when someone publishes candidate patches that meet criterial. Will hold off on creating that until we know it's necessary. Hopefully Tanmay can get his patches upstream soon. Also, Arnaud's patches.
- Kumar: Where are the components we need & how many are upstream
- Tanmay: Platform management unit turns off/on the remote processor. APU doesn't directly turn on/off remote processor. It makes the request to platform management unit. The firmware of this is open source.
- Kumar: Can have directions for how to reproduce those vendor things. Then, have OE binary references to those pre-built images b/c we don't need to change those things.
- Bill: Yes, cut build process in 2.
- Tanmay: Extra maintenance effort for the binaries. Who will maintain the binaries, version control?
- Bill: We can help set it up, but the vendor maintains it if it breaks. Can run automation weekly/bi-weekly that builds and can be imported into CI.
- Kumar: Can have those files revision controlled in some repo
- Tanmay: We need table where we define the SW components needed for end-to-end example. Which are built from upstream / vendor source tree / which are binaries, and where to find. Can have a Google Sheet and each vendor can fill it out.
- Xilinx: All from source except 1 ELF file. Still going through Legal. Rest via Yocto build.
- Kumar: There's building from source & then from OpenAMP view, do you need to re-build or change it? Could just use binary for that.
- Bill: It's not so much the build, but it brings in a lot of dependencies to build it from source.
- Kumar: Want to get to a state where build repository is kernel, OpenAMP, simple Linux user space, OE to construct the image format. Rest is just pulling some binaries & have instructions for how to reproduce.
- Bill: Being able to build PMU from source is nice & maybe touch it when we get into System DT, but OK to keep it in Xilinx-specific flow. Can demo certain things in vendor-neutral flow & demo other things in vendor specific flow.
- What to shoot to accomplish before next Wednesday’s call?
- Tanmay: Continuing to explore user space. May not have much of update on Wednesday.
- Nathalie: Move the Wednesday call to 1hr later because of Kumar recurring conflict
- Tomas
- Tanmay
- Nathalie
- Paul
- Kumar
- Dan
- Bill
- Arnaud
- Testing mailing list again
- Individual updates
- Discuss Tanmay's plan proposal
- How do other companies distribute binaries?
- For licensing recipes/instructions: What is preferred license for OpenAMP?
- What to shoot to accomplish before next Friday’s call
- Rescheduling to better slot
- (DONE) Dan, Arnaud: Sign up for mailing list with gmail account
- (DONE) Nathalie: Check for bounces (no bounces)
- (DONE) Tanmay: Call it System DT flow in plan, instead of decoupling flow. Post plan to https://github.com/OpenAMP/openamp-system-reference/wiki
- (DONE) Nathalie: Check with Etsam about 8am PT slot
- Pulling openamp & libmetal from Xilinx fork -> let's build from OpenAMP repo, even if it means you need Xilinx BSP
- Did anyone not receive the email from Tanmay this morning? ST, WR
- Tanmay update:
- QEMU up for Xilinx SW stack
- TFTP boot works, but haven't updated document yet. Waiting for Bill's feedback. Will make a v2.
- Bill update:
- Able to reproduce Tanmay's instructions with a large AWS instance
- Critical items of feedback have already been addressed:
- AWS image is server, not desktop
- 2 dependencies missing that Tanmay has now fixed, which would be fixed automatically for desktop. Was missing on server. Error messages were 6 levels deep, so that wasn't obvious.
- Would like to see the TFTP & SSH instructions and try them out.
- Will publish steps Bill goes through (covers stuff that Xilinx ppl understand, but others may not) & bug in meta-xilinx
- Xilinx fork of QEMU and Xilinx vendor kernel. Pulling openamp & libmetal from Xilinx fork -> let's build from OpenAMP repo, even if it means you need Xilinx BSP
- Arnaud update
- Didn't have time to update wiki to point to the docs to set up ST
- Dan update
- Pushed half of the hypervisorless virtio big picture to OpenAMP kvmtool GitHub repo. Back-end is contained in kvmtool.
- Still need to do other half: Virtio front end is still work in progress
- There is support kernel module that provides notification support. Linux mailbox driver was written by a Wind River colleague.
- Need to clear with IP review team to be able to push POC for use case
- Notification mechanism is supposed to be plug & play. Changes to virtio processing are all contained in kvmtool in user space code. Easy to identify b/c ifdefs in the code
- No custom Linux code except for the mailbox driver for notifications
- Would benefit from a higher level design document/write-up. Right now it works, but isn't thoroughly documented.
- Paul
- Able to reproduce Tanmay's build process. Have not tried to run yet.
- Will be OOO next 2 weeks.
- Upon return, would like to look more closely & deeper to get ideas on what should work on
- Tanmay's plan proposal: https://lists.openampproject.org/pipermail/openamp-system-reference/2021-September/000005.html
- Tanmay: Call it System DT flow, instead of decoupling flow
- Bill: After step 4 is done, user doesn't have to download XSCT?
- Tanmay: It will become transparent to user. Will be like compiling Yocto. Not sure what other SW stack might require XSCT.
- Bill: It's big and currently downloaded automatically, even if need or not. Embedded build files all assume it's there. Bill: Better if you can have simple files flow in, instead of big tools. Want to get to a point that we can have quick testing if someone pushes a change, without having to merge into Xilinx ESW repo. Will require a simple makefile. Could include a pre-built library for Xilinx R5, that could have been pre-built earlier in a complicated way.
- Bill: Is R5 the only thing holding us back from using upstream kernel on QEMU? If long process, should we create a staging kernel at open-amp so we can pre-test before things make it complete upstream. NOTE: we should *not* ask Mathieu to be maintainer of that.
- Tanmay: Like idea of staging kernel. Trying to post patches, but not sure when will be merged. Started work on driver upstreaming process, but new to this.
- Bill: When we need staging kernel, we'll create it. Won't create until needed.
- Arnaud: Could be interesting to have staging kernel.
- Ability to load __ firmware w/ OP-TEE can be shared.
- OpenAMP CI test & could choose branch for different platforms
- Bill: Would like to have a kernel.next flow where we have branch that gets rebuilt with the patch series & make sure they co-exist. Need to send message that this is not for products.
- Kumar: Kernel versions for Xilinx vs ST? How many changes from vendor kernel perspective, to be able to boot board on tip.
- Bill: Criteria for staging is that the patches apply to tip. Don't want to pull in everything, but everything that's ready. e.g. can start w/ Ben's patches & then replace with the new one later.
- Arnaud: Generic image that could be compatible w/ last kernel & use to update kernel image & be able to use to test. ST has similar for internal testing.
- Bill: Handling OE layers is a different Q & can tackle when we have more experience
- Arnaud: Can start w/ common Linux & push all the upstream proposed patches we want for test. TBD if can use for CI test.
- Arnaud: Today in OpenAMP, we use Zephyr for CI test w/ OpenAMP module to ensure no regression w/ Zephyr. Would like to have on complete system.
- Tanmay: Can maintain patches as part of Yocto recipe & patch kernel while building Yocto?
- Bill: Don't want to do that. Solves build problem but not community problem. OK for advanced OE ppl. Regular kernel devs can't engage at that level.
- Bill: Would be interested to understand if we could integrate Dan's functionality into this timeframe.
- Dan: We are aligned on platform right now. That will help.
- Tomas: Does this look like right order of doing things? Can be agile.
- Bill: This looks like a reasonable outline.
- Bill: Is Kria support coming in meta-xilinx in 2021.1?
- Tanmay: Think it is there. Will update to latest release for HW demo. (line item 3)
- How do other companies distribute binaries?
- Arnaud: For starter kit, we have binary download, as part of ST distribution. Today, we have nothing with basic image - contains demo application, BSP, etc. Can check size.
- Bill: The important thing is to not require the login. It's nicer if it's a smaller archive or single file to download. Xilinx is BSP is ~700 MB download.
- Bill: PMU ROM download is only for QEMU, not a problem when we do HW.
- For licensing recipes/instructions: What is preferred license for OpenAMP? Usually MIT
- Kumar: Is XSCT for cortex R?
- Tanmay: PMU firmware is Microblaze firmware
- Bill: Required to build the Device Tree, which feeds into U-Boot & possibly kernel. Decoupling step will help cut some of the dependencies.
- Kumar: Wouldn't be too difficult to replace Cortex-R FreeRTOS with Zephyr
- Bill: Xilinx R5 support in Zephyr today?
- Kumar: Have QEMU R5 target that targets ZCU102 environment. Shouldn't be too difficult to get a port done. Can look at orthogonally to what Tanmay will work on.
- Tanmay: Have done demo with Free RTOS
- Bill: Xilinx ESW repo is permissive, but has lots of TCL scripts instead of simple makefiles. Good starting point for missing functionality.
- Tomas: Want to move away from TCL -> Lopper & System DT
- Bill: What Kevin T duplicated, was using upstream Zephyr?
- Arnaud: Used ST distribution + upstream Zephyr. Could still add support for ST example to meta-zephyr.
- prepuild image: https://wiki.st.com/stm32mpu/wiki/STM32MP1_Starter_Package_-_images
- sdk: https://wiki.st.com/stm32mpu/wiki/SDK_for_OpenSTLinux_distribution
- Cortex-M is provided as alternative, but can focus on Zephyr & Linux
- Arnaud: Used ST distribution + upstream Zephyr. Could still add support for ST example to meta-zephyr.
- Tomas: Invite Edgar for QEMU?
- Bill: Would like to get Alex B also in same call
- Tomas: Let's wait for a few weeks out
- Next week:
- Bill: Look at ST. Publish notes on Tanmay's build steps (no changes required).
- Tanmay: Update document with TFTP & SSH support for QEMU.
- Dan
- Arnaud
- Bill
- Tomas
- Jeff
- Nathalie
- Tanmay
- Etsam
- Kumar
- Cover in 1st 10 minutes: Any topics we need to discuss w/ Tomas (meeting overlaps w/ Tomas’ LVC21F DT YAML presentation)
- KV260 boards
- Individual updates
- How we want to organize in repo & what is best for setting up Docker
- Did everyone receive the email to the list from this morning?
- What to shoot to accomplish before next Friday’s call
- (DONE) Nathalie, Bill, Tomas to discuss how to order the boards in email & which budget they come out of
- (DONE) Tanmay to make updates Friday and let Bill know
- (DONE) Nathalie to forward OpenAMP-rp meeting series to Tanmay
- (DONE) Tanmay to CC Bill on anything related to Xilinx R5 driver
- (DONE) Nathalie: Let Linaro IT know we still have issues with list
- (DONE) Nathalie: Send Tanmay the correct email ID for the list
- (DONE) Nathalie: Send out another poll for moving the meeting time
- Bill: Doing an analysis of upstream QEMU & Xilinx QEMU. Would like to get Xilinx & Linaro together to discuss once that is ready.
- Tomas: Edgar willing to meet when ready
- KV260 boards
- Bill's order expedited because of benefit to Xilinx
- Would like to target LAVA: 3-5 boards (5 is overkill, 2 could get by)
- Ordering now with standard back order time would put us in mid-February
- Nathalie, Bill, Tomas to discuss how to order the boards in email & which budget they come out of
- Illias from Maxim not here (should we invite him?)
- Tanmay update
- Able to verify steps with fresh Ubuntu. Some prerequisites missing. Will add them later
- Have to sort out memory allocation error
- Have to sort out system control settings & update document
- Bill would like to reproduce today or this weekend
- Tanmay to make updates Friday and let Bill know
- Next: Bring up TFTP boot
- Tomas: How are we doing on writing down plan of prioritized order of tasks?
- Have discussed with Arun
- Tanmay: Send out plan to openamp-system-reference@lists.openampproject.org (not bounces)
- Bill:
- Would be good if Tanmay could start attending OpenAMP-rp on Thursdays
- Bill to forward OpenAMP-rp meeting series to Tanmay
- Xilinx R5 driver. Ben was working on it. V26 and still needs more work.
- Mathieu asked Tanmay to start over from V1 b/c it's been a long time since March.
- Want to track it closely. Tanmay to CC Bill on anything related to Xilinx R5 driver
- Would be good if Tanmay could start attending OpenAMP-rp on Thursdays
- Able to verify steps with fresh Ubuntu. Some prerequisites missing. Will add them later
- Bill update
- Been looking at Xilinx & upstream QEMU. Topic came up at Linaro to get heterogeneous model upstream.
- Plan to try Tanmay's document.
- Dan update
- Have a functional hypervisorless virtio POC with Xilinx QEMU simulating ZCU102 with PetaLinux on A53 cores and VxWorks on one of the R5 cores. Vxworks boots with remoteproc. Shared memory in between. Mailbox notification mechanism. Full embodiment of hypervisorless virtio notion b/c only uses shared memory interrupts. KVM tool virtio back-end on Linux.
- Should include or mention in next iteration of end-to-end demo
- Disclaimer: Work ongoing to replace VxWorks with Zephyr in this example, but no target completion date yet.
- Next: Will prepare a write-up for next app-services call (will discuss at TSC call on 9/20)
- Need to discuss w/ Maarten & go through IP review, etc. for publishing binaries
- Documenting should be easy, providing access to binaries may be trickier
- Bill: Even knowing what options to build KVM tool
- Will go into openamp project GitHub repo. Will push the latest batch of updates there. That's only half. The other half is the front-end in VxWorks. Will try to push updates by end of next week.
- Arnaud update
- Waiting to see how we can find synergy & organize the repo to integrate the different platforms. Prefer not to extend too much until we have that figured out.
- Bill: You were able to have Kevin reproduce - do you have a pointer so Bill can try?
- Kevin's write-up: https://gist.github.com/microbuilder/2f117939cdb06a142f473db8cb75fb9e
- Kevin also enabled the wifi on the board & thinking to have sensor reading on co-processor that provides info to main processor, which could send to cloud or webpage. Christoph showed similar at Linaro Connect 1-2 years ago.
- Mailing list test message this morning
- Tomas, Nathalie, Tanmay, Bill got it
- Nathalie: Let Linaro IT know we still have issues with list
- Arnaud, Dan didn't get it
- Arnaud didn't receive any email to confirm subscription, not even in spam or quarantine
- Nathalie: Send Tanmay the correct email ID for the list
- How we want to organize in repo & what is best for setting up Docker
- Kumar: There's a Yocto Project-related Docker (not directly under YP). https://github.com/crops/poky-container
- Bill: Background on crops: was to address ppl who needed to support really old machines, or Windows/Mac machines. Think it's lower priority, but have seen 3 containers have updates this year. Are we trying to address Windows/Mac machines as build environments?
- Kumar: Not really, more a side benefit. Seemed like a good starting point for baseline container for building OE/Yocto systems. Had Ubuntu.
- Bill: Might be good to enable ppl to reproduce on those machines
- Bill: Background on crops: was to address ppl who needed to support really old machines, or Windows/Mac machines. Think it's lower priority, but have seen 3 containers have updates this year. Are we trying to address Windows/Mac machines as build environments?
- Kumar: Looking to use that as a baseline for images. Would like to look at Tanmay's & Arnaud/Kevin's work to see what additional packages are required. Need to get back to it, no specific timeframe. Want Bill to be able to reproduce the Xilinx side & then can set timeline. Can then make sure the container can build both.
- Bill: What are we trying to achieve with the Docker container?
- Kumar:
- Make it easier to reproduce builds
- To get CI environment up & running in future
- Wasn't thinking about pre-caching
- Bill: Docker becomes more important once we want more ppl to try this, or have complex dependencies to manage
- Kumar: Not a critical path activity & don't expect it should block anyone
- Arnaud: Even if we use Docker, will have to fork some repos
- Forked one ST repo. Forked Yocto solution manifest and meta-zephyr
- Can we put in 1 repo in openamp? How to maintain? Have to update to latest releases. Could be complex to handle.
- Bill: Project already has a meta-openamp. Could make sense to unify there.
- Arnaud:
- Will probably have to create >1 repo. Maybe 1-2 per company.
- Where to store new development before upstreaming?
- If base on ST distribution, have at least 2 images: with & without OP-TEE
- Have non-official distribution to be able to run with latest Linux kernel
- Today, Zephyr is in manifest.
- Not sure how to manage to move forward on example. Don't think it's reliable to keep in personal GitHub. Perhaps solution will come with the Docker.
- Bill: Would like to continue exploring & find all the problems we'll have before we try to organize the solution. e.g. Yocto version? Who's using vendor kernels? What can we do with upstream kernel?
- Arnaud: Each company could provide one or more images that we could load on a board & have SDK environment for Zephyr, updating Kernel, OP-TEE -> SD card. Could be alternative to avoid Yocto engine & repos. Could create a new Yocto distribution using this.
- Kumar: There's a Yocto Project-related Docker (not directly under YP). https://github.com/crops/poky-container
- For next call
- Tanmay to enable Bill with changes for last few issues
- Bill to try to reproduce what Tanmay has
- Bill will try to have 1st version of QEMU differences between Xilinx & upstream notes published
- Dan will kick off discussions on how to share instructions & binaries. Will also try to push updates to kvmtool repo in OpenAMP Project. https://github.com/OpenAMP/kvmtool
- Agenda for next week
- Individual updates
- Discuss Tanmay's plan proposal
- Agenda for TSC
- Getting access to MISRA C checker
- Nathalie: Send out another poll for moving the meeting time
- Arnaud
- Bill
- Dan
- Tanmay
- Tomas
- Nathalie
- Paul
- Arun
- Individual updates
- Tanmay’s google doc
- Board needs
- Mailing list
- Does Bill and/or Kumar want to be a list admin (once the mailing list is working…)
- Do we want both approve and confirm or just confirm for subscription?
- Have folks been getting the TSC, TSC-voting, system-reference emails?
- System Ready & U-Boot
- (DONE) Nathalie: Set up discussion with Xilinx Legal if we can post just this ELF outside of export control
- (DONE) Nathalie: Check into supporting special efforts with KV260.
- Tanmay can focus on verifying with Ubuntu 20.04 distribution, to start
- Tanmay's update: QEMU only
- Have posted document for echo test instructions to the working group's Google drive
- Uses Xilinx yocto-manifests repo, which is public
- Think it will work on any debian-based Linux distro
- Sysctl config in case of build errors
- Remoteproc driver is not upstream yet: What to add manually is given
- Need proprietary file: User will need Xilinx account to download the ZCU102 BSP and extract the binary.
- Nathalie: Set up discussion with Xilinx Legal if we can post just this ELF outside of export control
- If we don't use this file, we won't use PMU FW at all, so will lose all power management functionality. Not required for HW, just for QEMU.
- Have 1 more verification cycle after last set of modifications on non-Xilinx machine. Verifying on different distros on VM.
- Bill: Can focus on Ubuntu 20.04 for start
- Happy to take suggestions
- Tomas: Have to change DT & addresses in example?
- Tanmay: Yes
- Tomas: How to get QEMU binary?
- Tanmay: Building in the Yocto build. Using XSCT right now, but working to remove that dependency.
- Bill: How to get XSCT without proprietary download?
- Tanmay: It is available in binary that gets sync'd during Yocto build
- Tomas: ZCU102 will be expensive. Should get this going on Kria board.
- Tanmay: QEMU on Kria is not ready yet, so just wanted to get simulation up & running.
- Arun: Plan: QEMU, then TFTP boot, then kernel space (currently only have kernel space), SOM board, System-DT flow (a.k.a. decoupling flow) (Yocto patches are in process of getting merged), plug & play more advanced applications.
- Bill update
- Got ST DK2 board, but haven't had chance to try it yet
- Ordered the new Xilinx board b/c lead time, but having trouble getting through export control. Probably would get it mid/end Oct, which should be fine.
- Nathalie: Check into supporting special efforts with KV260.
- What Bill plans on doing: Guinea pig to reproduce everyone's work. Work on documentation, if possible. Time allocation: 1 day/week.
- Arnaud update
- Helped Kevin from Linaro to reproduce ST setup & he could boot with the board
- How we want to organize in repo & what is best for setting up Docker
- Nathalie: Add Bill as list admin
- Bill seeing subscribers joining just to spam, so want approve
- Loic did not receive the cancel, but Arnaud did.
- Nathalie: Check w/ Linaro IT on inconsistent arrival of mails since 8/28. Not sure if could be triggering
- Bill: Only aware of issues sending. Sending directly from server, instead of AWS. Philip said there were some internal Amazon things triggering.
- Dan: Didn't even show up in Spam folder
- What to accomplish before next Friday's call
- Bill can try to duplicate the procedure outside Xilinx
- Xilinx: Discuss priorities (e.g. Kria, removing login dependency) and Arun & Tanmay write up a strawman proposal & send to list + Dan + Arnaud for feedback
- Tanmay: Start on getting TFTP boot up & running so don't have to rebuild after a change. Get a network interface up to transfer files in & out easily to try new firmware & changes easily.
- Testing the list: Dan & Arnaud didn't receive. Bill & Tomas got.
- YP uses groups.io. If this continues being an issue, we can consider moving a list over to try that out.
- System ready & U-Boot
- Tomas: Different SW configurations, or hypervisor done at different levels by different vendors. The later we push things, like into U-Boot, the more similar we will be & more we can standardize so config can be less vendor-specific. Can we take more out of vendor-specific config & put more into common open source config? Creating standards, or adhering to existing standards like System Ready.
- Bill: System Ready is about decoupling firmware from the OS, so you could have multiple different OS on top of the firmware. We're not describing the board to the firmware, rather describing how we want to use the board.
- Tomas: Yes, different SW configs, like having an OP-TEE or hypervisor, or modifying SW config. Trying to make DT data-driven. Trying to look at other things that come earlier, like in boot image, to avoid getting into vendor specific.
- Bill:
- Hypervisor (type 1) fits into this story b/c takes place of 1st OS you're booting instead of base OS
- Configuring firmware in a portable fashion hasn't come up, but think Tomas is right. If do at U-Boot level, will be more visible & potentially more common.
- Tomas:
- To test theory, if have scripts for vendors, want the scripts to look as similar as possible. Next, I want to change something, how common is that between ST, Xilinx? Can we avoid having to do it in the firmware?
- Xilinx: Can do at different levels, in many ways. Want to push to do it "the open source way" (may have to define standard) to make it as similar as possible, so we don't have stuff like Bootgen coming into the flow.
- With Kria, have been pushing decisions later in the flow, things dynamically
- Paul
- Arnaud
- Tomas
- Tanmay
- Dan
- Nathalie
- Infrastructure update
- Individual updates
- What to discuss next call
- (DONE) Tanmay: Email Nathalie for help on open sourcing flow at Xilinx
- Infrastructure
- New mailing list created but impacted by AWS issue. Nathalie added everyone & no one has received the test email. Can ask Bill & Kumar if one of them wants to be a list admin
- Arnaud created the repo. Empty b/c need to define what we want to put in it.
- ST: Have 3 repos to represent layers. 1 represent manifest. Not sure how to package in 1 repo.
- We should discuss w/ Kumar how we want to organize in repo & what is best for setting up Docker
- Nathalie moved over wiki pages from open-amp to openamp-system-reference wiki and updated links
- Individual updates:
- Arnaud: Sent email yesterday RPC services for OpenAMP. Do we want to start with this service for OpenAMP-OpenAMP demo, or do we need something else?
- Tomas: Great that you put it there. Will leave it to the implementers to make the strawman proposal.
- Arnaud: Can register ID on callback & same on client. Can have file system manager on 1 side & have remote access to file system. Or, can have serial communication behind this RPC service.
- Tomas: Could we get a couple slides to show how RPC works & the interfaces?
- Arnaud: There isn't really a spec for RPC. More, you want to call a function & have it go to remote processor or server - have client layer, transport layer & on other side, you have server layer. Check that you can provide the service.
- Tomas: Uses standard Linux RPC?
- Arnaud: Yes, add as generic service in library, not application on top. Just have app on top to demo.
- Tomas: Think 1st thing would be RPMsg.
- Tanmay: Able to bring up ZynqMP platform on QEMU with some pre-built binaries of Microblaze & pre-built DT blob. Have documented. Prebuilt binary for Microblaze for PMU FW & DT blob. Will integrate in Yocto.
- Tomas: Think binary is preferable
- Tanmay: Email Nathalie for help on open sourcing flow at Xilinx
- Think we can modify DT so won't need binary next week
- Dan: Using same QEMU approach to create baseline hypervisorless virtio platform, so will make integration easier sooner than later. In progress.
- Paul: Just starting to get acquainted with the project. In Kumar's team. Previously only touched OpenAMP tangentially. Looking at OE builds in CI. Trying to download & build what Arnaud created.
- Arnaud: Sent email yesterday RPC services for OpenAMP. Do we want to start with this service for OpenAMP-OpenAMP demo, or do we need something else?
- Discuss next week:
- Board needs
- System Ready & U-Boot
- How we want to organize in repo & what is best for setting up Docker
- Does Bill and/or Kumar want to be a list admin (once the mailing list is working…)
- What to try to accomplish before next Friday's call
- Tanmay Shah
- Dan Milea
- Tomas Evensen
- Nathalie Chan King Choy
- Jeff Hancock
- Arnaud Pouliquen
- Arun Balaji Kannan
- Kumar Gala
- Tom Gall
- Paul Sokolovsky
- Etsam Anjum
- What infrastructure do we need to start with (mailing list – public/private?, git repo(s), etc) (Broaden scope of the Google Docs & wiki topics)
- Where do we want to start putting things?
- Nathalie created OpenAMP GitHub Wiki area & folder in OpenAMP Google Drive. Is anyone missing access to that Google Drive folder?
- Maybe a Google Doc per vendor for the flow steps for others to start trying out?
- Then can figure out what repositories to put stuff into
- When will we have schedule estimates?
- Etsam, Dan, Kumar, Bill: to come up with what they would like to work on & what their dependencies are & timeframe of availability
- Arun (Xilinx): 3 wks to have more solid idea
- Arnaud has prototyped a Yocto “OpenAMP ST distribution” including the meta-zephyr layer
- What is 1st bite of work for the coming week?
- Discuss: Linux master Cortex-A: which way of doing RPMsg: Is that kernel module getting loaded w/ demo app, or user space with VFIO/UIO?
- For boards: Nail down a bit more for future goal platform(s). How many Kria KV260 kits do we need?
- Landing page in the wiki: Populating the placeholders
- Instead of using a Google Doc for the initial draft of instructions for build flow, using Markdown in a repo would allow us to see the revision history.
- OpenAMP GitHub:
- Can start with separate manifests, then look at the differences & if possible to unify.
- Can start with 1 repo with ST folder, Xilinx folder, top level docs
- Call it openamp-system-reference
- Xilinx will start with non-decoupling flow. Will be good to then show the progression when we introduce decoupling flow.
- Which tag/SHA for Xilinx QEMU? v2021.1 tag
- OK to diverge initially so everyone gets to initial echo demo. Then can look at how to try to converge quickly.
- (DONE) Nathalie: File request to get openamp-system-reference mailing list created
- (DONE) Arnaud: Create GitHub repo openamp-system-reference
- (DONE) Arnaud: Send Nathalie email account for accessing Google for work
- (DONE) Nathalie: Use Tanmay's Linaro email to share the Google Drive folder with him
- (DONE) Etsam, Kumar, Bill: to come up with what they would like to work on & what their dependencies are & timeframe of availability
- (DONE) Bill: Creating Ubuntu 20.04 Docker image
- (DONE) Tanmay to find out if we can point to pre-builts to integrate into Docker repo
- (DONE) Tanmay: Look at what Xilinx has wrt RPMsg char & discuss w/ Wendy - Tanmay discussed w/ Ben & Sergei: Xilinx is using RPMSG char driver and Ben and Sergei will see how Arnaud’s upstream patches affects Xilinx use cases.
- (DONE) Bill: To be an "OpenAMP implementation" what are you supposed to support? - ask Bill to bring up in openamp-rp group (as part of which way of doing RPMsg discussion) - this is in brainstorm checklist
- What infrastructure do we need to start with (mailing list – public/private?, git repo(s), etc) (Broaden scope of the Google Docs & wiki topics)
- No one opposed to having a mailing list set up
- Nathalie: File request to get mailing list created
-
https://github.com/OpenAMP would be a good place to put things
- Could create specific branches
- Could use Yocto to pull things in
- Arnaud has initial example: Have 2 distributions (ST Linux, Zephyr) and they are not compatible. Need to build both in separate environments. Just cherry picked the manifests from different sources & put them together.
- What to call the mailing list? Suggestions:
- openamp-example
- openamp-demo
- openamp-e2e
- openamp-end2end
- system-demo(s)
- system-example
- openamp-system-demo(s)
- openamp-system-examples
- openamp-reference-system
- Chosen: openamp-system-reference
- Documenting build flow & instructions
- Kumar: Instead of using a Google Doc for the initial draft of instructions for build flow, using Markdown in a repo would allow us to see the revision history
- Manifests & documents in same or separate repos?
- Do we want 1 manifest per platform, or 1 manifest for all platforms?
- Arnaud: Having 1 could be difficult
- Kumar: Can start with separate manifests, then look at the differences & if possible to unify.
- Can start with 1 repo with ST folder, Xilinx folder, top level docs
- Arnaud: Create GitHub repo openamp-system-reference
- Docker container to build, with package dependencies. Useful for CI & for example.
- Arnaud: Send Nathalie email account for accessing Google for work
- Nathalie: Use Tanmay's Linaro email to share the Google Drive folder with him
- Where do we want to start putting things?
- Nathalie created OpenAMP GitHub Wiki area & folder in OpenAMP Google Drive. Is anyone missing access to that Google Drive folder?
- Maybe a Google Doc per vendor for the flow steps for others to start trying out?
- Then can figure out what repositories to put stuff into
- When will we have schedule estimates?
- Etsam, Dan, Kumar, Bill: to come up with what they would like to work on & what their dependencies are & timeframe of availability
- Kumar: Creating Ubuntu 20.04 Docker image so we have common environment for building. OOO next week. Target end of Aug/1st week Sept. Will be helpful to see what Arnaud has for ST platform.
- Arun (Xilinx): 3 wks to have more solid idea
- Will start with non-decoupling flow & later switch over to System DT flow
- Decoupling flow: When we introduce System DT & Lopper
- Non-Decoupling flow: Old one where you have to hand-edit DTs
- Tomas: Great to see non-decoupling flow, then the progression when we introduce decoupling flow
- Arnaud has prototyped a Yocto “OpenAMP ST distribution” including the meta-zephyr layer
- This covers ST's 1st step
- Will help Kumar with integrating in Docker
- What is 1st bite of work for the coming week?
- Xilinx:
- Discuss what board to use.
- Work on QEMU as first target: How to build RPU application with Yocto & without internal tools: Need to figure out the dependencies.
- Which tag/SHA for Xilinx QEMU? v2021.1 tag
- Should we take pre-builts for underlying machine & boot artifacts?
- Linux, OpenAMP app on kernel, baremetal BSP built from source
- Tanmay to find out if we can point Kumar to pre-builts to integrate into Docker repo
- Xilinx:
- Discuss: Linux master Cortex-A: which way of doing RPMsg: Is that kernel module getting loaded w/ demo app, or user space with VFIO/UIO?
- 2 ways of doing RPMsg from Linux
- Traditional: trap down into kernel & let kernel do all the work
- Virtio in user space: Map the memories from user space. Xilinx uses this.
- Arnaud: today, in kernel, there is no generic driver that allows Linux app to discuss w/ remote processor. In ST distribution, we have RPMsg-tty to send request & receive data from co-processor. This is integrated in ST prototype. Another option is to use RPMsg interface based on char device in Linux, which Arnaud is working on. Today, waiting on Bjorn's decision to integrate patches on mailing list.
- Tanmay: Can we have a way that works for all platforms independent of kernel, with OpenAMP in user space? e.g. if driver under development or still doesn't support
- Arnaud: No common solution in kernel or open amp libraries for communication b/c no driver providing standard interface for Linux
- Dan: Libmetal uses UIO, exporting everything to user space.
- Arnaud: Means you don't use Linux kernel RPMsg framework. Think we want to demo both. Would need simple services that can discuss w/ another OpenAMP on another processor or Linux driver. Matter of service name.
- Tomas: If you use tty or char interfaces from user space, it's a different kind of interface. OpenAMP is about standardizing interfaces. In kernel have 1 interface & in user space have hodge podge. In OpenAMP, want user space b/c where the applications are. Application shouldn't care if going through tty, char, userspace, libmetal: Should all have same interface.
- Arnaud: For services, should have same service in Linux kernel for user interface. Then application should directly use OpenAMP library in user space.
- Tomas: Maybe we can ask Bill to bring this topic up in openamp-rp group. Helpful to have example to see the differences.
- Arnaud: Have hello echo example: Service in OpenAMP to send loop of hello to remote processor. Same service implemented in Linux RPMsg sample.
- Arnaud: In OpenAMP, there is a contribution that started (not mature) to support RPC. New services. For OpenAMP-OpenAMP to allow co-processor to have services w/ ID & other side call.
- Arun: For Xilinx, userspace is straightforward to start with. Kernel driver is not merged upstream yet.
- Tanmay: Agree.
- Kumar: Sounds like we have 2.5 options. OK to diverge initially so everyone gets to initial echo demo. Then can look at how to try to converge quickly.
- Kumar: A few interesting things
- Configuration: If you have kernel support enabled & trying to do UIO solution, how does that look? If kernel implemented, do I need to disable that side to do UIO?
- Would like to see some type of kernel demo b/c interesting to show the different implementations working together
- Arnaud: Could implement simple service RPMsg-raw to allow communication between 2 processors, which would match with RPMsg-char Linux driver. Tty is more console, but similar. Advantage of tty is can have 2 on same link. With char, can only open 1 time, so only 1 file handle to manage your interface.
- Arnaud: Wendy had proposed something on RPMsg char some years ago.
- Tomas: User space does regular read & write to that fd handle?
- Tanmay: Look at what Xilinx has wrt RPMsg char & discuss w/ Wendy
- Tomas: When to use kernel driver from user space? Would like to make it similar for stuff to build on top.
- Tanmay: If don't have APU & want to communicate between RPU or 2 microcontrollers, UIO is way to go. Think should have both: APU-RPU w/ kernel side, 2 microcontrollers UIO way.
- Tomas: When to use trapping into OS? If multiple ways to trap, should we all implement the same way.
- Arnaud: To add in scope MCU-MCU communication. Should be similar to Linux user to co-processor.
- Tomas: Another way to look is that it's similar to user space. There are use cases for both. For MCU-MCU, it's sources we have in OpenAMP repo. To be an "OpenAMP implementation" what are you supposed to support? - ask Bill to bring up in openamp-rp group (as part of which way of doing RPMsg discussion)
- Kumar: This example will help us have a common platform. Then we can document when to pick which.
- 2 ways of doing RPMsg from Linux
- Landing page in the wiki: Populating the placeholders: Feel free to edit.
- Next week agenda items:
- Kumar, Tom OOO. Bill & Stefano will be back.
- Remember to record the call!
- Infrastructure updates (GitHub, list, docs)
- Progress updates
- Etsam, Dan, Kumar, Bill: to come up with what they would like to work on & what their dependencies are & timeframe of availability
- For boards: Nail down a bit more for future goal platform(s). How many Kria KV260 kits do we need?
- Bill
- Kumar
- Tomas
- Dan
- Arnaud
- Jeff
- Paul Sokolovsky
- Tanmay
- Tom
- Etsam
- Nathalie
- How do the OpenAMP & LITE efforts in this area relate? What falls under which project?
- nominate specific boards for this demo
- How to break up into phases? What's MVP? What is scope of each subsequent phase?
- How to project manage?
- Figure this out later: Should we try to plan a virtual sprint?
- Frequency to reconvene?
- (DONE) Tanmay & Tomas to come back to say when can have this initial milestone
- (DONE) Arnaud to come back to say when can have this initial milestone
- (DONE) Etsam, Dan, Kumar, Bill: to come up with what they would like to work on & what their dependencies are & timeframe of availability
- (DONE) Nathalie: Send invitation for weekly in this timeslot
- (DONE) Nathalie: Create area in OpenAMP Wiki to put documents, notes
- (DONE) Nathalie get access for Paul, Tanmay, Dan, anyone else access to OpenAMP Google Drive
- (DONE) For boards: Nail down a bit more for future goal platform(s). How many Kria KV260 kits do we need?
- How do the OpenAMP & LITE efforts in this area relate? What falls under which project?
- Tomas' write up (brain dump) is more OpenAMP focused
- Bottom-up: Taking all the OpenAMP pieces & making sure they work together
- LITE: More detailed: How to do all this from Yocto? How to tie it together
- FF had suggested to add
- Bill: Don't see a big conflict. Each company is deciding what engineering resources they want to put in. LITE will likewise decide how much resources to put in & work on.
- Kumar: Once you start going into OE & Yocto builds, will require more significant CI resources than what we need for libmetal & OpenAMP CI. If we're trying to do CI, how will that happen & where will it happen to meet the demands? This is where it makes sense to figure out what is part of Community Project & what is part of LITE.
- Tomas: Would like to see more CI in the open across vendors, but will have to be similar flows.
- Bill: Similarity is good & necessary in short term. But, don't want to send the message that you must use OE to use OpenAMP. Upstreaming helps. Once don't need so many patches, can document how to build custom kernel & insert into Debian-based system. Long-term goal.
- Kumar: Who's not a Linaro LITE member who is interested?
- Siemens Embedded is not a LITE member & wants to participate in this effort
- Wind River is not a LITE member & wants
- Want to switch to Zephyr as non-guest-guest. Looking into using ZCU102.
- Building infra for hypervisorless daemon on Linux & talk to RPU w/ mailbox driver to send notifications from 1 side to the other. That's working now & still internal. Goal to open source.
- Virtio not 100% aligned to Yocto effort, but probably will intersect in future.
- Can we componentize the instructions, so ppl can know what they can skip if they have pieces?
- e.g. Build Linux kernel from Yocto, or not
- Bill: Good to have long-term, but not required in early days
- Tomas' write up (brain dump) is more OpenAMP focused
- Demo LVC21F Friday is 4 weeks from today & many folks on vacation: Is anything realistic to demo there?
- What do we have today that could be glued together with a README?
- Tanmay: We have echo test sample application that sends payload to RPU & validate that it came back. Can modify to send characters in lower case & RPU convert to upper case & send data back to APU. APU can print the data.
- Tomas: Can we show someone how to get to that echo test in a reproducible way, e.g. with Yocto?
- Tanmay: Have to consider how to use System DT to configure both of the systems
- Tomas: What board, or QEMU? Ultra96?
- Nathalie: Ultra96 V1 & V2. Heard from a Xilinx Linux dev that V1 has better SW support, V2 handed off to partner and their support is lagging.
- Tomas: How close are we to using upstream QEMU, or DT? Ideally would want to use Zephyr.
- Bill: As 1st milestone, baremetal would be OK. Want someone to be able to reproduce without a big SDK download.
- Tomas: So the goal would be to document how, demo that that document - how someone goes to Yocto for Linux, configure it, and your bare metal, and your open APP and what to do to set up the device trees. And then, how you compile all that through Yocto and then how we run that on QEMU.
- Bill: it's a necessary output just to get this group going, regardless of if we demo
- Arnaud: ST close to having everything. Sample demo on Zephyr similar to Linux echo sample. Missing Yocto part & System DT. Could run on Avenger96. Independent of ST SDK download. Can use mainstream of Linux & Zephyr for Avenger96 to support this board and should work. Would need to write some documentation. Not a priority right now to put all these into Yocto.
- Tomas: Is it OK if we get 1 example in mainline & another in Yocto, or should be consistent?
- Kumar: Would like to see consistent. How do you deliver?
- Arnaud: We deliver Yocto-based solution w/ baremetal for co-processor.
- Kumar: Yocto should be the build packaging infrastructure we should use for the example. Full open source solution set & can replace RTOS w/ baremetal.
- Kumar: OK for echo test demo to be baremetal & not have System DT.
- Kumar: Value: Can show progression from the manual steps to do everything & show what steps are common between all the vendors. Then we show what manual steps go away with System DT. So, starting w/ simple baseline is OK.
- Tomas: Like the idea
- Arnaud: Does Linaro have Yocto for Avenger96? How to compile Zephyr & load binary for system would be enough.
- Bill: https://github.com/dh-electronics/meta-av96
- Kumar: Baseline: Get everyone's platform to a consistent state. Purely open source driven (no vendor SDK, HAL)
- Tanmay: Purely open source SW stack for all the components: Which remoteproc driver merged into upstream Linux? Xilinx remoteproc driver is not available yet.
- Kumar: Doesn't have to be upstream, just has to be available. Can host on OpenAMP repo & then pull in some Xilinx patches, then can update layers when the patches go away. Just don't want to have to get PetaLinux & ST SDK tools & NXP tool etc.
- Kumar: If there's something we can demo in 4 weeks, great. Outcome of this meeting should be what our 1st milestone content is.
- Tomas: Generating boot image might be a little vendor specific.
- Arnaud:
- ST can load firmware in U-Boot & attach when Linux is up.
- Future: We can sign & use OP-TEE. It's not upstream yet.
- Etsam: Would like to see Zephyr on both sides enabled for demo b/c simpler to set up than Linux. Easier to get Zephyr from that repo, no heavyweight build-specific components are needed. Will also highlight usage of OpenAMP in master mode. Usually we just show the remote configuration. Could 1st implement in master mode & then follow-up with Linux master & OpenAMP remote.
- Tomas: It's a good use case. When we have OpenAMP in master mode, want to have RPU is in command w/ RTOS starting Linux. Usually run Linux on APU. Not aware of port of Zephyr to our A53 or A72. Think important use case. Pragmatically, to take incremental approach, should start w/ Linux + baremetal. However, don't have to serialize the incremental work. Can do app services, hypervisor, OP-TEE, etc. in parallel. But, 1st need to get the whole flow working.
- Bill: Agree, have to walk before we run. Interesting combo would be Linux on APU & R5 in split mode. Linux talk to 1 of the R5 and the R5s talk to the other. Could even show one R5 start the other if wanted to show remoteproc. Doesn't have to be 1st example.
- Tomas: Value of this collaboration is that we can work on things together that is hard to do by ourselves & can get pieces owned by different ppl tweaked to make it work.
-
Initial milestone target:
- Xilinx and ST to document Yocto flow of getting Linux & baremetal & OpenAMP and build it (won't worry about System DT yet). Xilinx will do on QEMU, ST on maybe Avenger96. Echo test. Boot Linux & use remoteproc to start baremetal.
- nominate specific boards for this demo
- Xilinx: Initially QEMU
- ST: Initially Avenger96? (Update: Bill found Avenger96 not orderable. STM32MP157C-DK2 or STM32MP157F-DK2)
- Bill: Kria KV260 looks interesting, long lead time. Should we order now?
- Tomas: Good idea. How many do we need? Maybe we can use OpenAMP budget to enable the non-Xilinx devs who will need to be hands-on
- How to break up into phases? What's MVP? What is scope of each subsequent phase?
- Xilinx to document Yocto flow of getting Linux & baremetal & OpenAMP and build it (won't worry about System DT yet). On QEMU. Echo test. Boot Linux & use remoteproc to start baremetal.
- Similar for ST
- How to project manage?
- Bill: Don't need PM initially if we are meeting often enough
- Should we try to plan a virtual sprint?
- Defer to later.
- Frequency to reconvene?
- Kumar, Bill: Weekly initially
- This timeslot? OK for Tomas, Tanmay, Arnaud. Bill, Kumar can do for a month or 2.
- Let's record the meetings b/c ppl on vacation.