- System-dt - lists.openampproject.org

by Tomas Evensen

Here is a link to the presentation from the Linaro Tech Days: https://static.linaro.org/connect/ltd20/presentations/LTD20-205-0.pdf We will focus the discussion on firewalls and lopper feedback. Thanks, Tomas From: System-dt <system-dt-bounces(a)lists.openampproject.org> on behalf of Nathalie Chan King Choy via System-dt <system-dt(a)lists.openampproject.org> Reply-To: Nathalie Chan King Choy <nathalie(a)xilinx.com> Date: Saturday, April 4, 2020 at 2:07 PM To: "'system-dt(a)lists.openampproject.org'" <system-dt(a)lists.openampproject.org> Subject: [System-dt] System Device Tree call CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. [Please see below for NEW Zoom info due to Apr 5 onward Zoom password requirement] Hi all, Tomas and Stefano will be presenting about System Device Tree during the Linaro Tech Days (free registration)<https://www.eventbrite.co.uk/e/99529015966/> on Wed March 25th at 6pm GMT. The current plan is for them to address the FAQ mentioned in the action items below. So, we are holding the System DT call as a follow-on to that session. The notes from the previous call (Feb 13) can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2020#2020F… Action items from the Feb 13 call: * Stefano: review memory & reserved memory to make sure it's consistent * Tomas/Stefano: We should add FAQ to the System DT write-up * Tomas: Ask Bruce to send out Lopper more widely, even if draft, soon (Going through Xilinx open sourcing process) * Tomas: Drive documenting Xilinx internal discussion on firewalls & share * All: Please share your ideas & then we can discuss a proposal * Nathalie: Put on next call agenda to continue to discuss configuration lifecycle next meeting For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/system-dt For information about the System Device Trees effort, including a link to the intro presentation from Linaro Connect SAN19: https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Nathalie Chan King Choy is inviting you to a scheduled Zoom meeting. Topic: System DT call Time: Apr 6, 2020 08:00 AM Pacific Time (US and Canada) Join Zoom Meeting https://zoom.us/j/240197036?pwd=eUgvbC9RVnNoYjQyQUo1TTIzZ2lQQT09 Meeting ID: 240 197 036 Password: 066304 One tap mobile +16465588656,,240197036# US (New York) +16699009128,,240197036# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) +1 778 907 2071 Canada +1 438 809 7799 Canada +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +46 850 539 728 Sweden +46 8 4468 2488 Sweden +46 8 5050 0828 Sweden +46 8 5050 0829 Sweden +46 8 5052 0017 Sweden +44 208 080 6592 United Kingdom +44 330 088 5830 United Kingdom +44 131 460 1196 United Kingdom +44 203 481 5237 United Kingdom +44 203 481 5240 United Kingdom +44 208 080 6591 United Kingdom +33 7 5678 4048 France +33 1 7037 2246 France +33 1 7037 9729 France +33 1 7095 0103 France +33 1 7095 0350 France +39 021 241 28 823 Italy +39 069 480 6488 Italy +39 020 066 7245 Italy +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 240 197 036 Password: 066304 Find your local number: https://zoom.us/u/aejwWZq86k -- System-dt mailing list System-dt(a)lists.openampproject.org https://lists.openampproject.org/mailman/listinfo/system-dt

6 years, 1 month

1
0
0 0

System Device Tree call

by Nathalie Chan King Choy

[Please see below for NEW Zoom info due to Apr 5 onward Zoom password requirement] Hi all, Tomas and Stefano will be presenting about System Device Tree during the Linaro Tech Days (free registration)<https://www.eventbrite.co.uk/e/99529015966/> on Wed March 25th at 6pm GMT. The current plan is for them to address the FAQ mentioned in the action items below. So, we are holding the System DT call as a follow-on to that session. The notes from the previous call (Feb 13) can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2020#2020F… Action items from the Feb 13 call: * Stefano: review memory & reserved memory to make sure it's consistent * Tomas/Stefano: We should add FAQ to the System DT write-up * Tomas: Ask Bruce to send out Lopper more widely, even if draft, soon (Going through Xilinx open sourcing process) * Tomas: Drive documenting Xilinx internal discussion on firewalls & share * All: Please share your ideas & then we can discuss a proposal * Nathalie: Put on next call agenda to continue to discuss configuration lifecycle next meeting For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/system-dt For information about the System Device Trees effort, including a link to the intro presentation from Linaro Connect SAN19: https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community Nathalie Chan King Choy is inviting you to a scheduled Zoom meeting. Topic: System DT call Time: Apr 6, 2020 08:00 AM Pacific Time (US and Canada) Join Zoom Meeting https://zoom.us/j/240197036?pwd=eUgvbC9RVnNoYjQyQUo1TTIzZ2lQQT09 Meeting ID: 240 197 036 Password: 066304 One tap mobile +16465588656,,240197036# US (New York) +16699009128,,240197036# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) +1 778 907 2071 Canada +1 438 809 7799 Canada +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +46 850 539 728 Sweden +46 8 4468 2488 Sweden +46 8 5050 0828 Sweden +46 8 5050 0829 Sweden +46 8 5052 0017 Sweden +44 208 080 6592 United Kingdom +44 330 088 5830 United Kingdom +44 131 460 1196 United Kingdom +44 203 481 5237 United Kingdom +44 203 481 5240 United Kingdom +44 208 080 6591 United Kingdom +33 7 5678 4048 France +33 1 7037 2246 France +33 1 7037 9729 France +33 1 7095 0103 France +33 1 7095 0350 France +39 021 241 28 823 Italy +39 069 480 6488 Italy +39 020 066 7245 Italy +49 695 050 2596 Germany +49 69 7104 9922 Germany +49 30 5679 5800 Germany Meeting ID: 240 197 036 Password: 066304 Find your local number: https://zoom.us/u/aejwWZq86k

6 years, 1 month

1
0
0 0

Re: [System-dt] Calling for agenda items: System Device Tree call

by Frank Rowand

On 3/31/20 3:47 PM, Nathalie Chan King Choy via System-dt wrote: > Hi all, > > > > Please send your suggestions for agenda items for the upcoming call on Monday. So far I have: Did the call move from Wednesday to Monday in general? -Frank > > * Continue to discuss configuration lifecycle > * Follow up from the System DT FAQ talk during Linaro Tech Days > > > > Thanks & regards, > > Nathalie > > > > -----Original Appointment----- > *From:* Nathalie Chan King Choy > *To:* Nathalie Chan King Choy; 'system-dt(a)lists.openampproject.org' > *Subject:* System Device Tree call > *When:* Monday, April 6, 2020 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada). > *Where:* zoom > > > > Hi all, > > > > Tomas and Stefano will be presenting about System Device Tree during the Linaro Tech Days (free registration) <https://www.eventbrite.co.uk/e/99529015966/> on Wed March 25^th at 6pm GMT. The current plan is for them to address the FAQ mentioned in the action items below. So, we are holding the System DT call as a follow-on to that session. > > > > Please join the System DT call on Zoom: https://zoom.us/my/openampproject > > (If you need the meeting ID, it’s 9031895760) > > > > The notes from the previous call (Feb 13) can be found on the OpenAMP wiki at this link: > > https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2020#2020F… > > > > Action items from the Feb 13 call: > > * Stefano: review memory & reserved memory to make sure it's consistent > > * Tomas/Stefano: We should add FAQ to the System DT write-up > > * Tomas: Ask Bruce to send out Lopper more widely, even if draft, soon (Going through Xilinx open sourcing process) > > * Tomas: Drive documenting Xilinx internal discussion on firewalls & share > > * All: Please share your ideas & then we can discuss a proposal > > * Nathalie: Put on next call agenda to continue to discuss configuration lifecycle next meeting > > > > For info about the list, link to the archives, to unsubscribe yourself, or > > for someone to subscribe themselves, visit: > > https://lists.openampproject.org/mailman/listinfo/system-dt > > For information about the System Device Trees effort, including a link to > > the intro presentation from Linaro Connect SAN19: > > https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees > > > > Best regards, > > Nathalie C. Chan King Choy > > Program Manager focused on Open Source and Community > > > >

6 years, 1 month

2
1
0 0

Calling for agenda items: System Device Tree call

by Nathalie Chan King Choy

Hi all, Please send your suggestions for agenda items for the upcoming call on Monday. So far I have: * Continue to discuss configuration lifecycle * Follow up from the System DT FAQ talk during Linaro Tech Days Thanks & regards, Nathalie -----Original Appointment----- From: Nathalie Chan King Choy To: Nathalie Chan King Choy; 'system-dt(a)lists.openampproject.org' Subject: System Device Tree call When: Monday, April 6, 2020 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: zoom Hi all, Tomas and Stefano will be presenting about System Device Tree during the Linaro Tech Days (free registration)<https://www.eventbrite.co.uk/e/99529015966/> on Wed March 25th at 6pm GMT. The current plan is for them to address the FAQ mentioned in the action items below. So, we are holding the System DT call as a follow-on to that session. Please join the System DT call on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) The notes from the previous call (Feb 13) can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2020#2020F… Action items from the Feb 13 call: * Stefano: review memory & reserved memory to make sure it's consistent * Tomas/Stefano: We should add FAQ to the System DT write-up * Tomas: Ask Bruce to send out Lopper more widely, even if draft, soon (Going through Xilinx open sourcing process) * Tomas: Drive documenting Xilinx internal discussion on firewalls & share * All: Please share your ideas & then we can discuss a proposal * Nathalie: Put on next call agenda to continue to discuss configuration lifecycle next meeting For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/system-dt For information about the System Device Trees effort, including a link to the intro presentation from Linaro Connect SAN19: https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

6 years, 1 month

1
0
0 0

Links for System DT presentation at Linaro Tech Days

by Nathalie Chan King Choy

Hi all, Here are the links. It's probably best if you also register, in case there are late breaking updates (e.g. today there were some tech difficulties on Track 2 of the sessions). Registration link: https://www.eventbrite.co.uk/e/99529015966/ 11am PDT: LTD20-205 System Device Tree Project YouTube: https://youtu.be/34MuzEb4gmw Zoom: Link to join Webinar: https://zoom.us/j/800993714 Additionally, if you're interested in the Open Container Initiative, Stefano is also a presenter on that talk: 9:30am PDT: LTD20-200 Heterogeneous Hardware-Accelerated OCI Containers & Secure OCI Containers YouTube: https://youtu.be/34MuzEb4gmw Zoom: Link to join Webinar: https://zoom.us/j/800993714 Thanks & regards, Nathalie

6 years, 1 month

1
0
0 0

System DT session at Linaro Tech Days

by Nathalie Chan King Choy

Tomas and Stefano will be presenting about System DT during the Linaro Tech Days (free registration)<https://www.eventbrite.co.uk/e/99529015966/> on Wed March 25th at 6pm GMT. The current plan is to do a brief intro & then cover frequently asked questions about how System DT would work.

6 years, 2 months

1
0
0 0

System Device Tree call

by Nathalie Chan King Choy

Hi all, Tomas and Stefano will be presenting about System Device Tree during the Linaro Tech Days (free registration)<https://www.eventbrite.co.uk/e/99529015966/> on Wed March 25th at 6pm GMT. The current plan is for them to address the FAQ mentioned in the action items below. So, we are holding the System DT call as a follow-on to that session. Please join the System DT call on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) The notes from the previous call (Feb 13) can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2020#2020F… Action items from the Feb 13 call: * Stefano: review memory & reserved memory to make sure it's consistent * Tomas/Stefano: We should add FAQ to the System DT write-up * Tomas: Ask Bruce to send out Lopper more widely, even if draft, soon (Going through Xilinx open sourcing process) * Tomas: Drive documenting Xilinx internal discussion on firewalls & share * All: Please share your ideas & then we can discuss a proposal * Nathalie: Put on next call agenda to continue to discuss configuration lifecycle next meeting For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/system-dt For information about the System Device Trees effort, including a link to the intro presentation from Linaro Connect SAN19: https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees Best regards, Nathalie C. Chan King Choy Program Manager focused on Open Source and Community

6 years, 2 months

1
0
0 0

[PATCH v2 0/7] Introduce bus firewall controller framework

by Benjamin Gaignard

Bus firewall framework aims to provide a kernel API to set the configuration of the harware blocks in charge of busses access control. Framework architecture is inspirated by pinctrl framework: - a default configuration could be applied before bind the driver. If a configuration could not be applied the driver is not bind to avoid doing accesses on prohibited regions. - configurations could be apllied dynamically by drivers. - device node provides the bus firewall configurations. An example of bus firewall controller is STM32 ETZPC hardware block which got 3 possible configurations: - trust: hardware blocks are only accessible by software running on trust zone (i.e op-tee firmware). - non-secure: hardware blocks are accessible by non-secure software (i.e. linux kernel). - coprocessor: hardware blocks are only accessible by the coprocessor. Up to 94 hardware blocks of the soc could be managed by ETZPC. At least two other hardware blocks can take benefits of this: - ARM TZC-400: http://infocenter.arm.com/help/topic/com.arm.doc.100325_0001_02_en/arm_core… which is able to manage up to 8 regions in address space. - IMX Ressource Domain Controller (RDC): supports four domains and up to eight regions Version 2 has been rebased on top of v5.5 - Change framework name to "firewall" because the targeted hardware block are acting like firewall on the busses. - Mark Brown had reviewed the previous version but it was on kernel 5.1 and I change the name framework so I have decided to remove it. - Use yaml file to describe the bindings Benjamin Benjamin Gaignard (7): dt-bindings: bus: Add firewall bindings bus: Introduce firewall controller framework base: Add calls to firewall controller dt-bindings: bus: Add STM32 ETZPC firewall controller bus: firewall: Add driver for STM32 ETZPC controller ARM: dts: stm32: Add firewall node for stm32mp157 SoC ARM: dts: stm32: enable firewall controller node on stm32mp157c-ed1 .../bindings/bus/firewall/firewall-consumer.yaml | 25 ++ .../bindings/bus/firewall/firewall-provider.yaml | 18 ++ .../bindings/bus/firewall/st,stm32-etzpc.yaml | 41 ++++ arch/arm/boot/dts/stm32mp157c-ev1.dts | 2 + arch/arm/boot/dts/stm32mp157c.dtsi | 7 + drivers/base/dd.c | 9 + drivers/bus/Kconfig | 2 + drivers/bus/Makefile | 2 + drivers/bus/firewall/Kconfig | 14 ++ drivers/bus/firewall/Makefile | 2 + drivers/bus/firewall/firewall.c | 264 +++++++++++++++++++++ drivers/bus/firewall/stm32-etzpc.c | 140 +++++++++++ include/dt-bindings/bus/firewall/stm32-etzpc.h | 90 +++++++ include/linux/firewall.h | 70 ++++++ 14 files changed, 686 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/firewall/firewall-consumer.yaml create mode 100644 Documentation/devicetree/bindings/bus/firewall/firewall-provider.yaml create mode 100644 Documentation/devicetree/bindings/bus/firewall/st,stm32-etzpc.yaml create mode 100644 drivers/bus/firewall/Kconfig create mode 100644 drivers/bus/firewall/Makefile create mode 100644 drivers/bus/firewall/firewall.c create mode 100644 drivers/bus/firewall/stm32-etzpc.c create mode 100644 include/dt-bindings/bus/firewall/stm32-etzpc.h create mode 100644 include/linux/firewall.h -- 2.15.0

6 years, 3 months

8
33
0 0

Calling for agenda items: Thur Feb 13th System Device Tree call

by Nathalie Chan King Choy

Hi all, Please send your agenda items for the upcoming call on Thursday. Thanks & regards, Nathalie -----Original Appointment----- From: Nathalie Chan King Choy Sent: Monday, January 27, 2020 3:37 PM To: Nathalie Chan King Choy; system-dt(a)lists.openampproject.org Cc: nathalie-ckc(a)kestrel-omnitech.com; Kepa, Krzysztof (GE Global Research); Don Harbin; Bruce Ashfield; Wesley Skeffington; ilias.apalodimas(a)linaro.org; Milea, Danut Gabriel (Danut); Joakim Bech; Pierre Guironnet de Massas; Markham, Joel (GE Global Research, US); Tony McDowell; robherring2(a)gmail.com; Ed T. Mooring; Loic PALLARDY; Grant Likely Subject: System Device Tree call When: Thursday, February 13, 2020 10:00 AM-11:00 AM (UTC-08:00) Pacific Time (US & Canada). Where: Zoom Hi all, Please join the call on Zoom: https://zoom.us/my/openampproject (If you need the meeting ID, it's 9031895760) The notes from the previous call (Jan 22) can be found on the OpenAMP wiki at this link: https://github.com/OpenAMP/open-amp/wiki/System-DT-Meeting-Notes-2020#2020J… Action items from the previous call: * Stefano: Document a little bit more how the model works ** Remove reserved memory ** Add top-level use-case FAQ (e.g. how to do peripheral assignment to SW) ** Consider putting a qualifier word before "domain" to make it more specific * Everyone: Try to poke holes in the model. Good to have hard questions to think through & answer * Rob: Prototype proposal of changing root * Nathalie: co-ordinate next call over email (2 weeks from now doesn't work b/c Rob can't make it) For info about the list, link to the archives, to unsubscribe yourself, or for someone to subscribe themselves, visit: https://lists.openampproject.org/mailman/listinfo/system-dt For information about the System Device Trees effort, including a link to the intro presentation from Linaro Connect SAN19: https://github.com/OpenAMP/open-amp/wiki/System-Device-Trees Best regards, Nathalie C. Chan King Choy Project Manager focused on Open Source and Community

6 years, 3 months

1
1
0 0

Re: [System-dt] System Device Tree: description & explanation

by Francois Ozog

On Tue, 11 Feb 2020 at 02:03, Stefano Stabellini via System-dt <system-dt(a)lists.openampproject.org> wrote: > > Hi all, > > During the last system device tree call, we agreed it would be helpful > to have a document explaining how to use the proposed new device tree > bindings to describe heterogeneous systems and solve typical problems, > such as memory reservations for multiple domains, multiple interrupts > controllers, etc. > > Tomas and I wrote the following document (also attached: feel free to > use pandoc to convert it into html if you prefer to read it that way). > It includes an introduction to system device tree, a short description > of the bindings, and how to use them to solve common problems. I hope > that it will help create a common understanding of the problems we are > trying to solve and the potential solutions. I also attached the full > system device tree example as reference. > > Cheers, > > Stefano > > > > System Device Tree Concepts > =========================== > > System Device Trees extends traditional Device Trees to handle > heterogeneous SoCs with multiple CPUs and Execution Domains. An > Execution Domain can be seen as an address space that is running a > software image, whether an operating system, a hypervisor or firmware > that has a set of cpus, memory and devices attached to it. I.e. Each > individual CPU/core that is not part of an SMP cluster is a separate > Execution Domain as is the different Execution Levels on an ARMv8-A > architecture. Trusted and not trusted environment can also be viewed as > separate Execution Domains. > > A design goal of System Device Trees is that no current client of Device > Trees should have to change at all, unless it wants to take advantage of > the extra information. This means that Linux in particular does not need > to change since it will see a Device Tree that it can handle with the > current implementation, potentially with some extra information it can > ignore. > > System Device Trees must handle two types of heterogeneous additions: > > 1. Being able to specify different cpu clusters and the actual memory > and devices hard-wired to them > - This is done through the new Hardware Descriptions, such as > "cpu,cluster" and "indirect-bus" > - This information is provided by the SoC vendor and is typically > fixed for a given SoC/board > 2. Being able to assign hardware resources that can be configured by > software to be used by one or more Execution Domains > - This is done through the Execution Domain configuration > - This information is provided by a System Architect and will be > different for different use cases, even for the same board > - E.g. How much memory and which devices goes to Linux vs. an > RTOS can be different from one boot to another > - This information should be separated from the hard-wired > information for two reasons > - A different persona will add and edit the information > - Configuration should be separated from specification since it > has a different rate of change > > The System Device Trees and Execution Domain information are used in two > major use cases: > > 1. Exclusively on the host by using a tool like Lopper that will "prune" > the System Device Tree > - Each domain will get its own "traditional" Device Tree that only > sees one address space and has one "cpus" node, etc. > - Lopper has pluggable backends to it can also generate information > for clients that is using a different format > - E.g. It can generate a bunch of "#defines" that can be > included and compiled in to an RTOS > 2. System Device Trees can be used by a "master" target environment that > manages multiple Execution Domains: > - a firmware that can set up hardware protection and use it to > restart individual domains > - E.g. Protect the Linux memory so the R5 OS can't reach it > - any other operating system or hypervisor that has sub-domains > - E.g. Xen can use the Execution Domains to get info about the Xen > guests (also called domains) > - E.g. Linux could use the default domain for its own > configuration and the domains to manage other CPUs > - Since System Device Trees are backwards compatible with Device > Trees, the only changes needed in Linux would be any new code > taking advantage of the Domain information > - a default master has access to all resources (CPUs, memories, > devices), it has to make sure it stops using the resource > itself when it "gives it away" to a sub-domain > > There is a concept of a default Execution Domain in System Device Trees, > which corresponds to /cpus. The default domain is compatible with the > current traditional Device Tree. It is useful for a couple of reasons: > > 1. As a way to specify the default place to assign added hardware (see > use case #1) > - A default domain does not have to list the all the HW resources > allocated to it. It gets everything not allocated elsewhere by > Lopper. > - This minimizes the amount of information needed in the Domain > configuration. > - This is also useful for dynamic hardware such as add-on boards and > FPGA images that are adding new devices. > 2. The default domain can be used to specify what a master environment > sees (see use case #2) > - E.g. the default domain is what is configuring Linux or Xen, while > the other domains specify domains to be managed by the master > > > System Device Tree Hardware Description > ======================================= > > To turn system device tree into a reality we are introducing a few new > concepts. They enable us to describe a system with multiple cpus > clusters and potentially different address mappings for each of them > (i.e. a device could be seen at different addresses from different cpus > clusters). > > The new concepts are: > > - Multiple top level "cpus,cluster" nodes to describe heterogeneous CPU > clusters. > - "indirect-bus": a new type of bus that does not automatically map to > the parent address space (i.e. not automatically visible). > - An "address-map" property to express the different address mappings of > the different cpus clusters and to map indirect-buses. > > The following is a brief example to show how they can be used together: > > > /* default cluster */ > cpus { > cpu@0 { > }; > cpu@1 { > }; > }; > > /* additional R5 cluster */ > cpus_r5: cpus-cluster@0 { > compatible = "cpus,cluster"; > > /* specifies address mappings */ > address-map = <0xf9000000 &amba_rpu 0xf9000000 0x10000>; > > cpu@0 { > }; > > cpu@1 { > }; > }; > > amba_rpu: indirect-bus@f9000000 { > compatible = "indirect-bus"; > }; > > > In this example we can see: > - two cpus clusters, one of them is the default top-level cpus node > - an indirect-bus "amba_rpu" which is not visible to the top-level cpus > node > - the cpus_r5 cluster can see amba_rpu because it is explicitly mapped > using the address-map property > > > Devices only physically accessible from one of the two clusters should > be placed under an indirect-bus as appropriate. For instance, in the > following example we can see how interrupts controllers are expressed: > > > /* default cluster */ > cpus { > }; > > /* additional R5 cluster */ > cpus_r5: cpus-cluster@0 { > compatible = "cpus,cluster"; > > /* specifies address mappings */ > address-map = <0xf9000000 &amba_rpu 0xf9000000 0x10000>; > }; > > /* bus only accessible by cpus */ > amba_apu: bus@f9000000 { > compatible = "simple-bus"; > > gic_a72: interrupt-controller@f9000000 { > }; > }; > > /* bus only accessible by cpus_r5 */ > amba_rpu: indirect-bus@f9000000 { > compatible = "indirect-bus"; > > gic_r5: interrupt-controller@f9000000 { > }; > }; > > > gic_a72 is accessible by /cpus, but not by cpus_r5, because amba_apu is > not present in the address-map of cpus_r5. > > gic_r5 is visible to cpus_r5, because it is present in the address map > of cpus_r5. gic_r5 is not visible to /cpus because indirect-bus doesn't > automatically map to the parent address space, and /cpus doesn't have an > address-map property in the example. > > Relying on the fact that each interrupt controller is correctly visible > to the right cpus cluster, it is possible to express interrupt routing > from a device to multiple clusters. For instance: > > > amba: bus@f1000000 { > compatible = "simple-bus"; > ranges; > > #interrupt-cells = <3>; > interrupt-map-pass-thru = <0xffffffff 0xffffffff 0xffffffff>; > interrupt-map-mask = <0x0 0x0 0x0>; > interrupt-map = <0x0 0x0 0x0 &gic_a72 0x0 0x0 0x0>, > <0x0 0x0 0x0 &gic_r5 0x0 0x0 0x0>; > > can@ff060000 { > compatible = "xlnx,canfd-2.0"; > reg = <0x0 0xff060000 0x0 0x6000>; > interrupts = <0x0 0x14 0x1>; > }; > }; > > In this example, all devices under amba, including can@ff060000, have > their interrupts routed to both gic_r5 and gic_a72. > > Memory only physically accessible by one of the clusters can be placed > under an indirect-bus like any other device types. However, normal > memory is usually physically accessible by all clusters. It is just a > software configuration that splits memory into ranges and assigns a > range for each execution domain. Software configurations are explained > below. > > > Execution Domains > ================= > > An execution domain is a collection of software, firmware, and board > configurations that enable an operating system or an application to run > a cpus cluster. With multiple cpus clusters in a system it is natural to > have multiple execution domains, at least one per cpus cluster. There > can be more than one execution domain for each cluster, with > virtualization or non-lockstep execution (for cpus clusters that support > it). Execution domains are configured and added at a later stage by a > software architect. > > Execution domains are expressed by a new node "openamp,domain" > compatible. Being a configuration rather than a description, their > natural place is under /chosen or under a similar new top-level node. In > this example, I used /domains: > > > domains { > openamp_r5 { > compatible = "openamp,domain-v1"; > cpus = <&cpus_r5 0x2 0x80000000>; > memory = <0x0 0x0 0x0 0x8000000>; > access = <&can@ff060000>; > }; > }; > > > An openamp,domain node contains information about: > - cpus: physical cpus on which the software is running on > - memory: memory assigned to the domain > - access: any devices configured to be only accessible by a domain > > The access list is an array of links to devices that are configured to > be only accessible by an execution domain, using bus firewalls or > similar technologies. > > The memory range assigned to an execution domain is expressed by the > memory property. It needs to be a subset of the physical memory in the > system. The memory property can also be used to express memory sharing > between domains: > > > domains { > openamp_r5 { > compatible = "openamp,domain-v1"; > memory = <0x0 0x0 0x0 0x8000000 0x8 0x0 0x0 0x10000>; > }; > openamp_a72 { > compatible = "openamp,domain-v1"; > memory = <0x0 0x8000000 0x0 0x80000000 0x8 0x0 0x0 0x10000>; > }; > }; > Are those domains also define a "reset domain"? I mean, you may want to selectively reset a domain (within a particular clock domain). Or shall reset-domains be defined and then domains would be defined on subsets of those? > In this example, a 16 pages range starting at 0x800000000 is shared > between two domains. > > In a system device tree without a default cpus cluster (no top-level > cpus node), lopper figures out memory assignment for each domain by > looking at the memory property under each "openamp,domain" node. In a > device tree with a top-level cpus cluster, and potentially a legacy OS > running on it, we might want to "hide" the memory reservation for other > clusters from /cpus. We can do that with /reserved-memory: > > reserved-memory { > #address-cells = <0x2>; > #size-cells = <0x2>; > ranges; > > memory_r5@0 { > compatible = "openamp,domain-memory-v1"; > reg = <0x0 0x0 0x0 0x8000000>; > }; > }; > > The purpose of memory_r5@0 is to let the default execution domain know > that it shouldn't use the 0x0-0x8000000 memory range because it is > reserved for use by other domains. > > /reserved-memory and /chosen are top-level nodes dedicated to > configurations, rather than hardware description. Each execution domain > might need similar configurations, hence, chosen and reserved-memory are > also specified under each openamp,domain node for domains specific > configurations. The top-level /reserved-memory and /chosen nodes remain in > place for the default execution domain. As an example: > > /chosen -> configuration for a legacy OS running on /cpus > /reserved-memory -> reserved memory for a legacy OS running on /cpus > > /domains/openamp_r5/chosen -> configuration for the domain "openamp_r5" > /domains/openamp_r5/reserved-memory -> reserved memory for "openamp_r5"-- > System-dt mailing list > System-dt(a)lists.openampproject.org > https://lists.openampproject.org/mailman/listinfo/system-dt -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

6 years, 3 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

System-dt