Documentation: bindings: Add DT bindings for ARM's FVP models.
Subsystems (2)
PATCH 1/2 Documentation: bindings: Add DT bindings for ARM's FVP models.
List the required properties used to describe ARM's FVP models.
--- Documentation/devicetree/bindings/arm/arm-boards | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
Documentation/devicetree/bindings/arm/arm-boards +21 -0
@@ -234,3 +234,24 @@ Example: }; }; + +ARM Fixed Virtual Platforms (FVP) +--------------------------------- +FVPs are simulated platforms produced by ARM to aid software development without +the requirement for actual hardware. They come in several families, each of +which (usually) contain variants for different configurations of simulated +hardware. These are documented in the Fixed Virtual Platforms FVP Reference +Guide (reference number ARM DUI0837H). + +Required properties (in root node): +- compatible value: + compatible = "arm,<family>,<variant>", "arm,<family>"; + where <family> is one of: + - "fvp-base" for the Base FVP + - "fvp-ve" for the VE FVP + and <variant> is the part of the model's executable filename with the family + name omitted, converted to lower case, and with non-alphanumeric characters + replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU clusters has an + executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible value for + this would be: + compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base";
Signature · 1 line
2.1.4
PATCH 2/2 arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Fixed Virtual Platform (FVP) Base models are simulations of systems that resemble Versatile Express or Juno hardware.
This adds a device-tree for the model variant that has two clusters of Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that are common to all variants of Base models have been placed in a separate file (fvp-base.dtsi) to facilitate creating device-trees for other models.
It is desirable to use simulations for code testing purposes and so it is beneficial to include nodes for things that are timing and power consumption related, even when these don't otherwise have relevance or accuracy. Where these have been included here (e.g. idle-states) entries have been copied from real hardware platforms such as Juno.
--- arch/arm64/boot/dts/arm/Makefile | 1 + arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts | 221 +++++++++++++++++ arch/arm64/boot/dts/arm/fvp-base.dtsi | 267 +++++++++++++++++++++ 3 files changed, 489 insertions(+)
arch/arm64/boot/dts/arm/Makefile +1 -0
@@ -1,4 +1,5 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb foundation-v8-gicv3.dtb +dtb-$(CONFIG_ARCH_VEXPRESS) += fvp-base-aemv8a-aemv8a.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb juno-r2.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2f-1xv7-ca53x2.dtb
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +221 -0
221 lines not on this page · raw message
arch/arm64/boot/dts/arm/fvp-base.dtsi new file +267 -0
267 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH 2/2 arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Hi,
Quoted 9 lines · Jon Medhurst
Fixed Virtual Platform (FVP) Base models are simulations of systems that resemble Versatile Express or Juno hardware.
This adds a device-tree for the model variant that has two clusters of Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that are common to all variants of Base models have been placed in a separate file (
fvp-base.dtsi) to facilitate creating device-trees for other models.
Quoted 5 lines
It is desirable to use simulations for code testing purposes and so it is beneficial to include nodes for things that are timing and power consumption related, even when these don't otherwise have relevance or accuracy. Where these have been included here (e.g. idle-states) entries have been copied from real hardware platforms such as Juno.
Which firmware are you using, and what precisely does it do w.r.t. those idle states? Judging by the FVP ATF pm code [1], those state IDs aren't valid (though perhaps the comment is wrong, or I've misunderstood something).
People use the FVPs with a variety of FW and bootloaders, so I'm not keen on putting anything FW or bootloader specific into the canonical FVP DT files.
Quoted 29 lines
Signed-off-by Jon Medhurst <[email protected]>--- arch/arm64/boot/dts/arm/Makefile | 1 + arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts | 221 +++++++++++++++++ arch/arm64/boot/dts/arm/fvp-base.dtsi | 267 +++++++++++++++++++++ 3 files changed, 489 insertions(+)arch/arm64/boot/dts/arm/Makefile +1
-0@@ -1,4 +1,5 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += foundation-v8.dtb foundation-v8-gicv3.dtb +dtb-$(CONFIG_ARCH_VEXPRESS) += fvp-base-aemv8a-aemv8a.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += juno.dtb juno-r1.dtb juno-r2.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += vexpress-v2f-1xv7-ca53x2.dtbarch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +6
-0@@ -0,0 +1,221 @@ +/* + * ARM Ltd. Fixed Virtual Platform (FVP) Base model with dual cluster + * Architecture Envelope Model (AEM) v8-A CPUs + */ + +/dts-v1/;
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts line 16
Quoted 10 lines
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +10
-0+ +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base", "arm,vexpress"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + chosen { };
Please add stdout-path, e.g.
stdout-path = "serial0:115200";
Quoted 7 lines
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +7
-0+ + aliases { + serial0 = &bp_serial0; + serial1 = &bp_serial1; + serial2 = &bp_serial2; + serial3 = &bp_serial3; + };
[...]
Quoted 21 lines
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +21
-0+ idle-states { + entry-method = "arm,psci"; + + CPU_SLEEP_0: cpu-sleep-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010000>; + local-timer-stop; + entry-latency-us = <300>; + exit-latency-us = <1200>; + min-residency-us = <2000>; + }; + + CLUSTER_SLEEP_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x1010000>; + local-timer-stop; + entry-latency-us = <300>; + exit-latency-us = <1200>; + min-residency-us = <2500>; + }; + };
[...]
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts line 174
Quoted 6 lines
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +6
-0+ timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
The cpumask shouldn't be there (it's not valid for GICv3).
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts line 175
Quoted 1 line
arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file +1
-0+ clock-frequency = <100000000>;
FW should program CNTFRQ correctly, so we should drop the clock-frequency property. We should never have had it in the first place for the original RTSM DT.
Thanks,
Mark.
PATCH 2/2 arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Quoted 12 lines · Mark Rutland
Hi,
Quoted 9 lines · Jon Medhurst
Fixed Virtual Platform (FVP) Base models are simulations of systems that resemble Versatile Express or Juno hardware.
This adds a device-tree for the model variant that has two clusters of Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that are common to all variants of Base models have been placed in a separate file (
fvp-base.dtsi) to facilitate creating device-trees for other models.
Quoted 7 lines
Quoted 5 lines
It is desirable to use simulations for code testing purposes and so it is beneficial to include nodes for things that are timing and power consumption related, even when these don't otherwise have relevance or accuracy. Where these have been included here (e.g. idle-states) entries have been copied from real hardware platforms such as Juno.
Which firmware are you using,
ARM Trusted Firmware
Quoted 2 lines
and what precisely does it do w.r.t.
those idle states?
I don't know, will check. Those states are also in the ARM TF device-tree for the Base FVP [2] but I admit I didn't verify they were correct. (Unlike real 'hardware' dt nodes, for which I methodically went through documentation and LISA files to check and fix).
[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
Quoted 3 lines
Judging by the FVP ATF pm code [1], those state IDs
aren't valid (though perhaps the comment is wrong, or I've misunderstood something).
I'm not sure which comment you are referring to, that link [1] doesn't seem to anchor to a particular source line in my web browser, and I don't spot anything relevant scanning by eye.
Quoted 3 lines
People use the FVPs with a variety of FW and bootloaders, so I'm not keen on putting anything FW or bootloader specific into the canonical FVP DT files.
I can agree about bootloaders, but would anyone be using FVP's without ARM Trusted firmware? And if they aren't using using that, can we still assume a PSCI capable firmware for things like CPU enable-method? I'm asking to get an idea where the line is as I have changes for Foundation model too. Also, want something to say to the people who asked me to 'upstream the FVP DTs' as I expect they think people are using the One True Way which involves ARM's Trusted Firmware and other sacred tomes passed down to them ;-)
I'll fix your other comment on the DT, so snipping email here.
Quoted 1 line
Signature · 1 line
Tixy
PATCH 2/2 arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Quoted 33 lines · Jon Medhurst (Tixy)
Quoted 12 lines · Mark Rutland
Hi,
Quoted 9 lines · Jon Medhurst
Fixed Virtual Platform (FVP) Base models are simulations of systems that resemble Versatile Express or Juno hardware.
This adds a device-tree for the model variant that has two clusters of Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that are common to all variants of Base models have been placed in a separate file (
fvp-base.dtsi) to facilitate creating device-trees for other models.Quoted 7 lines
Quoted 5 lines
It is desirable to use simulations for code testing purposes and so it is beneficial to include nodes for things that are timing and power consumption related, even when these don't otherwise have relevance or accuracy. Where these have been included here (e.g. idle-states) entries have been copied from real hardware platforms such as Juno.
Which firmware are you using,
ARM Trusted Firmware
Quoted 2 lines
and what precisely does it do w.r.t.
those idle states?I don't know, will check. Those states are also in the ARM TF device-tree for the Base FVP [2] but I admit I didn't verify they were correct. (Unlike real 'hardware' dt nodes, for which I methodically went through documentation and LISA files to check and fix).
[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
Quoted 7 lines
Quoted 3 lines
Judging by the FVP ATF pm code [1], those state IDs
aren't valid (though perhaps the comment is wrong, or I've misunderstood something).I'm not sure which comment you are referring to, that link [1] doesn't seem to anchor to a particular source line in my web browser, and I don't spot anything relevant scanning by eye.
Aargh, the web interface appears to have given me a duff URL. Let's try again [3]. ;)
The comments note state-ids 0x01, 0x02, and 0x22, which don't appear to match the DT. It might be that I've just misunderstood, but it could be that every attempt to idle simply fails if we're passing the wrong state-ids, and that's somewhat sub-optimal.
I'm not sure if there's a simple diagnostic for that. Lorenzo, any idea if/how we can detect when the FW rejects an idle state it doesn't recognise?
Quoted 6 lines
Quoted 3 lines
People use the FVPs with a variety of FW and bootloaders, so I'm not keen on putting anything FW or bootloader specific into the canonical FVP DT files.
I can agree about bootloaders, but would anyone be using FVP's without ARM Trusted firmware?
Yes. I know of several people just using the bootwrapper [4], with custom DTs.
Quoted 2 lines
And if they aren't using using that, can we still assume a PSCI capable firmware for things like CPU enable-method?
I was counting that under "FW or bootloader specific", so no.
Quoted 5 lines
I'm asking to get an idea where the line is as I have changes for Foundation model too. Also, want something to say to the people who asked me to 'upstream the FVP DTs' as I expect they think people are using the One True Way which involves ARM's Trusted Firmware and other sacred tomes passed down to them ;-)
Ideally, the Base stuff is meant to be all fixed, so we should be able to support the default configuration.
To handle different FWs and bootloaders, I think we should have a DT without the enable-method, PSCI node, and idle states, for the default FVP Base configuration.
We can *also* have a DT for the default FVP Base + ATF configuration (so long as clearly named as such), with the appropriate nodes and properties.
Quoted 1 line
I'll fix your other comment on the DT, so snipping email here.
Sure, cheers!
Thanks,
Mark.
Quoted 1 line
[3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53
[4] https://git.kernel.org/cgit/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git/
PATCH 2/2 arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Quoted 42 lines · Mark Rutland
Quoted 33 lines · Jon Medhurst (Tixy)
Quoted 12 lines · Mark Rutland
Hi,
Quoted 9 lines · Jon Medhurst
Fixed Virtual Platform (FVP) Base models are simulations of systems that resemble Versatile Express or Juno hardware.
This adds a device-tree for the model variant that has two clusters of Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that are common to all variants of Base models have been placed in a separate file (
fvp-base.dtsi) to facilitate creating device-trees for other models.Quoted 7 lines
Quoted 5 lines
It is desirable to use simulations for code testing purposes and so it is beneficial to include nodes for things that are timing and power consumption related, even when these don't otherwise have relevance or accuracy. Where these have been included here (e.g. idle-states) entries have been copied from real hardware platforms such as Juno.
Which firmware are you using,
ARM Trusted Firmware
Quoted 2 lines
and what precisely does it do w.r.t.
those idle states?I don't know, will check. Those states are also in the ARM TF device-tree for the Base FVP [2] but I admit I didn't verify they were correct. (Unlike real 'hardware' dt nodes, for which I methodically went through documentation and LISA files to check and fix).
[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
Quoted 7 lines
Quoted 3 lines
Judging by the FVP ATF pm code [1], those state IDs
aren't valid (though perhaps the comment is wrong, or I've misunderstood something).I'm not sure which comment you are referring to, that link [1] doesn't seem to anchor to a particular source line in my web browser, and I don't spot anything relevant scanning by eye.
Quoted 5 lines
Aargh, the web interface appears to have given me a duff URL. Let's try again [3]. ;)
The comments note state-ids
0x01,0x02, and0x22, which don't appear to match the DT. It might be that I've just misunderstood
That function is only compiled when ARM_RECOM_STATE_ID_ENC is true, which it isn't when I build TF using "make PLAT=fvp ...." so I think it's a red herring.
When I boot the FVP with my posted device-tree, the core run state icons on the CLCD window behave as you would expect for CPUs and whole clusters powering off/on as CPU's activity changes. So idle _looks_ like it's working OK.
I also put printfs in ATF's psci_cpu_suspend() function and I can see the values specified in device-tree being passed in and the code behaving sensibly. From how it cracks the power_state value [4] it certainly looks like the numbers have the following meanings:
top byte = 0..3 for the 'level' of the power state top-but-one byte = 0/1 for Standby/Powerdown
For FVP [5], the level appears to be 0=CPU, 1=Cluster. This matches what's in the device-tree I posted, where we have 0x00010000 for CPU sleep, and 0x01010000 for cluster sleep.
All of which is a long way of saying that I believe the values that the firmware guys and Linaro have been using for the past year or two are correct ;-)
Quoted 1 line
[4] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/include/bl31/services/psci.h#L100
[5] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L195
Signature · 1 line
Tixy
PATCH 2/2 arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model
Quoted 46 lines · Jon Medhurst (Tixy)
Quoted 45 lines · Mark Rutland
Quoted 33 lines · Jon Medhurst (Tixy)
Quoted 12 lines · Mark Rutland
Hi,
Quoted 9 lines · Jon Medhurst
Fixed Virtual Platform (FVP) Base models are simulations of systems that resemble Versatile Express or Juno hardware.
This adds a device-tree for the model variant that has two clusters of Architecture Envelope Model (AEM) v8-A CPUs. The peripheral devices that are common to all variants of Base models have been placed in a separate file (
fvp-base.dtsi) to facilitate creating device-trees for other models.Quoted 7 lines
Quoted 5 lines
It is desirable to use simulations for code testing purposes and so it is beneficial to include nodes for things that are timing and power consumption related, even when these don't otherwise have relevance or accuracy. Where these have been included here (e.g. idle-states) entries have been copied from real hardware platforms such as Juno.
Which firmware are you using,
ARM Trusted Firmware
Quoted 2 lines
and what precisely does it do w.r.t.
those idle states?I don't know, will check. Those states are also in the ARM TF device-tree for the Base FVP [2] but I admit I didn't verify they were correct. (Unlike real 'hardware' dt nodes, for which I methodically went through documentation and LISA files to check and fix).
[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-base-gicv3-psci.dts
Quoted 7 lines
Quoted 3 lines
Judging by the FVP ATF pm code [1], those state IDs
aren't valid (though perhaps the comment is wrong, or I've misunderstood something).I'm not sure which comment you are referring to, that link [1] doesn't seem to anchor to a particular source line in my web browser, and I don't spot anything relevant scanning by eye.
Aargh, the web interface appears to have given me a duff URL. Let's try again [3]. ;)
Quoted 6 lines
Quoted 2 lines
The comments note state-ids
0x01,0x02, and0x22, which don't appear to match the DT. It might be that I've just misunderstoodThat function is only compiled when
ARM_RECOM_STATE_ID_ENCis true, which it isn't when I build TF using "make PLAT=fvp ...." so I think it's a red herring.
Ah,ok.
Quoted 13 lines
When I boot the FVP with my posted device-tree, the core run state icons on the CLCD window behave as you would expect for CPUs and whole clusters powering off/on as CPU's activity changes. So idle _looks_ like it's working OK.
I also put printfs in ATF's
psci_cpu_suspend()function and I can see the values specified in device-tree being passed in and the code behaving sensibly. From how it cracks thepower_statevalue [4] it certainly looks like the numbers have the following meanings:top byte = 0..3 for the 'level' of the power state top-but-one byte = 0/1 for Standby/Powerdown
Quoted 7 lines
For FVP [5], the level appears to be 0=CPU, 1=Cluster. This matches what's in the device-tree I posted, where we have
0x00010000for CPU sleep, and0x01010000for cluster sleep.All of which is a long way of saying that I believe the values that the firmware guys and Linaro have been using for the past year or two are correct ;-)
Great, thanks for digging into that, and apologies for the noise!
Thanks,
Mark.
Quoted 9 lines
Quoted 2 lines
[4] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/include/bl31/services/psci.h#L100
[5] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L195Signature · 1 line
Tixy
Rob Herring
maintainerPATCH 1/2 Documentation: bindings: Add DT bindings for ARM's FVP models.
In reply to Jon MedhurstQuoted 24 lines · Jon Medhurst
List the required properties used to describe ARM's FVP models.
Signed-off-by Jon Medhurst <[email protected]>--- Documentation/devicetree/bindings/arm/arm-boards | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)Documentation/devicetree/bindings/arm/arm-boards +9
-0@@ -234,3 +234,24 @@ Example: }; }; + +ARM Fixed Virtual Platforms (FVP) +--------------------------------- +FVPs are simulated platforms produced by ARM to aid software development without +the requirement for actual hardware. They come in several families, each of +which (usually) contain variants for different configurations of simulated +hardware. These are documented in the Fixed Virtual Platforms FVP Reference +Guide (reference number ARM DUI0837H). +
Documentation/devicetree/bindings/arm/arm-boards Example: · line 255
Quoted 10 lines
Documentation/devicetree/bindings/arm/arm-boards +10
-0+Required properties (in root node): +- compatible value: + compatible = "arm,<family>,<variant>", "arm,<family>"; + where <family> is one of: + - "fvp-base" for the Base FVP + - "fvp-ve" for the VE FVP + and <variant> is the part of the model's executable filename with the family + name omitted, converted to lower case, and with non-alphanumeric characters + replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU clusters has an + executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible value for
Naming conventions of the exe aren't going to change?
Quoted 10 lines
Documentation/devicetree/bindings/arm/arm-boards +2
-0+ this would be: + compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base";Signature · 7 lines
2.1.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/2 Documentation: bindings: Add DT bindings for ARM's FVP models.
Quoted 8 lines · Rob Herring
Documentation/devicetree/bindings/arm/arm-boards Example:
Quoted 7 lines
Documentation/devicetree/bindings/arm/arm-boards +7
-0+Required properties (in root node): +- compatible value: + compatible = "arm,<family>,<variant>", "arm,<family>"; + where <family> is one of: + - "fvp-base" for the Base FVP + - "fvp-ve" for the VE FVP + and <variant> is the part of the model's executable filename withthe family
Quoted 8 lines
Quoted 1 line
+ name omitted, converted to lower case, and with non-alphanumeric
characters
Quoted 1 line
+ replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU
clusters has an
Quoted 1 line
+ executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible
value for
Naming conventions of the exe aren't going to change?
Almost certainly will at some point, as will the very name Fixed Virtual Platform, what 'families' ARM produce and their naming, and the configuration of the 'hardware' compiled into the models.
These are software models, so can be changed easily at the whim of marketing, or current perceived requirements from engineers and managers. So generally, it's a moving target, that doesn't fit nicely into the needs producing device-trees.
Signature · 1 line
Tixy
Rob Herring
maintainerPATCH 1/2 Documentation: bindings: Add DT bindings for ARM's FVP models.
Quoted 18 lines · Jon Medhurst (Tixy)
Quoted 8 lines · Rob Herring
Documentation/devicetree/bindings/arm/arm-boards Example:
Quoted 7 lines
Documentation/devicetree/bindings/arm/arm-boards +7
-0+Required properties (in root node): +- compatible value: + compatible = "arm,<family>,<variant>", "arm,<family>"; + where <family> is one of: + - "fvp-base" for the Base FVP + - "fvp-ve" for the VE FVP + and <variant> is the part of the model's executable filename withthe family
Quoted 8 lines
Quoted 1 line
+ name omitted, converted to lower case, and with non-alphanumeric
characters
Quoted 1 line
+ replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU
clusters has an
Quoted 1 line
+ executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible
value for
Naming conventions of the exe aren't going to change?
Quoted 8 lines
Almost certainly will at some point, as will the very name Fixed Virtual Platform, what 'families' ARM produce and their naming, and the configuration of the 'hardware' compiled into the models.
These are software models, so can be changed easily at the whim of marketing, or current perceived requirements from engineers and managers. So generally, it's a moving target, that doesn't fit nicely into the needs producing device-trees.
Then do we even need to specify something so specific? The kernel probably doesn't even care. Are you going to upstream new strings everytime there's a new one (that's public)?
We've had models supported upstream for a long time. What's changed now?
Rob
PATCH 1/2 Documentation: bindings: Add DT bindings for ARM's FVP models.
Quoted 23 lines · Rob Herring
Quoted 22 lines · Jon Medhurst (Tixy)
Quoted 8 lines · Rob Herring
Documentation/devicetree/bindings/arm/arm-boards Example:
Quoted 7 lines
Documentation/devicetree/bindings/arm/arm-boards +7
-0+Required properties (in root node): +- compatible value: + compatible = "arm,<family>,<variant>", "arm,<family>"; + where <family> is one of: + - "fvp-base" for the Base FVP + - "fvp-ve" for the VE FVP + and <variant> is the part of the model's executable filename withthe family
Quoted 8 lines
Quoted 1 line
+ name omitted, converted to lower case, and with non-alphanumeric
characters
Quoted 1 line
+ replaced with '-'. E.g. the Base FVP that has two AEMv8 CPU
clusters has an
Quoted 1 line
+ executable file called FVP_Base_AEMv8A-AEMv8A, so the compatible
value for
Naming conventions of the exe aren't going to change?
Almost certainly will at some point, as will the very name Fixed Virtual Platform, what 'families' ARM produce and their naming, and the configuration of the 'hardware' compiled into the models.
Quoted 7 lines
Quoted 4 lines
These are software models, so can be changed easily at the whim of marketing, or current perceived requirements from engineers and managers. So generally, it's a moving target, that doesn't fit nicely into the needs producing device-trees.
Then do we even need to specify something so specific? The kernel probably doesn't even care.
Well, it would certainly be easier if we could just use a simple 'arm,fvp' for compatible and model name and not worry about the 100 or so current variants. (Some are 32-bit, some 64-bit with just about every current ARM CPU represented, plus various peripheral sets with regard to display, iommu, dma, etc.
Quoted 2 lines
Are you going to upstream new strings
everytime there's a new one (that's public)?
I've only been asked to upstream a device-tree for the one that ARM targets in its 'platform release' [1]. Note, all 100+ models are equally 'public' in the sense that they are available to people are pay (like real hardware supported by Linux).
[1] https://community.arm.com/docs/DOC-10803)
Quoted 2 lines
We've had models supported upstream for a long time. What's changed now?
ARM's software releases are targeting a different model.
Signature · 1 line
Tixy