Adding a 30 min sync in the alternate weeks between our main sync, leading up to the November webinar.
November 2022 webinar planning document in OpenAMP Google Drive (limited access)<https://docs.google.com/document/d/1aje8wThv7pKdJ5tvX0SNncJtK1YtigFgyXpxhvO…>
[https://st2.zoom.us/static/6.2.8460/image/new/ZoomLogo_110_25.png]<https://zoom.us/>
Hi there,
Nathalie Chan King Choy is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting<https://xilinx.zoom.us/j/91782323144?pwd=SDAxbUZLSWQ1akEvek9tY0dUcWZsZz09&f…>
Phone one-tap:
US: +17209289299,,91782323144#,,,,,,0#,,8593217354#<tel:+17209289299,,91782323144#,,,,,,0#,,8593217354#> or +19292056099,,91782323144#,,,,,,0#,,8593217354#<tel:+19292056099,,91782323144#,,,,,,0#,,8593217354#>
Meeting URL:
https://xilinx.zoom.us/j/91782323144?pwd=SDAxbUZLSWQ1akEvek9tY0dUcWZsZz09&f…
Meeting ID:
917 8232 3144
Passcode:
fp$3QJysed
Join by Telephone
For higher quality, dial a number based on your current location.
Dial:
US: +1 720 928 9299 or +1 929 205 6099 or +1 669 900 6833 or 833 548 0276 (Toll Free) or 833 548 0282 (Toll Free) or 877 853 5257 (Toll Free) or 888 475 4499 (Toll Free)
India: +91 226 480 2722 or +91 22 71 279 525 or +91 406 480 2722 or +91 446 480 2722 or +91 806 480 2722 or +91 80 71 279 440 or +91 116 480 2722 or +91 22 48 798 004 or +91 224 879 8012 or +91 225 097 2744 or +91 225 097 2745 or 000 800 001 4002 (Toll Free) or 000 800 050 5050 (Toll Free)
Ireland: +353 1 653 3895 or +353 6 163 9031 or +353 1 536 9320 or 1800 943 965 (Toll Free) or 1800 949 238 (Toll Free) or 1800 901 561 (Toll Free)
Singapore: +65 3158 7288 or +65 3165 1065 or 800 101 3814 (Toll Free) or 800 852 6054 (Toll Free) or 1800 407 5602 (Toll Free)
Meeting ID:
917 8232 3144
Passcode:
8593217354
International numbers<https://xilinx.zoom.us/u/acpYowtZ5>
Join from a Video Conference room system
Meeting ID:
917 8232 3144
Passcode:
8593217354
US:
91782323144(a)global.zoomcrc.com<mailto:91782323144@global.zoomcrc.com>
Passcode:
8593217354
APAC:
91782323144(a)global.zoomcrc.com<mailto:91782323144@global.zoomcrc.com>
Passcode:
8593217354
India:
91782323144(a)global.zoomcrc.com<mailto:91782323144@global.zoomcrc.com>
Passcode:
8593217354
Europe:
91782323144(a)global.zoomcrc.com<mailto:91782323144@global.zoomcrc.com>
Passcode:
8593217354
SIP:
91782323144(a)zoomcrc.com<mailto:91782323144@zoomcrc.com>
Passcode:
8593217354
Hi all,
Please let us know if you have specific topics for this week's OpenAMP System Reference call. Here's what I have so far:
* Is 1st half of November still looking good for a demo?
* November demo:
* What to convey?
* What should it include?
* What work needs to happen to support that?
* Individual updates
For the November demo discussion, here is an outline that can be helpful (we don't have to use it, but it can be a starting point):
Who is our target audience?
Target audience
e.g. System architect
e.g. RTOS vendor
???
Need/pain/application
How could they benefit from OpenAMP?
What is their alternative to OpenAMP?
Why makes OpenAMP better suited to their needs?
Webinar plan
* What is expected state of audience coming into the webinar?
* What is desired state of the audience after viewing the webinar?
* Call to action:
* What should they do next?
* Why should they do this? (i.e. what's the benefit for them?)
* Top 3 key takeaways
* What are the sections of the webinar? For example:
* Intro (Why OpenAMP slides) + what's in today's demo
* Demo 1: ??
* Demo 2: ??
* CTA:
* Try it out, here's where to find the stuff & how to give feedback
* Get involved, here's how
* Summary of takeaways/Conclusion
Work breakdown
* Getting the webinar scheduled/advertised
* Slides
* Demo 1
* Demo 2
* Demo N
* Repositories
* Documentation
* Any other top level tasks to break down, or better way to categorize the tasks?
Thanks & regards,
Nathalie
Hi all,
Notes from yesterday's call can be found at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… .
Action items from this call:
* @arnaud.pouliquen@st.com<mailto:arnaud.pouliquen@st.com>: Check if ST has parts w/ hard-wired Ethernet.
* @Bill Mills<mailto:bill.mills@linaro.org>: ask if others in Linaro know more on Zephyr certification project status.
* @Chan King Choy, Nathalie<mailto:nathalie.chan-king-choy@amd.com>: Send email to Board when we should meet again & put social channels on the agenda
* @Milea, Danut Gabriel (Danut)<mailto:Danut.Milea@windriver.com>: The required mods to use UART for R5 are in one of our Zephyr repos. In a DT overlay somewhere. Can check & share.
Best regards,
Nathalie
Hi all,
Calling for agenda items. Here's what I have so far:
* Individual updates
* 7/6 call: Dan will be OOO 7/6 & other US folks might be taking holidays that week due to the long weekend. Options:
* A) Keep it?
* B) Push out the 7/6 call by a week, reconvene on 7/13
* C) Cancel 7/6, reconvene on 7/20
Thanks & regards,
Nathalie
On 6/9/22 10:33 AM, Rob Herring wrote:
> On Tue, Jun 07, 2022 at 10:32:48AM -0700, Tanmay Shah wrote:
>> Hi Rob,
>>
>> Ping for reviews.
> No need to ping me. You can check status of your patch here:
>
> https://patchwork.ozlabs.org/project/devicetree-bindings/list/
>
> If it is listed, Krzysztof or I will get to it.
Thanks for the link. This is good to know.
> Rob
HI Rob,
Thanks for reviews. Please find my comments below.
On 6/9/22 10:41 AM, Rob Herring wrote:
> On Fri, Jun 03, 2022 at 08:33:13AM +0200, Peter Korsgaard wrote:
>>>>>>> "Tanmay" == Tanmay Shah <tanmay.shah(a)xilinx.com> writes:
>> Hi,
>>
>> > Xilinx ZynqMP platform has dual-core ARM Cortex R5 Realtime Processing
>> > Unit(RPU) subsystem. This patch adds dt-bindings for RPU subsystem
>> > (cluster).
>>
>> > Signed-off-by: Tanmay Shah <tanmay.shah(a)xilinx.com>
>> > ---
>>
>> > Changes in v8:
>> > - Add 'items:' for sram property
>>
>> > Changes in v7:
>> > - Add minItems in sram property
>>
>> > Changes in v6:
>> > - Add maxItems to sram and memory-region property
>>
>> > Changes in v5:
>> > - Add constraints of the possible values of xlnx,cluster-mode property
>> > - fix description of power-domains property for r5 core
>> > - Remove reg, address-cells and size-cells properties as it is not required
>> > - Fix description of mboxes property
>> > - Add description of each memory-region and remove old .txt binding link
>> > reference in the description
>>
>> > Changes in v4:
>> > - Add memory-region, mboxes and mbox-names properties in example
>>
>> > Changes in v3:
>> > - None
>>
>> > .../bindings/remoteproc/xlnx,r5f-rproc.yaml | 130 ++++++++++++++++++
>> > include/dt-bindings/power/xlnx-zynqmp-power.h | 6 +
>> > 2 files changed, 138 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
>>
>> > diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
>> > new file mode 100644
>> > index 000000000000..adfe05ff157a
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,r5f-rproc.yaml
>> > @@ -0,0 +1,132 @@
>> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> > +%YAML 1.2
>> > +---
>> > +$id: http://devicetree.org/schemas/remoteproc/xlnx,r5f-rproc.yaml#
>> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> > +
>> > +title: Xilinx R5F processor subsystem
>> > +
>> > +maintainers:
>> > + - Ben Levinsky <ben.levinsky(a)xilinx.com>
>> > + - Tanmay Shah <tanmay.shah(a)xilinx.com>
>> > +
>> > +description: |
>> > + The Xilinx platforms include a pair of Cortex-R5F processors (RPU) for
>> > + real-time processing based on the Cortex-R5F processor core from ARM.
>> > + The Cortex-R5F processor implements the Arm v7-R architecture and includes a
>> > + floating-point unit that implements the Arm VFPv3 instruction set.
>> > +
>> > +properties:
>> > + compatible:
>> > + const: xlnx,zynqmp-r5fss
>> > +
>> > + xlnx,cluster-mode:
>> > + $ref: /schemas/types.yaml#/definitions/uint32
>> > + enum: [0, 1, 2]
>>
>> A textual mode ("dual", "lock-step", "single") would be more readable.
>>
>>
>> > + description: |
>> > + The RPU MPCore can operate in split mode(Dual-processor performance), Safety
>>
>> space missing before "(Dual-processor"
>>
>>
>> > + lock-step mode(Both RPU cores execute the same code in lock-step,
>> > + clock-for-clock) or Single CPU mode (RPU core 0 can be held in reset while
>>
>> "can be" sounds a bit weak, perhaps "is"
>>
>>
>> > + core 1 runs normally). The processor does not support dynamic configuration.
>> > + Switching between modes is only permitted immediately after a processor reset.
>> > + If set to 1 then lockstep mode and if 0 then split mode.
>> > + If set to 2 then single CPU mode. When not defined, default will be lockstep mode.
>>
>> This looks a bit confusing. If you decide to stick to the numerical
>> modes, then at least list them in numerical order, E.G.:
>>
>> 0: split
>> 1: lockstep
>> 2: single
I think the description is fine. for readability I can just add
numerical order as above.
> The bigger issue has been multiple Cortex-R5 bindings all doing their
> own thing for this feature which is not vendor specific (except TI has
> their own extra mode or something). How TCMs are described is the
> other issue. I've just stopped caring because no one listens.
Values used for cluster-mode property for xlnx platform is same as ti's
cluster mode property.
0: split, 1: lockstep and 2: single-cpu mode. It is matching with
ti,k3-r5 bindings.
However, default value for some of the ti platforms are different.
xlnx platforms have single-cpu mode as well.
It will take some time to design system-dt spec for TCM.
So, for now I use hard-code values of TCM from driver.
TCM bindings for linux will be posted once system-dt spec is accepted.
Meanwhile we would like to upstream rest of the bindings and driver.
>
>>> +
>> > +patternProperties:
>> > + "^r5f-[a-f0-9]+$":
>> > + type: object
>> > + description: |
>> > + The RPU is located in the Low Power Domain of the Processor Subsystem.
>> > + Each processor includes separate L1 instruction and data caches and
>> > + tightly coupled memories (TCM). System memory is cacheable, but the TCM
>> > + memory space is non-cacheable.
>> > +
>> > + Each RPU contains one 64KB memory and two 32KB memories that
>> > + are accessed via the TCM A and B port interfaces, for a total of 128KB
>> > + per processor. In lock-step mode, the processor has access to 256KB of
>> > + TCM memory.
>> > +
>> > + properties:
>> > + compatible:
>> > + const: xlnx,zynqmp-r5f
>> > +
>> > + power-domains:
>> > + description: RPU core PM domain specifier
>> > + maxItems: 1
>>
>> A bit more detail would be good, E.G. something like arm/cpus.yaml does:
>>
>> List of phandles and PM domain specifiers, as defined by bindings of the
>> PM domain provider (see also ../power_domain.txt).
>>
>> And the phandle-array ref.
> Both suggestions are wrong. We don't need common properties re-described
> by every user. They already have a type definition too, so we don't need
> to repeat phandle-array ref either.
>
> The existing description is not needed either as it doesn't provide any
> information specific to this binding. You only need to describe each
> entry when there is more than 1 entry because we need to know what each
> entry is and the order.
I will remove current description as well.
Thanks.
>
>>> +
>> > + mboxes:
>> > + minItems: 1
>> > + items:
>> > + - description: mailbox channel to send data to RPU
>> > + - description: mailbox channel to receive data from RPU
>> > +
>> > + mbox-names:
>> > + minItems: 1
>> > + items:
>> > + - const: tx
>> > + - const: rx
>>
>> And here as well for mailbox/mailbox.txt
> Nope!
>
>>
>> > +
>> > + sram:
>> > + $ref: /schemas/types.yaml#/definitions/phandle-array
>> > + minItems: 1
>> > + maxItems: 8
>> > + items:
>> > + maxItems: 1
>> > + description: |
>> > + phandles to one or more reserved on-chip SRAM regions. Other than TCM,
>> > + the RPU can execute instructions and access data from, the OCM memory,
>> > + the main DDR memory, and other system memories.
>>
>> Drop the comma after "from"
>>
>>
>> > +
>> > + The regions should be defined as child nodes of the respective SRAM
>> > + node, and should be defined as per the generic bindings in,
>>
>> Drop the comma after "in"
>>
>>
>> > + Documentation/devicetree/bindings/sram/sram.yaml
>> > +
>> > + memory-region:
>> > + description: |
>> > + List of phandles to the reserved memory regions associated with the
>> > + remoteproc device. This is variable and describes the memories shared with
>> > + the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
>> > + vrings, ...). This reserved memory region will be allocated on DDR memory.
>>
>> s/on DDR/in DDR/
>>
>> > + minItems: 1
>> > + maxItems: 8
>> > + items:
>> > + - description: region used for RPU firmware image section
>> > + - description: vdev buffer
>> > + - description: vring0
>> > + - description: vring1
>> > + additionalItems: true
>> > +
>> > + required:
>> > + - compatible
>> > + - power-domains
>> > +
>> > + unevaluatedProperties: false
>> > +
>> > +required:
>> > + - compatible
>> > +
>> > +additionalProperties: false
>> > +
>> > +examples:
>> > + - |
>> > + r5fss: r5fss {
>> > + compatible = "xlnx,zynqmp-r5fss";
>> > + xlnx,cluster-mode = <1>;
>> > +
>> > + r5f-0 {
>> > + compatible = "xlnx,zynqmp-r5f";
>> > + power-domains = <&zynqmp_firmware 0x7>;
>> > + memory-region = <&rproc_0_fw_image>, <&rpu0vdev0buffer>, <&rpu0vdev0vring0>, <&rpu0vdev0vring1>;
>> > + mboxes = <&ipi_mailbox_rpu0 0>, <&ipi_mailbox_rpu0 1>;
>> > + mbox-names = "tx", "rx";
>> > + };
>> > +
>> > + r5f-1 {
>> > + compatible = "xlnx,zynqmp-r5f";
>> > + power-domains = <&zynqmp_firmware 0x8>;
>> > + memory-region = <&rproc_1_fw_image>, <&rpu1vdev0buffer>, <&rpu1vdev0vring0>, <&rpu1vdev0vring1>;
>> > + mboxes = <&ipi_mailbox_rpu1 0>, <&ipi_mailbox_rpu1 1>;
>> > + mbox-names = "tx", "rx";
>> > + };
>> > + };
>> > +...
>> > diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h b/include/dt-bindings/power/xlnx-zynqmp-power.h
>> > index 0d9a412fd5e0..618024cbb20d 100644
>> > --- a/include/dt-bindings/power/xlnx-zynqmp-power.h
>> > +++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
>> > @@ -6,6 +6,12 @@
>> > #ifndef _DT_BINDINGS_ZYNQMP_POWER_H
>> > #define _DT_BINDINGS_ZYNQMP_POWER_H
>>
>> > +#define PD_RPU_0 7
>> > +#define PD_RPU_1 8
>> > +#define PD_R5_0_ATCM 15
>> > +#define PD_R5_0_BTCM 16
>> > +#define PD_R5_1_ATCM 17
>> > +#define PD_R5_1_BTCM 18
>> > #define PD_USB_0 22
>> > #define PD_USB_1 23
>> > #define PD_TTC_0 24
>> > --
>>
>> > 2.25.1
>>
>>
>> --
>> Bye, Peter Korsgaard
>>