-
Notifications
You must be signed in to change notification settings - Fork 15
OpenAMP System Reference Meeting Notes 2023
Nathalie Chan King Choy edited this page Dec 13, 2023
·
24 revisions
- Arnaud, Bill, Tomas, Tanmay, Nathalie
- Embedded Open Source Summit CFP closes 2nd week of Jan
- Anything interesting to discuss from Linux Plumbers?
- Promoting Nishanth’s presentation recording (LinkedIn, blog)
- Updating the elevator pitch deck
- Task Tracking sheet
- Individual updates
- AMP Virtio would be a good presentation for Embedded Open Source Summit (April in Seattle)
- Bill will draft AMP Virtio proposal & send for review in 1st week of Jan
- Bill will submit AMP Virtio proposal https://events.linuxfoundation.org/embedded-open-source-summit/program/cfp/#eoss-2024-events-and-suggested-topics
- Nathalie: Create the website blog post & OpenAMP LinkedIn post for Nishanth's presentation at LPC using time-stamped link
- Nathalie: Review AMP BOF video on Linaro Connect Resources page. Ask Linaro Events if they can post to YouTube, or if we could post to OpenAMP channel.
- Tanmay to test if kernel changes are backward compatible (old FW, FW that can negotiate this feature + new kernel w/ this feature, new FW+new kernel).
- Tanmay to post to list about RPMsg config to optimize size of buffer in January
- Pitch deck:
- Removed bullets
- The rest of Arnaud's changes were in later slides
- CFP
- Bill will submit AMP Virtio proposal https://events.linuxfoundation.org/embedded-open-source-summit/program/cfp/#eoss-2024-events-and-suggested-topics
- Will it be mature enough to show? Want to have code in decent shape. Have Virtio in Zephyr using QEMU.
- What problem? Our solution
- Likely will slant towards Zephyr as companion OS to Linux & also mention Xen
- More & more common use case
- Virtio & Xen devs may be in Linux track
- Bill will aim to have something to us to review in 1st week of Jan
- Bill will submit AMP Virtio proposal https://events.linuxfoundation.org/embedded-open-source-summit/program/cfp/#eoss-2024-events-and-suggested-topics
- Anything relevant to System Reference from Linux Plumbers?
- Nishanth presented
- Will want to use the link w/ the timestamp
- Promoting on LinkedIn for wider reach
- Putting in blog as record of what we've done
- Nishanth replied w/ the abstract, so assuming he's OK with us promoting it
- PCI & IOMMU track
- PCI endpoint update
- Number of ppl trying to do virtio over PCI: 3 different approaches
- Elisa project update on combining Linux, Xen & Zephyr
- They are trying to create a baseline
- Using multi-config for Xilinx platform discussed between Tanmay & Bruce
- Currently FW not built w/ multi-config
- Need to figure out w/ Mark
- Attached/detached feature: How to add in kernel
- Tanmay will present approaches at RP call & which chosen
- To discuss w/ Matthieu (Bill will miss call & has already given feedback)
- Nishanth presented
- Other things to promote?
- OpenAMP BOF from spring is not in the OpenAMP playlist b/c it wasn't posted to YouTube
- Can ask Linaro Events/Marketing if they can post to YouTube or if we can post it?
- Task tracking
- Arnaud: Discussed w/ Mathieu by email, but he has some other priorities right now
- Bill:
- Felipe looking at dual QEMU
- Issues w/ Xilinx QEMU last release
- Either need those issues fixed or look at other way
- Tanmay filed an internal ticket & someone is looking at it, but not sure if it will be fixed before end of 2023. Tanmay will follow up to find out fix ETA.
- Infrastructure items were pending release being done
- Bill will do GitHub team change today in case need to react
- Tanmay
- Discussing upstreaming TCM bindings w/ Mathieu
- RPMsg config to optimize size of buffer:
- Arm working on it. Need to discuss w/ Mathieu
- Existing patches from Xiaomi works on existing platforms supporting remoteproc & openamp library: Should we also merge the kernel changes, or wait for more proper solution?
- Bill: OK to have stepping stone, but changes backward compatible? Thought there was something in the patch that would make it not work, but think it was fixable
- Tanmay to test if kernel changes are backward compatible (old FW, FW that can negotiate this feature + new kernel w/ this feature, new FW+new kernel)
- Tanmay to post to list about it in Jan
- Tammy, Dan, Arnaud, Nathalie
- Any release related topics?
- Update OpenAMP elevator pitch deck
- Task Tracking sheet
- Very short call today!
- None
- Release:
- Bill would have the status about the CI, but can refer to the release status doc
- Issue w/ starting ST board w/ current ST release
- Pitch deck update
- Should save for when we have Bill & Tomas in the call
- Task tracking
- Dan:
- Align Zephyr task done
- For all the tasks, the alignment is done for latest version of Zephyr staging & OpenAMP, there is still some work to be done to get into Main branch
- Arnaud: Option that needs deeper discussion in the virtio meeting next week: 1st step could be to put API as non-stable API
- Dan: Think it's a good way forward
- Arnaud: Can I remove the old virtio-exp branch from openamp?
- Dan: Yes, have back-up
- Dan:
- Bill, Bruce, Tanmay, Nathalie, Tammy
- Does anyone else want to join our small working group to propose candidate conferences for OpenAMP to consider sponsoring?
- Any OpenAMP release-related topics?
- OpenAMP Board has approved the expenditures for these items. Any follow-on topics to discuss w/ this group?
- GitHub Teams for 10-13 team members
- ReadTheDocs org subscription
- Docker Pro for 5 core team
- ~$100/mo GitHub Actions, AWS EC2 server & builders, AWS S3 storage
- Update OpenAMP elevator pitch deck
- Task Tracking sheet
- Conference sponsorship working group to start meeting Nov 30, every 2 weeks
- GitHub Team changes, and others approved by Board will happen after the 2023.10 release
- Tanmay redo his DT w/o duplication between lockstep & split
- Bill & Tanmay: Get ZCU102 working w/ Zephyr (UART node level disabled & leave pin mux in?)
- Let's review the stale tickets once a quarter & figure out what to do with them
- Conference sponsorship working group
- We'll start with 1pm PT Thur starting Nov 30, every 2 weeks (cancel during winter holidays)
- Bill is waiting until after the release to make changes to stuff like GitHub Team
- Does anyone else want to join our small working group to propose candidate conferences for OpenAMP to consider sponsoring?
- Smaller team for tradeshow is OK
- Bill: Arm wants to get more involved, but not sure how
- They want to have a meeting specifically about System DT
- Bruce, Stefano, Grant, Bill M, Arm folks
- Let's check calendars after this call
- NXP platform
- Zephyr + Linux
- They want to have a meeting specifically about System DT
- Release
- Next need to do openamp-system-reference repo
- Need to get DT stabilized for that
- Would prefer to use upstream kernel sources & add overlays
- Tanmay redo his DT w/o duplication between lockstep & split
- Would like to tag it on Friday
- Tanmay didn't have to modify on Zephyr side for ZCU102. Not sure if UART pins for KV260 are being used for something else on ZCU102.
- QEMU
- ZCU102: both UARTs get pinned out, so R5 can use
- Bill: Having pin mux taken out is a little strange b/c may lose R5 output
- Bill & Tanmay: Get ZCU102 working w/ Zephyr (UART node level disabled & leave pin mux in?)
- Arnaud's script had auto-closed some tickets (the default was if no one touches 7 days after marked stale, it would close)
- Arnaud fixed the script to not to automatically close & only mark stale after 45 days
- Bill re-opened some that he noticed got closed. Arnaud checked the rest.
- Only applied to lib-metal & openamp
- Next need to do openamp-system-reference repo
- Let's review the stale tickets once a quarter & figure out what to do with them
- Doc generation
- If we make a mod in the repo to the docs, does it get generated on the fly? How is it linked to release?
- If you make a change, it generates a new one in the PR for review, then it will go live on main on latest branch
- Bill tags the docs at the point of release, so ReadTheDocs will show that as the release version option, but it will default to latest
- The PDF is also auto-generated by RTD
- Individual updates (see task tracking sheet)
- Tanmay highest priority is on making Zephyr demo working on ZCU102 & KV260 for the system-reference release
- Arnaud, Felipe, Tammy, Bill, Tomas, Tanmay, Nathalie, Dan, Bruce
- Bill/Arnaud GitHub repo & manifest proposal
- Submodules & Lopper/System DT
- Docs
- Felipe: Virtio MMIO drivers in Virtio native mode
- Arnaud: Test plan & release
- Task Tracking sheet
- We'll only tackle the glaring broken links in docs for 23.10 release
- OK to create the new repository openamp-zephyr-modules in OpenAMP GitHub w/ README & populate rest w/ PRs. Will test it with this release.
- For System Reference testing for 23.10 release, use v3.5 Zephyr release (as modified by openamp-system-reference manifest)
- (DONE) Nathalie to give Arnaud access to OpenAMP Google Drive at his ST address
- Bill to create a PR & submit to Lopper for Readthedocs integration.
- Bruce to install Readthedocs, make the RTD project & set up the hooks, with guidance from Bill
- Felipe: When Felipe has draft code, should submit PRs & add Dan as reviewer
- Arnaud to move the 23.10 test plan sheet from his Google Drive to OpenAMP Google Drive after the release is completed (since others are already editing in the current location)
- Tanmay to discuss w/ Ed who will own the usual release tests for baremetal & FreeRTOS ZynqMP in the RP call
- Tanmay to check w/ Ed if we have a HW test for 1 R5 loading the other R5. If we don't, then we can look into a QEMU platform to test it.
- (DONE) Nathalie to update the burn-up chart tab to reflect the test plan structure
- Bill & Arnaud have been prototyping changing manifest in OpenAMP System Reference
- Adding new repo at OpenAMP level for Zephyr modules w/ glue code for OpenAMP module + resources it needs for libmetal & openamp
- Will get cloned alongside openamp & libmetal libs
- Eclipses the definitions that come from Zephyr -> so you won't get openamp & libmetal from Zephyr any more
- Tested w/ ST & KV260
- Want to create virtio-exp branch in OpenAMP System Reference that will clone all the virtio branches for everything we need. May include some WIP samples. Then we will need to remove the Zephyr code (won't need it).
- Dan: Sounds good.
- Will need to ensure we are aligned w/ Zephyr updates of Zephyr openamp modules. Not difficult.
- They plan to change configuration around cache management
- With separate repo, we can put tags on a consistent set, so will be easy to version along w/ everything else
- Could also have separate branch to test Zephyr configurations
- Should also work for stock apps & don’t' have to be doing OpenAMP System Reference
- Arnaud plans to test some more configurations
- OK to create the new repository for OpenAMP Zephyr Modules in OpenAMP GitHub w/ README & populate rest w/ PRs. Will test it with this release.
- Adding new repo at OpenAMP level for Zephyr modules w/ glue code for OpenAMP module + resources it needs for libmetal & openamp
- Submodules for OpenAMP docs (library, libmetal, system reference) have support for regenerating the documents for every PR in those projects, so you can see how that PR would affect the docs. Do we want that for DT spec & Lopper?
- If so, Bill would need help to do that b/c it doesn't reside in OpenAMP GitHub
- Bruce: Would be OK to do that & can help
- Bill to create a PR & submit to Lopper for Readthedocs integration.
- Bruce to install Readthedocs, make the RTD project & set up the hooks, with guidance from Bill
- Docs
- April-Oct items have been addressed
- The broken links issue is not yet fixed in this release. Bill will fix the glaring ones.
- Can we close https://github.com/OpenAMP/openamp-docs/issues/5 ? Yes.
- Bill closed it & anything new that comes up can be filed as a new issue.
- Felipe: Virtio MMIO drivers in Virtio native mode
- In upstream, we have common infrastructure to develop virtio-mmio from driver side
- Dan implemented on virtio-exp branch for rng, serial & net drivers
- Working on porting to upstream, takes some work to make compatible. Upstream has some different names.
- Testing from simple to complex cases
- Testing on RNG sample project on Zephyr
- Next: Serial & networking device
- Will Felipe's work going to clash w/ Dan's?
- Dan focused on create & delete virtqueue b/c those creation routines are in Zephyr
- Dan & Felipe can sync up later
- Felipe: When Felipe has draft code, should submit PRs & add Dan as reviewer
- Arnaud: Test plan & release
- Code is now frozen for release
- There are still several PRs in queue, mainly from Xiaomi, but they landed too late for this release
- Time to start non-regression tests. Would like to have something to track the tests that we run for the release. Created a test plan tracking sheet, which we can also use as basis for testing future releases.
- Move it to OpenAMP Google Drive after the release is done
- Started to list some tests. You can add tests & categories.
- Each test owner can mark off what we've done & also can mark ones that we won't test in this release as "Won't Do"
- For OpenAMP System Reference tests, should we use V3.5 Zephyr when it is released on Friday, or stick to RC3? Let's go with the V3.5 Zephyr release (as modified by openamp-system-reference manifest). Will be pointing to 23.10 main for libmetal & openamp w/ upstream Zephyr, until we tag it & then will get 23.10 tags after release.
- Nathalie to update the burn-up chart tab to reflect the test plan structure
- Would like to make sure Tanmay doesn't duplicate Ed's testing
- We think Ed doesn't have KV260, probably has ZCU102
- Ben & Tanmay have also added a lot of changes, so harder for Ed to stay current for testing
- Tanmay to discuss w/ Ed who will own the usual release tests for baremetal & FreeRTOS ZynqMP in the RP call
- Remoteproc tests for openamp library
- Arnaud doesn't have a platform to test OpenAMP remoteproc
- Tanmay to check w/ Ed if we have a HW test for 1 R5 loading the other R5. If we don't, then we can look into a QEMU platform to test it.
- Task tracking status updated in Task Tracking sheet
- Bill, Tammy, Arnaud, Dan, Hari, Tanmay, Nathalie, Bruce, Tomas
- OpenAMP GitHub
- Linux DT -> Lopper -> System DT
- HPP update & outlook https://linaro.atlassian.net/wiki/spaces/HPP/pages/29003218948/2023-09+Update
- Anything to discuss related to the upcoming OpenAMP release? (Feature Freeze 10/15)
- Demo refresh (not on main)
- Q2/Q3 task tracking status
- Individual updates
- OpenAMP GitHub
- Tag virtio-exp branch, then re-base on top of main to get updated openamp library. Dan to own this branch.
- Have another branch with ST+Linaro work. ST+Linaro to own that branch.
- Linux DT -> Lopper -> System DT
- This could help System DT to become more pervasive
- Bruce interested to work on it
- Timeline TBD and will need a real test usecase (TI? ST? NXP?)
- Bill to ping Nishanth about if he'd be interested in the Zephyr work being the real test use case for Linux DT -> Lopper -> System DT
- Bruce to share simplified YAML documentation
- Arnaud to list OpenAMP GitHub members & propose new list of who should have more/less privileges
- Bill: Doing some QEMU work. Would like to do QEMU staging repo in OpenAMP. Want to start clean, not on virtio-exp branch. Virtio-exp2 branch, or tab & rebase. Does Arnaud have a preference?
- Arnaud: No preference. Maybe more impact to Dan's work.
- Dan: Easy to cherry pick commits & move on top of existing OpenAMP main branch. Checked that it works. Keep existing virtio-exp branch to have snapshot of how things work & easily reproduce what we had. Either rename branch to staging or some new branch based on HEAD of OpenAMP+bunch of commits (still experimental, still working on getting everything in main)
- Arnaud: Can name existing branch "-old" and create new one once we release
- Dan: Can do merge if have push rights to new virtio-exp
- Bill: Not convinced everything in virtio-exp should go into new branch
- Dan: Agree. Some stuff needed to show device drivers, otherwise you end up w/ current WIP state w/ just framework that's in main.
- Arnaud: Should be able to merge work from intern on this branch.
- Bill: Felipe is trying to take his & Nicholas' work & merge together. Also trying to refactor more work into OpenAMP library instead of always in Zephyr. He has serial, i2c & __ as his targets. Not tackling network yet. Maybe should discuss next week.
- Dan: Can't make next week's call
- Bill: Propose to keep branch name same. Put tag on what old one was & re-base on top of main. That way it is everything Dan had, but w/ updated openamp library. Dan can be owner of this branch.
- Dan: OK
- Bill: Create new branch w/ ST+Linaro stuff. We'll be owner of that.
- Arnaud, Dan: OK
- Bill: Linux DT -> Lopper -> System DT
- Most ppl view kernel.org as the canonical DT
- System DT & Lopper assume System DT living somewhere else is the canonical DT & you generate the Linux DT. Could we flip that? Maybe needs some extra info, like for R5.
- Bruce: Agree it's a good use case & would solve the problem, with bits added.
- Bill: Wonder if upstream kernel.org would accept the System DT fragments that turn it into a System DT & Lopper does the transformation.
- Bruce: May have to do some work, but think it's not that far removed from DTSIs, which are already accepted
- Tomas: If we have a separate fragment w/ the R5 or other cluster stuff or other buses/devices that are no in Linux, we'd put in separate file & Lopper would merge & transform? Sounds straightforward…
- Bruce: Depends if you go route of simplified YAML, maybe there is info that could be inferred & do more transformation. Bit more than what you could do with DTSI & preprocessor & sed/awk.
- Bill: Sounds OK. Solution would look ugly w/ preprocessor if it was possible.
- Tomas: Agree, Lopper would give us cleaner & easier to read System DT.
- Bruce: Rest of workflows could generate other bits (e.g. baremetal)
- Tomas: If we want to do that, it would be good to have a test use case from upstream. Have some stuff upstream in Linux?
- Bruce: We do have Xilinx stuff upstream, but it's simplified for Michal's defconfigs. Think we generate System DT from design files.
- Bill: In OpenAMP, the candidates would be ST, TI & NXP.
- Tomas: They would have to add their M cores, or other info.
- Bill: Nishanth interested in System DT wrt Zephyr
- Hari: I'm not involved in those discussions. Still experimental & not productized.
- Bill: Not thinking product level demo, just need someone interested in prototyping something. Maybe this could fit into what they're doing w/ prototyping Zephyr.
- Bill to ping Nishanth about if he'd be interested in the Zephyr work being the real test use case for Linux DT -> Lopper -> System DT
- Tomas: We want System DT to become pervasive, so want to do this. TBD how timing will work out. Will need real test use case.
- Bill: Need to update on simplified YAML
- Bruce: Close to finished on documentation on simplified YAML
- Bruce to share simplified YAML documentation
- Bill: HPP update
- https://linaro.atlassian.net/wiki/spaces/HPP/pages/29003218948/2023-09+Update
- Finding that other ppl are trying to do similar things to what we're doing, so likely to have bigger impact than AMP
- Normal, secure space
- Google project
- Safety Certified Xen might need some of this stuff
- Cross-RTOS library for virtio
- We would do the transport layers, but not stuff like sound
- RPMsg & remoteproc
- Want to do more demo platforms
- Linaro working on 2 QEMUs talking to each other through ivshmem
- Could do X86 on 1 side, but not doing at the moment
- A53 (Linux or Zephyr - testing Zephyr)
- M3 (Zephyr, future: FreeRTOS or baremetal to test cross-RTOS)
- Future: ArmV8 Xen w/ multiple OS under Xen
- Got good prototype demo on ST side w/ M4 & A7 over I2C
- Dual QEMU Demo works w/ upstream QEMU & upstream OpenAMP
- Virtio serial prototype working in that configuration
- Prototype of A53 as device & enabled UIO to provide access to shared memory, interrupt & notification method. Need to build QEMU device model.
- Native virtio will be tested with QEMU as device: A53 Zephyr w/ QEMU providing the virtio devices. Want to refresh the Dec demo.
- For end of 2023 target
- "Upstream" = virtio-exp2 branch
- Native virtio (Dan's Dec demo): upstream OpenAMP, TBD if upstream Zephyr
- Arnaud: No work to enable virtio on top of existing remoteproc virtio transport?
- Bill: Not sure if that will make it into this year, unless Arnaud can focus on it. Arnaud's M4 Zephyr + A7 Linux branches & kernel staging on a branch is working towards that.
- Arnaud: OK, no strong requirement & not much time. Today the STM1 demo is based on virtio-mmio. Know can play w/ remoteproc virtio in parallel.
- Bill: ST preference to use virtio-mmio instead of remoteproc virtio?
- Arnaud: Virtio-mmio transport layer is in spec of __ so we have the old implementation for RPMsg. For MP1, we have limited memory. For MP2 platform, will have more memory & becomes interesting to also use virtio-mmio which allows description of devices in DT. Updating last yr's demo would require a lot of work on remoteproc.
- Bill: Think virtio-mmio will only be accepted for 1.x, so would need to run in non-legacy. Think we haven't done that yet.
- 2024 priorities
- Get our prototypes upstreamed to spec, kernel, QEMU, RustVMM, OpenAMP libs, Zephyr
- Virtio-FFA doesn't seem to have much to it yet. Need to figure out what we want to do & what they want to do. Can we unify what we both want to do to the spec.
- Sound is iffy b/c doesn't belong in library, but maybe external device & driver would want to use OpenAMP library to do. Sound would be easier than GPU
- X86+Arm on PCIe card. Raspberry Pi 5 uses PCIe internally to its south bridge chip & x1 PCIe connector. If we could get M2 hat. Some Xilinx FPGAs plug into M2 slot. If could be RC & EP, could do RPi5-RPi5
- Non-transparent bridges: 2 device with PCIe root complexes that connect over non-transparent bridge that can be endpoint to both sides so they can share some memory. Similar to ivshmem. This is production in Automotive.
- Arnaud: What about Linux part of virtio?
- Bill: The upstreaming bullet covers that
- Tanmay: We will work on refactoring demos & libraries as part of this?
- Bill: Would like to include that. Would like to see the demos on KV260 at end of year. Maybe Q1 of 2024.
- Tanmay: What about the existing apps that we are trying to get into OpenAMP System Reference
- Bill: That's counted as "tax" to maintain the upstream project, like updating the docs. Gustavo is helping us to make libmetal documentation improvements as he tries it out. Will refresh the Dec Docker demo containers for the October release.
- Backlog:
- Felipe interested in ROS + uROS, which might be a good fit for Xilinx KR260
- Q2/Q3 task tracking status
- Updates made in sheet
- Tammy: Have PR open for review in OpenAMP.
- Bill: Board topic
- Will suggest that we update the OpenAMP GitHub organization to "Team" level
- We have 11 team members today -> $500/year
- Wondering if we should downgrade some contributors who have not been active in several years
- Arnaud: have been discussing that w/ Ed. Can list the members & propose a new list. May want to add some ppl.
- Arnaud to list OpenAMP GitHub members & propose new list of who should have more/less privileges
- Nishanth, Tomas, Arnaud, Dan, Stefano, Tammy, Tanmay, Nathalie, Bruce
- System Device Tree:
- Are there things we can do in this group to make sure it gets into Yocto, works with our reference platforms, 1st class citizen, etc.
- AMD Xilinx HW can mutate for each customer, so what gets checked into kernel isn't that interesting. In other markets, where HW doesn't mutate, what is checked into kernel is important. If Lopper took what's in kernel & transform into SDT that other operating systems could use - flipping the inputs & outputs. Might increase interest in System DT if you didn't need 2 ways to do things.
- Discuss brainstorm list of Google Summer Of Code topics.
- If you have trouble accessing this link, then contact me directly and let me know your Google account email.
- Reminder to add your ideas to the brainstorm list before the call :)
- Q2/Q3 task tracking status
- Individual updates
- Would like the architectures, operating systems, etc. to standardize around DT
- Lopper tooling as infrastructure that can be beneficial to those using DT
- Tomas to bring up Lopper integration at future TSC & board calls (e.g. w/ U-Boot)
- How can we make System DT & Lopper more pervasive in other areas (e.g. Zephyr, RISC-V, U-Boot)
- Nishanth
- Submitted a talk on System DT to Linux Plumbers micro-conference on Internet of Things
- Challenges in DT sync
- Zephyr is using Lopper to an extent, U-Boot is not
- How bindings are handled for the different DT styles
- Validating the DT per the bindings
- More seamless in kernel in kernel
- Tomas: Want to see how we can use Lopper & System DT in more and more places
- Stefano defined system DT
- Bruce writes Lopper (but he has not joined yet)
- How can we make it more applicable to more things?
- Have started to use it in Xen Hypervisor
- AMD Xilinx getting it into product in next release w/ CPU clusters
- Nishanth:
- Seeing similar interest w/ RISC-V vendors
- DT description for system config auto-generation
- Starting to become a challenge: What language are we going to use to talk
- Tomas: Starting to talk to RISE (SW ecosystem around RISC-V). They have bene looking at server & trying to convince them they should look more at Embedded. Want to have same tooling & standards. Would be good to know who in RISC-V community would be interested.
- Nishanth: Think all of them are!
- Nishanth: Under HIP umbrella?
- Tomas: Stefano is leading System DT working group under OpenAMP. But, in OSS everything is meshing together. DT ppl, Linaro interested. Much work behind the scenes, but haven't had a meeting in a while. Maybe we should have a RISC-V focused System DT call.
- Stefano:
- Would be good to hear RISC-V requirements
- Jan-June were working w/ Zephyr community to help Zephyr adopt it. They have issue w/ some SoCs having same address for different devices depending on secure/non-secure. Made some changes in spec to accommodate.
- OpenAMP topics are more settled
- Bruce:
- Some use cases have gone quiet b/c it's working
- Zephyr - spec
- Would like to consolidate competing ideas about 1 source of truth, then have spec back it up, then have our tools do it the easiest
- We use in Yocto to configure builds & configure guest domains automatically when building Xen systems in meta-virtualization
- Would like to extend it further
- Tomas: Anything around U-Boot?
- Nishanth:
- We have R5 core that starts booting in K3 architecture. Linux has different view of SoC.
- We handled by creating another DTS file where we override the properties. Feels like an artificial way to fix it. Saw similar in Zephyr for GPIO nexus.
- Irritating that each OS has their style
- Tomas: This is what Lopper is good at. Have you tried it?
- Nishanth: played w/ it a little, but not looked into the mechanics
- Tomas:
- Lopper is a framework that can read bunch of things, write bunch of things & do transformations. Have richer formats than just DT (e.g. YAML). Can write "lop" w/ pattern matching (data driven).
- Bruce is adding more general python things (e.g. tree manipulation)
- Bruce:
- We're aware that certain things we like to do w/ System DT to generate OS-specific DT & firmware files
- You could use pre-processor includes & DT overlays to do similar things to what we do when we create the OS DT or processor-specific DT. But can lose track of things that way.
- Lopper can also produce overlays & make sure it matches overall system view. Could potentially simplify.
- More expressive to carry 1 tree & simple readable rules, which is why prefer YAML.
- Get checking & simple & complex operations. Looking for challenging situation to simplify w/ Lopper.
- e.g. Have assist to do bus tracking
- Tomas: Who else using system DT?
- Dan: We are not using System DT yet. Using DT everywhere. VxWorks aligning to official upstream format of DT b/c we had diverged & that effort is ongoing. Think System DT is the way to go for heterogeneous systems, so think we'll get there eventually.
- Tomas: Wind River & Siemens have hypervisors. How is Xen using System DT?
- Stefano:
- Have # of static VMs you have to define somehow & need to configure the system. Instead of hypervisors having to come up w/ their own format (especially b/c want tooling - UI, checking). System DT attemps to give you generic way to describe these using basic DT format. Similar/same to AMP case w/ different domains.
- We are using w/ Dom0-less (static config of Xen w/ domains created at boot time). Well aligned w/ system DT.
- Using on Arm. Getting into RISC-V and X86.
- We have quite a bit of tooling around the configuration (e.g. translation, UI)
- Tammy:
- Siemens uses System DT also for AMP & other things
- Not sure where we got format for remoteproc
- Use upstream vendor implementation
- Have we standardized on remoteproc node on OpenAMP?
- Stefano:
- Think we do have public examples. Need to double check if it's in the spec. There are some interesting extra properties that need to be described. Were discussing internally a few days ago.
- Tomas:
- W/ remoteproc & RPMsg. So hard to describe. Linux have to describe ring buffers. For RTOS have to use #defines. Was a pain, now can put in domain.yaml & put YAML anchors - define in 1 place, process it & use in multiple places. 1 true source gets rid of a lot of mistakes of things getting out of sync.
- Nishanth: Do you maintain your system DT in separate repo or common?
- Tomas:
- AMD Xilinx generates the DT b/c we have board & SoC & programmable fabric. There is an upstream DT, but it's not that useful. SoC snippets, board snippets, pins can be used in different ways so need to state how used.
- Bill had suggested that others don't have this HW configurability need & put more weight on Linux DT. Could you generate System DT from Linux DT?
- Nishanth: Was thinking similar
- Tomas:
- Sounds like it would be do-able. Want to make sure it's done in a way that would be usable to ppl.
- For many cases, the "standard" comes from Linux DT.
- Stefano:
- Complex topic. What was suggested is do-able & ppl do similar.
- Having DT live in Linux does pose some problems, but currently the most practical place
- Tomas:
- Linaro had an effort to improve DT
- Folks in Linux land didn't want to remove DT from Linux
- Nishanth:
- Hit many of these points in our work
- Mathieu had made a good point
- FW on microcontroller on side. How to provide something consistent for them? Zephyr build would be completely separate.
- Also some topics that Tammy mentioned are relevant to TI
- Is this something that could make sense to focus on attacking next year?
- Tomas:
- Even if we wouldn't use the feature, we're interested to make it more adoptable b/c helps up.
- Think most of the work will be for ppl to come into agreement on what they want. Then think should be straightforward to implement the tooling.
- Being able to configure everything means AMD Xilinx needs all the flexibility. Will want to make it suit all different SoCs. Would want real users/clients like yourselves instead of theoretical suitability.
- Think Bill would also be interested in looking at this. But, should probably drive through the System DT working group instead of System Reference (end-to-end examples).
- Messiness around U-Boot: Are there ways to use Lopper (maybe not System DT) to make it more data-driven to add things to U-Boot b/c needs to know more than what Linux needs.
- Nishanth: Has Bruce talked to Simon Glass?
- Bruce: In Prague, briefly. He & others wrangling DTs understand why we have Lopper. Worth spending time to discuss w/ ppl like that & understand how to accommodate their needs.
- Nishanth: U-Boot Lopper integration could be interesting GSOC project (added to the brainstorm sheet)
- Tomas: Should bring up in OpenAMP TSC & Board calls. Could figure out who is interested & set up dedicated call.
- Arnaud:
- Loic is following System DT for ST. Need system to have consistent DT. Today, we just have some overview of Lopper based on intern's work. Haven't had time to look at Lopper in depth.
- We are trying to push device bus on Linux side to check access rights to some peripherals. Relevant to System DT. Want to have IP that are assigned to secure world & co-processor. Want to be able to check we can use it before probing.
- https://patchwork.kernel.org/project/linux-dmaengine/list/?series=762784&state=*
- Recall AMD Xilinx had protection/firewall discussion w/ Rob
- In Linux, we have bus where have to check access rights of IP based on system firewalling. Then need consistent DT w/ components. Think Lopper is good tool for that.
- Tomas: When you have to express that you can access device between 1 part of system & not another.
- Nishanth: We took another route. TI security told us not to do in DT. Use ___ and authenticate at boot.
- Stefano: For Xen we had requirement of secure boot. Configuration of multiple domains is described in DT. We solved problem w/ U-Boot's ability to encrypt multiple binaries & check signatures. Can bundle together & check signature at boot time.
- Tomas: Protection & firewalls is not yet mature w/ DT. Interested in what can be done there.
- Nathalie: Any other DT topics?
- Tomas:
- We have our own SDK where we can build, but want to make sure when you use Yocto matches
- Our design tools give us System DT & domain.yaml. OS type flag in domain.yaml to indicate if for Linux, baremetal, etc. We have a prepare step gen-machine-conf w/ Lopper that generates what Yocto build needs, so that we don't have to change build system.
- Nishanth
- Individual updates
- Arnaud: no update
- Dan: Added new items to list. Rebased everything for native virtio on top of latest lib openamp commits. Will create another PR once deal with some details.
- Nishanth: Andrew still looking at libmetal w/ baremetal R5 stuff but got diverted for a few weeks. For video, want patches merged (maintainer on vacation)
- Tammy: Need to carve out some time next week & target PR end of next week.
- Tammy: Ported multi-service demo on KV260. Tested on QEMU but not HW yet. Will create PR
- Bill, Dan, Tomas, Hari, Tanmay, Nathalie, Nishanth
- Tomas: Have we looked at doing OpenAMP / System Reference for other architectures, or considered for future?
- Nishanth: Zephyr & System DT: How to do as a holistic view?
- Google Summer of Code: TI projects from this summer & brainstorming for next summer
- Q2/Q3 task tracking status
- Individual updates
- Haven't really looked at system reference for other architectures yet
- Would like RISC-V to standardize AMP & DT in similar way to Arm & not do yet another way
- It would be really interesting if Lopper could start w/ kernel DT & transform into System DT
- We can probably come up with a few potential GSOC project topics
- Tomas & Nishanth: Discuss OpenAMP with RISC-V Foundation at Santa Clara event
- Tomas: Check if anyone at AMD is working on System DT for RISC-V
- Nathalie: Put on agenda for next call to discuss starting w/ kernel DT & transforming into System DT w/ Lopper and invite Bruce
- Nathalie to create a Google doc where ppl can drop in their brainstorm ideas & we can look at the list next time
- Nishanth will work on cleaner video of the GSOC projects, let us know when the more polished one is on Beagle channel & we will link to it in our Playlist on OpenAMP channel
- Dan will add tasks that he's working on to the task tracking sheet
- Tomas: Have we looked at doing system reference for other architectures? Or, considered for the future?
- Dan: WR has some unsupported BSPs for some popular RISC-V boards & run VxWorks
- Tomas:
- AMD has soft cores based on RISC-V. Might be good to get some RISC-V folks involved in OpenAMP & might reach out to RISE (like the Linaro of RISC-V).
- Would like OpenAMP to be working architectures, but would need someone coming
- Bill: Would like to see someone w/ heterogeneous SoC doing the same things you're doing on MPSoC
- Bill: Has TI looked at System DT?
- Nishanth: We did. Looking at it for Zephyr enablement. Unifying SDT & kernel DT definition - same challenge, different views. Would like to maintain compatible similar to what kernel DT is in drivers. Zephyr has forked from what kernel is using, but not much reason for that fork. Seeing same on U-Boot. See possibility to unify.
- Tomas: We hope that DTs look the same, but for the specific things good to have SDT with everything in it & then can have framework w/ Lopper to translate.
- Nishanth: Struggling w/ bindings check. Kernel has more elegant bindings check. Would like to have similar in Zephyr & U-Boot. Don't want our customers to have to learn 3 different DT formats (Kernel, Zephyr, U-Boot).
- Tomas: Thinking would like RISC-V to not invent another standard - would like DT & AMP to be handled similarly.
- Nishanth: U-Boot closer to kernel, Zephyr forked out even for RISC-V. Should probably discuss at RISC-V Foundation. RISE bit different focus.
- Tomas: Pointed out to RISE that embedded could use some standardization.
- Nishanth: Mostly seeing SMP systems.
- Tomas: Think ppl will start mixing ISAs
- https://www.beagleboard.org/boards/beaglev-ahead is a new RSIC-V board. It has DSPs and ISPs but no GP MCU
- Nishanth: Are we looking at integrating RISC-V into System DT?
- Tomas: So far, no one externally. Need to check w/ internal team if they are, but think they're doing much work similar to what was done for Arm (for baremetal & FreeRTOS).
- Tomas: Will bring up at OpenAMP Board or TSC call
- Nishanth: Will be good to bring up OpenAMP w/ RISC-V Foundation at Santa Clara event
- Nishanth: Zephyr & System DT – how to do as a holistic view?
- Bill:
- Talked to Marti before he left Nordic. For asymmetric SOC w/ Linux as a target, would be big churn to change lots of devices.
- Lopper can do transforms - the input could still be a standard DT & could manipulate
- Nishanth
- Hoping to get these tools integrated into DT schema & DTC
- Discussed w/ Tom & few others about Lopper & if we could integrate w/ U-Boot
- Bill: Think U-Boot is smaller issue. They didn't change IIC binding, just added their own properties.
- Nishanth:
- They got some upstream (Michal from AMD using, we are using).
- Really, you shouldn't have to change the HW description
- Bill: Zephyr started w/ different description of HW, describing the same thing but different language. Most of the MCU consumers of Zephyrs - will they see much value in having to go change their bindings.
- Nishanth:
- Agree. Splitting the scope. Have to document.
- TI is in early stages w/ 3-4 peripherals. What guidelines should we follow?
- e.g. GPIO nexus to handle >32 GPIOs in HW block is described in DT
- Can probably come up with some guidelines, but the core binding would probably be in kernel DT
- Or, if other SW ecosystems want to use it, need some DT schema equivalent. We don't have that.
- Bill: AMD Xilinx HW can mutate for each customer, so what gets checked into kernel isn't that interesting. In other markets, where HW doesn't mutate, what is checked into kernel is important. If Lopper took what's in kernel & transform into SDT that other operating systems could use - flipping the inputs & outputs.
- Tomas: Would be interesting to us. Do have customers that start w/ kernel DT & we are trying to move to System DT. Worth looking into. Will bring it up w/ Stefano & Bruce - might increase interest in System DT if you didn't need 2 ways to do things.
- Nishanth: Microcontrollers have SVD & quite a few tools around that. Would be interesting to stitch to System DT.
- Tomas: Especially if you can do it in scalable way. Power of DT is that you can split things in different ways & get repeatable process.
- Nathalie: Put on agenda for next call to discuss starting w/ kernel DT & transforming into System DT w/ Lopper
- SVD: https://www.keil.com/pack/doc/CMSIS/SVD/html/index.html
- Bill:
- Google Summer of Code
- Nishanth:
- Posted Prashanth's video of integration of mailbox. Patches to Zephyr master are still outstanding. Would like to get that upstream & then post video to Beagle channel.
- Kendall only did internal video for baremetal & would like to have a public video for that.
- Part Marketing, Tech showcasing, Hiring opportunities. Had students complete projects w/ POC: Zephyr, Baremetal & OpenAMP.
- Students struggle w/ the community code contribution aspect. Do have to plan for upstreaming work to go on after the internship is done. Period is only 3 months.
- How to maintain after POC, if it's successful. Need someone to pick it up & bring rest of org around & carry it forward.
- Bill:
- Could probably brainstorm a few topics. Once we get vitio MMIO basics done, there will be lots of devices/protocols that we won't have.
- Taking that & adding to the list of supported protocols w/ Zephyr, Linux, QEMU would be a good GSOC project.
- Getting System DT for a different processor might be challenging but interesting.
- Nishanth:
- Good to have the master list & prioritize to use for internships & GSOC b/c not all topics are accepted by Google.
- Expect we will get interns next year too & may be able to attack some topics from TI side.
- Nathalie to create a Google doc where ppl can drop in their brainstorm ideas & we can look at the list next time
- Nishanth will work on cleaner video of the GSOC projects, let us know when the more polished one is on Beagle channel & we will link to it in our Playlist on OpenAMP channel
- Nishanth:
- Task tracking
- Dan will add tasks that he's working on to the task tracking sheet
- Nishanth forwarded Tanmay's patchwork links & Hari responded
- Bill Mills, Tanmay Shah, Andrew Davis, Arnaud Pouliquen, Dan Milea, Nathalie Chan King Choy, Hari Nagalla
- RPMsg in U-Boot & Demo video
- Integrating board/environment specific code into system reference a generic way
- Q2/Q3 task tracking status
- Individual updates
- Perfect world would be to move application part in System Reference w/ README that explains how to run on vendor platform. Then OpenAMP repo would become just a library & would rip out the examples. That's the goal & in transition period now.
- Would like to build next virtio experimental branch w/ what Arnaud & Felipe both need - not ready for main yet.
- Dan will switch to new IPI mechanism when update the samples & Zephyr driver to work w/ openamp layer.
- Got request from upstream to move from IPM driver to mailbox for userspace. Open to proposals on how to do that.
- Tanmay will add info on limitations & create public link to his document and share it to openamp-rp mailing list
- Andrew will add a note related to today's discussion & close TI intern's PR15
- Arnaud will try prototyping system reference example on his GitHub integrating all the work done by ST intern, with goal to put it in branches in OpenAMP GitHub
- RPMsg in U-Boot & Demo video
- Tanmay prepared a document to explain the background for the patch & the functionality. Patch v1 is proof of concept and what else needs to be done is listed in future work.
- What's the best way to share the document with folks who need to review. Put it in the Google drive so far.
- Nathalie: Everyone in this call except Andrew has access to the drive folder. Andrew can send Nathalie his Google account to share access.
- Bill: For a given document, we can make it publicly visible with a link & put that in the mailing list email
- Arnaud: Can ask U-Boot community if they have a preferred way to share documentation
- Bill: Differences from the normal framework are good to document. Don't want to have duplicate documentation that we'd have to maintain - prefer if changes go into common documentation & refer to existing docs.
- Tanmay: Need to document limitations (e.g. interrupts)
- Bill: For OpenAMP-rp list, it's fine
- Video is only for the reviews, so we will make it as Unlisted
- Integrating board/environment specific code into system reference a generic way
- Arnaud:
- How to integrate baremetal system-reference example in OpenAMP?
- Kendall Willis proposed an example, but it includes a lot of files to be able to run the example on Cortex R5.
- Prefer not to have such a complex project. Prefer generic application w/ adaptation layer & README explaining how to do baremetal.
- Bill: AMD Xilinx not a good example b/c have support in OpenAMP libmetal layer
- Arnaud:
- Thinking more the application structure
- Application is generic with some specific code
- Something external for the build (meta-open-amp)
- Bill: Something similar to what AMD has in libmetal should show up in system reference & complex stuff somewhere else?
- Arnaud:
- To support cortex R5 today, then have to support Cortex M tomorrow & lots of others. Would be maintenance burden.
- https://github.com/OpenAMP/openamp-system-reference/pull/15
- Andrew:
- Taking step back & looking at how to organize - Glue code & external support code
- You don't want all the code to make it work in this repo, but libmetal does support some baremetal
- It feels like there's glue at every layer in OpenAMP
- Arnaud:
- Libmetal is to support the porting layer of the different platforms & not perfect
- Need some config file in OpenAMP library too
- Not sure if supporting baremetal makes sense
- Concern that we could end up with much complexity to support everything
- Andrew:
- Sounds like you don't want to support baremetal. Was trying to get us on equal footing w/ Xilinx wh/ has baremetal.
- Working on Zephyr & will be our blessed solution
- Bill
- Wrt glue at all layers, had asked previously: Why are you starting w/ baremetal b/c that's the hardest one?
- Would like to see support for Zephyr, FreeRTOS & baremetal
- w/ Zephyr & FreeRTOS, you get the SoC or board support from elsewhere
- AMD baremetal has its own project where they get that from
- Nishanth indicated you don't want to hook into RTOS SDK & understand why
- Where to put the baremetal support for platforms?
- If TI were to create a project that is independent, then you would be on par with AMD Xilinx & could put the glue in there
- Another idea: pico lib C - if you could build a hello world with pico lib C, you'd miss IRQ & __
- Andrew:
- Depends on GCC build in micro lib
- This is just mailbox driver & R5 init code
- Bill: R5 init code could live in pico lib C
- Andrew:
- Should we move mailbox to libmetal?
- Why did we do it this way? Kendall was our summer intern & this is for her to explore baremetal support on R5. So, we are not married to this implementation.
- Bill: Would be nice for TI customer to go someplace for baremetal on R5 w/ interrupts & a few simple drivers (UART, timer, etc.)
- Andrew:
- This is just the bare minimum code to get examples running in OpenAMP. No consoles, just messages across wire.
- Not trying to make alternative to PDK & MCU+. There's no will behind making another baremetal existence.
- Arnaud: Could there be a repo in TI GitHub for the environment & just have the application w/ some platform info & config info.
- Andrew:
- That’s MCU+ SDK on GitHub, which is a huge solution. We can add the instructions & linking.
- Trying to figure out what the layering should look like in OpenAMP. Trouble is we have examples & integration code in all 3 layers. If you could clear that up, we don't need this PR.
- Arnaud: Perfect world would be to move application part in System Reference w/ README that explains how to run on AMD or TI platform
- Andrew: Then OpenAMP repo would become just a library & would rip out the examples
- Bill: That's the goal & in transition period now.
- Andrew: If we're aligned on that, then this PR can be ignored.
- Tanmay: Then you don't have to worry about examples under Linux except for multi-services. That is going to be our default example. We included the 3 other examples b/c legacy Xilinx examples. If Andrew is going Zephyr path, look at multi-services.
- Andrew: We've been showing off matrix multiply internally, so would like that kept alive.
- Tanmay: Zephyr is not available for that
- Andrew: We've just been doing baremetal for that
- Bill: Do you have a demo that uses TI SDK?
- Andrew: We ship the alternative to this. There are other simple demos in our SDK that maybe could be ported to here. Agree they would be good to get ported as more system reference demos.
- Bill: SDK has own RPMsg stack
- Andrew: Trying to push customers to get away from their own stack
- Bill: Have a way to get baremetal in w/ AMD, ST SDKs. Potentially TI.
- Arnaud: ST has own baremetal environment w/ fork of OpenAMP b/c want to support several IDEs. So we have to make some adaptations. We build all the sources in 1 project (not the library). Don't think we have something that could be run on ST platform in system reference.
- Arnaud:
- Q2/Q3 task tracking status
- Arnaud
- Virtio MMIO discussed in meeting this week
- Intern provided source code to run Zephyr example w/ Virtio MMIO on virtio IIC device relying on OpenAMP. Zephyr driver relies on virtio IIC device from OpenAMP.
- Shared source code w/ Bill
- Bill: Felipe is looking at it & will both try to run on HW. Felipe is trying to make it work w/o daughter card & displays
- Arnaud is starting this work b/c intern wraps up at end of this week. To be able to have something working, Arnaud will need to integrate intern's OpenAMP work somewhere & create associated system-reference example for Zephyr. Zephyr has IIC EEPROM target that is very simple to use. Trying to figure out how to reference in Zephyr to avoid forking. Short term, can create branch for Nicholas' work (based on clean upstream).
- Bill: Felipe also has some patches for Zephyr that he needs for his example. Would like to build next virtio experimental branch w/ what Arnaud & Felipe both need - not ready for main yet.
- Arnaud: Similarly for Linux part & replacing the sensor by EEPROM
- Bill
- 1st item: Felipe has standalone version working, but has not been reviewed.
- Not tracked: Bill sent email today to NXP about their reference board. Suggesting iMX8 for now & transition iMX9 when they have the upstream kernel support ready. If they want to go straight to 9, then want to know when they will be ready for upstream.
- Arnaud: They pushed a series upstream on Linux & on Zephyr to be able to play OpenAMP resource table example from Zephyr. They have some issue due to synchronization between remote processor & main processor b/c they want to kick the Linux part when they are ready. Today kick is Linux to Zephyr. They would like kick from Zephyr to Linux. Discussion happening on that. Mail from Daniel to Mathieu. ACK in mailbox driver to send the kick.
- https://github.com/zephyrproject-rtos/zephyr/pull/61709
- Once they have this working, they should be able to run OpenAMP system reference multi-system example
- Bill: More interested in their M than their DSP. This looks like it's for DSP w/ iMX8. Think Cortex-M stuff for iMX8 is already upstream for Zephyr & Linux. They were suggesting iMX9 as OpenAMP reference, which is maybe not ready yet. OpenAMP would have to carry a lot of patches for kernel & Zephyr - rather they get upstream first. Also, more ppl have iMX8
- Dan
- Tasks have been pushed to waiting list. No changes to these tasks.
- Bill: Arnaud accepted Dan's PRs into main. So, should be able to do native legacy virtio mmio?
- Dan: Almost true. What's debatable is how we allocate virtqueues & place them in the shared memory region. Not sure current API allows. Was using set of macros which is set of Zephyr b/c didn't get merged as part of this PR. Need to figure out how to use existing API or tweak it to get the queues to be in the right region. Then we'll be able to use the drivers to show native legacy virtio mmio. This work is still planned.
- Bill: Think we need someone working on 1.x of non-legacy virtio native. Does Dan have b/w, or assign someone from Linaro?
- Dan: Want to try to get legacy stuff done, before moving on to 1.1.
- Bill: Upstream will want implementation on 1.x, not legacy. Aside from order, is 1.x in Dan's scope?
- Dan: It's within scope, but b/w is the issue.
- Bill will defer this question for a month
- Hari
- AI64 is now our reference platform. Andrew discussed PR about AM64 (related) and baremetal.
- Tanmay
- Updated task list earlier
- Zephyr driver is merged in upstream repo, so moved the task to done
- Shared interrupt controller: Have something working in repo
- Virtio experimental branch for IPI that directly writes into registers. Since we now have driver, would Dan like to use it for IPI communication?
- Dan: Yes, will switch to new IPI mechanism when update the samples & Zephyr driver to work w/ openamp layer.
- When upstreamed the driver, got comment to introduce mailbox driver instead of IPM for userspace. But, we use IPM API in OpenAMP. So, they accepted it. We should still implement mailbox at some point.
- Arnaud: May need some kind of wrapper. Open to proposals.
- Arnaud
- Bill, Tanmay, Nishanth, Dan, Tammy, Tomas, Nathalie
- Reference platforms
- Tanmay: Demo Zephyr work & post to U-Boot mailing list
- Using GH Issues to track action items related to specific repos
- Q2/Q3 task tracking status
- 8/9 call: Nathalie & Arnaud OOO. Does someone else want to be the call host? Or will others be OOO & should cancel?
- Is anyone in this group using System DT?
- Cancel 8/9 call
- Nishanth confirmed Beaglebone-AI64 will be TI's reference platform for OpenAMP
- Discuss System DT in next call
- (DONE) Tanmay will post link to the recording of his demo to OpenAMP-rp call to Discord
- Nishanth will try to get some TI guys to review Tanmay's patch series http://patchwork.ozlabs.org/project/uboot/cover/[email protected]
- Tanmay will create a short video to explain more about his patch series & work with Nathalie to get it shared
- (IN PROGRESS) Nathalie will look through Openamp-system-reference call notes & try to file GitHub issues for actions related to repos
- Nathalie to invite Stefano & Mark Hatle & Bruce to next call: Are there things we can do in this group to make sure it gets into Yocto, works with our reference platforms, 1st class citizen, etc.
- Nishanth:
- Beaglebone-AI64 (TDF4-VM w/ kernel J721E)
- Capability: Has 6? x R5, 1 C6, 1 C7 processors to demo & showcase the capabilities of OpenAMP
- Relatively low cost & easily accessible for folks to try
- Zephyr: Working through how to manage the interrupts. Some PRs have gone through
- Some demos working, but want the code upstream
- Baremetal is working & submitted patches to libmetal
- 6.4 Kernel: All the R6, C6 & C7 are enabled
- Platform has IOMMU, which will help us prototype virtio solutions w/ both Zephyr & Cortex
- Think more attractive for ppl to showcase & demonstrate w/ OpenAMP
- Debian, Yocto support. Armbian might be on the way. Not sure about AOSP plans
- Enabled in Kernel CI: Tracking master & next
- Planning to enable remoteproc in upstream kernel & test on the fly
- Beagleplay just has M4. Can't showcase multiple graph capability.
- AM69-SK (J784S4) SW ecosystem isn't mature yet
- Beaglebone-AI64 (TDF4-VM w/ kernel J721E)
- Tanmay: Demo of Zephyr work, to get to AMD Xilinx version of Arnaud's demo
- Zephyr was missing Xilinx IPI driver. Tanmay wrote it & will upstream.
- AMD Xilinx remoterpoc driver was not upstream yet.
- Today's demo is on QEMU. Planned for KV260, which has same underlying architecture.
- ST documentation: https://openamp.readthedocs.io/en/latest/openamp-system-reference/examples/zephyr/rpmsg_multi_services/README.html
- When have upstreamed, can do same type of doc for AMD Xilinx
- RPU: Zephyr 3.4.0
- 3 channels created
- 1 end point is available
- APU:
- 3 channels (rpmsg, tty, client sample)
- RPMsg client sample demo
- APU sending messages & RPU sends messages back, about 100 messages
- Goodbye & destroy channel
- TTY over RPMsg
- TTY device is enabled in kernel & device is created
- Listen on TTY device
- When write to device, it goes to remote processor & reply comes back on TTY and append channel
- Nishanth: Is there remoteproc TTY driver on Zephyr side?
- Tanmay: No, more like a loopback
- RPMsg character device
- Will use the RPMsg raw channel
- Character driver will send the data to RPU
- Using rpmsg_ping utility in system reference repo
- Remote processor replies back appending device name
- Multiple endpoint creation w/ rpmsg_export_ept utility
- Exporting multiple endpoints
- See that relative devices are created under /dev as character devices
- Can use rpmsg_ping utility to communicate w/ them on RPU
- Can use rpmsg_destroy_ept (ioctl to kernel) to destroy channels
- Then stopping remote processor destroys /dev/ttyRPMSG0 device & see R5 message
- Tanmay posted RPMsg U-boot patch to U-Boot mailing list http://patchwork.ozlabs.org/project/uboot/cover/[email protected]/
- Creating virtio devices in U-Boot & configuring resource table & __
- Pretty close to Linux kernel, but not as advanced. This is more POC to show our work to U-Boot community & get their input. When get their input, can add more functionality, like more endpoints dynamically, name service, relative endpoints & channels dynamically.
- Please review & comment
- Nishanth: Glad to see you have extended much more
- Tanmay will post link to the recording of the demo to OpenAMP-rp call to Discord
- Nishanth:
- Nishanth will try to get some TI guys to review Tanmay's patch series
- Think ppl will ask why we need this advanced functionality
- Would be helpful if you post some documentation
- Tanmay will create a short video to explain more & work with Nathalie to get it shared
- Using GH issues
- Nishanth supportive
- Bill thinks we could use issues more
- Nathalie will look through notes & try to file GitHub issues for actions related to repos
- Bill: If not sure, could go in openamp system reference
- Tomas: Is anyone using System DT?
- Nishanth: Trying to align U-Boot side w/ Linux. Zephyr is following System DT - Challenging. The bindings seem to be different in various aspects. Would like to use kernel DT in & use System DT on top. Concerns around licensing.
- Bill: Zephyr has some work items to align on bindings. Approach will be to align platform by platform (i.e. focus on the ones that Linux will care about). What TI is trying to do is aligned w/ what Zephyr is trying to do.
- Tomas: AMD Xilinx is rolling out System DT for our products. Are there things we can do in this group to make sure it gets into Yocto, works with our reference platforms, 1st class citizen, etc. Probably a longer discussion next time & Nathalie should invite Stefano & Mark Hatle & Bruce to that call.
- Bill: What is the System DT to rule them all? For AMD Xilinx it comes from our HW designer, but other vendors don't have that.
- Tomas: We have to do a bit different b/c our problem is superset of others. With each bitstream we might have a new DT. Where do you define which domain builds what OS e.g. build Yocto Linux kernel for this domain. Want to make sure it's useful across multiple architectures.
- Nishanth: Are we interested in pulling in Tom Rennie & Zephyr maintainers?
- Bill: We should figure out what we want before we pull in community.
- Tomas: Easier if we go in with a strawman proposal that we can be open to changing.
- Bill, Tammy, Arnaud, Tanmay, Tomas, Nathalie, Dan, Hari
- Congrats on doc release!
- Prague updates
- Discuss reply on NXP candidate platform
- Q2/Q3 task tracking status
- Individual updates
- Do we need the wiki page on demos?
- Full hypervisor doesn't need AMP virtio that we're working on, but as hypervisor gets more lightweight then our work becomes more relevant
- (DONE) Bill to reply on the thread with NXP about concerns around availability of the NXP platform and ask about upstream Linux kernel support
- Bill: Prague update
- Xen Summit:
- Stefano's plan for safety certified Xen still includes grant tables & IO request servers. Some argue that maybe shouldn't include those in highest level of Xen.
- If you remove IO request server, they need everything we will do in virtio-mmio changes. If you remove grant table, then they will have pre-shared memory for comm, which looks more like OpenAMP virtio work.
- Xen support of virtio: Device can't see all memory in the guest until the guest takes specific action (e.g. iommu, explicit grant of the pages). This means to guest that any piece of its memory can be shared w/ device, so don't have to copy to certain place, but needs to be modified to have grant mechanism.
- Tammy has seen mention of virtio integration w/ Xen. Replacing grant table w/ virtio? Another media transport layer?
- Bill: Links to slides
- Bill: Virtio as alternative to standard Xen para-virtualized devices & drivers. Grant table would operate under both, ideally.
- Tammy: Would have to update front/back end drivers
- Bill: Assuming that they will hide under IOMMU subsystem for Linux drivers
- Tomas: Don't think will take away b/c don't want to break backward compatibility.
- Tammy: If could get rid of grant tables, would make smaller for safety certification
- Bill: Full hypervisor doesn't need AMP virtio that we're working on, but as hypervisor gets more lightweight then our work becomes more relevant
-
AMD Virtio GPU presentation was also very interesting
- Think OpenAMP will stay away from GPU for now, but is interesting
- Nishanth from TI & Jason from Beagleboard
- Think they settled on Beagle Play. Hari believes so as well & Nishanth to get back to us formally.
- Think Beagle Play will be certified as an upstream Yocto reference board -> good alignment
- Pull request for Zephyr support on M4 to support that device -> good alignment
- Bill: On the PR, someone mentioned it would be nice to have remoteproc on Zephyr
- Hari: Think India team got it working but not with RPMsg. In parallel, someone was trying libmetal.
- Bill: Libmetal for Zephyr should be easy b/c shouldn't have to port anything specific to your platform
- Arnaud: Agree. Need to define mailbox & resource table. Zephyr on co-processor talking to Linux?
- Hari: Yes, they got resource table & think also shared memory. Need to check w/ them on mailbox.
- Arnaud: There is sample that should be generic for that. You define your own mailbox & customize shared memory address & size & maybe some cache management. Should be straightforward. Need resource table in binary file.
- Bill: Think RPMsg will eventually come up. This commenter talking about remoteproc in Zephyr. Think there's Cortex-A support on Beagle Play, then if M support… unclear if to load, or if inter-processor communication. OpenAMP library supports being a remoteproc host, but is anyone actually using that?
- Arnaud: If you need to load the firmware, don't think anyone implemented that approach. Library should support the capability. Think AMD uses it in Linux user space.
- Tanmay: Not sure on libmetal, but on Zephyr side think have to look into interrupt controller for support for RPMsg.
- Tammy: Which core?
- Bill: AM625 with 2xA53 & 1xM4
- Tammy: Have it working on M7 & would have to check what remoteproc support had. Had RPMsg. Would that help?
- Bill: Guessing Zephyr on A53 in SMP & use remoteproc in Zephyr to load Zephyr on M4
- Tammy: Mine was Linux on A53, haven't done Zephyr on A53
- Hari: Linux loading Zephyr has been tried on Beagle Play
- Tammy: Have not yet thought about RTOS loading RTOS. Usually have Linux on A cores & boots up the other cores w/ RTOS.
- Arnaud: NuttX also has use case for loading co-processor. Believe 2 co-processors w/ 1 loading the second one.
- Good progress: Generic Arm64 build for standard Yocto HW reference for Arm
- Can be tested on multiple boards: KV260, hopefully TI will test on Beagle Play
- Similar to what Bill is doing in OpenAMP CI build & good if it matches the HW platforms we're using
- Xen Summit:
- NXP platform
- Concerns: Price & availability of board (can order, 0 available)
- Upstream Linux kernel support is an open question. Prefer not to have to carry patches. Could we do iMX8 in short term & intersect iMX9 next year?
- Bill to reply on the thread with NXP about concerns around availability of the NXP platform and ask about upstream Linux kernel support
- Arnaud, Tanmay, Dan, Tammy, Nathalie, Bill, Tomas, Hari, Bruce
- With the bi-weekly System Reference Virtio calls, do we want to keep the 2-week cadence for the main System Reference call, or move to 4-week cadence?
- Virtio update
- Documentation status
- NXP i.MX93? 2 Cortex-A55 and 1 CM33
- OpenAMP LinkedIn follower stats: Dec webinar vs. BOF
- Q2/Q3 task tracking status
- Individual updates
- Keep this meeting series going
- Webinars are better for recruiting new users of OpenAMP than BOF
- (OBSOLETE) Nathalie: Update the bi-weekly meeting series to 30 min
- (DONE) Nathalie: Check with NXP about upstream support of i.MX93
- (OBSOLETE) Nathalie: Try contacting Marti on LinkedIn about System-dt talk at EOSS
- (DONE) Arnaud will ask intern to create branch without rpmsg part
- With the bi-weekly System Reference Virtio calls, do we want to keep the 2-week cadence for the main System Reference call, or move to 4-week cadence?
- Bill: Either way is OK. There is work happening aside from Virtio.
- Tomas: Could shorten to 30 min.
- Tanmay: 30 min good.
- Dan can make the first 30 min
- Arnaud: Can also cancel if nothing on agenda
- Nathalie: Update the bi-weekly meeting series to 30 min
- Bill: Virtio work update
- 3 things going on:
- Dan is taking native virtio & isolating it & creating PRs. This is the non-controversial part. Others on OpenAMP PRs who are doing similar work. Good way to pipecliean virtio in openamp library.
- Arnaud + intern are working on demo that have M4 as device being exposed to Linux (reverse of Dan's demo)
- Felipe from Linaro is taking 2 QEMU instances running A53 running Zephyr w/ IV shared memory between them. Both sides of a virtio connection. Getting the infrastructure up. There are public slides: https://drive.google.com/file/d/1mFCiHxItcJzgWLNRfa37jBLitbu4Nvew/view
- Arnaud: Xiaomi also has their own implementation. Probably on NuttX OS. They are involved in Dan's PR review.
- 3 things going on:
- Bill: Documentation
- Cleaned up & squashed commits for old PR before Connect & added README that Tammy suggested
- Tested in a clean Docker to verify it works
- Merged the PR
- Any issues can be addressed in another PR
- GitHub Action that automatically bumps the submodule revisions (e.g. openamp library accepts something into main branch -> revision will get updated)
- Opened an issue in doc repo as to do: Would be good if the OpenAMP PRs can generate reviewable docs
- Want to put tag on: v2023.04.0 version
- If we get v2023.04.1 then can tag that & un-publish the .0 doc
- Process of publishing the tag is manual. Might not be worth the effort to automate.
- Cleaned up & squashed commits for old PR before Connect & added README that Tammy suggested
- NXP i.MX93? 2 Cortex-A55 and 1 CM33
- Bill: The concerns would be price & upstream status. $600 is not too high. iMX.8 is about $500.
- Nathalie: Check with NXP about upstream support of i.MX93
- OpenAMP LinkedIn follower stats: Dec webinar vs. BOF
- 24 of our 55 followers joined in Dec 2022
- 3 in Apr/May and 2 of those are people already involved with the project
- BOF also has a different connotation (ppl already involved). Webinar is more aimed at newbies.
- Nathalie: Try contacting Marti on LinkedIn about System-dt talk at EOSS
- Webinar better for recruit
- Arnaud: No spike in star history with webinar, but seeing consistent increase in interest. Libmetal has less interest than openamp library.
- Tanmay:
- Had success in porting. Arnaud's work has 3 demo parts. Can run rpmessage plan sample. Yet to test the other 2 - will do this week. With new Zephyr R5 diver that I have written in a fork from Zephyr in openamp staging. Should be able to upstream once driver is done b/c have solid example. Currently in own repo. Will create PR when all the demos are tested on QEMU.
- Do we want to open a Linaro ticket for this work?
- Bill: Yes. Felipe & Kevin T. also want working on KV260 HW, but QEMU is 1st step. They each have a KV260.
- Tanmay: Will also test on KV260.
- Bill: Does Hari know if Nishanth prefers AI64 vs BeaglePlay?
- Hari: Intern trying on AI64 but not sure which way he leans.
- Hari: Trying to get OpenAMP Libmetal working on AI64 & will be helping her on that.
- Arnaud:
- Provided code in GitHub for Bill & Felipe. Should update w/ split between Zephyr & OpenAMP. Need to check on intern's progress.
- Bill: When 6.4 kernel comes out, would be good to rebase on top of that. What do you think of doing a clean rebase? What do you think of having a clean branch without rpmsg TTY?
- Arnaud: Could split, but Virtio part is not clean enough yet. Need to make usable in more generic way. Was using 2 implementations to compare if rpmsg iic is working.
- Arnaud will ask intern to create branch without rpmsg part
- Bill:
- Rpmsg is working better this week. Should be in shape for review this Friday.
- Virtio serial is the next thing to do. Due in July.
- device & driver both in Zephyr both on A53, communicating in AMP fashion
- Dan
- No updates on tracking sheet
- Will reply to Arnaud's comments on PR by end of week. Will figure out how to use the other PR referenced there w/ reference for transports.
- Arnaud: The split of the files for virtio mmio driver is OK for me. Forgot to mention in the PR.
- Tammy: No update
- Bruce: No update
- Bill: OpenAMP Sphinx docs now points to the System DT stuff
- Tammy, Bill, Dan, Tomas, Arnaud, Nathalie, Tanmay
- Post-OpenAMP April release: Anything to discuss about post-release System Reference items?
- We have various efforts happening in parallel in the task tracking. Is there a milestone we want to try to converge to, like the October OpenAMP release or maybe another webinar in Q4?
- Individual updates
- Let's revisit in September if we should have a webinar at the end of the year
- April OpenAMP release outstanding items:
- Docs targeting June
- Meta-openamp to build - need someone who can work on it
- Tasks for next milestones have been added to the task tracking
- (DONE) Nathalie: Look at previous conversation w/ NXP and see what discussions we can get started wrt System Reference
- (OBSOLETE) Bill to email Ben to find out if he can work on meta-openamp to define the recipes to build the April 2023 OpenAMP release. CC System Reference list.
- (DONE) Bill & Arnaud to discuss Nucleo boardfurther in Discord
- (DONE) Bill to add Tanmay to the Virtio system reference call to sync about Zephyr ZynqMP development
- Converging parallel efforts towards a milestone
- Nathalie: What does it make sense to target for Oct release or maybe another Q4 webinar?
- Bill: Would like Oct release & EOY milestone, whether or not we have another webinar. Would also like an earlier milestone than Oct.
- Arnaud: No strong opinion. Would like to have something for virtio in Oct release. Maybe can decide in ~September if we should have another webinar.
- Bill: Think we should plan for a roll-up demo, whether or not we have a webinar, to put together everything we accomplished in the year.
- Tomas: Agree we should have a roll-up & virtio demo is a great idea. Will depend on what can be done up to that point.
- Bill: Some important tasks missing from the tracking sheet. We have Linaro Jira for a lot of things, so don't want to duplicate too much.
- Think we should have a milestone for NXP platform
- Arnaud: Can aim to present work on Virtio MMIO feasible w/ co-processor -> tracked in Linaro Jira
- Bill: Took a first swag at a roadmap before Connect:
- https://linaro.atlassian.net/wiki/spaces/HPP/overview#Roadmap
- Would like Virtio demo in Oct release tracked in the sheet -> added some tasks for Bill
- Ivshmem = IV Shared Memory
- Getting NXP involved w/ system reference
- Nathalie: This call time is very late for China participants. Would probably have to figure out a subset call that is either China-Europe-EastCoastNA or China-North America.
- Bill: 1 NXP person has been joining RP call consistently, which is 1 hr earlier (11pm for them). System Reference would be midnight, which is harder.
- Nathalie can look at previous conversation w/ NXP and see what we can get started wrt System Reference
- Post-OpenAMP April release topics
- Arnaud: What is target for 1st docs release?
- Bill will produce a version of the docs based on April tags, once his automation PR goes in (ETA June)
- Bill: There's still meta-openamp work to define the recipes the build the 04 released version. Not able to commit to doing that right now.
- Bill to email Ben to find out if he can work on meta-openamp to define the recipes to build the April 2023 OpenAMP release. CC System Reference list.
- Arnaud: What is target for 1st docs release?
- Bill update
- Will do the doc change later this week
- Working w/ Felipe on dual QEMU IV shared mem w/ Zephyr on both sides & IV shared mem to connect the 2, Get the infra hooked up & run RPMsg to prove they work.
- Tackling RTOS-RTOS first
- Same setup can be used for Linux-RTOS
- Felipe will target OpenAMP System Reference repo. Believe he won't need to change Zephyr repo.
- Next: AMP Virtio, which will require changes.
- Would like Felipe to reproduce ST work on ST MP1 platform once he's done this task
- Arnaud: Would be good to have Nucleo board that can measure things like temperature, pressure, to have a few devices on IIC bus.
- Bill & Arnaud to discuss Nucleo boardfurther in Discord
- Tanmay update
- Working on U-Boot. Almost done. Will present at tomorrow's OpenAMP RP call. Mostly in U-Boot. For openamp library changes, targeting Aug/Sept.
- Arnaud: RPMsg configuration to be able to optimize the size of the buffer? Xiaomi had proposed to add to RPMsg protocol to negotiate size of RPMsg buffers.
- Tanmay: May not happen as quickly, but it is in plan.
- Arnaud: October?
- Tanmay: Can't commit for October
- Will continue working on Zephyr from this week
- Bill: Felipe was able to add a rudimentary PR into current release for Zephyr to add platform support for KV260. Should probably coordinate on Zephyr ZynqMP stuff.
- Bill to add Tanmay to the Virtio system reference call to sync about Zephyr ZynqMP development
- Arnaud update
- Started to upstream OP-TEE remoteproc
- Intern continues to work on virtio MMIO
- Tammy, Tanmay, Tomas, Nathalie, Dan, Hari
- Recap from Linaro Connect
- OpenAMP April release: Anything to discuss about post-release System Reference items?
- Individual updates
- Update task tracking: https://docs.google.com/spreadsheets/d/1N5eO0FDX-gqpJtBleh_iGn-k9gr3j-w8ByjPFsjIoB4/edit?usp=sharing
- Recap from Linaro Connect
- BOF: Not big quantity (the after lunch slot :P), but high quality attendance
- Good engagement from Arm & TI
- Tomas:
- Lot more focus on automotive & embedded than previous years
- OpenAMP being mentioned left & right in Blueprints, so we have more visibility now
- Linaro Connect was sold out, so that was good.
- Good to be back. Valuable F2F discussions.
- Dan:
- Like the engagement from the non-OpenAMP ppl who are now interested in OpenAMP
- Discussed plans w/ Bill & Arnaud for enhancing virtio support in libopenamp
- Have both back-end & front-end support in libopenamp
- Touched on possibility of rewriting libmetal in Rust. Would be a stretch goal.
- Tomas:
- Arm group didn't know about a lot of the stuff we are doing & very interested in OpenAMP work.
- Nathalie:
- I will be reaching out this week to 1 of them who will be participating in our calls, to get him on the mailing lists.
- BOF: Not big quantity (the after lunch slot :P), but high quality attendance
- Individual updates
- Tanmay: Porting Arnaud's demo to Xilinx platform is still work in progress.
- Dan: Working on a plan to merge the virtio-exp branch into main. Most comments are related to source layout. WIP.
- Tammy: No update.
- Hari: No update. Had to work on internal issues.
- Task tracking updated
- Tanmay is working on RPMsg in U-Boot, so has not had a chance to continue on 10
- Tammy has updated the headers for 12
- Dan has no status changes
- Tammy: Is Rust a new idea for OpenAMP?
- Dan: It keeps being brought up.
- Tammy: Know Rust is supported by Zephyr. Is it gaining popularity in multicore, or just in general?
- Dan: Rust is very popular among Linaro engineers, visible on Linaro Connect agenda. Think everyone will eventually have to learn it. Currently not big fan.
- Tomas:
- Linux took a decision that they are starting to accept Rust drivers into kernel, so that was a big boost for Rust language.
- Linaro also has a Rust training for Linaro members. They have some projects around virtio where they are implementing w/ Rust VMM.
- Rust is definitely a safer language. Concern about Rust adding too many modern concepts - maybe OK for a language, but not ideal for safe language.
- Interesting, but not big fan after prelim reading.
- Tanmay, Tomas, Arnaud, Bruce, Nathalie, Tammy, Hari, Bill
- Tomas: ChatGPT & testing
- Arnaud: Proposal from Raveem KG to contribute to OpenAMP
- https://github.com/OpenAMP/open-amp/discussions/479
- Which subject can we propose?
- Arnaud: Should Xilinx/AMD demos and examples be moved from openamp/libmetal repositories to openamp-system-reference?
- This question is related to the pull request from Sergei https://github.com/OpenAMP/libmetal/pull/231
- Anything to discuss for Connect?
- Who will be around for May 3 call? Keep/cancel?
- Individual updates
- Reminder to update task tracking sheet: https://docs.google.com/spreadsheets/d/1N5eO0FDX-gqpJtBleh_iGn-k9gr3j-w8ByjPFsjIoB4/edit?usp=sharing
- Decision: Release openamp, libmetal & system reference. Rest will get tagged later.
- Use mailing list for discussion of intern's code? Yes.
- Bill & Arnaud to discuss: What gaps in release test plan? What else can we automate in release test plan? What can we get to run on every PR?
- (OBSOLETE) Bill to answer Raveem KG in https://github.com/OpenAMP/open-amp/discussions/479
- (DONE) Tanmay to discuss w/ Mark & Ben if moving the demos & examples from library repos to system-reference would impact AMD Xilinx production build -> It will affect. Will have to plan to change the recipes first before moving the demos.
- (DONE) Bill, Dan & Arnaud to coordinate for Tue on Discord
- (DONE) Nathalie: Cancel May 3 call
- (DONE) Tammy to review & comment on checkpatch PR
- (DONE) Arnaud to discuss w/ intern if should add him to the OpenAMP Discord -> Intern will not join the Discord.
- Tomas: ChatGPT & testing
- Any help we can get to have more tests would be great
- Tomas showed some query results for OpenAMP & DT related code generated by ChatGPT
- Can train it by pointing it to some code or documentation
- Idea for a hackathon: to use ChatGPT or Co-pilot to create tests
- ChatGPT4 is paid & produces better results, so expect it will continue to improve
- Nathalie: AMD Legal has advised against use for now b/c license violation issues.
- Bill: Linaro has also said that any use of ChatGPT has to go to the execs for review.
- Tomas: OK to play with it until there is more clarity as long as you don't publish the code.
- Bill: Can also help you clear the cobwebs to begin a task
- Tomas: Also helps take care of the template type things like includes, etc. So you can get on to the fun part.
- Tammy: Very cool. thanks for sharing.
- Bill: Have to define the problem in a way that it can engage. Didn't come back with ACPI tables for Beaglebone Black.
- Tomas: After some practice, you learn how
- Nathalie: Has anyone tried Bing w/ AI? It produces footnote references, which might help w/ attribution issues?
- Arnaud: Proposal from student Raveem KG to contribute to OpenAMP
- Seems like he has tried Zynq board. Not sure his level of expertise.
- Can propose ideas. Maybe Xilinx/AMD demos and examples be moved from openamp/libmetal repositories to openamp-system-reference. CI. Documentation. Other examples.
- Bill: Getting the CI to do better testing, even if 100% simulated. Can ignore real HW for a while. Linux-Linux? Can leverage what we did in the demo & run real QEMU-based systems.
- Arnaud: QEMU is best candidate for improving CI tests & increasing coverage.
- Bill & Arnaud to discuss on Tue: What gaps in release test plan? What else can we automate in release test plan? What can we get to run on every PR?
- Bill to answer Raveem KG in https://github.com/OpenAMP/open-amp/discussions/479
- Arnaud:
- Should AMD Xilinx demos and examples be moved from openamp/libmetal repositories to openamp-system-reference? This question is related to the pull request from Sergei https://github.com/OpenAMP/libmetal/pull/231
- Today implementation is for Linux & AMD Xilinx platform. Would like to move examples & demos to system reference so that just library code in the library repositories.
- Bill: How does that intersect AMD Xilinx production build? Think the examples are included…
- Tanmay to discuss w/ Mark & Ben if moving the demos & examples from library repos to system-reference would impact AMD Xilinx production build
- Tanmay: Some internal/non-open source libraries required to build these demos (w/ RPU BSP). Can build w/ Yocto, but no cmake command to build the demos.
- Bill: To build the Xilinx way
- Tanmay: Arnaud's concern is right - these are not generic demos. Can discuss internally how to make it compile generically
- Bill: Can decouple:
- Xilinx nightly product build has all that stuff. Can we move from 1 repo to another & not break the build?
- Getting to build in a generic fashion is an OpenAMP problem we can tackle separately
- Arnaud: Don't need to solve in short term. This question is triggered by Sergei's PR https://github.com/OpenAMP/libmetal/pull/231. Can keep code we have until we make a decision, but don't want to integrate more code like this until we have a decision.
- Bill: The generic ones are pretty usable & platforms only need thin layer. The early ones are grandfathered in. Would like to get rid of device-specific stuff & set good example in library.
- Anything to discuss for Connect?
- Bill: We have the BOF slot, which is longer than we need. BOF ~1h and OpenAMP meeting ~1h. There's a meeting that Tomas & Nathalie are invited to for TSC that takes last 15 min of that slot. So, we might have to max the BOF to 1h and 45min for OpenAMP meeting.
- Bill: Slides are due today. Will be working on them this afternoon. BOF slides will be minimal. May redo the Virtio presentation & keep as back-up slide set in case we run out of topics. Need list of topics we'll bring if we run out of topics.
- Arnaud can show demo as follow-up to talk. Zephyr demo w/ authentication of remoteproc FW & try to load it. Can set up while Bill gives intro.
- Bill: Would like some discussion topics for BOF, not just demos. Will have docker demos on computer as backup.
- Arnaud: Can take opportunity to discuss Virtio & plan for next 6 mo. But, this might take >1h.
- Bill: Hope is that ppl will attend & start telling us the problems that they face engaging w/ an AMP system. Need to be prepared in case we don't have questions from the audience.
- Bill, Arnaud & Dan will meet Tue afternoon. Likely Tomas, Nathalie, Loic, Eric will be tied up in LPM.
- Bill, Dan & Arnaud to coordinate for Tue on Discord
- Nathalie: Cancel May 3 call
- Individual updates
- Bill:
- ZCU102 is operational in UK LAVA lab & has run 295 jobs as of this morning. Need to integrate the 2nd UART on ZCU102 & KV260 for it to be a good OpenAMP platform.
- Doxygen integration for OpenAMP docs. Have made a PR for what is likely to get done before mid-May. Arnaud & Tammy can decide if want to wait, or pull it in. It does build on a PR, but the links you get are hardcoded to assume the real content, but nothing is there until the PR lands.
- Tammy
- Submitted PR for function headers. Arnaud commented & approved. Need Ed's approval before merge. Have ben updating over last 2 weeks.
- Arnaud: Will release without Ed's approval if no answer by end of this week.
- Arnaud: Planning to integrate it in this release.
- Submitted PR for function headers. Arnaud commented & approved. Need Ed's approval before merge. Have ben updating over last 2 weeks.
- Bill: Are we OK to tag the 2023.04 doc release in mid-May?
- Arnaud: Can do. We don't specify what repos will be in release. Should we tag system reference?
- Bill: Yes, will tag CI builds & demos. So, the April release might not be done on the other repos until the end of May.
- Arnaud: If we release in April, do we have to release OpenAMP library & libmetal mid-month to give time for releasing the others?
- Bill: No. The others will catch up. Would like to fix the docs & tag the docs & then rebuild everything from the tags & include in the demos. Arnaud should release the libraries & these other tasks will come later.
- Arnaud: We should discuss plan for October.
- Decision: Release openamp, libmetal & system reference. Rest will get tagged later.
- Arnaud: Added Tammy as member of openamp project to review PRs.
- Tammy to review & comment on checkpatch PR
- Arnaud:
- Will share code of intern for virtio MMIO. Use mailing list for discussion of intern's code? Yes.
- Arnaud to discuss w/ intern if should add him to the OpenAMP Discord
- Nathalie: Did we say we were going to move to community channel?
- Bill: Created an openamp-dev private channel on Linaro server & added the contributors.
- Tanmay:
- Focused on RPMsg in U-Boot. Can discuss in OpenAMP-RP call later.
- Have been asked to spend more time reviewing PRs in libraries. Have not had a chance yet, but planning to be more active.
- Hari:
- Was busy with internal product release/builds last couple weeks.
- Tanmay: Example for TI?
- Hari: TI RPMsg char on TI website. Has ping & echo application.
- Bill: TI still using own implementation of RPMsg?
- Hari: Yes
- Tanmay: Extending current work to add RPMsg
- Bill:
- Nathalie: Reminder to please update the tracking sheet https://docs.google.com/spreadsheets/d/1N5eO0FDX-gqpJtBleh_iGn-k9gr3j-w8ByjPFsjIoB4/edit?usp=sharing
- Bill, Tammy, Dan, Nathalie, Nishanth, Bruce, Hari, Arnaud, Tanmay,
- TI Platform
- Arnaud, Tammy: April release topics (e.g. doc update)
- Bill, Nathalie: OpenAMP BOF deck
- Nathalie: Should we update OpenAMP governance page to reflect what we’ve established by the work the System Reference group has done (e.g. docs, CI)
- Nathalie: Are there any tasks we want to track as a group (e.g. where there are interdependencies between devs) for Q2 work? Any work from our webinar tracking sheet that we should continue tracking?
- All: Individual updates
- Let's track April - August tasks for now
- (DONE) Arnaud: Tammy can start with a couple files Pull Request & we can discuss on that concrete example
- (DONE) Bill can schedule a remote working session over Zoom for next week with Tammy, Arnaud, (Ed optional)
- (DONE) Bill will polish up the deck & submit to Connect organizers so that it can be included in the schedule blurb
- (DONE) Nathalie, Bill, Arnaud to update OpenAMP Governance page at Connect to reflect latest project status & practices
- (DONE) Nathalie start a new System Reference tracking sheet til end of August & Nishanth to add a milestone for TI platform
- Bill to share Jailhouse notes with Dan
- TI platform
- BeagleBone AI-64 or BeaglePlay
- AI-64 has many micro controllers, so would likely be the most interesting
- Google summer of code student
- Could generate video encode, decode, camera pipeline & would show lots of interesting communication w/ OpenAMP
- AI-64 has many micro controllers, so would likely be the most interesting
- Nishanth looking at AM62 platform w/ Rust
- M4 can showcase basic communication works
- Gets interesting from BeaglePlay perspective
- BP goes from within to outside the SOC for sensors. To investigate if it adds value.
- BP has 1352 sensor & sensor gateway
- Shows that OpenAMP isn't just tied to C or Linux
- To investigate: Can OpenAMP go beyond SoC? Beagle guys have done their custom protocol on top of grey bus
- Bill: Could be in scope for OpenAMP organization & project. Some discussion if RPMsg over mailbox could be in scope.
- Bill: Was trying to push grey bus inside Linaro for convergence of Virtio IIC & GPIO, but they decided to go with Virtio IIC to keep it simple. We're extending Virtio OpenAMP libs, so Virtio IIC would come into play as testcase. Would be interesting to contrast w/ what Beagle is doing w/ grey bus.
- Nishanth: Looks like lot of duplication, would be good to compare notes.
- BeagleBone AI-64 or BeaglePlay
- Docs update
- Tammy needs input on ticket #477 from Ed & Bill wrt API
- Bill: Looks like most of this effort is in OpenAMP library?
- Tammy: Correct, haven't looked at Libmetal yet
- Arnaud: Tammy can start with a couple files Pull Request & we can discuss on that concrete example
- Bill can schedule a remote working session over Zoom for next week with Tammy, Arnaud, (Ed optional)
- Code freeze is 4/15, but documentation can be accepted later
- Bill: Looked into GitHub Action & Readthedocs automation & Breathe.
- Think you can add Breathe annotations, but the only required are the ones for TOC, which wouldn't be too much work
- Will give Breathe another shot.
- If that doesn't work, will back up to seeing if Readthedocs can build it
- If that doesn't work, will back up to GitHub Action
- Tammy: Tried Breathe, but wasn't successful.
- Bill: Breathe is already integrated on Readthedocs servers. Think if we put it in the config, it will run for us & convert into XML that could be consumed by Sphinx. TBD If will change the formatting.
- Tammy: OK if it changes the formatting
- Bill: Targeting to have something working in automation by end of next week
- Tammy needs input on ticket #477 from Ed & Bill wrt API
-
OpenAMP BOF slides
- Bill will polish up the deck & submit to Connect organizers so that it can be included in the schedule blurb
- Nathalie, Bill, Arnaud to update OpenAMP Governance page at Connect to reflect latest project status & practices
- Nathalie start a new System Reference tracking sheet til end of August & Nishanth to add a milestone for TI platform
- Individual updates
- Bill:
- We have jailhouse working on ZCU102. GIC demo runs & Zephyr on A53 runs.
- Thinking about adding that when re-spin OpenAMP Docker image.
- Jailhouse has a lot of things that weren't upstream 5yrs ago & still not upstream yet :(
- Nishanth: Had upstreamed GIC code to Jailhouse master on TI boards
- Bill: They are still using 5.10 for CI. Found their 5.15 kernel
- Bill to share Jailhouse notes with Dan
- Arnaud:
- Preparing presentation for Connect & will have a board that could demo with during BOF
- Bill: Let's encourage folks to join the first hour, including the demo. 2nd hour will be an OpenAMP F2F meeting. Timing is flexible.
- Intern working on Virtio MMIO: Started to modify some code to add mgmt of mailbox for notification to allocate some space for IPC. Can start FW on coprocessor & probe the Virtio IIC on Linux. Next, have to try Dan's work to extend for Virtio IIC.
- Bill: Hardcoding the features & queue sizes?
- Arnaud: Added shared memory space for virtio MMIO & put address in Linux DT & fill the virtio MMIO when we load the FW. Then virtio MMIO can detect that it's on Virtio IIC & probe the driver. In remoteproc we parse the child node to find virtio MMIO. He should start to work on OpenAMP part this month. For now, wrap everything in Zephyr to enable part of the protocol.
- Can give more details in dedicated virtio call next week
- Tanmay
- Debugging Zephyr
- Xilinx RPMsg driver is upstream now. Patch is accepted for next branch & likely in next release.
- Need to work on attach/detach feature & will upstream later.
- Remoteproc is working & RPMsg is working
- Bill: Marked the story for RPMsg in Jira as done & will close the epic when the 6.4 kernel is released with that support. We can open a new card for attach/detach.
- Nishanth
- Trying to get Rust working. Looked at libmetal in Rust. Is anyone interested in formalizing it? Someone had worked on it 2 yrs back & abandoned it. Should it go into Rust or OpenAMP repo?
- Full Rust implementation of libmetal. Not sure if that will lead to OpenAMP library as well.
- Bill: Expect the libs will evolve a lot over next 2 years. Understand desire for a pure Rust, but it will be playing catch-up for next 2 years. Have you considered wrapping?
- Nishanth: Can shim, but could probably done in pure Rust implementation. Can see how it goes. Is anyone else looking at it?
- Bill: No one has
- Tammy: Update given during docs topic
- Dan: Plan to resurrect VxWorks on R5 cores on ZCU102 w/ OpenAMP support w/ goal to release binary SDK to run VxWorks instead of Zephyr in hypervisorless virtio setup
- Hari: Trying to refactor R5 driver
- TI coming to Connect? John will represent & will touch base w/ OpenAMP
- Bill:
- Bruce, Tomas, Bill, Dan, Arnaud, Tammy, Tanmay, Nathalie
- Bill, Arnaud, Dan: Quick summary of last week’s Virtio spin-off call
- All: Starting on slide deck for OpenAMP BOF presentation (making something short is always harder than making it long…)
- Tammy & Arnaud: Update on docs for 2023.04 release
- Individual updates
- Goal is ~5 slides for 10 min of presentation as intro at BOF
- Decision: Document only within header file
- (DONE) Bill will publish the notes & share the recording from the Virtio spin-off call
- (DONE) Bill to discuss w/ Mathieu about joining the AMP BOF
- (DONE) Bill & Arnaud to reply on doc data structures thread from Tammy
- Arnaud will look at Zephyr for what could be leveraged for automatic checking of pull requests for Doxygen-compatible comments
- (DONE) Nathalie: Make a copy of Dec deck & share to rest of group as editors
- (DONE) Nathalie: Find out call-in capability for Session Room 1
- Tammy will submit a pull request for the input parameters mods (Separate commits for libs & apps & tests. OK to submit in same pull request)
- Bill, Arnaud, Dan: Quick summary of last week’s Virtio spin-off call
- Good kick off meeting but missed Arnaud b/c of daylight savings misalignment
- Bill will publish the notes & share the recording from the Virtio spin-off call
- Logistics: Call time, meeting at Connect
- Upstreaming: What will it take to get upstream on RTOS side
- What threads/chunks of work that can be tackled independently
- All: Starting on slide deck for OpenAMP BOF presentation (making something short is always harder than making it long…)
- Linaro Connect Schedule
- Nathalie: We have the December webinar deck & need to compress it down to 10 min
- Bill:
- Intro, mention the webinar, point to the demos & slides. Focus on what we have done since then & what we plan to do in next 6 months (e.g. Virtio work)
- We can have as many ppl up front as we want
- Bill can add 2 more presenters: Tomas & Arnaud, so we have 3 Linaro members supporting the work
- Arnaud: Mathieu?
- Bill: We should ask him to be there.
- Bill to discuss w/ Mathieu about joining the AMP BOF
- Bill requested 40 min & got 2hrs
- Can have expanded BOF for 1hr
- Then can have an open OpenAMP meeting after (entire OpenAMP, not just system reference)
- Nathalie: What's the room layout? Conducive to discussion or presenter/audience layout?
- Bill: We can move the first few rows of chairs into a circle for the meeting
- Nathalie: Make a copy of Dec deck & share to rest of group as editors
- Goal is ~5 slides for 10 min of presentation as intro at BOF
- Arnaud can also do some demo wrt remoteproc & advertise the BOF at the end of his session (12pm on Thur)
- Bill: This is good b/c it was on the what's next list
- Tomas: Does Session Room 1 allow ppl to call in?
- Bill: Think that room will be really big. We won't make any voting resolutions during this meeting.
- Nathalie: Find out call-in capability for Session Room 1
- Tammy & Arnaud: Update on docs for 2023.04 release
- Input parameters
- Tammy sent Input Parameters modifications email - it didn't display correctly (should have line breaks)
- Tammy: Think the output would be the same
- Arnaud: Would like something readable in the code as much as possible. Think ":" will help
- Tammy: leaning towards indented view
- Tammy: Document only within header files?
- Arnaud: Yes
- Tammy: Not sure if there is script we could put into GH Action. Don't anticipate a lot of mods, so maybe don't need. Can't commit bandwidth.
- Arnaud: Would like to see automatic check to pull request to make sure Doxygen comments are complete & compatible. Would like to avoid running Doxygen to check. But, can start with manual.
- Tammy: Have list of other things to do in long term, maybe after April
- Arnaud: Not expecting for April. Long term is OK. Would like to be able to run a check before releasing libs
- Tammy: Wonder if Zephyr has any policies we can leverage
- Arnaud will look at Zephyr for what could be leveraged for automatic checking of pull requests for Doxygen-compatible comments
- Tammy will submit a pull request for the input parameters mods
- Arnaud: We do separate commits between libs & apps & tests. OK to do in same pull request.
- Data structures: Want a consistent format & update all the data structures to match
- Tammy: Can we remove "Definition at line of <file></file>"? Would like to show the field description instead
- Bill: Think the source references are useful, but doesn't have to be verbose, maybe click?
- Tammy: Can only do what Doxygen allows
- Bill: Maybe if had 1 for the whole structure, the rest of the fields should be defined in the same place.
- Arnaud: Where does clicking on the link take you? Rpmsg.h
- Tammy: It's not sending you to GitHub, it's pointing to local copy on your computer in the HTML Doxygen artifacts.
- Bill: It will be a particular version of OpenAMP, so probably can reference the version it was built with at the top level & let Doxygen do it's references to its pretty-printed source
- Arnaud: Zephyr or TF-M docs can show version per release & point to master
- Bill: Tammy generates HTML for a particular version. Can have multiple versions on website.
- Tammy: Keep the reference to definition? The one under Detailed Description is useful, but can only keep all or delete all. We have the header file & the fields, so doesn't buy you much more.
- Bill, Arnaud: OK to remove. As long as you can find the file the definition is in.
- Tammy: File is there
- Arnaud:
- There is a link at the bottom of the page that gives the path for the file where it is defined. Could be enough.
- TF-M docs do keep the reference to each line
- Bill: Showed Zephyr docs
- Tammy: They have a lot more integrated than just pure doxygen and they show everything (not just what has doxy comments)
- Bill: Our API is small enough. We should set a goal to document everything worth documenting.
- Bill & Arnaud to reply on doc data structures thread from Tammy
- Input parameters
- Tanmay update
- Zephyr demo
- Trying to get RPU-RPU communication. Found a bug & fixed it but can't get call-back ISR for RPU-RPU. Same code works for APU-RPU communication. Debugging.
- Ported 1 demo from upstream OpenAMP System Reference Zephyr example to communicate w/ sample driver w/ Xilinx IPM driver. Works in lock-step mode now. Would like to get APU-RPU & RPU-RPU communication both working.
- Bill: Not limited to lockstep only, just focusing on it - will do split mode for RPU-RPU?
- Tanmay: Not limited. Will do split for RPU-RPU.
- How to synchronize? Platform specific? Address in DT to point resource table?
- Arnaud: ST board Zephyr adds resource table at specific address in specific section. Table is available for Linux from firware load. Don't need to define area in DT, except defining memory region that will register in remoteproc. No DT node to specify address of resource table. How do you specify on AMD distribution?
- Tanmay: Vendor-specific property DT. FW linker script is compiled accordingly for resource table available at specific address.
- Arnaud: Linux is able to get ELF section w/ resource table if you provide good name
- Bill: Finding the resource table is an issue if you pre-load. If you use Linux load, it parses the ELF file.
- Tanmay: Loading through Linux is nota problme. Loading demo when RPU is preloaded, then it'sa problem.
- Bill: OK, you're trying to work out method of pre-loading
- Arnaud: You could define memory region in Linux DT w/ address of resource table & in remoteproc driver, you can get it w/ specific name for resource table address. ST gets it from a SW register. You can get it from DT & provide it in same way.
- Bill: Memory location w/ address of resource table, not table itself.
- Will this be a vendor-specific thing or standard method to synch resource table, via DT?
- Bill: Wouldn't be a bad idea for vendors to opt-into if they want. Having a pattern to follow is good. Having a bare pointer is dangerous, maybe data structure better. Wendy wanted to put version # of FW in there too. Can be indirection.
- Arnaud: It's more reliable to get the address + the size of the resource table. B/c if have to flush the cache, need to know the size.
- Zephyr demo
- Bill update
- Linaro is interested in running Zephyr on A53 & other A cores. 1st crack run Zephyr under Jailhouse. Trying to get Jailhouse on a newer kernel (challenging). Will keep trying 1 more day.
- Zephyr on Xen & maybe on baremetal next
- This as test vehicle for Virtio
- Jailhouse is interesting b/c they need what we're doing for virtio, but Xen doesn't need
- Disappointed with Jailhouse compatibilitiy with upstream kernel
- Tomas: For Xen, even if iti has its own way for doing stuff, Stefano's team is working on virtio solution for automotive.
- Bill: at least Xen hypervisor helps. Jailhouse doesn't provide help, it's almost like hypervisorless virtio.
- Arnaud: NuttX OS has integrated virtio. They are interested in Dan's work in OpenAMP to be able to rebase on OpenAMP virtio framework
- Bill: they want to consume virtio from us?
- Arnaud: Yes
- Dan: They wanted to know how to run the regular virtio support from OpenAMP
- Dan: No updates
- Tammy: No other updates
- Tanmay: Yocto 2022.2 release from Xilinx is up. Contains KV260 support in QEMU. Could consider updating in Docker.
- Bill: in Docker, consumed Xilinx QEMU from Zephyr SDK. Cant use the pre-builts b/c under login. If build myself, it's hard to port b/c sysroot. Will take a look, but might not have a chance before Connect. If not new set of binaries, then updating Zephyr SDK to do both might be 1 way to go.
- Bill, Dan, Nathalie, Arnaud, Hari, Tammy
- Should we break out the virtio discussion to another call w/ the new Linaro virtio resource?
- Linaro Connect:
- Who submitted for the CFP & what topics?
- Bill: OpenAMP BOF (Birds Of a Feather)
- Arnaud: management of the coprocessor firmware in OP-TEE
- Any updates on who is able to attend Connect?
- Should we plan F2F or sprint?
- Who submitted for the CFP & what topics?
- Individual updates on OpenAMP System Reference-related work
- No official "demo day"/"demo hours" at Connect, so may end up joining a demo room during hacking time
- Split virtio technical discussion into a separate call (but hold off on inviting Arnaud's intern for now)
- (DONE) Hari to check with Nishanth if TI is approved for Linaro Connect
- (DONE) Nathalie: Start thread on email regarding OpenAMP F2F at Linaro Connect
- (DONE) Nathalie: Reach out to NXP OpenAMP folks to see if they are attending Linaro Connect
- Virtio breakout w/ new Linaro resource?
- Dan: Interested, let's use another slot. Cadence should be based on how much updates. Let's start w/ kick-off w/ intro & plans. Free next week at 8:30PT (due to daylight async w/ Europe)
- Arnaud intersted & available next week
- Bill will schedule for 9:30am PT next Wed
- Linaro connect submissions
- BOF: Open discussion session
- Requested longer slot (40min)
- 15min: Short intro about what HPP & OpenAMP, point ppl to the Dec webinar materials + Status update of where we are at
- 25min: Open discussion
- Official presenters: Can list those who know we're attending
- Android team will have BOF in hacking room instead of official slot. This is an option for us if we get rejected.
- No official demo time at connect - grass roots session being organized during hacking time (see the high-level schedule of time blocks on the Connect page)
- Dan will be attending
- Hari to check with Nishanth if TI is approved for Linaro Connect
- Tammy's request did not get approved
- Arnaud's session: ST work to capability to authenticate coprocessor FW w/ OP-TEE
- Plan to start the upstreaming of this work
- Trying to do in a generic way & would like to get feedback
- Linux & OP-TEE maintainer can get some intro, so will need to synchronize both
- Detailed schedule publish 3/15. Rough outline schedule
- F2F:
- Bill & Arnaud available Tue
- Or session during hacking time
- Nathalie: Start thread on email regarding OpenAMP F2F at Linaro Connect
- Nathalie: Reach out to NXP OpenAMP folks to see if they are attending Linaro Connect
- BOF: Open discussion session
- Bill update
- Refreshing the demos. Trying to make the container work on Arm-based Mac (Arm native, Double emulation does work)
- Looking at builds
- Linaro working on Jailhouse & running Zephyr in Jailhouse on QEMU and KV260. Had started the work when NXP was asking for it. Will look at doing same thing for Xen.
- Goal: OpenAMP working for Linux in a Xen guest as base. Also useful for the virtio work.
- Arnaud update:
- Have an intern starting on virtio MMIO: Address virtio IIC with virtio MMIO between main & co-processor. Looking at using virtio MMIO in remote processor context.
- Bill: Should we invite ST intern to virtio call?
- Arnaud: Not yet as just started.
- Bill:
- Trying to write up the work we foresee doing as an SOW
- Will share w/ Arnaud & Dan & Stefano once it is drafted
- Will try to do before next Wed call
- Arnaud: Virtio to be addressed in automotive group?
- Bill: 2 projects
- Virtio unification in HPP: Got resourcing. Will decouple from automotive b/c not a high priority for automotive.
- Orka (Alex Benee from QEMU group): improve virtio for Xen using QEMU & Rust. Not specifically looking at AMP
- Bruce, Tanmay, Dan, Nishanth, Nathalie, Tomas, Tammy, Bill, Hari
- What to work on by end of Q2?
- Would be good to sync release of doc & lib for 2023.04.
- Can discuss Google Summer of Code 2024 at end of this year
- (DONE) Bill to put on agenda for RP call in 2 weeks to discuss fixing up of API reference guide (requires touching a lot of files)
- (DONE) Nathalie to reach out to NXP to figure out which calls they want to participate in
- Nathalie: Put in calendar reminders for Google Summer of Code consideration
- Remoteproc & RPMsg
- Tanmay working on ZynqMP upstreaming. Think this will complete in the next quarter. There is the turnaround time to get Mathieu's feedback & then address it.
- Once RPMsg part is upstream, Tanmay can start upstreaming Zephyr part
- Linaro is putting someone on Zephyr for these topics & they will start looking at ZynqMP
- Multi Virtio devices is staged for this year
- RPMSg flow control: if someone gets motivated to tackle, then it may happen. Otherwise not prioritizing.
- Tanmay working on ZynqMP upstreaming. Think this will complete in the next quarter. There is the turnaround time to get Mathieu's feedback & then address it.
- Other VirtIO devices
- Linaro putting an additional engineer on implementing Virtio in OpenAMP libraries. Need to figure out how to coordinate that w/ Dan's work, so that it doesn't all fall to Dan.
- Let's align on specifics (e.g. what types of devices to go after)
- Bill is working on description of work items for the virtio unification project
- Someone working on openamp libraries, testing it in Zephyr
- Include back-end implementation
- In-kernel support would be a different resource, if it gets resourced. TBD.
- Linaro putting an additional engineer on implementing Virtio in OpenAMP libraries. Need to figure out how to coordinate that w/ Dan's work, so that it doesn't all fall to Dan.
- System DT
- System DT used for OpenAMP parts of Yocto
- System DT used for splitting things between Zephyr, baremetal, Linux, etc. Some parts here could be simplified.
- Bruce: Simplification & make it more useful in not too distant future. Likely to complete by end of Q2
- DT comparison & verification will be used to test the further Yocto integration
- Currently adding functionality to map the address ranges, which is framework to get all that info & then it can be used for comparisons & verification
- Think building blocks will be there & put into sample assists
- TBD what interest will drive specific implementations
- CI
- Want something up & operational by end of Q2
- Test coverage TBD, will evolve
- Documentation
- Before we make April release, Bill hopes to work on automation.
- Would be good to sync release of doc & lib for 2023.04.
- Markup in some of the docs was not ideal. Could fix it up to be more consistent, then the API reference guide could be more accurate. Would like to see this happen for April release.
- Will require touching a lot of files in OpenAMP directory & decide on style on where to place (e.g. only in header files) -> The maintainers will have to decide when they want to accept it.
- Tammy will see if can get some time before April to work on docs
- Bill to put on agenda for RP call in 2 weeks to discuss fixing up of API reference guide (requires touching a lot of files)
- Nishanth: Hari & I looking at Beagle AI64. TBD if there is an intersection point. A72, C7, C6, R5 heterogeneous system. Considering another low-cost board that is simpler.
- Bill: R5 are easiest target for demo. Bringing in DSPs pulls in proprietary toolchain & RTOS support.
- Nishanth: Looking at Zephyr for R5. Bit early from demo perspective to step in.
- Bill: Some of the demos just need R5, GICv2, GICv3, UART, which basic support is there for.
- Nathalie to reach out to NXP to figure out which calls they want to participate in
- Nishanth: Are we involved in any Google Summer of Code projects? Starting conversation wrt Beagle.
- Bill: Getting Zephyr ported to AI64 on R5 might be too small. Maybe need some stretch goals.
- Nishanth: Looking at some other heterogeneous type projects.
- Bill: We haven't done that before, but can consider for 2024.
- Nishanth: We started planning for it in January. Early Feb is deadline for foundations to present their proposals. Then project acceptance deadline is coming up in a few weeks.
- Nathalie: Put in calendar reminders for Google Summer of Code consideration
- Bill, Tomas, Hari, Dan, Tammy, Tanmay, Nathalie
- Linaro Connect CFP is March 1, so we should sketch BOF / demo proposal outline this call & finalize in our next call
- Does the date for next TSC make sense? Reasoning was to be able to discuss Virtio proposal after Linaro had a chance to discuss internally. Also, Arnaud OOO on that date (but then Loic not available later in the poll, so would have to push out several weeks)
- Tanmay: zephyr ipm driver for zynqmp platform. First draft is here: https://github.com/TanmayShah-xilinx/zephyr-openamp-staging/commit/064807297f332f9cd9f9dfb7b5a795c7170ea66a
- Individual updates
- Let's keep the TSC meeting date as-is
- Tanmay can create the pull request and further discussion can happen there
- Let's try to make an ongoing roadmap - quarter by quarter targets
- Everyone: For next call: What does everyone want to get done in the next quarter? Can refer to Dec webinar future work slides to seed your thinking.
- (DONE) Bill will start a BOF proposal slide deck w/ title & exec summary and send out for review later this week
- Bill will send an email to the board list asking for any objections for the expenditure for Docker, readthedocs, and GitHub upgrade
- Nathalie: Invite Stefano to TSC give an update on System DT, Bruce as back-up
- (DONE) Tanmay: Create pull request RFC for Zephyr IPM driver for ZynqMP with overlay for default UART change
- Linaro Connect CFP BOF
- Title & Description should be pretty easy
- There is a place to drop slides - maybe PDF outline of what we're planning
- List of co-presenters: Not huge list, but a couple names: Tomas, Bill, Arnaud?, Dan?
- Bill will start a BOF proposal slide deck w/ title & exec summary and send out for review later this week
- TSC date
- Some internal discussions at Linaro have happened
- Bill updated the presentation to v1.1 w/ more automotive context
- Don't think resourcing will sort out in Feb
- Mathieu can commit some time to review, would like to do more but not sure if that would be possible
- RTOS execution resource in Zephyr context needs to be worked out
- While Arnaud is not available, Loic is the voting member from ST and he responded as available on that date
- Let's go ahead with the TSC date
- Nathalie: Invite Stefano to TSC give an update on System DT, Bruce as back-up
- Tanmay: Zephyr ipm driver
- Trying to get system reference ZynqMP platform example
- Found this driver was missing. Created basic version
- Showed demo running
- Printing physical data buffer directly
- App code: Works fine when compiled for RPU0. When compile for RPU1, firmware on RPU1 is crashing when call into Zephyr library. Think some special linking is needed for RPU1 b/c code should not be accessing same memory region, need to figure out.
- Will create pull request for code as-is to openamp-staging. Do we need to wait for RPU1 issue to be resolved?
- Bill: Suggest to create the pull request so it's easy to find the work, mark as RFC.
- Dan: Check the MPU if you can access that memory. I had to move some of my text sections somewhere else & enlarge size of area that RPU able to access. Default is 64MB & rest is protected. Not sure what RPU1 address is…
- Dan: Do you have timer support, k_sleep?
- Tanmay: Yes
- Dan: Test if k_sleep works. Could try busy wait version.
- Tanmay: Tried replacing w/ busy loop. Still didn't get ipm_callback - doesn't seem to be registered w/ driver. RPU can ping APU but callback not working for RPU1.
- Dan: Gut feeling is that it doesn't seem like memory access issue
- Hari: In same cluster?
- Tanmay: Yes. Saw K3 R5. Is there Zephyr?
- Hari: There is interest, but not supported w/ RPMsg yet.
- Tanmay: Think this will work for Dan b/c have callback for RPU0
- Tanmay: Where to create PR against?
- Dan: Main of Zephyr, ideally upstream Zephyr.
- Bill: Can't change the default UART for upstream Zephyr. Would have to create overlay.
- Tanmay: Create overlay for default UART change.
- Tanmay: Should be OK for lockstep mode b/c don't use 2 RPUs
- Bill: Linaro has an engineer working to create memory map for R5, which will help this a lot. Think the IPI stuff here is good.
- Tanmay: Made change in DTS for zynqmp-ipi, based on Linux DT bindings - not sure if should have these or leave it out of this patch. Ideally this would be generated from System DT.
- Bill: System DT won't be upstream in near term, so need a solution before then.
- Tanmay: to create the pull request & we can discuss there
- Bill update: Fixed the openamp GitHub billing ($5/mo). Looking to get Docker & readthedocs more official status
- Bill will send an email to the board list asking for any objections for the expenditure for Docker, readthedocs, and GitHub upgrade
- Tomas: December demo had some work that was rushed to make it work (e.g. DT + Yocto). Do we have plan for next step for demo & list of what to fix up?
- Bill:
- Not yet. Good idea to start doing that.
- Presentation has next steps, so we can continue along those lines.
- Would be great to get TI & NXP in the next demo.
- Tomas: Sometimes good to set a date and get ppl to sign up to shoot for that, so we have a roadmap that we can try to resource.
- Bill: Instead of big bang demo, let's shoot for continuous roadmap. Even goals per quarter would be appropriate.
- For next call: What does everyone want to get done in the next quarter? Can refer to Dec webinar future work slides to seed your thinking.
- Bill:
- Dan, Tanmay, Tammy, Nathalie, Hari, Arnaud, Bill
- Welcome Hari & what is System Reference working group doing?
- Who's going to Linaro Connect? Possibility of Tue afternoon/evening F2F for OpenAMP?
- Demo/BOF at Linaro Connect?
- Which Discord to use?
- HPP plans for 2023
- GitHub, Docker, Readthedocs
- Posting materials from Dec webinar
- Move over to Linaro server OpenAMP community Discord
- (OBSOLETE) Hari will check with Praneeth if could get travel budget
- (DONE) Bill will ask Linaro Events if the static link will generate stats or if we only track users landing on the resource page
- (DONE) Bill will ask Linaro Events if they will allow us to post the video on OpenAMP YouTube channel so that we can add a TOC
- (OBSOLETE) Nathalie to check the membership contract to see if assignees are required to attend Linaro Connect.
- (DONE) Nathalie to increase text that is hyperlinked to make it easier to see & explain how to download the slides from the resource page
- Welcome Hari
- TI for 15 yrs, different role in pre-silicon development
- Back in remoteproc/RPMsg team, will work on upstreaming
- What is System Reference working group doing?
- Examples to run on different vendor platforms w/o vendor toolchain/SDK
- Using OpenAMP library
- Trying to use upstream kernel, Zephyr as lead RTOS
- Maybe of interest to TI: Could show both TI & OpenAMP RPMsg implementation so customers have a path to intersect
- Who's going to Linaro Connect?
- Bill (will be around Tuesday), Arnaud (if can resolve conflict), Nathalie & Tomas (might be tied up in member meetings)
- Tammy: If paper gets accepted
- Dan: Think it would be a good opportunity to meet F2F & will try to convince management
- Tanmay: Unknown
- Nathalie to check the membership contract to see if assignees are required to attend Linaro Connect.
- Hari will check with Praneeth if could get travel budget
- TBD if there will be demo session on Connect schedule. If so, not the usual full afternoon on last day. Likely to be different day ~1.5h if it happens.
- Arnaud: Should we plan for something at Connect if there are demos?
- Bill: Yes, something that would fit into a lightning talk (~10 min with ~1-2 min demo) and we may propose to do a BOF that starts with the lightning talk then open up for Q/A/discussion.
- Nathalie: Believe proposals are due March 1
- Should we keep private Discord organized by Arnaud or use Linaro OpenAMP Discord? Doesn't make sense to keep 2 servers.
- Arnaud: If we need private discussion, we can always spin up a private thread or email. Prefer to move to the public chat.
- Bill: We have openamp-system, documentation, general. In Linaro, we just have openamp-community. We could create openamp-dev, openamp-documentation, etc. on Linaro server if we want.
- The link for joining the OpenAMP community Discord on Linaro server is https://discord.gg/8quFQBWq42
- Bill: HPP for 2023
- Finish up leftovers from last year
- We wanted to create generic reference platform in QEMU, which could be interesting but unclear if we would get help with that. TBD if will keep that task.
- Virtio unification project that was shared at Linaro TSC & will present to LEDGE next week.
- Will present HPP roadmap once it is more firm
- Bill: GitHub, Docker, Readthedocs fees
- Dec demo was using Bill's personal GitHub for Docker b/c using large file extension. Requires $5/mo to get the extension. Would like to move that over to OpenAMP billing - working on figuring out how to charge it to the project via Linaro.
- Updated GitHub billing contact from Ed to Bill
- OpenAMP Docker account is free account run by Bill. For redundancy, may be better to switch over to a team account to have other owners, which requires upgrade to team tier. Will look at this more once we figure out the GitHub billing.
- Linaro vs. OpenAMP team in DockerHub: Prefer to have the Docker download path to have OpenAMP branding, so rather keep it to OpenAMP project instead of all Linaro community projects
- Bill will look into moving readthedocs from personal account to OpenAMP project
- Nathalie: Blog post on system reference presentation
- Access to PDF - can it be downloaded directly from Linaro? Yes
- https://static.linaro.org/assets/2022-12-13_OpenAMP_HPP_webinar_full_deck.pdf
- Bill will ask Linaro Events if the static link will generate stats or if we only track users landing on the resource page
- Nathalie to increase text that is hyperlinked to make it easier to see & explain how to download the slides from the resource page
- Access to PDF - can it be downloaded directly from Linaro? Yes
- System Reference webinar video
- YouTube could allow us to put in a TOC or we could split up into multiple videos for each section and post those
- Bill will ask Linaro Events if they will allow us to post the video on OpenAMP YouTube channel so that we can add a TOC
- Arnaud, Nathalie, Tanmay, Dan
- Nathalie: Scheduling 2023 meeting series
- All: Discuss brainstorm list on what makes sense to work on next
- Let's start the meeting series next week, 1hr slot at the usual time
- (DONE) Dan to send Tanmay link about mailbox
- (DONE) Tanmay to share link to Xilinx GitHub for FreeRTOS on R5 example -> On discord
- Scheduling 2023 meeting series
- Dan's conflict: If we start next week & go on 2 week cadence, it should be fine
- Works for Arnaud & Tanmay
- Discuss brainstorm list on what makes sense to work on next
- Added Tanmay's goal to the brainstorm list Google Doc for making Zephyr demo work on AMD Xilinx platform
- Dan:
- https://github.com/OpenAMP/zephyr-openamp-staging/blob/virtio-exp/samples/virtio/hvl_net_rng_reloc/src/xlnx_ipi.c
- https://github.com/danmilea/hypervisorless_virtio_zcu102/tree/main/zephyr_r5
- Dan:
- Arnaud mentioned the virtio convergence proposal. Dan would like to see demo on HW instead of QEMU. Also added notes on this to the brainstorm list Google Doc.
- Added Tanmay's goal to the brainstorm list Google Doc for making Zephyr demo work on AMD Xilinx platform
- Bill presented slides created with ST & AMD Xilinx to Linaro TSC about creating blueline of convergence of virtio remoteproc implementation & virtio generic implementation for virtual machine
- Related to the work that Dan started, to have something generic that works for both cases
- Would like virtio working for both
- With transport layer, Virtio MMIO
- Also virtio client
- Specification to add RPMsg
- Linaro will discuss and get back to us
- Likely will influence work in System Reference working group
- Dan: Would like to provide demos that work on HW instead of QEMU
- Arnaud will have an intern for 6 months to help on this work in March (communication between Linux & Zephyr)
- Dan: Are there any other options for open source OS to run on R5 instead of Zephyr?
- Tanmay: FreeRTOS is supported on R5. Provide examples in PetaLinux that builds & runs with FreeRTOS. Available on Xilinx GitHub. Also bare metal, which is in OpenAMP repo.