* [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models. @ 2016-06-20 12:13 Jon Medhurst 2016-06-20 12:13 ` [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model Jon Medhurst 2016-06-21 13:22 ` [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Rob Herring 0 siblings, 2 replies; 11+ messages in thread From: Jon Medhurst @ 2016-06-20 12:13 UTC (permalink / raw) To: linux-arm-kernel List the required properties used to describe ARM's FVP models. Signed-off-by: Jon Medhurst <tixy@linaro.org> --- Documentation/devicetree/bindings/arm/arm-boards | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards index ab318a5..4639a9b 100644 --- a/Documentation/devicetree/bindings/arm/arm-boards +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -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"; -- 2.1.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model 2016-06-20 12:13 [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Jon Medhurst @ 2016-06-20 12:13 ` Jon Medhurst 2016-06-20 12:39 ` Mark Rutland 2016-06-21 13:22 ` [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Rob Herring 1 sibling, 1 reply; 11+ messages in thread From: Jon Medhurst @ 2016-06-20 12:13 UTC (permalink / raw) To: linux-arm-kernel 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. Signed-off-by: Jon Medhurst <tixy@linaro.org> --- 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(+) diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile index 75cc2aa..7531001 100644 --- a/arch/arm64/boot/dts/arm/Makefile +++ b/arch/arm64/boot/dts/arm/Makefile @@ -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 diff --git a/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts new file mode 100644 index 0000000..2acfd26 --- /dev/null +++ b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts @@ -0,0 +1,221 @@ +/* + * ARM Ltd. Fixed Virtual Platform (FVP) Base model with dual cluster + * Architecture Envelope Model (AEM) v8-A CPUs + */ + +/dts-v1/; + +#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 { }; + + aliases { + serial0 = &bp_serial0; + serial1 = &bp_serial1; + serial2 = &bp_serial2; + serial3 = &bp_serial3; + }; + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0_0>; + }; + core1 { + cpu = <&CPU0_1>; + }; + core2 { + cpu = <&CPU0_2>; + }; + core3 { + cpu = <&CPU0_3>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU1_0>; + }; + core1 { + cpu = <&CPU1_1>; + }; + core2 { + cpu = <&CPU1_2>; + }; + core3 { + cpu = <&CPU1_3>; + }; + }; + }; + + 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>; + }; + }; + + CPU0_0: cpu at 0 { + compatible = "arm,armv8"; + reg = <0x0 0x0>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER0_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU0_1: cpu at 1 { + compatible = "arm,armv8"; + reg = <0x0 0x1>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER0_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU0_2: cpu at 2 { + compatible = "arm,armv8"; + reg = <0x0 0x2>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER0_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU0_3: cpu at 3 { + compatible = "arm,armv8"; + reg = <0x0 0x3>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER0_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU1_0: cpu at 100 { + compatible = "arm,armv8"; + reg = <0x0 0x100>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER1_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU1_1: cpu at 101 { + compatible = "arm,armv8"; + reg = <0x0 0x101>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER1_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU1_2: cpu at 102 { + compatible = "arm,armv8"; + reg = <0x0 0x102>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER1_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CPU1_3: cpu at 103 { + compatible = "arm,armv8"; + reg = <0x0 0x103>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&CLUSTER1_L2>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + }; + + CLUSTER0_L2: l2-cache0 { + compatible = "cache"; + }; + + CLUSTER1_L2: l2-cache1 { + compatible = "cache"; + }; + }; + + 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)>; + clock-frequency = <100000000>; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + interrupt-affinity = <&CPU0_0>, + <&CPU0_1>, + <&CPU0_2>, + <&CPU0_3>, + <&CPU1_0>, + <&CPU1_1>, + <&CPU1_2>, + <&CPU1_3>; + }; + + gic: interrupt-controller at 2f000000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + reg = <0x0 0x2f000000 0x0 0x10000>, + <0x0 0x2f100000 0x0 0x100000>, + <0x0 0x2c000000 0x0 0x2000>, + <0x0 0x2c010000 0x0 0x2000>, + <0x0 0x2c02f000 0x0 0x2000>; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + + its: its at 2f020000 { + compatible = "arm,gic-v3-its"; + msi-controller; + #msi-cells = <1>; + reg = <0x0 0x2f020000 0x0 0x20000>; + }; + }; + + #include "fvp-base.dtsi" +}; diff --git a/arch/arm64/boot/dts/arm/fvp-base.dtsi b/arch/arm64/boot/dts/arm/fvp-base.dtsi new file mode 100644 index 0000000..ea3f170 --- /dev/null +++ b/arch/arm64/boot/dts/arm/fvp-base.dtsi @@ -0,0 +1,267 @@ + bp_clock35mhz: clock35mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <35000000>; + clock-output-names = "bp:clock35mhz"; + }; + + bp_clock24mhz: clock24mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <24000000>; + clock-output-names = "bp:clock24mhz"; + }; + + flash at 8000000 { + compatible = "arm,vexpress-flash", "cfi-flash"; + reg = <0x0 0x08000000 0x0 0x04000000>, + <0x0 0x0C000000 0x0 0x04000000>; + bank-width = <4>; + }; + + bp_video_ram: vram at 18000000 { + compatible = "arm,vexpress-vram"; + reg = <0x0 0x18000000 0x0 0x00800000>; + }; + + ethernet at 1a000000 { + compatible = "smsc,lan91c111"; + reg = <0x0 0x1a000000 0x0 0x10000>; + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + }; + + bp_sysreg: sysreg at 1c010000 { + compatible = "arm,vexpress-sysreg"; + reg = <0x0 0x1c010000 0x0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + }; + + mcc { + compatible = "arm,vexpress,config-bus"; + arm,vexpress,config-bridge = <&bp_sysreg>; + + bp_oscclk1: oscclk1 { + compatible = "arm,vexpress-osc"; + arm,vexpress-sysreg,func = <1 1>; + freq-range = <23750000 63500000>; + #clock-cells = <0>; + clock-output-names = "bp:oscclk1"; + }; + + muxfpga { + compatible = "arm,vexpress-muxfpga"; + arm,vexpress-sysreg,func = <7 0>; + }; + + shutdown { + compatible = "arm,vexpress-shutdown"; + arm,vexpress-sysreg,func = <8 0>; + }; + + reboot { + compatible = "arm,vexpress-reboot"; + arm,vexpress-sysreg,func = <9 0>; + }; + }; + + sysctl_refclk: sysctl-refclk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <1000000>; + clock-output-names = "sysctl:refclk"; + }; + + sysctl_timclk: sysctl-timclk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + clock-output-names = "sysctl:timclk"; + }; + + bp_sysctl: sysctl at 1c020000 { + compatible = "arm,sp810", "arm,primecell"; + reg = <0x0 0x1c020000 0x0 0x1000>; + clocks = <&sysctl_refclk>, <&sysctl_timclk>, <&bp_clock35mhz>; + clock-names = "refclk", "timclk", "apb_pclk"; + #clock-cells = <1>; + clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3"; + assigned-clocks = <&bp_sysctl 0>, <&bp_sysctl 1>, <&bp_sysctl 3>, <&bp_sysctl 3>; + assigned-clock-parents = <&sysctl_timclk>, <&sysctl_timclk>, <&sysctl_timclk>, <&sysctl_timclk>; + }; + + aaci at 1c040000 { + compatible = "arm,pl041", "arm,primecell"; + reg = <0x0 0x1c040000 0x0 0x1000>; + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>; + clock-names = "apb_pclk"; + }; + + bp_fixed_3v3: bp-3v3 { + compatible = "regulator-fixed"; + regulator-name = "3V3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + mmci at 1c050000 { + compatible = "arm,pl180", "arm,primecell"; + reg = <0x0 0x1c050000 0x0 0x1000>; + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; + cd-gpios = <&bp_sysreg 0 0>; + wp-gpios = <&bp_sysreg 1 0>; + max-frequency = <12000000>; + vmmc-supply = <&bp_fixed_3v3>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "mclk", "apb_pclk"; + }; + + kmi at 1c060000 { + compatible = "arm,pl050", "arm,primecell"; + reg = <0x0 0x1c060000 0x0 0x1000>; + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "KMIREFCLK", "apb_pclk"; + }; + + kmi at 1c070000 { + compatible = "arm,pl050", "arm,primecell"; + reg = <0x0 0x1c070000 0x0 0x1000>; + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "KMIREFCLK", "apb_pclk"; + }; + + bp_serial0: uart at 1c090000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0x1c090000 0x0 0x1000>; + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "uartclk", "apb_pclk"; + }; + + bp_serial1: uart at 1c0a0000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0x1c0a0000 0x0 0x1000>; + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "uartclk", "apb_pclk"; + }; + + bp_serial2: uart at 1c0b0000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0x1c0b0000 0x0 0x1000>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "uartclk", "apb_pclk"; + }; + + bp_serial3: uart at 1c0c0000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0x1c0c0000 0x0 0x1000>; + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "uartclk", "apb_pclk"; + }; + + wdt at 1c0f0000 { + compatible = "arm,sp805", "arm,primecell"; + reg = <0x0 0x1c0f0000 0x0 0x1000>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>, <&bp_clock24mhz>; + clock-names = "wdogclk", "apb_pclk"; + }; + + bp_timer01: timer at 1c110000 { + compatible = "arm,sp804", "arm,primecell"; + reg = <0x0 0x1c110000 0x0 0x1000>; + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_sysctl 0>, <&bp_sysctl 1>, <&bp_clock35mhz>; + clock-names = "timclken1", "timclken2", "apb_pclk"; + }; + + bp_timer23: timer at 1c120000 { + compatible = "arm,sp804", "arm,primecell"; + reg = <0x0 0x1c120000 0x0 0x1000>; + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_sysctl 2>, <&bp_sysctl 3>, <&bp_clock35mhz>; + clock-names = "timclken1", "timclken2", "apb_pclk"; + }; + + virtio_block at 1c0130000 { + compatible = "virtio,mmio"; + reg = <0x0 0x1c130000 0x0 0x200>; + interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>; + }; + + rtc at 1c170000 { + compatible = "arm,pl031", "arm,primecell"; + reg = <0x0 0x1c170000 0x0 0x1000>; + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_clock24mhz>; + clock-names = "apb_pclk"; + }; + + clcd at 1c1f0000 { + compatible = "arm,pl111", "arm,primecell"; + reg = <0x0 0x1c1f0000 0x0 0x1000>; + interrupt-names = "combined"; + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bp_oscclk1>, <&bp_clock24mhz>; + clock-names = "clcdclk", "apb_pclk"; + arm,pl11x,framebuffer = <0x18000000 0x00180000>; + memory-region = <&bp_video_ram>; + max-memory-bandwidth = <130000000>; /* 16bpp @ 63.5MHz */ + + port { + bp_clcd_pads: endpoint { + remote-endpoint = <&bp_clcd_panel>; + arm,pl11x,tft-r0g0b0-pads = <0 8 16>; + }; + }; + + panel { + compatible = "panel-dpi"; + + port { + bp_clcd_panel: endpoint { + remote-endpoint = <&bp_clcd_pads>; + }; + }; + + panel-timing { + clock-frequency = <63500127>; + hactive = <1024>; + hback-porch = <152>; + hfront-porch = <48>; + hsync-len = <104>; + vactive = <768>; + vback-porch = <23>; + vfront-porch = <3>; + vsync-len = <4>; + }; + }; + }; + + timer at 2a810000 { + compatible = "arm,armv7-timer-mem"; + reg = <0x0 0x2a810000 0x0 0x1000>; + clock-frequency = <50000000>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + frame at 2a830000 { + frame-number = <1>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x0 0x2a830000 0x0 0x1000>; + }; + }; + + memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x80000000>, + <0x00000008 0x80000000 0 0x80000000>; + }; -- 2.1.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model 2016-06-20 12:13 ` [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model Jon Medhurst @ 2016-06-20 12:39 ` Mark Rutland 2016-06-20 14:34 ` Jon Medhurst (Tixy) 0 siblings, 1 reply; 11+ messages in thread From: Mark Rutland @ 2016-06-20 12:39 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote: > 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. 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. > Signed-off-by: Jon Medhurst <tixy@linaro.org> > --- > 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(+) > > diff --git a/arch/arm64/boot/dts/arm/Makefile b/arch/arm64/boot/dts/arm/Makefile > index 75cc2aa..7531001 100644 > --- a/arch/arm64/boot/dts/arm/Makefile > +++ b/arch/arm64/boot/dts/arm/Makefile > @@ -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 > diff --git a/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts > new file mode 100644 > index 0000000..2acfd26 > --- /dev/null > +++ b/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dts > @@ -0,0 +1,221 @@ > +/* > + * ARM Ltd. Fixed Virtual Platform (FVP) Base model with dual cluster > + * Architecture Envelope Model (AEM) v8-A CPUs > + */ > + > +/dts-v1/; > + > +#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"; > + > + aliases { > + serial0 = &bp_serial0; > + serial1 = &bp_serial1; > + serial2 = &bp_serial2; > + serial3 = &bp_serial3; > + }; [...] > + 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>; > + }; > + }; [...] > + 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). > + 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. [1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model 2016-06-20 12:39 ` Mark Rutland @ 2016-06-20 14:34 ` Jon Medhurst (Tixy) 2016-06-20 14:55 ` Mark Rutland 0 siblings, 1 reply; 11+ messages in thread From: Jon Medhurst (Tixy) @ 2016-06-20 14:34 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote: > Hi, > > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote: > > 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. > > Which firmware are you using, ARM Trusted Firmware > 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 > 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. > 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. > [1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53 -- Tixy ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model 2016-06-20 14:34 ` Jon Medhurst (Tixy) @ 2016-06-20 14:55 ` Mark Rutland 2016-06-21 18:01 ` Jon Medhurst (Tixy) 0 siblings, 1 reply; 11+ messages in thread From: Mark Rutland @ 2016-06-20 14:55 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote: > On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote: > > Hi, > > > > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote: > > > 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. > > > > Which firmware are you using, > > ARM Trusted Firmware > > > 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 > > > 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? > > 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. > 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. > 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. > I'll fix your other comment on the DT, so snipping email here. Sure, cheers! Thanks, Mark. > > [1] https://github.com/ARM-software/arm-trusted-firmware/commit/6355f2347aec8bf6ad74867c2b0c996e10546ad4#L53 [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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model 2016-06-20 14:55 ` Mark Rutland @ 2016-06-21 18:01 ` Jon Medhurst (Tixy) 2016-06-22 9:35 ` Mark Rutland 0 siblings, 1 reply; 11+ messages in thread From: Jon Medhurst (Tixy) @ 2016-06-21 18:01 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2016-06-20 at 15:55 +0100, Mark Rutland wrote: > On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote: > > On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote: > > > Hi, > > > > > > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote: > > > > 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. > > > > > > Which firmware are you using, > > > > ARM Trusted Firmware > > > > > 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 > > > > > 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 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 ;-) > [3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53 [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 -- Tixy ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model 2016-06-21 18:01 ` Jon Medhurst (Tixy) @ 2016-06-22 9:35 ` Mark Rutland 0 siblings, 0 replies; 11+ messages in thread From: Mark Rutland @ 2016-06-22 9:35 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 07:01:27PM +0100, Jon Medhurst (Tixy) wrote: > On Mon, 2016-06-20 at 15:55 +0100, Mark Rutland wrote: > > On Mon, Jun 20, 2016 at 03:34:37PM +0100, Jon Medhurst (Tixy) wrote: > > > On Mon, 2016-06-20 at 13:39 +0100, Mark Rutland wrote: > > > > Hi, > > > > > > > > On Mon, Jun 20, 2016 at 01:13:16PM +0100, Jon Medhurst wrote: > > > > > 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. > > > > > > > > Which firmware are you using, > > > > > > ARM Trusted Firmware > > > > > > > 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 > > > > > > > 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 > > 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. Ah,ok. > 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 ;-) Great, thanks for digging into that, and apologies for the noise! Thanks, Mark. > > > [3] https://github.com/ARM-software/arm-trusted-firmware/blob/6355f2347aec8bf6ad74867c2b0c996e10546ad4/plat/arm/board/fvp/fvp_pm.c#L53 > > [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 > > -- > Tixy > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models. 2016-06-20 12:13 [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Jon Medhurst 2016-06-20 12:13 ` [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model Jon Medhurst @ 2016-06-21 13:22 ` Rob Herring 2016-06-21 13:38 ` Jon Medhurst (Tixy) 1 sibling, 1 reply; 11+ messages in thread From: Rob Herring @ 2016-06-21 13:22 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 20, 2016 at 01:13:15PM +0100, Jon Medhurst wrote: > List the required properties used to describe ARM's FVP models. > > Signed-off-by: Jon Medhurst <tixy@linaro.org> > --- > Documentation/devicetree/bindings/arm/arm-boards | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards > index ab318a5..4639a9b 100644 > --- a/Documentation/devicetree/bindings/arm/arm-boards > +++ b/Documentation/devicetree/bindings/arm/arm-boards > @@ -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 Naming conventions of the exe aren't going to change? > + this would be: > + compatible = "arm,fvp-base,aemv8a-aemv8a", "arm,fvp-base"; > -- > 2.1.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models. 2016-06-21 13:22 ` [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Rob Herring @ 2016-06-21 13:38 ` Jon Medhurst (Tixy) 2016-06-21 21:33 ` Rob Herring 0 siblings, 1 reply; 11+ messages in thread From: Jon Medhurst (Tixy) @ 2016-06-21 13:38 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote: > > +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? 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. -- Tixy ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models. 2016-06-21 13:38 ` Jon Medhurst (Tixy) @ 2016-06-21 21:33 ` Rob Herring 2016-06-22 8:43 ` Jon Medhurst (Tixy) 0 siblings, 1 reply; 11+ messages in thread From: Rob Herring @ 2016-06-21 21:33 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 02:38:32PM +0100, Jon Medhurst (Tixy) wrote: > On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote: > > > +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? > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models. 2016-06-21 21:33 ` Rob Herring @ 2016-06-22 8:43 ` Jon Medhurst (Tixy) 0 siblings, 0 replies; 11+ messages in thread From: Jon Medhurst (Tixy) @ 2016-06-22 8:43 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2016-06-21 at 16:33 -0500, Rob Herring wrote: > On Tue, Jun 21, 2016 at 02:38:32PM +0100, Jon Medhurst (Tixy) wrote: > > On Tue, 2016-06-21 at 08:22 -0500, Rob Herring wrote: > > > > +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? > > > > 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. 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. > 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) > > We've had models supported upstream for a long time. What's changed now? ARM's software releases are targeting a different model. -- Tixy ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-06-22 9:35 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-20 12:13 [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Jon Medhurst 2016-06-20 12:13 ` [PATCH 2/2] arm64: dts: Add device-tree for ARM's AEMv8A-AEMv8A FVP Base model Jon Medhurst 2016-06-20 12:39 ` Mark Rutland 2016-06-20 14:34 ` Jon Medhurst (Tixy) 2016-06-20 14:55 ` Mark Rutland 2016-06-21 18:01 ` Jon Medhurst (Tixy) 2016-06-22 9:35 ` Mark Rutland 2016-06-21 13:22 ` [PATCH 1/2] Documentation: bindings: Add DT bindings for ARM's FVP models Rob Herring 2016-06-21 13:38 ` Jon Medhurst (Tixy) 2016-06-21 21:33 ` Rob Herring 2016-06-22 8:43 ` Jon Medhurst (Tixy)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).