* [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-25 19:46 ` nick.hawkins
0 siblings, 0 replies; 27+ messages in thread
From: nick.hawkins @ 2022-01-25 19:46 UTC (permalink / raw)
To: verdun
Cc: nick.hawkins, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
From: Nick Hawkins <nick.hawkins@hpe.com>
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 8 +
arch/arm/Kconfig | 2 +
arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
arch/arm/configs/gxp_defconfig | 243 ++++++
arch/arm/mach-hpe/Kconfig | 20 +
arch/arm/mach-hpe/Makefile | 1 +
arch/arm/mach-hpe/gxp.c | 63 ++
8 files changed, 1039 insertions(+)
create mode 100644 arch/arm/boot/dts/gxp.dts
create mode 100644 arch/arm/configs/gxp_defconfig
create mode 100644 arch/arm/mach-hpe/Kconfig
create mode 100644 arch/arm/mach-hpe/Makefile
create mode 100644 arch/arm/mach-hpe/gxp.c
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 294093d45a23..e8b0ec874aed 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -515,6 +515,8 @@ patternProperties:
description: Jiangsu HopeRun Software Co., Ltd.
"^hp,.*":
description: Hewlett Packard
+ "^hpe,.*":
+ description: Hewlett Packard Enterprise
"^hsg,.*":
description: HannStar Display Co.
"^holtek,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..007d99734dd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8382,6 +8382,14 @@ L: linux-efi@vger.kernel.org
S: Maintained
F: block/partitions/efi.*
+GXP ARCHITECTURE
+M: Jean-Marie Verdun <verdun@hpe.com>
+M: Nick Hawkins <nick.hawkins@hpe.com>
+S: Maintained
+F: arch/arm/boot/dts/gxp.dts
+F: arch/arm/configs/gxp_defconfig
+F: arch/arm/mach-hpe/gxp.c
+
H8/300 ARCHITECTURE
M: Yoshinori Sato <ysato@users.sourceforge.jp>
L: uclinux-h8-devel@lists.sourceforge.jp (moderated for non-subscribers)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fabe39169b12..d428d0d35889 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -708,6 +708,8 @@ source "arch/arm/mach-vt8500/Kconfig"
source "arch/arm/mach-zynq/Kconfig"
+source "arch/arm/mach-hpe/Kconfig"
+
# ARMv7-M architecture
config ARCH_LPC18XX
bool "NXP LPC18xx/LPC43xx"
diff --git a/arch/arm/boot/dts/gxp.dts b/arch/arm/boot/dts/gxp.dts
new file mode 100644
index 000000000000..7bd814ecaaee
--- /dev/null
+++ b/arch/arm/boot/dts/gxp.dts
@@ -0,0 +1,700 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE GXP
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "HPE,GXP";
+ model = "GXP";
+
+ chosen {
+ bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
+ };
+
+ aliases {
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x20000000>;
+ };
+
+ ahb@80000000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ vic0: vic@ceff0000 {
+ compatible = "arm,pl192-vic";
+ interrupt-controller;
+ reg = <0xceff0000 0x1000>;
+ #interrupt-cells = <1>;
+ };
+
+ vic1: vic@80f00000 {
+ compatible = "arm,pl192-vic";
+ interrupt-controller;
+ reg = <0x80f00000 0x1000>;
+ #interrupt-cells = <1>;
+ };
+
+ timer0: timer@c0000080 {
+ compatible = "hpe,gxp-timer";
+ reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
+ interrupts = <0>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <400000000>;
+ };
+
+ watchdog: watchdog@c0000090 {
+ compatible = "hpe,gxp-wdt";
+ reg = <0xc0000090 0x02>, <0xc0000096 0x01>;
+ };
+
+ uartc: serial@c00000f0 {
+ compatible = "ns16550a";
+ reg = <0xc00000f0 0x8>;
+ interrupts = <19>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ };
+
+ uarta: serial@c00000e0 {
+ compatible = "ns16550a";
+ reg = <0xc00000e0 0x8>;
+ interrupts = <17>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ };
+
+ uartb: serial@c00000e8 {
+ compatible = "ns16550a";
+ reg = <0xc00000e8 0x8>;
+ interrupts = <18>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ };
+
+ vuart_a_cfg: vuarta_cfg@80fc0230 {
+ compatible = "hpe,gxp-vuarta_cfg", "simple-mfd", "syscon";
+ reg = <0x80fc0230 0x100>;
+ reg-io-width = <1>;
+ };
+
+ vuart_a: vuart_a@80fd0200 {
+ compatible = "hpe,gxp-vuart";
+ reg = <0x80fd0200 0x100>;
+ interrupts = <2>;
+ interrupt-parent = <&vic1>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ status = "okay";
+ serial-line = <3>;
+ vuart_cfg = <&vuart_a_cfg>;
+ };
+
+ usb0: ehci@cefe0000 {
+ compatible = "generic-ehci";
+ reg = <0xcefe0000 0x100>;
+ interrupts = <7>;
+ interrupt-parent = <&vic0>;
+ };
+
+ usb1: ohci@cefe0100 {
+ compatible = "generic-ohci";
+ reg = <0xcefe0100 0x110>;
+ interrupts = <6>;
+ interrupt-parent = <&vic0>;
+ };
+
+ spifi0: spifi@c0000200 {
+ compatible = "hpe,gxp-spifi";
+ reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
+ interrupts = <20>;
+ interrupt-parent = <&vic0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bmc@0 {
+ label = "bmc";
+ reg = <0x0 0x2000000>;
+ };
+ u-boot@0 {
+ label = "u-boot";
+ reg = <0x0 0x60000>;
+ };
+ u-boot-env@60000 {
+ label = "u-boot-env";
+ reg = <0x60000 0x20000>;
+ };
+ kernel@80000 {
+ label = "kernel";
+ reg = <0x80000 0x4c0000>;
+ };
+ rofs@540000 {
+ label = "rofs";
+ reg = <0x540000 0x1740000>;
+ };
+ rwfs@1c80000 {
+ label = "rwfs";
+ reg = <0x1c80000 0x250000>;
+ };
+ section@1edf000{
+ label = "section";
+ reg = <0x1ed0000 0x130000>;
+ };
+ };
+ };
+
+ flash@1 {
+ compatible = "jedec,spi-nor";
+ reg = <1>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ host-prime@0 {
+ label = "host-prime";
+ reg = <0x0 0x02000000>;
+ };
+ host-second@0 {
+ label = "host-second";
+ reg = <0x02000000 0x02000000>;
+ };
+ };
+ };
+ };
+
+ sram@d0000000 {
+ compatible = "mtd-ram";
+ reg = <0xd0000000 0x80000>;
+ bank-width = <1>;
+ erase-size =<1>;
+ partition@0 {
+ label = "host-reserved";
+ reg = <0x0 0x10000>;
+ };
+ partition@10000 {
+ label = "nvram";
+ reg = <0x10000 0x70000>;
+ };
+ };
+
+ srom@80fc0000 {
+ compatible = "hpe,gxp-srom", "simple-mfd", "syscon";
+ reg = <0x80fc0000 0x100>;
+ };
+
+ vrom@58000000 {
+ compatible = "mtd-ram";
+ bank-width = <4>;
+ reg = <0x58000000 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "vrom-prime";
+ reg = <0x0 0x2000000>;
+ };
+ partition@2000000 {
+ label = "vrom-second";
+ reg = <0x2000000 0x2000000>;
+ };
+ };
+
+ i2cg: i2cg@c00000f8 {
+ compatible = "syscon";
+ reg = <0xc00000f8 0x08>;
+ };
+
+ i2c0: i2c@c0002000 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002000 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@c0002100 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002100 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@c0002200 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002200 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ 24c02@50 {
+ compatible = "atmel,24c02";
+ pagesize = <8>;
+ reg = <0x50>;
+ };
+ };
+
+ i2c3: i2c@c0002300 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002300 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4: i2c@c0002400 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002400 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c5: i2c@c0002500 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002500 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ };
+
+ i2c6: i2c@c0002600 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002600 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c7: i2c@c0002700 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002700 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ psu1: psu@58 {
+ compatible = "hpe,gxp-psu";
+ reg = <0x58>;
+ };
+
+ psu2: psu@59 {
+ compatible = "hpe,gxp-psu";
+ reg = <0x59>;
+ };
+ };
+
+ i2c8: i2c@c0002800 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002800 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c9: i2c@c0002900 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002900 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2cmux@4 {
+ compatible = "i2c-mux-reg";
+ i2c-parent = <&i2c4>;
+ reg = <0xd1000074 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c4@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ i2cmux@6 {
+ compatible = "i2c-mux-reg";
+ i2c-parent = <&i2c6>;
+ reg = <0xd1000076 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c6@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@5 {
+ reg = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ mdio0: mdio@c0004080 {
+ compatible = "hpe,gxp-umac-mdio";
+ reg = <0xc0004080 0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ext_phy0: ethernt-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ phy-mode = "sgmii";
+ reg = <0>;
+ };
+ };
+
+ mdio1: mdio@c0005080 {
+ compatible = "hpe,gxp-umac-mdio";
+ reg = <0xc0005080 0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_phy0: ethernt-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ phy-mode = "gmii";
+ reg = <0>;
+ };
+ int_phy1: ethernt-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ phy-mode = "gmii";
+ reg = <1>;
+ };
+ };
+
+ umac0: umac@c0004000 {
+ compatible = "hpe, gxp-umac";
+ reg = <0xc0004000 0x80>;
+ interrupts = <10>;
+ interrupt-parent = <&vic0>;
+ mac-address = [94 18 82 16 04 d8];
+ phy-handle = <&ext_phy0>;
+ int-phy-handle = <&int_phy0>;
+ };
+
+ umac1: umac@c0005000 {
+ compatible = "hpe, gxp-umac";
+ use-ncsi;
+ reg = <0xc0005000 0x80>;
+ interrupts = <11>;
+ interrupt-parent = <&vic0>;
+ mac-address = [94 18 82 16 04 d9];
+ phy-handle = <&int_phy1>;
+ };
+
+ kcs_conf: kcs_conf@80fc0430 {
+ compatible = "hpe,gxp-kcs-bmc-cfg", "simple-mfd", "syscon";
+ reg = <0x80fc0430 0x100>;
+ };
+
+ kcs_reg: kcs_reg@080fd0400 {
+ compatible = "hpe,gxp-kcs-bmc";
+ reg = <0x80fd0400 0x8>;
+ interrupts = <6>;
+ interrupt-parent = <&vic1>;
+ kcs_chan = <1>;
+ status = "okay";
+ kcs-bmc-cfg = <&kcs_conf>;
+ };
+
+ thumbnail: thumbnail@c0000500 {
+ compatible = "hpe,gxp-thumbnail";
+ reg = <0xc0000500 0x20>;
+ bits-per-pixel = <32>;
+ width = <800>;
+ height = <600>;
+ };
+
+ xreg: xreg@d1000000 {
+ compatible = "hpe,gxp-xreg", "simple-mfd", "syscon";
+ reg = <0xd1000000 0xFF>;
+ interrupts = <26>;
+ interrupt-parent = <&vic0>;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "", "", "", "", "", "", "POWER", "HEARTBEAT", "FAN1_INST", "FAN2_INST",
+ "FAN3_INST", "FAN4_INST", "FAN5_INST", "FAN6_INST", "FAN7_INST",
+ "FAN8_INST", "FAN9_INST", "FAN10_INST", "FAN11_INST", "FAN12_INST",
+ "FAN13_INST", "FAN14_INST", "FAN15_INST", "FAN16_INST", "FAN1_FAIL",
+ "FAN2_FAIL", "FAN3_FAIL", "FAN4_FAIL", "FAN5_FAIL", "FAN6_FAIL",
+ "FAN7_FAIL", "FAN8_FAIL", "FAN9_FAIL", "FAN10_FAIL", "FAN11_FAIL",
+ "FAN12_FAIL", "FAN13_FAIL", "FAN14_FAIL", "FAN15_FAIL", "FAN16_FAIL",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "IDENTIFY", "HEALTH_RED", "HEALTH_AMBER",
+ "POWER_BUTTON", "", "SIO_POWER_GOOD", "NMI_BUTTON", "RESET_BUTTON",
+ "SIO_S5", "SIO_ONCONTROL", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "";
+ };
+
+ fanctrl: fanctrl@c1000c00 {
+ compatible = "hpe,gxp-fan-ctrl";
+ reg = <0xc1000c00 0x200>;
+ xreg_handle = <&xreg>;
+ fn2_handle = <&fn2>;
+ };
+
+ fn2: fn2@80200000 {
+ compatible = "hpe,gxp-fn2", "simple-mfd", "syscon";
+ reg = <0x80200000 0x100000>;
+ xreg_handle = <&xreg>;
+ interrupts = <0>;
+ interrupt-parent = <&vic1>;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "POWER_OUT", "PS_PWROK", "PCIERST", "POST_COMPLETE", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "";
+ chif {
+ compatible = "hpe,gxp-chif";
+ interrupts = <12>;
+ };
+ };
+
+ csm: csm@80000000 {
+ compatible = "hpe,gxp-csm", "simple-mfd", "syscon";
+ reg = <0x80000000 0x400>;
+ };
+
+ gpio: gpio@0 {
+ compatible = "hpe,gxp-gpio";
+ #gpio-cells = <2>;
+ csm_handle = <&csm>;
+ vuhc0_handle = <&vuhc0>;
+ gpio-line-names =
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "RESET_OUT", "NMI_OUT", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "";
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+
+ power {
+ gpios = <&xreg 6 0>;
+ default-state = "off";
+ };
+
+ heartbeat {
+ gpios = <&xreg 7 0>;
+ default-state = "off";
+ };
+
+ identify {
+ gpios = <&xreg 56 0>;
+ default-state = "off";
+ };
+
+ health_red {
+ gpios = <&xreg 57 0>;
+ default-state = "off";
+ };
+
+ health_amber {
+ gpios = <&xreg 58 0>;
+ default-state = "off";
+ };
+ };
+
+ xreg_kyes: xreg_keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ IdButton {
+ label = "ID Button";
+ linux,code = <200>;
+ gpios = <&xreg 60 1>;
+ };
+ };
+
+ vuhc: vuhc {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ PortOwner@0 {
+ label = "Port Owner";
+ linux,code = <200>;
+ gpios = <&gpio 250 1>;
+ };
+
+ PortOwner@1 {
+ label = "Port Owner";
+ linux,code = <201>;
+ gpios = <&gpio 251 1>;
+ };
+ };
+
+ vuhc0: vuhc@80400080 {
+ compatible = "syscon";
+ reg = <0x80400000 0x80>;
+ };
+
+ udcg: udcg@80400800 {
+ compatible = "syscon";
+ reg = <0x80400800 0x200>;
+ };
+
+ udc0: udc@80401000 {
+ compatible = "hpe, gxp-udc";
+ reg = <0x80401000 0x1000>;
+ interrupts = <13>;
+ interrupt-parent = <&vic1>;
+ vdevnum = <0>;
+ fepnum = <7>;
+ udcg-handle = <&udcg>;
+ };
+
+ udc1: udc@80402000 {
+ compatible = "hpe, gxp-udc";
+ reg = <0x80402000 0x1000>;
+ interrupts = <13>;
+ interrupt-parent = <&vic1>;
+ vdevnum = <1>;
+ fepnum = <7>;
+ udcg-handle = <&udcg>;
+ };
+
+ coretemp: coretemp@c0000130 {
+ compatible = "hpe,gxp-coretemp";
+ reg = <0xc0000130 0x8>;
+ };
+
+ syspower: syspower {
+ compatible = "hpe,gxp-power";
+ psu_phandle = <&psu1>, <&psu2>;
+ };
+
+ peci: peci@80000400 {
+ compatible = "hpe,gxp-peci";
+ reg = <0x80000400 0x200>;
+ interrupts = <22>;
+ interrupt-parent = <&vic1>;
+ };
+ };
+
+ clocks {
+ osc: osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "osc";
+ clock-frequency = <33333333>;
+ };
+
+ iopclk: iopclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clocks = <&osc>;
+ clock-out-put-names = "iopclk";
+ clock-frequency = <400000000>;
+ };
+
+ memclk: memclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clocks = <&osc>;
+ clock-out-put-names = "memclk";
+ clock-frequency = <800000000>;
+ };
+ };
+};
diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
new file mode 100644
index 000000000000..f37c6630e06d
--- /dev/null
+++ b/arch/arm/configs/gxp_defconfig
@@ -0,0 +1,243 @@
+CONFIG_KERNEL_XZ=y
+CONFIG_DEFAULT_HOSTNAME="gxp"
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_NAMESPACES=y
+CONFIG_SCHED_AUTOGROUP=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLAB=y
+CONFIG_ARCH_MULTI_V6=y
+CONFIG_ARCH_HPE=y
+CONFIG_ARCH_HPE_GXP=y
+CONFIG_SECCOMP=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+# CONFIG_SUSPEND is not set
+CONFIG_JUMP_LABEL=y
+# CONFIG_STRICT_KERNEL_RWX is not set
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_KSM=y
+CONFIG_CLEANCACHE=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_XFRM_STATISTICS=y
+CONFIG_INET=y
+CONFIG_VLAN_8021Q=y
+CONFIG_NETLINK_DIAG=y
+CONFIG_NET_NCSI=y
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_PLATRAM=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_GXP_SPIFI=y
+CONFIG_BLK_DEV_NULL_BLK=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_NBD=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ALACRITECH is not set
+# CONFIG_NET_VENDOR_AMAZON is not set
+# CONFIG_NET_VENDOR_AQUANTIA is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_VENDOR_AURORA is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CADENCE is not set
+# CONFIG_NET_VENDOR_CAVIUM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_CORTINA is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_GOOGLE is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_HUAWEI is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_MICROSEMI is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NETRONOME is not set
+# CONFIG_NET_VENDOR_NI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SOLARFLARE is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_SOCIONEXT is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_NET_VENDOR_XILINX is not set
+CONFIG_UMAC=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+CONFIG_VT_HW_CONSOLE_BINDING=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=6
+CONFIG_SERIAL_8250_RUNTIME_UARTS=6
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_8250_GXP_VUART=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_TTY_PRINTK=y
+CONFIG_IPMI_HANDLER=y
+CONFIG_IPMI_DEVICE_INTERFACE=y
+CONFIG_IPMI_SI=y
+CONFIG_IPMI_SSIF=y
+CONFIG_HPE_KCS_IPMI_BMC=y
+CONFIG_HW_RANDOM_TIMERIOMEM=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_GXP=y
+CONFIG_I2C_SLAVE=y
+CONFIG_I2C_SLAVE_EEPROM=y
+CONFIG_SPI=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_GXP=y
+CONFIG_SENSORS_EMC1403=y
+CONFIG_SENSORS_GXP_FAN_CTRL=y
+CONFIG_SENSORS_GXP_CORETEMP=y
+CONFIG_SENSORS_GXP_PSU=y
+CONFIG_SENSORS_GXP_POWER=y
+CONFIG_WATCHDOG=y
+CONFIG_GXP_WATCHDOG=y
+CONFIG_MFD_SYSCON=y
+CONFIG_FB=y
+CONFIG_FB_THUMBNAIL=y
+CONFIG_FB_SIMPLE=y
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GXP_UDC=y
+CONFIG_USB_CONFIGFS=y
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_CONFIGFS_F_HID=y
+CONFIG_USB_CONFIGFS_F_PRINTER=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_MTD=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_TRANSIENT=y
+CONFIG_LEDS_TRIGGER_PANIC=y
+# CONFIG_VIRTIO_MENU is not set
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_HPE_GXP_XREG=y
+CONFIG_HPE_GXP_FN2=y
+CONFIG_HPE_GXP_CSM=y
+CONFIG_HPE_GXP_SROM=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_OVERLAY_FS_REDIRECT_DIR=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_JFFS2_FS=y
+# CONFIG_JFFS2_FS_WRITEBUFFER is not set
+CONFIG_JFFS2_SUMMARY=y
+CONFIG_JFFS2_FS_XATTR=y
+# CONFIG_JFFS2_FS_POSIX_ACL is not set
+# CONFIG_JFFS2_FS_SECURITY is not set
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
+# CONFIG_NETWORK_FILESYSTEMS is not set
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEFLATE=y
+CONFIG_CRYPTO_LZO=y
+CONFIG_CRYPTO_ZSTD=y
+CONFIG_CRYPTO_USER_API_HASH=y
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC16=y
+# CONFIG_XZ_DEC_ARM is not set
+# CONFIG_XZ_DEC_ARMTHUMB is not set
+CONFIG_DMA_API_DEBUG=y
+CONFIG_PRINTK_TIME=y
+CONFIG_BOOT_PRINTK_DELAY=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_FUNCTION_PROFILER=y
+CONFIG_STACK_TRACER=y
+CONFIG_SCHED_TRACER=y
+CONFIG_STRICT_DEVMEM=y
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_DEBUG_LL_UART_8250=y
+CONFIG_DEBUG_UART_PHYS=0xC00000F0
+CONFIG_DEBUG_UART_VIRT=0xF00000F0
+CONFIG_DEBUG_UART_8250_SHIFT=0
+CONFIG_EARLY_PRINTK=y
+CONFIG_TEST_KSTRTOX=y
diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
new file mode 100644
index 000000000000..9b27f97c6536
--- /dev/null
+++ b/arch/arm/mach-hpe/Kconfig
@@ -0,0 +1,20 @@
+menuconfig ARCH_HPE
+ bool "HPE SoC support"
+ help
+ This enables support for HPE ARM based SoC chips
+if ARCH_HPE
+
+config ARCH_HPE_GXP
+ bool "HPE GXP SoC"
+ select ARM_VIC
+ select PINCTRL
+ select IRQ_DOMAIN
+ select GENERIC_IRQ_CHIP
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
+ select CLKSRC_MMIO
+ depends on ARCH_MULTI_V7
+ help
+ Support for GXP SoCs
+
+endif
diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
new file mode 100644
index 000000000000..8b0a91234df4
--- /dev/null
+++ b/arch/arm/mach-hpe/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_HPE_GXP) += gxp.o
diff --git a/arch/arm/mach-hpe/gxp.c b/arch/arm/mach-hpe/gxp.c
new file mode 100644
index 000000000000..b58f25fbae5a
--- /dev/null
+++ b/arch/arm/mach-hpe/gxp.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+
+#include <linux/init.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+
+#define IOP_REGS_PHYS_BASE 0xc0000000
+#define IOP_REGS_VIRT_BASE 0xf0000000
+#define IOP_REGS_SIZE (240*SZ_1M)
+
+#define IOP_EHCI_USBCMD 0x0efe0010
+
+static struct map_desc gxp_io_desc[] __initdata = {
+ {
+ .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
+ .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
+ .length = IOP_REGS_SIZE,
+ .type = MT_DEVICE,
+ },
+};
+
+void __init gxp_map_io(void)
+{
+ iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
+}
+
+static void __init gxp_dt_init(void)
+{
+ //reset EHCI host controller for clear start
+ __raw_writel(0x00080002,
+ (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void gxp_restart(enum reboot_mode mode, const char *cmd)
+{
+ pr_info("gpx restart");
+ __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
+}
+
+static const char * const gxp_board_dt_compat[] = {
+ "HPE,GXP",
+ NULL,
+};
+
+DT_MACHINE_START(GXP_DT, "HPE GXP")
+ .init_machine = gxp_dt_init,
+ .map_io = gxp_map_io,
+ .restart = gxp_restart,
+ .dt_compat = gxp_board_dt_compat,
+MACHINE_END
--
2.17.1
^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-25 19:46 ` nick.hawkins
0 siblings, 0 replies; 27+ messages in thread
From: nick.hawkins @ 2022-01-25 19:46 UTC (permalink / raw)
To: verdun
Cc: nick.hawkins, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
From: Nick Hawkins <nick.hawkins@hpe.com>
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 8 +
arch/arm/Kconfig | 2 +
arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
arch/arm/configs/gxp_defconfig | 243 ++++++
arch/arm/mach-hpe/Kconfig | 20 +
arch/arm/mach-hpe/Makefile | 1 +
arch/arm/mach-hpe/gxp.c | 63 ++
8 files changed, 1039 insertions(+)
create mode 100644 arch/arm/boot/dts/gxp.dts
create mode 100644 arch/arm/configs/gxp_defconfig
create mode 100644 arch/arm/mach-hpe/Kconfig
create mode 100644 arch/arm/mach-hpe/Makefile
create mode 100644 arch/arm/mach-hpe/gxp.c
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 294093d45a23..e8b0ec874aed 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -515,6 +515,8 @@ patternProperties:
description: Jiangsu HopeRun Software Co., Ltd.
"^hp,.*":
description: Hewlett Packard
+ "^hpe,.*":
+ description: Hewlett Packard Enterprise
"^hsg,.*":
description: HannStar Display Co.
"^holtek,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..007d99734dd1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8382,6 +8382,14 @@ L: linux-efi@vger.kernel.org
S: Maintained
F: block/partitions/efi.*
+GXP ARCHITECTURE
+M: Jean-Marie Verdun <verdun@hpe.com>
+M: Nick Hawkins <nick.hawkins@hpe.com>
+S: Maintained
+F: arch/arm/boot/dts/gxp.dts
+F: arch/arm/configs/gxp_defconfig
+F: arch/arm/mach-hpe/gxp.c
+
H8/300 ARCHITECTURE
M: Yoshinori Sato <ysato@users.sourceforge.jp>
L: uclinux-h8-devel@lists.sourceforge.jp (moderated for non-subscribers)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fabe39169b12..d428d0d35889 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -708,6 +708,8 @@ source "arch/arm/mach-vt8500/Kconfig"
source "arch/arm/mach-zynq/Kconfig"
+source "arch/arm/mach-hpe/Kconfig"
+
# ARMv7-M architecture
config ARCH_LPC18XX
bool "NXP LPC18xx/LPC43xx"
diff --git a/arch/arm/boot/dts/gxp.dts b/arch/arm/boot/dts/gxp.dts
new file mode 100644
index 000000000000..7bd814ecaaee
--- /dev/null
+++ b/arch/arm/boot/dts/gxp.dts
@@ -0,0 +1,700 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE GXP
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "HPE,GXP";
+ model = "GXP";
+
+ chosen {
+ bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
+ };
+
+ aliases {
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x40000000 0x20000000>;
+ };
+
+ ahb@80000000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ vic0: vic@ceff0000 {
+ compatible = "arm,pl192-vic";
+ interrupt-controller;
+ reg = <0xceff0000 0x1000>;
+ #interrupt-cells = <1>;
+ };
+
+ vic1: vic@80f00000 {
+ compatible = "arm,pl192-vic";
+ interrupt-controller;
+ reg = <0x80f00000 0x1000>;
+ #interrupt-cells = <1>;
+ };
+
+ timer0: timer@c0000080 {
+ compatible = "hpe,gxp-timer";
+ reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
+ interrupts = <0>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <400000000>;
+ };
+
+ watchdog: watchdog@c0000090 {
+ compatible = "hpe,gxp-wdt";
+ reg = <0xc0000090 0x02>, <0xc0000096 0x01>;
+ };
+
+ uartc: serial@c00000f0 {
+ compatible = "ns16550a";
+ reg = <0xc00000f0 0x8>;
+ interrupts = <19>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ };
+
+ uarta: serial@c00000e0 {
+ compatible = "ns16550a";
+ reg = <0xc00000e0 0x8>;
+ interrupts = <17>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ };
+
+ uartb: serial@c00000e8 {
+ compatible = "ns16550a";
+ reg = <0xc00000e8 0x8>;
+ interrupts = <18>;
+ interrupt-parent = <&vic0>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ };
+
+ vuart_a_cfg: vuarta_cfg@80fc0230 {
+ compatible = "hpe,gxp-vuarta_cfg", "simple-mfd", "syscon";
+ reg = <0x80fc0230 0x100>;
+ reg-io-width = <1>;
+ };
+
+ vuart_a: vuart_a@80fd0200 {
+ compatible = "hpe,gxp-vuart";
+ reg = <0x80fd0200 0x100>;
+ interrupts = <2>;
+ interrupt-parent = <&vic1>;
+ clock-frequency = <1846153>;
+ reg-shift = <0>;
+ status = "okay";
+ serial-line = <3>;
+ vuart_cfg = <&vuart_a_cfg>;
+ };
+
+ usb0: ehci@cefe0000 {
+ compatible = "generic-ehci";
+ reg = <0xcefe0000 0x100>;
+ interrupts = <7>;
+ interrupt-parent = <&vic0>;
+ };
+
+ usb1: ohci@cefe0100 {
+ compatible = "generic-ohci";
+ reg = <0xcefe0100 0x110>;
+ interrupts = <6>;
+ interrupt-parent = <&vic0>;
+ };
+
+ spifi0: spifi@c0000200 {
+ compatible = "hpe,gxp-spifi";
+ reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
+ interrupts = <20>;
+ interrupt-parent = <&vic0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bmc@0 {
+ label = "bmc";
+ reg = <0x0 0x2000000>;
+ };
+ u-boot@0 {
+ label = "u-boot";
+ reg = <0x0 0x60000>;
+ };
+ u-boot-env@60000 {
+ label = "u-boot-env";
+ reg = <0x60000 0x20000>;
+ };
+ kernel@80000 {
+ label = "kernel";
+ reg = <0x80000 0x4c0000>;
+ };
+ rofs@540000 {
+ label = "rofs";
+ reg = <0x540000 0x1740000>;
+ };
+ rwfs@1c80000 {
+ label = "rwfs";
+ reg = <0x1c80000 0x250000>;
+ };
+ section@1edf000{
+ label = "section";
+ reg = <0x1ed0000 0x130000>;
+ };
+ };
+ };
+
+ flash@1 {
+ compatible = "jedec,spi-nor";
+ reg = <1>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ host-prime@0 {
+ label = "host-prime";
+ reg = <0x0 0x02000000>;
+ };
+ host-second@0 {
+ label = "host-second";
+ reg = <0x02000000 0x02000000>;
+ };
+ };
+ };
+ };
+
+ sram@d0000000 {
+ compatible = "mtd-ram";
+ reg = <0xd0000000 0x80000>;
+ bank-width = <1>;
+ erase-size =<1>;
+ partition@0 {
+ label = "host-reserved";
+ reg = <0x0 0x10000>;
+ };
+ partition@10000 {
+ label = "nvram";
+ reg = <0x10000 0x70000>;
+ };
+ };
+
+ srom@80fc0000 {
+ compatible = "hpe,gxp-srom", "simple-mfd", "syscon";
+ reg = <0x80fc0000 0x100>;
+ };
+
+ vrom@58000000 {
+ compatible = "mtd-ram";
+ bank-width = <4>;
+ reg = <0x58000000 0x4000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "vrom-prime";
+ reg = <0x0 0x2000000>;
+ };
+ partition@2000000 {
+ label = "vrom-second";
+ reg = <0x2000000 0x2000000>;
+ };
+ };
+
+ i2cg: i2cg@c00000f8 {
+ compatible = "syscon";
+ reg = <0xc00000f8 0x08>;
+ };
+
+ i2c0: i2c@c0002000 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002000 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@c0002100 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002100 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@c0002200 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002200 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ 24c02@50 {
+ compatible = "atmel,24c02";
+ pagesize = <8>;
+ reg = <0x50>;
+ };
+ };
+
+ i2c3: i2c@c0002300 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002300 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4: i2c@c0002400 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002400 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c5: i2c@c0002500 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002500 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ };
+
+ i2c6: i2c@c0002600 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002600 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c7: i2c@c0002700 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002700 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ psu1: psu@58 {
+ compatible = "hpe,gxp-psu";
+ reg = <0x58>;
+ };
+
+ psu2: psu@59 {
+ compatible = "hpe,gxp-psu";
+ reg = <0x59>;
+ };
+ };
+
+ i2c8: i2c@c0002800 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002800 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c9: i2c@c0002900 {
+ compatible = "hpe,gxp-i2c";
+ reg = <0xc0002900 0x70>;
+ interrupts = <9>;
+ interrupt-parent = <&vic0>;
+ i2cg-handle = <&i2cg>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2cmux@4 {
+ compatible = "i2c-mux-reg";
+ i2c-parent = <&i2c4>;
+ reg = <0xd1000074 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c4@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ i2cmux@6 {
+ compatible = "i2c-mux-reg";
+ i2c-parent = <&i2c6>;
+ reg = <0xd1000076 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c6@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c6@5 {
+ reg = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ mdio0: mdio@c0004080 {
+ compatible = "hpe,gxp-umac-mdio";
+ reg = <0xc0004080 0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ext_phy0: ethernt-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ phy-mode = "sgmii";
+ reg = <0>;
+ };
+ };
+
+ mdio1: mdio@c0005080 {
+ compatible = "hpe,gxp-umac-mdio";
+ reg = <0xc0005080 0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_phy0: ethernt-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ phy-mode = "gmii";
+ reg = <0>;
+ };
+ int_phy1: ethernt-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ phy-mode = "gmii";
+ reg = <1>;
+ };
+ };
+
+ umac0: umac@c0004000 {
+ compatible = "hpe, gxp-umac";
+ reg = <0xc0004000 0x80>;
+ interrupts = <10>;
+ interrupt-parent = <&vic0>;
+ mac-address = [94 18 82 16 04 d8];
+ phy-handle = <&ext_phy0>;
+ int-phy-handle = <&int_phy0>;
+ };
+
+ umac1: umac@c0005000 {
+ compatible = "hpe, gxp-umac";
+ use-ncsi;
+ reg = <0xc0005000 0x80>;
+ interrupts = <11>;
+ interrupt-parent = <&vic0>;
+ mac-address = [94 18 82 16 04 d9];
+ phy-handle = <&int_phy1>;
+ };
+
+ kcs_conf: kcs_conf@80fc0430 {
+ compatible = "hpe,gxp-kcs-bmc-cfg", "simple-mfd", "syscon";
+ reg = <0x80fc0430 0x100>;
+ };
+
+ kcs_reg: kcs_reg@080fd0400 {
+ compatible = "hpe,gxp-kcs-bmc";
+ reg = <0x80fd0400 0x8>;
+ interrupts = <6>;
+ interrupt-parent = <&vic1>;
+ kcs_chan = <1>;
+ status = "okay";
+ kcs-bmc-cfg = <&kcs_conf>;
+ };
+
+ thumbnail: thumbnail@c0000500 {
+ compatible = "hpe,gxp-thumbnail";
+ reg = <0xc0000500 0x20>;
+ bits-per-pixel = <32>;
+ width = <800>;
+ height = <600>;
+ };
+
+ xreg: xreg@d1000000 {
+ compatible = "hpe,gxp-xreg", "simple-mfd", "syscon";
+ reg = <0xd1000000 0xFF>;
+ interrupts = <26>;
+ interrupt-parent = <&vic0>;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "", "", "", "", "", "", "POWER", "HEARTBEAT", "FAN1_INST", "FAN2_INST",
+ "FAN3_INST", "FAN4_INST", "FAN5_INST", "FAN6_INST", "FAN7_INST",
+ "FAN8_INST", "FAN9_INST", "FAN10_INST", "FAN11_INST", "FAN12_INST",
+ "FAN13_INST", "FAN14_INST", "FAN15_INST", "FAN16_INST", "FAN1_FAIL",
+ "FAN2_FAIL", "FAN3_FAIL", "FAN4_FAIL", "FAN5_FAIL", "FAN6_FAIL",
+ "FAN7_FAIL", "FAN8_FAIL", "FAN9_FAIL", "FAN10_FAIL", "FAN11_FAIL",
+ "FAN12_FAIL", "FAN13_FAIL", "FAN14_FAIL", "FAN15_FAIL", "FAN16_FAIL",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "IDENTIFY", "HEALTH_RED", "HEALTH_AMBER",
+ "POWER_BUTTON", "", "SIO_POWER_GOOD", "NMI_BUTTON", "RESET_BUTTON",
+ "SIO_S5", "SIO_ONCONTROL", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "";
+ };
+
+ fanctrl: fanctrl@c1000c00 {
+ compatible = "hpe,gxp-fan-ctrl";
+ reg = <0xc1000c00 0x200>;
+ xreg_handle = <&xreg>;
+ fn2_handle = <&fn2>;
+ };
+
+ fn2: fn2@80200000 {
+ compatible = "hpe,gxp-fn2", "simple-mfd", "syscon";
+ reg = <0x80200000 0x100000>;
+ xreg_handle = <&xreg>;
+ interrupts = <0>;
+ interrupt-parent = <&vic1>;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "POWER_OUT", "PS_PWROK", "PCIERST", "POST_COMPLETE", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "";
+ chif {
+ compatible = "hpe,gxp-chif";
+ interrupts = <12>;
+ };
+ };
+
+ csm: csm@80000000 {
+ compatible = "hpe,gxp-csm", "simple-mfd", "syscon";
+ reg = <0x80000000 0x400>;
+ };
+
+ gpio: gpio@0 {
+ compatible = "hpe,gxp-gpio";
+ #gpio-cells = <2>;
+ csm_handle = <&csm>;
+ vuhc0_handle = <&vuhc0>;
+ gpio-line-names =
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "RESET_OUT", "NMI_OUT", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "";
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+
+ power {
+ gpios = <&xreg 6 0>;
+ default-state = "off";
+ };
+
+ heartbeat {
+ gpios = <&xreg 7 0>;
+ default-state = "off";
+ };
+
+ identify {
+ gpios = <&xreg 56 0>;
+ default-state = "off";
+ };
+
+ health_red {
+ gpios = <&xreg 57 0>;
+ default-state = "off";
+ };
+
+ health_amber {
+ gpios = <&xreg 58 0>;
+ default-state = "off";
+ };
+ };
+
+ xreg_kyes: xreg_keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ IdButton {
+ label = "ID Button";
+ linux,code = <200>;
+ gpios = <&xreg 60 1>;
+ };
+ };
+
+ vuhc: vuhc {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ PortOwner@0 {
+ label = "Port Owner";
+ linux,code = <200>;
+ gpios = <&gpio 250 1>;
+ };
+
+ PortOwner@1 {
+ label = "Port Owner";
+ linux,code = <201>;
+ gpios = <&gpio 251 1>;
+ };
+ };
+
+ vuhc0: vuhc@80400080 {
+ compatible = "syscon";
+ reg = <0x80400000 0x80>;
+ };
+
+ udcg: udcg@80400800 {
+ compatible = "syscon";
+ reg = <0x80400800 0x200>;
+ };
+
+ udc0: udc@80401000 {
+ compatible = "hpe, gxp-udc";
+ reg = <0x80401000 0x1000>;
+ interrupts = <13>;
+ interrupt-parent = <&vic1>;
+ vdevnum = <0>;
+ fepnum = <7>;
+ udcg-handle = <&udcg>;
+ };
+
+ udc1: udc@80402000 {
+ compatible = "hpe, gxp-udc";
+ reg = <0x80402000 0x1000>;
+ interrupts = <13>;
+ interrupt-parent = <&vic1>;
+ vdevnum = <1>;
+ fepnum = <7>;
+ udcg-handle = <&udcg>;
+ };
+
+ coretemp: coretemp@c0000130 {
+ compatible = "hpe,gxp-coretemp";
+ reg = <0xc0000130 0x8>;
+ };
+
+ syspower: syspower {
+ compatible = "hpe,gxp-power";
+ psu_phandle = <&psu1>, <&psu2>;
+ };
+
+ peci: peci@80000400 {
+ compatible = "hpe,gxp-peci";
+ reg = <0x80000400 0x200>;
+ interrupts = <22>;
+ interrupt-parent = <&vic1>;
+ };
+ };
+
+ clocks {
+ osc: osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-output-names = "osc";
+ clock-frequency = <33333333>;
+ };
+
+ iopclk: iopclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clocks = <&osc>;
+ clock-out-put-names = "iopclk";
+ clock-frequency = <400000000>;
+ };
+
+ memclk: memclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clocks = <&osc>;
+ clock-out-put-names = "memclk";
+ clock-frequency = <800000000>;
+ };
+ };
+};
diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
new file mode 100644
index 000000000000..f37c6630e06d
--- /dev/null
+++ b/arch/arm/configs/gxp_defconfig
@@ -0,0 +1,243 @@
+CONFIG_KERNEL_XZ=y
+CONFIG_DEFAULT_HOSTNAME="gxp"
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_NAMESPACES=y
+CONFIG_SCHED_AUTOGROUP=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLAB=y
+CONFIG_ARCH_MULTI_V6=y
+CONFIG_ARCH_HPE=y
+CONFIG_ARCH_HPE_GXP=y
+CONFIG_SECCOMP=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+# CONFIG_SUSPEND is not set
+CONFIG_JUMP_LABEL=y
+# CONFIG_STRICT_KERNEL_RWX is not set
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_KSM=y
+CONFIG_CLEANCACHE=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_XFRM_STATISTICS=y
+CONFIG_INET=y
+CONFIG_VLAN_8021Q=y
+CONFIG_NETLINK_DIAG=y
+CONFIG_NET_NCSI=y
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_PLATRAM=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_GXP_SPIFI=y
+CONFIG_BLK_DEV_NULL_BLK=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_NBD=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ALACRITECH is not set
+# CONFIG_NET_VENDOR_AMAZON is not set
+# CONFIG_NET_VENDOR_AQUANTIA is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_VENDOR_AURORA is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CADENCE is not set
+# CONFIG_NET_VENDOR_CAVIUM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_CORTINA is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_GOOGLE is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_HUAWEI is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_MICROSEMI is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NETRONOME is not set
+# CONFIG_NET_VENDOR_NI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SOLARFLARE is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_SOCIONEXT is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_NET_VENDOR_XILINX is not set
+CONFIG_UMAC=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+CONFIG_VT_HW_CONSOLE_BINDING=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=6
+CONFIG_SERIAL_8250_RUNTIME_UARTS=6
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_8250_GXP_VUART=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_TTY_PRINTK=y
+CONFIG_IPMI_HANDLER=y
+CONFIG_IPMI_DEVICE_INTERFACE=y
+CONFIG_IPMI_SI=y
+CONFIG_IPMI_SSIF=y
+CONFIG_HPE_KCS_IPMI_BMC=y
+CONFIG_HW_RANDOM_TIMERIOMEM=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_GXP=y
+CONFIG_I2C_SLAVE=y
+CONFIG_I2C_SLAVE_EEPROM=y
+CONFIG_SPI=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_GXP=y
+CONFIG_SENSORS_EMC1403=y
+CONFIG_SENSORS_GXP_FAN_CTRL=y
+CONFIG_SENSORS_GXP_CORETEMP=y
+CONFIG_SENSORS_GXP_PSU=y
+CONFIG_SENSORS_GXP_POWER=y
+CONFIG_WATCHDOG=y
+CONFIG_GXP_WATCHDOG=y
+CONFIG_MFD_SYSCON=y
+CONFIG_FB=y
+CONFIG_FB_THUMBNAIL=y
+CONFIG_FB_SIMPLE=y
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GXP_UDC=y
+CONFIG_USB_CONFIGFS=y
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_CONFIGFS_F_HID=y
+CONFIG_USB_CONFIGFS_F_PRINTER=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_MTD=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_LEDS_TRIGGER_TRANSIENT=y
+CONFIG_LEDS_TRIGGER_PANIC=y
+# CONFIG_VIRTIO_MENU is not set
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_HPE_GXP_XREG=y
+CONFIG_HPE_GXP_FN2=y
+CONFIG_HPE_GXP_CSM=y
+CONFIG_HPE_GXP_SROM=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_OVERLAY_FS_REDIRECT_DIR=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_JFFS2_FS=y
+# CONFIG_JFFS2_FS_WRITEBUFFER is not set
+CONFIG_JFFS2_SUMMARY=y
+CONFIG_JFFS2_FS_XATTR=y
+# CONFIG_JFFS2_FS_POSIX_ACL is not set
+# CONFIG_JFFS2_FS_SECURITY is not set
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
+# CONFIG_NETWORK_FILESYSTEMS is not set
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEFLATE=y
+CONFIG_CRYPTO_LZO=y
+CONFIG_CRYPTO_ZSTD=y
+CONFIG_CRYPTO_USER_API_HASH=y
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC16=y
+# CONFIG_XZ_DEC_ARM is not set
+# CONFIG_XZ_DEC_ARMTHUMB is not set
+CONFIG_DMA_API_DEBUG=y
+CONFIG_PRINTK_TIME=y
+CONFIG_BOOT_PRINTK_DELAY=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_FUNCTION_PROFILER=y
+CONFIG_STACK_TRACER=y
+CONFIG_SCHED_TRACER=y
+CONFIG_STRICT_DEVMEM=y
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_DEBUG_LL_UART_8250=y
+CONFIG_DEBUG_UART_PHYS=0xC00000F0
+CONFIG_DEBUG_UART_VIRT=0xF00000F0
+CONFIG_DEBUG_UART_8250_SHIFT=0
+CONFIG_EARLY_PRINTK=y
+CONFIG_TEST_KSTRTOX=y
diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
new file mode 100644
index 000000000000..9b27f97c6536
--- /dev/null
+++ b/arch/arm/mach-hpe/Kconfig
@@ -0,0 +1,20 @@
+menuconfig ARCH_HPE
+ bool "HPE SoC support"
+ help
+ This enables support for HPE ARM based SoC chips
+if ARCH_HPE
+
+config ARCH_HPE_GXP
+ bool "HPE GXP SoC"
+ select ARM_VIC
+ select PINCTRL
+ select IRQ_DOMAIN
+ select GENERIC_IRQ_CHIP
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
+ select CLKSRC_MMIO
+ depends on ARCH_MULTI_V7
+ help
+ Support for GXP SoCs
+
+endif
diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
new file mode 100644
index 000000000000..8b0a91234df4
--- /dev/null
+++ b/arch/arm/mach-hpe/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_HPE_GXP) += gxp.o
diff --git a/arch/arm/mach-hpe/gxp.c b/arch/arm/mach-hpe/gxp.c
new file mode 100644
index 000000000000..b58f25fbae5a
--- /dev/null
+++ b/arch/arm/mach-hpe/gxp.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+
+#include <linux/init.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+
+#define IOP_REGS_PHYS_BASE 0xc0000000
+#define IOP_REGS_VIRT_BASE 0xf0000000
+#define IOP_REGS_SIZE (240*SZ_1M)
+
+#define IOP_EHCI_USBCMD 0x0efe0010
+
+static struct map_desc gxp_io_desc[] __initdata = {
+ {
+ .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
+ .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
+ .length = IOP_REGS_SIZE,
+ .type = MT_DEVICE,
+ },
+};
+
+void __init gxp_map_io(void)
+{
+ iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
+}
+
+static void __init gxp_dt_init(void)
+{
+ //reset EHCI host controller for clear start
+ __raw_writel(0x00080002,
+ (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void gxp_restart(enum reboot_mode mode, const char *cmd)
+{
+ pr_info("gpx restart");
+ __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
+}
+
+static const char * const gxp_board_dt_compat[] = {
+ "HPE,GXP",
+ NULL,
+};
+
+DT_MACHINE_START(GXP_DT, "HPE GXP")
+ .init_machine = gxp_dt_init,
+ .map_io = gxp_map_io,
+ .restart = gxp_restart,
+ .dt_compat = gxp_board_dt_compat,
+MACHINE_END
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-25 19:46 ` nick.hawkins
@ 2022-01-25 20:41 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-01-25 20:41 UTC (permalink / raw)
To: nick.hawkins, verdun
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Arnd Bergmann,
Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
On 25/01/2022 20:46, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
Thanks for the patches. The commit should come with description. Please
check other commits adding new sub-arch or boards for nice examples.
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> arch/arm/Kconfig | 2 +
> arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
DTS goes separately.
> arch/arm/configs/gxp_defconfig | 243 ++++++
Defconfig is separate commit.
> arch/arm/mach-hpe/Kconfig | 20 +
> arch/arm/mach-hpe/Makefile | 1 +
> arch/arm/mach-hpe/gxp.c | 63 ++
> 8 files changed, 1039 insertions(+)
> create mode 100644 arch/arm/boot/dts/gxp.dts
> create mode 100644 arch/arm/configs/gxp_defconfig
> create mode 100644 arch/arm/mach-hpe/Kconfig
> create mode 100644 arch/arm/mach-hpe/Makefile
> create mode 100644 arch/arm/mach-hpe/gxp.c
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 294093d45a23..e8b0ec874aed 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -515,6 +515,8 @@ patternProperties:
> description: Jiangsu HopeRun Software Co., Ltd.
> "^hp,.*":
> description: Hewlett Packard
Is Hewlett Packard not an Enterprise?
> + "^hpe,.*":
> + description: Hewlett Packard Enterprise
...
> "^hsg,.*":
> description: HannStar Display Co.
> "^holtek,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..007d99734dd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8382,6 +8382,14 @@ L: linux-efi@vger.kernel.org
> S: Maintained
> F: block/partitions/efi.*
>
> +GXP ARCHITECTURE
> +M: Jean-Marie Verdun <verdun@hpe.com>
> +M: Nick Hawkins <nick.hawkins@hpe.com>
> +S: Maintained
> +F: arch/arm/boot/dts/gxp.dts
> +F: arch/arm/configs/gxp_defconfig
> +F: arch/arm/mach-hpe/gxp.c
> +
> H8/300 ARCHITECTURE
> M: Yoshinori Sato <ysato@users.sourceforge.jp>
> L: uclinux-h8-devel@lists.sourceforge.jp (moderated for non-subscribers)
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index fabe39169b12..d428d0d35889 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -708,6 +708,8 @@ source "arch/arm/mach-vt8500/Kconfig"
>
> source "arch/arm/mach-zynq/Kconfig"
>
> +source "arch/arm/mach-hpe/Kconfig"
All entries in that secion are ordered alphabetically, so mach-hp or
mach-hpe should not stick out.
> +
> # ARMv7-M architecture
> config ARCH_LPC18XX
> bool "NXP LPC18xx/LPC43xx"
> diff --git a/arch/arm/boot/dts/gxp.dts b/arch/arm/boot/dts/gxp.dts
This needs some better, longer name than just gxp... Look how other
files are named in that directory.
> new file mode 100644
> index 000000000000..7bd814ecaaee
> --- /dev/null
> +++ b/arch/arm/boot/dts/gxp.dts
Where is DTSI? What is this file about? Why there is no description?
What's the purpose?
Where is the dts Makefile change? How do you compile it?
> @@ -0,0 +1,700 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE GXP
> + */
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
Didn't checkpatch complain about undocumented compatible?
If even if it did not, you need to document it. And solve all the issues
like - why uppercase, where is DTSI or SoC compatible... and what is it
exactly?
> + model = "GXP";
So informative... Model GXP like compatible.
> +
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
earlyprint is a debugging feature, not suitable for mainline DTS. The
same seems with "user_debug=31". Remove both.
Console should go to chosen stdout-path node instead.
> + };
> +
> + aliases {
> + };
No need for an empty node.
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0x40000000 0x20000000>;
> + };
> +
> + ahb@80000000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + vic0: vic@ceff0000 {
Node names should be generic, so this is interrupt-controller.
> + compatible = "arm,pl192-vic";
> + interrupt-controller;
> + reg = <0xceff0000 0x1000>;
> + #interrupt-cells = <1>;
> + };
> +
> + vic1: vic@80f00000 {
> + compatible = "arm,pl192-vic";
> + interrupt-controller;
> + reg = <0x80f00000 0x1000>;
> + #interrupt-cells = <1>;
> + };
> +
> + timer0: timer@c0000080 {
> + compatible = "hpe,gxp-timer";
Undocumented compatible. Also looks too generic.
> + reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
> + interrupts = <0>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <400000000>;
> + };
> +
> + watchdog: watchdog@c0000090 {
> + compatible = "hpe,gxp-wdt";
Undocumented compatible. Also looks too generic.
> + reg = <0xc0000090 0x02>, <0xc0000096 0x01>;
> + };
> +
> + uartc: serial@c00000f0 {
> + compatible = "ns16550a";
> + reg = <0xc00000f0 0x8>;
> + interrupts = <19>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + };
> +
> + uarta: serial@c00000e0 {
> + compatible = "ns16550a";
> + reg = <0xc00000e0 0x8>;
> + interrupts = <17>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + };
> +
> + uartb: serial@c00000e8 {
> + compatible = "ns16550a";
> + reg = <0xc00000e8 0x8>;
> + interrupts = <18>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + };
> +
> + vuart_a_cfg: vuarta_cfg@80fc0230 {
> + compatible = "hpe,gxp-vuarta_cfg", "simple-mfd", "syscon";
> + reg = <0x80fc0230 0x100>;
> + reg-io-width = <1>;
> + };
> +
> + vuart_a: vuart_a@80fd0200 {
> + compatible = "hpe,gxp-vuart";
> + reg = <0x80fd0200 0x100>;
> + interrupts = <2>;
> + interrupt-parent = <&vic1>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + status = "okay";
> + serial-line = <3>;
> + vuart_cfg = <&vuart_a_cfg>;
> + };
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + spifi0: spifi@c0000200 {
What is spifi? Maybe "spi"?
> + compatible = "hpe,gxp-spifi";
Undocumented compatible. Also looks too generic.
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
> + u-boot-env@60000 {
> + label = "u-boot-env";
> + reg = <0x60000 0x20000>;
> + };
> + kernel@80000 {
> + label = "kernel";
> + reg = <0x80000 0x4c0000>;
> + };
> + rofs@540000 {
> + label = "rofs";
> + reg = <0x540000 0x1740000>;
> + };
> + rwfs@1c80000 {
> + label = "rwfs";
> + reg = <0x1c80000 0x250000>;
> + };
> + section@1edf000{
> + label = "section";
> + reg = <0x1ed0000 0x130000>;
> + };
> + };
> + };
> +
> + flash@1 {
> + compatible = "jedec,spi-nor";
> + reg = <1>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + host-prime@0 {
> + label = "host-prime";
> + reg = <0x0 0x02000000>;
> + };
> + host-second@0 {
> + label = "host-second";
> + reg = <0x02000000 0x02000000>;
> + };
> + };
> + };
> + };
> +
> + sram@d0000000 {
> + compatible = "mtd-ram";
> + reg = <0xd0000000 0x80000>;
> + bank-width = <1>;
> + erase-size =<1>;
> + partition@0 {
> + label = "host-reserved";
> + reg = <0x0 0x10000>;
> + };
> + partition@10000 {
> + label = "nvram";
> + reg = <0x10000 0x70000>;
> + };
> + };
> +
> + srom@80fc0000 {
> + compatible = "hpe,gxp-srom", "simple-mfd", "syscon";
> + reg = <0x80fc0000 0x100>;
> + };
> +
> + vrom@58000000 {
> + compatible = "mtd-ram";
> + bank-width = <4>;
> + reg = <0x58000000 0x4000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "vrom-prime";
> + reg = <0x0 0x2000000>;
> + };
> + partition@2000000 {
> + label = "vrom-second";
> + reg = <0x2000000 0x2000000>;
> + };
> + };
> +
> + i2cg: i2cg@c00000f8 {
What's this exactly?
> + compatible = "syscon";
> + reg = <0xc00000f8 0x08>;
> + };
> +
> + i2c0: i2c@c0002000 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002000 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c@c0002100 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002100 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c@c0002200 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002200 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + 24c02@50 {
> + compatible = "atmel,24c02";
> + pagesize = <8>;
> + reg = <0x50>;
> + };
> + };
> +
> + i2c3: i2c@c0002300 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002300 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4: i2c@c0002400 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002400 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c5: i2c@c0002500 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002500 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + };
> +
> + i2c6: i2c@c0002600 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002600 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c7: i2c@c0002700 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002700 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + psu1: psu@58 {
> + compatible = "hpe,gxp-psu";
> + reg = <0x58>;
> + };
> +
> + psu2: psu@59 {
> + compatible = "hpe,gxp-psu";
> + reg = <0x59>;
> + };
> + };
> +
> + i2c8: i2c@c0002800 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002800 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c9: i2c@c0002900 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002900 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2cmux@4 {
Does it even compile with W=1? The unit address looks quite different
than what is below.
Also - node name should be generic.
> + compatible = "i2c-mux-reg";
> + i2c-parent = <&i2c4>;
> + reg = <0xd1000074 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c4@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4@4 {
> + reg = <4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + i2cmux@6 {
> + compatible = "i2c-mux-reg";
> + i2c-parent = <&i2c6>;
> + reg = <0xd1000076 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c6@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@4 {
> + reg = <4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@5 {
> + reg = <5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + mdio0: mdio@c0004080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0004080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ext_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "sgmii";
> + reg = <0>;
> + };
> + };
> +
> + mdio1: mdio@c0005080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0005080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <0>;
> + };
> + int_phy1: ethernt-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <1>;
> + };
> + };
> +
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
No spaces in compatibles. Previous comments about compatibles also
apply. About node name as well.
I'll stop on DTS now, because it does not look much better below.
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
> + };
> +
(...)
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
> @@ -0,0 +1,243 @@
> +CONFIG_KERNEL_XZ=y
> +CONFIG_DEFAULT_HOSTNAME="gxp"
> +CONFIG_SYSVIPC=y
> +CONFIG_NO_HZ=y
> +CONFIG_HIGH_RES_TIMERS=y
> +CONFIG_BSD_PROCESS_ACCT=y
> +CONFIG_BSD_PROCESS_ACCT_V3=y
> +CONFIG_LOG_BUF_SHIFT=18
> +CONFIG_CFS_BANDWIDTH=y
> +CONFIG_RT_GROUP_SCHED=y
> +CONFIG_CGROUP_FREEZER=y
> +CONFIG_CGROUP_DEVICE=y
> +CONFIG_CGROUP_CPUACCT=y
> +CONFIG_NAMESPACES=y
> +CONFIG_SCHED_AUTOGROUP=y
> +CONFIG_RELAY=y
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +CONFIG_KALLSYMS_ALL=y
> +CONFIG_EMBEDDED=y
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLAB=y
> +CONFIG_ARCH_MULTI_V6=y
> +CONFIG_ARCH_HPE=y
> +CONFIG_ARCH_HPE_GXP=y
> +CONFIG_SECCOMP=y
> +# CONFIG_ATAGS is not set
> +CONFIG_ZBOOT_ROM_TEXT=0x0
> +CONFIG_ZBOOT_ROM_BSS=0x0
> +# CONFIG_SUSPEND is not set
> +CONFIG_JUMP_LABEL=y
> +# CONFIG_STRICT_KERNEL_RWX is not set
> +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> +CONFIG_KSM=y
> +CONFIG_CLEANCACHE=y
> +CONFIG_NET=y
> +CONFIG_PACKET=y
> +CONFIG_PACKET_DIAG=y
> +CONFIG_UNIX=y
> +CONFIG_UNIX_DIAG=y
> +CONFIG_XFRM_USER=y
> +CONFIG_XFRM_STATISTICS=y
> +CONFIG_INET=y
> +CONFIG_VLAN_8021Q=y
> +CONFIG_NETLINK_DIAG=y
> +CONFIG_NET_NCSI=y
> +# CONFIG_WIRELESS is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_STANDALONE is not set
> +CONFIG_MTD=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_PHYSMAP=y
> +CONFIG_MTD_PHYSMAP_OF=y
> +CONFIG_MTD_PLATRAM=y
> +CONFIG_MTD_SPI_NOR=y
> +CONFIG_SPI_GXP_SPIFI=y
> +CONFIG_BLK_DEV_NULL_BLK=y
> +CONFIG_BLK_DEV_LOOP=y
> +CONFIG_BLK_DEV_NBD=y
> +CONFIG_BLK_DEV_RAM=y
> +CONFIG_EEPROM_AT24=y
> +CONFIG_SCSI=y
> +CONFIG_BLK_DEV_SD=y
> +# CONFIG_SCSI_LOWLEVEL is not set
> +CONFIG_NETDEVICES=y
> +# CONFIG_NET_VENDOR_ALACRITECH is not set
> +# CONFIG_NET_VENDOR_AMAZON is not set
> +# CONFIG_NET_VENDOR_AQUANTIA is not set
> +# CONFIG_NET_VENDOR_ARC is not set
> +# CONFIG_NET_VENDOR_AURORA is not set
> +# CONFIG_NET_VENDOR_BROADCOM is not set
> +# CONFIG_NET_VENDOR_CADENCE is not set
> +# CONFIG_NET_VENDOR_CAVIUM is not set
> +# CONFIG_NET_VENDOR_CIRRUS is not set
> +# CONFIG_NET_VENDOR_CORTINA is not set
> +# CONFIG_NET_VENDOR_EZCHIP is not set
> +# CONFIG_NET_VENDOR_FARADAY is not set
> +# CONFIG_NET_VENDOR_GOOGLE is not set
> +# CONFIG_NET_VENDOR_HISILICON is not set
> +# CONFIG_NET_VENDOR_HUAWEI is not set
> +# CONFIG_NET_VENDOR_INTEL is not set
> +# CONFIG_NET_VENDOR_MARVELL is not set
> +# CONFIG_NET_VENDOR_MELLANOX is not set
> +# CONFIG_NET_VENDOR_MICREL is not set
> +# CONFIG_NET_VENDOR_MICROCHIP is not set
> +# CONFIG_NET_VENDOR_MICROSEMI is not set
> +# CONFIG_NET_VENDOR_NATSEMI is not set
> +# CONFIG_NET_VENDOR_NETRONOME is not set
> +# CONFIG_NET_VENDOR_NI is not set
> +# CONFIG_NET_VENDOR_QUALCOMM is not set
> +# CONFIG_NET_VENDOR_RENESAS is not set
> +# CONFIG_NET_VENDOR_ROCKER is not set
> +# CONFIG_NET_VENDOR_SAMSUNG is not set
> +# CONFIG_NET_VENDOR_SEEQ is not set
> +# CONFIG_NET_VENDOR_SOLARFLARE is not set
> +# CONFIG_NET_VENDOR_SMSC is not set
> +# CONFIG_NET_VENDOR_SOCIONEXT is not set
> +# CONFIG_NET_VENDOR_STMICRO is not set
> +# CONFIG_NET_VENDOR_SYNOPSYS is not set
> +# CONFIG_NET_VENDOR_VIA is not set
> +# CONFIG_NET_VENDOR_WIZNET is not set
> +# CONFIG_NET_VENDOR_XILINX is not set
> +CONFIG_UMAC=y
> +# CONFIG_USB_NET_DRIVERS is not set
> +# CONFIG_WLAN is not set
> +# CONFIG_INPUT_LEDS is not set
> +CONFIG_INPUT_EVDEV=y
> +# CONFIG_KEYBOARD_ATKBD is not set
> +CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_GPIO_POLLED=y
> +# CONFIG_INPUT_MOUSE is not set
> +CONFIG_SERIO_LIBPS2=y
> +CONFIG_VT_HW_CONSOLE_BINDING=y
> +# CONFIG_LEGACY_PTYS is not set
> +CONFIG_SERIAL_8250=y
> +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_NR_UARTS=6
> +CONFIG_SERIAL_8250_RUNTIME_UARTS=6
> +CONFIG_SERIAL_8250_EXTENDED=y
> +CONFIG_SERIAL_8250_SHARE_IRQ=y
> +CONFIG_SERIAL_8250_GXP_VUART=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_TTY_PRINTK=y
> +CONFIG_IPMI_HANDLER=y
> +CONFIG_IPMI_DEVICE_INTERFACE=y
> +CONFIG_IPMI_SI=y
> +CONFIG_IPMI_SSIF=y
> +CONFIG_HPE_KCS_IPMI_BMC=y
> +CONFIG_HW_RANDOM_TIMERIOMEM=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_GXP=y
> +CONFIG_I2C_SLAVE=y
> +CONFIG_I2C_SLAVE_EEPROM=y
> +CONFIG_SPI=y
> +CONFIG_GPIOLIB=y
> +CONFIG_GPIO_SYSFS=y
> +CONFIG_GPIO_GXP=y
> +CONFIG_SENSORS_EMC1403=y
> +CONFIG_SENSORS_GXP_FAN_CTRL=y
> +CONFIG_SENSORS_GXP_CORETEMP=y
> +CONFIG_SENSORS_GXP_PSU=y
> +CONFIG_SENSORS_GXP_POWER=y
> +CONFIG_WATCHDOG=y
> +CONFIG_GXP_WATCHDOG=y
> +CONFIG_MFD_SYSCON=y
> +CONFIG_FB=y
> +CONFIG_FB_THUMBNAIL=y
> +CONFIG_FB_SIMPLE=y
> +CONFIG_USB=y
> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_ROOT_HUB_TT=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_HCD_PLATFORM=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GXP_UDC=y
> +CONFIG_USB_CONFIGFS=y
> +CONFIG_USB_CONFIGFS_SERIAL=y
> +CONFIG_USB_CONFIGFS_ACM=y
> +CONFIG_USB_CONFIGFS_OBEX=y
> +CONFIG_USB_CONFIGFS_NCM=y
> +CONFIG_USB_CONFIGFS_ECM=y
> +CONFIG_USB_CONFIGFS_ECM_SUBSET=y
> +CONFIG_USB_CONFIGFS_RNDIS=y
> +CONFIG_USB_CONFIGFS_EEM=y
> +CONFIG_USB_CONFIGFS_MASS_STORAGE=y
> +CONFIG_USB_CONFIGFS_F_LB_SS=y
> +CONFIG_USB_CONFIGFS_F_FS=y
> +CONFIG_USB_CONFIGFS_F_HID=y
> +CONFIG_USB_CONFIGFS_F_PRINTER=y
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_TRIGGERS=y
> +CONFIG_LEDS_TRIGGER_TIMER=y
> +CONFIG_LEDS_TRIGGER_ONESHOT=y
> +CONFIG_LEDS_TRIGGER_MTD=y
> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> +CONFIG_LEDS_TRIGGER_CPU=y
> +CONFIG_LEDS_TRIGGER_GPIO=y
> +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> +CONFIG_LEDS_TRIGGER_TRANSIENT=y
> +CONFIG_LEDS_TRIGGER_PANIC=y
> +# CONFIG_VIRTIO_MENU is not set
> +# CONFIG_IOMMU_SUPPORT is not set
> +CONFIG_HPE_GXP_XREG=y
> +CONFIG_HPE_GXP_FN2=y
> +CONFIG_HPE_GXP_CSM=y
> +CONFIG_HPE_GXP_SROM=y
> +CONFIG_FANOTIFY=y
> +CONFIG_OVERLAY_FS=y
> +CONFIG_OVERLAY_FS_REDIRECT_DIR=y
> +CONFIG_TMPFS=y
> +CONFIG_TMPFS_POSIX_ACL=y
> +CONFIG_JFFS2_FS=y
> +# CONFIG_JFFS2_FS_WRITEBUFFER is not set
> +CONFIG_JFFS2_SUMMARY=y
> +CONFIG_JFFS2_FS_XATTR=y
> +# CONFIG_JFFS2_FS_POSIX_ACL is not set
> +# CONFIG_JFFS2_FS_SECURITY is not set
> +CONFIG_SQUASHFS=y
> +CONFIG_SQUASHFS_XZ=y
> +CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
> +# CONFIG_NETWORK_FILESYSTEMS is not set
> +CONFIG_NLS_CODEPAGE_437=y
> +CONFIG_NLS_ASCII=y
> +CONFIG_NLS_ISO8859_1=y
> +CONFIG_NLS_UTF8=y
> +CONFIG_CRYPTO_CCM=y
> +CONFIG_CRYPTO_GCM=y
> +CONFIG_CRYPTO_CRC32C=y
> +CONFIG_CRYPTO_ARC4=y
> +CONFIG_CRYPTO_DEFLATE=y
> +CONFIG_CRYPTO_LZO=y
> +CONFIG_CRYPTO_ZSTD=y
> +CONFIG_CRYPTO_USER_API_HASH=y
> +# CONFIG_CRYPTO_HW is not set
> +CONFIG_CRC16=y
> +# CONFIG_XZ_DEC_ARM is not set
> +# CONFIG_XZ_DEC_ARMTHUMB is not set
> +CONFIG_DMA_API_DEBUG=y
> +CONFIG_PRINTK_TIME=y
> +CONFIG_BOOT_PRINTK_DELAY=y
> +CONFIG_DYNAMIC_DEBUG=y
> +CONFIG_DEBUG_INFO=y
> +# CONFIG_ENABLE_MUST_CHECK is not set
> +CONFIG_MAGIC_SYSRQ=y
> +CONFIG_PANIC_ON_OOPS=y
> +CONFIG_FUNCTION_PROFILER=y
> +CONFIG_STACK_TRACER=y
> +CONFIG_SCHED_TRACER=y
> +CONFIG_STRICT_DEVMEM=y
> +CONFIG_DEBUG_USER=y
> +CONFIG_DEBUG_LL=y
> +CONFIG_DEBUG_LL_UART_8250=y
> +CONFIG_DEBUG_UART_PHYS=0xC00000F0
> +CONFIG_DEBUG_UART_VIRT=0xF00000F0
> +CONFIG_DEBUG_UART_8250_SHIFT=0
> +CONFIG_EARLY_PRINTK=y
> +CONFIG_TEST_KSTRTOX=y
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
> + help
> + Support for GXP SoCs
> +
> +endif
> diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
> new file mode 100644
> index 000000000000..8b0a91234df4
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARCH_HPE_GXP) += gxp.o
> diff --git a/arch/arm/mach-hpe/gxp.c b/arch/arm/mach-hpe/gxp.c
> new file mode 100644
> index 000000000000..b58f25fbae5a
> --- /dev/null
> +++ b/arch/arm/mach-hpe/gxp.c
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +
> +#include <linux/init.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
> +
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
Linux style comments please, so /*.
> + __raw_writel(0x00080002,
What is this magic value?
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
Why do you need the cast?
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
Skip it.
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
> +
> +static const char * const gxp_board_dt_compat[] = {
> + "HPE,GXP",
> + NULL,
> +};
> +
> +DT_MACHINE_START(GXP_DT, "HPE GXP")
> + .init_machine = gxp_dt_init,
> + .map_io = gxp_map_io,
> + .restart = gxp_restart,
> + .dt_compat = gxp_board_dt_compat,
> +MACHINE_END
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-25 20:41 ` Krzysztof Kozlowski
0 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-01-25 20:41 UTC (permalink / raw)
To: nick.hawkins, verdun
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Arnd Bergmann,
Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
On 25/01/2022 20:46, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
Thanks for the patches. The commit should come with description. Please
check other commits adding new sub-arch or boards for nice examples.
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> arch/arm/Kconfig | 2 +
> arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
DTS goes separately.
> arch/arm/configs/gxp_defconfig | 243 ++++++
Defconfig is separate commit.
> arch/arm/mach-hpe/Kconfig | 20 +
> arch/arm/mach-hpe/Makefile | 1 +
> arch/arm/mach-hpe/gxp.c | 63 ++
> 8 files changed, 1039 insertions(+)
> create mode 100644 arch/arm/boot/dts/gxp.dts
> create mode 100644 arch/arm/configs/gxp_defconfig
> create mode 100644 arch/arm/mach-hpe/Kconfig
> create mode 100644 arch/arm/mach-hpe/Makefile
> create mode 100644 arch/arm/mach-hpe/gxp.c
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 294093d45a23..e8b0ec874aed 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -515,6 +515,8 @@ patternProperties:
> description: Jiangsu HopeRun Software Co., Ltd.
> "^hp,.*":
> description: Hewlett Packard
Is Hewlett Packard not an Enterprise?
> + "^hpe,.*":
> + description: Hewlett Packard Enterprise
...
> "^hsg,.*":
> description: HannStar Display Co.
> "^holtek,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..007d99734dd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8382,6 +8382,14 @@ L: linux-efi@vger.kernel.org
> S: Maintained
> F: block/partitions/efi.*
>
> +GXP ARCHITECTURE
> +M: Jean-Marie Verdun <verdun@hpe.com>
> +M: Nick Hawkins <nick.hawkins@hpe.com>
> +S: Maintained
> +F: arch/arm/boot/dts/gxp.dts
> +F: arch/arm/configs/gxp_defconfig
> +F: arch/arm/mach-hpe/gxp.c
> +
> H8/300 ARCHITECTURE
> M: Yoshinori Sato <ysato@users.sourceforge.jp>
> L: uclinux-h8-devel@lists.sourceforge.jp (moderated for non-subscribers)
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index fabe39169b12..d428d0d35889 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -708,6 +708,8 @@ source "arch/arm/mach-vt8500/Kconfig"
>
> source "arch/arm/mach-zynq/Kconfig"
>
> +source "arch/arm/mach-hpe/Kconfig"
All entries in that secion are ordered alphabetically, so mach-hp or
mach-hpe should not stick out.
> +
> # ARMv7-M architecture
> config ARCH_LPC18XX
> bool "NXP LPC18xx/LPC43xx"
> diff --git a/arch/arm/boot/dts/gxp.dts b/arch/arm/boot/dts/gxp.dts
This needs some better, longer name than just gxp... Look how other
files are named in that directory.
> new file mode 100644
> index 000000000000..7bd814ecaaee
> --- /dev/null
> +++ b/arch/arm/boot/dts/gxp.dts
Where is DTSI? What is this file about? Why there is no description?
What's the purpose?
Where is the dts Makefile change? How do you compile it?
> @@ -0,0 +1,700 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE GXP
> + */
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
Didn't checkpatch complain about undocumented compatible?
If even if it did not, you need to document it. And solve all the issues
like - why uppercase, where is DTSI or SoC compatible... and what is it
exactly?
> + model = "GXP";
So informative... Model GXP like compatible.
> +
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
earlyprint is a debugging feature, not suitable for mainline DTS. The
same seems with "user_debug=31". Remove both.
Console should go to chosen stdout-path node instead.
> + };
> +
> + aliases {
> + };
No need for an empty node.
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0x40000000 0x20000000>;
> + };
> +
> + ahb@80000000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + vic0: vic@ceff0000 {
Node names should be generic, so this is interrupt-controller.
> + compatible = "arm,pl192-vic";
> + interrupt-controller;
> + reg = <0xceff0000 0x1000>;
> + #interrupt-cells = <1>;
> + };
> +
> + vic1: vic@80f00000 {
> + compatible = "arm,pl192-vic";
> + interrupt-controller;
> + reg = <0x80f00000 0x1000>;
> + #interrupt-cells = <1>;
> + };
> +
> + timer0: timer@c0000080 {
> + compatible = "hpe,gxp-timer";
Undocumented compatible. Also looks too generic.
> + reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
> + interrupts = <0>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <400000000>;
> + };
> +
> + watchdog: watchdog@c0000090 {
> + compatible = "hpe,gxp-wdt";
Undocumented compatible. Also looks too generic.
> + reg = <0xc0000090 0x02>, <0xc0000096 0x01>;
> + };
> +
> + uartc: serial@c00000f0 {
> + compatible = "ns16550a";
> + reg = <0xc00000f0 0x8>;
> + interrupts = <19>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + };
> +
> + uarta: serial@c00000e0 {
> + compatible = "ns16550a";
> + reg = <0xc00000e0 0x8>;
> + interrupts = <17>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + };
> +
> + uartb: serial@c00000e8 {
> + compatible = "ns16550a";
> + reg = <0xc00000e8 0x8>;
> + interrupts = <18>;
> + interrupt-parent = <&vic0>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + };
> +
> + vuart_a_cfg: vuarta_cfg@80fc0230 {
> + compatible = "hpe,gxp-vuarta_cfg", "simple-mfd", "syscon";
> + reg = <0x80fc0230 0x100>;
> + reg-io-width = <1>;
> + };
> +
> + vuart_a: vuart_a@80fd0200 {
> + compatible = "hpe,gxp-vuart";
> + reg = <0x80fd0200 0x100>;
> + interrupts = <2>;
> + interrupt-parent = <&vic1>;
> + clock-frequency = <1846153>;
> + reg-shift = <0>;
> + status = "okay";
> + serial-line = <3>;
> + vuart_cfg = <&vuart_a_cfg>;
> + };
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + spifi0: spifi@c0000200 {
What is spifi? Maybe "spi"?
> + compatible = "hpe,gxp-spifi";
Undocumented compatible. Also looks too generic.
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
> + u-boot-env@60000 {
> + label = "u-boot-env";
> + reg = <0x60000 0x20000>;
> + };
> + kernel@80000 {
> + label = "kernel";
> + reg = <0x80000 0x4c0000>;
> + };
> + rofs@540000 {
> + label = "rofs";
> + reg = <0x540000 0x1740000>;
> + };
> + rwfs@1c80000 {
> + label = "rwfs";
> + reg = <0x1c80000 0x250000>;
> + };
> + section@1edf000{
> + label = "section";
> + reg = <0x1ed0000 0x130000>;
> + };
> + };
> + };
> +
> + flash@1 {
> + compatible = "jedec,spi-nor";
> + reg = <1>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + host-prime@0 {
> + label = "host-prime";
> + reg = <0x0 0x02000000>;
> + };
> + host-second@0 {
> + label = "host-second";
> + reg = <0x02000000 0x02000000>;
> + };
> + };
> + };
> + };
> +
> + sram@d0000000 {
> + compatible = "mtd-ram";
> + reg = <0xd0000000 0x80000>;
> + bank-width = <1>;
> + erase-size =<1>;
> + partition@0 {
> + label = "host-reserved";
> + reg = <0x0 0x10000>;
> + };
> + partition@10000 {
> + label = "nvram";
> + reg = <0x10000 0x70000>;
> + };
> + };
> +
> + srom@80fc0000 {
> + compatible = "hpe,gxp-srom", "simple-mfd", "syscon";
> + reg = <0x80fc0000 0x100>;
> + };
> +
> + vrom@58000000 {
> + compatible = "mtd-ram";
> + bank-width = <4>;
> + reg = <0x58000000 0x4000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "vrom-prime";
> + reg = <0x0 0x2000000>;
> + };
> + partition@2000000 {
> + label = "vrom-second";
> + reg = <0x2000000 0x2000000>;
> + };
> + };
> +
> + i2cg: i2cg@c00000f8 {
What's this exactly?
> + compatible = "syscon";
> + reg = <0xc00000f8 0x08>;
> + };
> +
> + i2c0: i2c@c0002000 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002000 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c@c0002100 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002100 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c@c0002200 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002200 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + 24c02@50 {
> + compatible = "atmel,24c02";
> + pagesize = <8>;
> + reg = <0x50>;
> + };
> + };
> +
> + i2c3: i2c@c0002300 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002300 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4: i2c@c0002400 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002400 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c5: i2c@c0002500 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002500 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + };
> +
> + i2c6: i2c@c0002600 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002600 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c7: i2c@c0002700 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002700 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + psu1: psu@58 {
> + compatible = "hpe,gxp-psu";
> + reg = <0x58>;
> + };
> +
> + psu2: psu@59 {
> + compatible = "hpe,gxp-psu";
> + reg = <0x59>;
> + };
> + };
> +
> + i2c8: i2c@c0002800 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002800 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c9: i2c@c0002900 {
> + compatible = "hpe,gxp-i2c";
> + reg = <0xc0002900 0x70>;
> + interrupts = <9>;
> + interrupt-parent = <&vic0>;
> + i2cg-handle = <&i2cg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2cmux@4 {
Does it even compile with W=1? The unit address looks quite different
than what is below.
Also - node name should be generic.
> + compatible = "i2c-mux-reg";
> + i2c-parent = <&i2c4>;
> + reg = <0xd1000074 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c4@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4@4 {
> + reg = <4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + i2cmux@6 {
> + compatible = "i2c-mux-reg";
> + i2c-parent = <&i2c6>;
> + reg = <0xd1000076 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c6@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@4 {
> + reg = <4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c6@5 {
> + reg = <5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + mdio0: mdio@c0004080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0004080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ext_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "sgmii";
> + reg = <0>;
> + };
> + };
> +
> + mdio1: mdio@c0005080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0005080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <0>;
> + };
> + int_phy1: ethernt-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <1>;
> + };
> + };
> +
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
No spaces in compatibles. Previous comments about compatibles also
apply. About node name as well.
I'll stop on DTS now, because it does not look much better below.
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
> + };
> +
(...)
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
> @@ -0,0 +1,243 @@
> +CONFIG_KERNEL_XZ=y
> +CONFIG_DEFAULT_HOSTNAME="gxp"
> +CONFIG_SYSVIPC=y
> +CONFIG_NO_HZ=y
> +CONFIG_HIGH_RES_TIMERS=y
> +CONFIG_BSD_PROCESS_ACCT=y
> +CONFIG_BSD_PROCESS_ACCT_V3=y
> +CONFIG_LOG_BUF_SHIFT=18
> +CONFIG_CFS_BANDWIDTH=y
> +CONFIG_RT_GROUP_SCHED=y
> +CONFIG_CGROUP_FREEZER=y
> +CONFIG_CGROUP_DEVICE=y
> +CONFIG_CGROUP_CPUACCT=y
> +CONFIG_NAMESPACES=y
> +CONFIG_SCHED_AUTOGROUP=y
> +CONFIG_RELAY=y
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +CONFIG_KALLSYMS_ALL=y
> +CONFIG_EMBEDDED=y
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLAB=y
> +CONFIG_ARCH_MULTI_V6=y
> +CONFIG_ARCH_HPE=y
> +CONFIG_ARCH_HPE_GXP=y
> +CONFIG_SECCOMP=y
> +# CONFIG_ATAGS is not set
> +CONFIG_ZBOOT_ROM_TEXT=0x0
> +CONFIG_ZBOOT_ROM_BSS=0x0
> +# CONFIG_SUSPEND is not set
> +CONFIG_JUMP_LABEL=y
> +# CONFIG_STRICT_KERNEL_RWX is not set
> +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> +CONFIG_KSM=y
> +CONFIG_CLEANCACHE=y
> +CONFIG_NET=y
> +CONFIG_PACKET=y
> +CONFIG_PACKET_DIAG=y
> +CONFIG_UNIX=y
> +CONFIG_UNIX_DIAG=y
> +CONFIG_XFRM_USER=y
> +CONFIG_XFRM_STATISTICS=y
> +CONFIG_INET=y
> +CONFIG_VLAN_8021Q=y
> +CONFIG_NETLINK_DIAG=y
> +CONFIG_NET_NCSI=y
> +# CONFIG_WIRELESS is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_STANDALONE is not set
> +CONFIG_MTD=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_PHYSMAP=y
> +CONFIG_MTD_PHYSMAP_OF=y
> +CONFIG_MTD_PLATRAM=y
> +CONFIG_MTD_SPI_NOR=y
> +CONFIG_SPI_GXP_SPIFI=y
> +CONFIG_BLK_DEV_NULL_BLK=y
> +CONFIG_BLK_DEV_LOOP=y
> +CONFIG_BLK_DEV_NBD=y
> +CONFIG_BLK_DEV_RAM=y
> +CONFIG_EEPROM_AT24=y
> +CONFIG_SCSI=y
> +CONFIG_BLK_DEV_SD=y
> +# CONFIG_SCSI_LOWLEVEL is not set
> +CONFIG_NETDEVICES=y
> +# CONFIG_NET_VENDOR_ALACRITECH is not set
> +# CONFIG_NET_VENDOR_AMAZON is not set
> +# CONFIG_NET_VENDOR_AQUANTIA is not set
> +# CONFIG_NET_VENDOR_ARC is not set
> +# CONFIG_NET_VENDOR_AURORA is not set
> +# CONFIG_NET_VENDOR_BROADCOM is not set
> +# CONFIG_NET_VENDOR_CADENCE is not set
> +# CONFIG_NET_VENDOR_CAVIUM is not set
> +# CONFIG_NET_VENDOR_CIRRUS is not set
> +# CONFIG_NET_VENDOR_CORTINA is not set
> +# CONFIG_NET_VENDOR_EZCHIP is not set
> +# CONFIG_NET_VENDOR_FARADAY is not set
> +# CONFIG_NET_VENDOR_GOOGLE is not set
> +# CONFIG_NET_VENDOR_HISILICON is not set
> +# CONFIG_NET_VENDOR_HUAWEI is not set
> +# CONFIG_NET_VENDOR_INTEL is not set
> +# CONFIG_NET_VENDOR_MARVELL is not set
> +# CONFIG_NET_VENDOR_MELLANOX is not set
> +# CONFIG_NET_VENDOR_MICREL is not set
> +# CONFIG_NET_VENDOR_MICROCHIP is not set
> +# CONFIG_NET_VENDOR_MICROSEMI is not set
> +# CONFIG_NET_VENDOR_NATSEMI is not set
> +# CONFIG_NET_VENDOR_NETRONOME is not set
> +# CONFIG_NET_VENDOR_NI is not set
> +# CONFIG_NET_VENDOR_QUALCOMM is not set
> +# CONFIG_NET_VENDOR_RENESAS is not set
> +# CONFIG_NET_VENDOR_ROCKER is not set
> +# CONFIG_NET_VENDOR_SAMSUNG is not set
> +# CONFIG_NET_VENDOR_SEEQ is not set
> +# CONFIG_NET_VENDOR_SOLARFLARE is not set
> +# CONFIG_NET_VENDOR_SMSC is not set
> +# CONFIG_NET_VENDOR_SOCIONEXT is not set
> +# CONFIG_NET_VENDOR_STMICRO is not set
> +# CONFIG_NET_VENDOR_SYNOPSYS is not set
> +# CONFIG_NET_VENDOR_VIA is not set
> +# CONFIG_NET_VENDOR_WIZNET is not set
> +# CONFIG_NET_VENDOR_XILINX is not set
> +CONFIG_UMAC=y
> +# CONFIG_USB_NET_DRIVERS is not set
> +# CONFIG_WLAN is not set
> +# CONFIG_INPUT_LEDS is not set
> +CONFIG_INPUT_EVDEV=y
> +# CONFIG_KEYBOARD_ATKBD is not set
> +CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_GPIO_POLLED=y
> +# CONFIG_INPUT_MOUSE is not set
> +CONFIG_SERIO_LIBPS2=y
> +CONFIG_VT_HW_CONSOLE_BINDING=y
> +# CONFIG_LEGACY_PTYS is not set
> +CONFIG_SERIAL_8250=y
> +# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_NR_UARTS=6
> +CONFIG_SERIAL_8250_RUNTIME_UARTS=6
> +CONFIG_SERIAL_8250_EXTENDED=y
> +CONFIG_SERIAL_8250_SHARE_IRQ=y
> +CONFIG_SERIAL_8250_GXP_VUART=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_TTY_PRINTK=y
> +CONFIG_IPMI_HANDLER=y
> +CONFIG_IPMI_DEVICE_INTERFACE=y
> +CONFIG_IPMI_SI=y
> +CONFIG_IPMI_SSIF=y
> +CONFIG_HPE_KCS_IPMI_BMC=y
> +CONFIG_HW_RANDOM_TIMERIOMEM=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_GXP=y
> +CONFIG_I2C_SLAVE=y
> +CONFIG_I2C_SLAVE_EEPROM=y
> +CONFIG_SPI=y
> +CONFIG_GPIOLIB=y
> +CONFIG_GPIO_SYSFS=y
> +CONFIG_GPIO_GXP=y
> +CONFIG_SENSORS_EMC1403=y
> +CONFIG_SENSORS_GXP_FAN_CTRL=y
> +CONFIG_SENSORS_GXP_CORETEMP=y
> +CONFIG_SENSORS_GXP_PSU=y
> +CONFIG_SENSORS_GXP_POWER=y
> +CONFIG_WATCHDOG=y
> +CONFIG_GXP_WATCHDOG=y
> +CONFIG_MFD_SYSCON=y
> +CONFIG_FB=y
> +CONFIG_FB_THUMBNAIL=y
> +CONFIG_FB_SIMPLE=y
> +CONFIG_USB=y
> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_ROOT_HUB_TT=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_HCD_PLATFORM=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GXP_UDC=y
> +CONFIG_USB_CONFIGFS=y
> +CONFIG_USB_CONFIGFS_SERIAL=y
> +CONFIG_USB_CONFIGFS_ACM=y
> +CONFIG_USB_CONFIGFS_OBEX=y
> +CONFIG_USB_CONFIGFS_NCM=y
> +CONFIG_USB_CONFIGFS_ECM=y
> +CONFIG_USB_CONFIGFS_ECM_SUBSET=y
> +CONFIG_USB_CONFIGFS_RNDIS=y
> +CONFIG_USB_CONFIGFS_EEM=y
> +CONFIG_USB_CONFIGFS_MASS_STORAGE=y
> +CONFIG_USB_CONFIGFS_F_LB_SS=y
> +CONFIG_USB_CONFIGFS_F_FS=y
> +CONFIG_USB_CONFIGFS_F_HID=y
> +CONFIG_USB_CONFIGFS_F_PRINTER=y
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_TRIGGERS=y
> +CONFIG_LEDS_TRIGGER_TIMER=y
> +CONFIG_LEDS_TRIGGER_ONESHOT=y
> +CONFIG_LEDS_TRIGGER_MTD=y
> +CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> +CONFIG_LEDS_TRIGGER_CPU=y
> +CONFIG_LEDS_TRIGGER_GPIO=y
> +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> +CONFIG_LEDS_TRIGGER_TRANSIENT=y
> +CONFIG_LEDS_TRIGGER_PANIC=y
> +# CONFIG_VIRTIO_MENU is not set
> +# CONFIG_IOMMU_SUPPORT is not set
> +CONFIG_HPE_GXP_XREG=y
> +CONFIG_HPE_GXP_FN2=y
> +CONFIG_HPE_GXP_CSM=y
> +CONFIG_HPE_GXP_SROM=y
> +CONFIG_FANOTIFY=y
> +CONFIG_OVERLAY_FS=y
> +CONFIG_OVERLAY_FS_REDIRECT_DIR=y
> +CONFIG_TMPFS=y
> +CONFIG_TMPFS_POSIX_ACL=y
> +CONFIG_JFFS2_FS=y
> +# CONFIG_JFFS2_FS_WRITEBUFFER is not set
> +CONFIG_JFFS2_SUMMARY=y
> +CONFIG_JFFS2_FS_XATTR=y
> +# CONFIG_JFFS2_FS_POSIX_ACL is not set
> +# CONFIG_JFFS2_FS_SECURITY is not set
> +CONFIG_SQUASHFS=y
> +CONFIG_SQUASHFS_XZ=y
> +CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
> +# CONFIG_NETWORK_FILESYSTEMS is not set
> +CONFIG_NLS_CODEPAGE_437=y
> +CONFIG_NLS_ASCII=y
> +CONFIG_NLS_ISO8859_1=y
> +CONFIG_NLS_UTF8=y
> +CONFIG_CRYPTO_CCM=y
> +CONFIG_CRYPTO_GCM=y
> +CONFIG_CRYPTO_CRC32C=y
> +CONFIG_CRYPTO_ARC4=y
> +CONFIG_CRYPTO_DEFLATE=y
> +CONFIG_CRYPTO_LZO=y
> +CONFIG_CRYPTO_ZSTD=y
> +CONFIG_CRYPTO_USER_API_HASH=y
> +# CONFIG_CRYPTO_HW is not set
> +CONFIG_CRC16=y
> +# CONFIG_XZ_DEC_ARM is not set
> +# CONFIG_XZ_DEC_ARMTHUMB is not set
> +CONFIG_DMA_API_DEBUG=y
> +CONFIG_PRINTK_TIME=y
> +CONFIG_BOOT_PRINTK_DELAY=y
> +CONFIG_DYNAMIC_DEBUG=y
> +CONFIG_DEBUG_INFO=y
> +# CONFIG_ENABLE_MUST_CHECK is not set
> +CONFIG_MAGIC_SYSRQ=y
> +CONFIG_PANIC_ON_OOPS=y
> +CONFIG_FUNCTION_PROFILER=y
> +CONFIG_STACK_TRACER=y
> +CONFIG_SCHED_TRACER=y
> +CONFIG_STRICT_DEVMEM=y
> +CONFIG_DEBUG_USER=y
> +CONFIG_DEBUG_LL=y
> +CONFIG_DEBUG_LL_UART_8250=y
> +CONFIG_DEBUG_UART_PHYS=0xC00000F0
> +CONFIG_DEBUG_UART_VIRT=0xF00000F0
> +CONFIG_DEBUG_UART_8250_SHIFT=0
> +CONFIG_EARLY_PRINTK=y
> +CONFIG_TEST_KSTRTOX=y
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
> + help
> + Support for GXP SoCs
> +
> +endif
> diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
> new file mode 100644
> index 000000000000..8b0a91234df4
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARCH_HPE_GXP) += gxp.o
> diff --git a/arch/arm/mach-hpe/gxp.c b/arch/arm/mach-hpe/gxp.c
> new file mode 100644
> index 000000000000..b58f25fbae5a
> --- /dev/null
> +++ b/arch/arm/mach-hpe/gxp.c
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +
> +#include <linux/init.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
> +
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
Linux style comments please, so /*.
> + __raw_writel(0x00080002,
What is this magic value?
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
Why do you need the cast?
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
Skip it.
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
> +
> +static const char * const gxp_board_dt_compat[] = {
> + "HPE,GXP",
> + NULL,
> +};
> +
> +DT_MACHINE_START(GXP_DT, "HPE GXP")
> + .init_machine = gxp_dt_init,
> + .map_io = gxp_map_io,
> + .restart = gxp_restart,
> + .dt_compat = gxp_board_dt_compat,
> +MACHINE_END
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-25 19:46 ` nick.hawkins
@ 2022-01-25 22:30 ` Andrew Lunn
-1 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2022-01-25 22:30 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
> + mdio0: mdio@c0004080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0004080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ext_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
c22 is the default, so you don't strictly need this.
> + phy-mode = "sgmii";
> + reg = <0>;
> + };
> + };
> +
> + mdio1: mdio@c0005080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0005080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <0>;
> + };
> + int_phy1: ethernt-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <1>;
> + };
> + };
> +
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
A space in a compatible?
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
That is pretty unusual. Normally you leave the bootloader to fill this
in with a per board MAC address. The danger with listing it here is
that you have multiple boards in the same network using this MAC
address, and then bad things happen.
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
Two phy-handles? Some very odd going on here!
> + xreg_kyes: xreg_keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <100>;
> +
> + IdButton {
> + label = "ID Button";
> + linux,code = <200>;
include/dt-bindings/input/linux-event-codes.h
However
#define KEY_PLAYCD 200
A BMC has a CD player? Maybe i have this wrong?
> + PortOwner@0 {
> + label = "Port Owner";
> + linux,code = <200>;
> + gpios = <&gpio 250 1>;
Two CD players?
> + };
> +
> + PortOwner@1 {
> + label = "Port Owner";
> + linux,code = <201>;
#define KEY_PAUSECD 201
And you can pause the second player?
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-25 22:30 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2022-01-25 22:30 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
> + mdio0: mdio@c0004080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0004080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ext_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
c22 is the default, so you don't strictly need this.
> + phy-mode = "sgmii";
> + reg = <0>;
> + };
> + };
> +
> + mdio1: mdio@c0005080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0005080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <0>;
> + };
> + int_phy1: ethernt-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <1>;
> + };
> + };
> +
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
A space in a compatible?
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
That is pretty unusual. Normally you leave the bootloader to fill this
in with a per board MAC address. The danger with listing it here is
that you have multiple boards in the same network using this MAC
address, and then bad things happen.
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
Two phy-handles? Some very odd going on here!
> + xreg_kyes: xreg_keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <100>;
> +
> + IdButton {
> + label = "ID Button";
> + linux,code = <200>;
include/dt-bindings/input/linux-event-codes.h
However
#define KEY_PLAYCD 200
A BMC has a CD player? Maybe i have this wrong?
> + PortOwner@0 {
> + label = "Port Owner";
> + linux,code = <200>;
> + gpios = <&gpio 250 1>;
Two CD players?
> + };
> +
> + PortOwner@1 {
> + label = "Port Owner";
> + linux,code = <201>;
#define KEY_PAUSECD 201
And you can pause the second player?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-25 19:46 ` nick.hawkins
@ 2022-01-25 22:46 ` Andrew Lunn
-1 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2022-01-25 22:46 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
> + };
I suggest you don't add any DT for drivers which have not been
accepted yet. When you MAC driver is posted to netdev, the DT binding
will get reviewed. And i expect int-phy-handle will be rejected.
Often the first dtsi and dts submission for a new SoC have just the
CPUs and the serial port, since none of the other drivers have been
reviewed yet, unless they reuse existing drivers. The additional nodes
are then added one by one as the drivers get accepted.
Andrew
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-25 22:46 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2022-01-25 22:46 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
> + };
I suggest you don't add any DT for drivers which have not been
accepted yet. When you MAC driver is posted to netdev, the DT binding
will get reviewed. And i expect int-phy-handle will be rejected.
Often the first dtsi and dts submission for a new SoC have just the
CPUs and the serial port, since none of the other drivers have been
reviewed yet, unless they reuse existing drivers. The additional nodes
are then added one by one as the drivers get accepted.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-25 19:46 ` nick.hawkins
@ 2022-01-26 0:22 ` Arnd Bergmann
-1 siblings, 0 replies; 27+ messages in thread
From: Arnd Bergmann @ 2022-01-26 0:22 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
'On Tue, Jan 25, 2022 at 8:46 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Hi Nick,
Thanks for your submission, it's always nice to see support for a new platform.
I assume that you have a number of other drivers that are required for
an initial
support, at least to get you booting into a shell. I recommend to keep
those together
as a series, and we can merge them through the soc tree initially, with an Ack
from the corresponding subsystem maintainers. For later updates to the drivers,
you should send them to the maintainers directly, same for any
non-essential drivers
Krzysztof already commented on most issues I see, here are a few more things
to consider:
>
> +GXP ARCHITECTURE
Make this "ARM/HPE GXP ARCHITECTURE", so it does not get mistaken
for a separate instruction set architecture, or something else with that three
letter acronym.
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
> + model = "GXP";
Make this the specific machine rather than the SoC, unless you can guarantee
that there won't ever be another board revision made from the same SoC (family).
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
> + };
The bootargs should be set by the bootloader. In particular there should be
not 'earlyprintk' by default, and the console should be selected using the
'stdout-path' property.
You seem to be missing CPU nodes.
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
Add a custom compatible string as a specialization in case you ever
need to work around some quirk on these devices.
> + spifi0: spifi@c0000200 {
> + compatible = "hpe,gxp-spifi";
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
The partitions should ideally be set by the bootloader as well, or
at least be in the .dts file separately from the soc .dtsi file.
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
Do you have a strong reason for needing a custom defconfig file?
Usually this should
work with the normal multi_v7_defconfig.
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
Most of the symbols you select are implied by ARCH_MULTI_V7, so you
can remove them here.
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
We don't normally do custom mappings any more, these should come from
the device tree and get mapped by the corresponding drivers.
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
> + __raw_writel(0x00080002,
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
This belongs into the bootloader, or the EHCI driver, see the comment about a
custom compatible value above ;-)
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
This should be a reset driver, see
drivers/power/reset/syscon-reboot.c either as an example, or something you
can use directly.
Arnd
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-26 0:22 ` Arnd Bergmann
0 siblings, 0 replies; 27+ messages in thread
From: Arnd Bergmann @ 2022-01-26 0:22 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski,
Shawn Guo, Stanislav Jakubek, Sam Ravnborg, Linus Walleij,
Hao Fang, Arnd Bergmann, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
'On Tue, Jan 25, 2022 at 8:46 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Hi Nick,
Thanks for your submission, it's always nice to see support for a new platform.
I assume that you have a number of other drivers that are required for
an initial
support, at least to get you booting into a shell. I recommend to keep
those together
as a series, and we can merge them through the soc tree initially, with an Ack
from the corresponding subsystem maintainers. For later updates to the drivers,
you should send them to the maintainers directly, same for any
non-essential drivers
Krzysztof already commented on most issues I see, here are a few more things
to consider:
>
> +GXP ARCHITECTURE
Make this "ARM/HPE GXP ARCHITECTURE", so it does not get mistaken
for a separate instruction set architecture, or something else with that three
letter acronym.
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
> + model = "GXP";
Make this the specific machine rather than the SoC, unless you can guarantee
that there won't ever be another board revision made from the same SoC (family).
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
> + };
The bootargs should be set by the bootloader. In particular there should be
not 'earlyprintk' by default, and the console should be selected using the
'stdout-path' property.
You seem to be missing CPU nodes.
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
Add a custom compatible string as a specialization in case you ever
need to work around some quirk on these devices.
> + spifi0: spifi@c0000200 {
> + compatible = "hpe,gxp-spifi";
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
The partitions should ideally be set by the bootloader as well, or
at least be in the .dts file separately from the soc .dtsi file.
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
Do you have a strong reason for needing a custom defconfig file?
Usually this should
work with the normal multi_v7_defconfig.
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
Most of the symbols you select are implied by ARCH_MULTI_V7, so you
can remove them here.
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
We don't normally do custom mappings any more, these should come from
the device tree and get mapped by the corresponding drivers.
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
> + __raw_writel(0x00080002,
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
This belongs into the bootloader, or the EHCI driver, see the comment about a
custom compatible value above ;-)
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
This should be a reset driver, see
drivers/power/reset/syscon-reboot.c either as an example, or something you
can use directly.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-26 0:22 ` Arnd Bergmann
@ 2022-01-26 1:49 ` Verdun, Jean-Marie
-1 siblings, 0 replies; 27+ messages in thread
From: Verdun, Jean-Marie @ 2022-01-26 1:49 UTC (permalink / raw)
To: Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Krzysztof Kozlowski, Shawn Guo,
Stanislav Jakubek, Sam Ravnborg, Linus Walleij, Hao Fang,
Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
Hello Arnd,
I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
vejmarie
On 1/25/22, 4:22 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
'On Tue, Jan 25, 2022 at 8:46 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Hi Nick,
Thanks for your submission, it's always nice to see support for a new platform.
I assume that you have a number of other drivers that are required for
an initial
support, at least to get you booting into a shell. I recommend to keep
those together
as a series, and we can merge them through the soc tree initially, with an Ack
from the corresponding subsystem maintainers. For later updates to the drivers,
you should send them to the maintainers directly, same for any
non-essential drivers
Krzysztof already commented on most issues I see, here are a few more things
to consider:
>
> +GXP ARCHITECTURE
Make this "ARM/HPE GXP ARCHITECTURE", so it does not get mistaken
for a separate instruction set architecture, or something else with that three
letter acronym.
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
> + model = "GXP";
Make this the specific machine rather than the SoC, unless you can guarantee
that there won't ever be another board revision made from the same SoC (family).
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
> + };
The bootargs should be set by the bootloader. In particular there should be
not 'earlyprintk' by default, and the console should be selected using the
'stdout-path' property.
You seem to be missing CPU nodes.
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
Add a custom compatible string as a specialization in case you ever
need to work around some quirk on these devices.
> + spifi0: spifi@c0000200 {
> + compatible = "hpe,gxp-spifi";
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
The partitions should ideally be set by the bootloader as well, or
at least be in the .dts file separately from the soc .dtsi file.
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
Do you have a strong reason for needing a custom defconfig file?
Usually this should
work with the normal multi_v7_defconfig.
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
Most of the symbols you select are implied by ARCH_MULTI_V7, so you
can remove them here.
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
We don't normally do custom mappings any more, these should come from
the device tree and get mapped by the corresponding drivers.
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
> + __raw_writel(0x00080002,
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
This belongs into the bootloader, or the EHCI driver, see the comment about a
custom compatible value above ;-)
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
This should be a reset driver, see
drivers/power/reset/syscon-reboot.c either as an example, or something you
can use directly.
Arnd
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-26 1:49 ` Verdun, Jean-Marie
0 siblings, 0 replies; 27+ messages in thread
From: Verdun, Jean-Marie @ 2022-01-26 1:49 UTC (permalink / raw)
To: Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Krzysztof Kozlowski, Shawn Guo,
Stanislav Jakubek, Sam Ravnborg, Linus Walleij, Hao Fang,
Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
Hello Arnd,
I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
vejmarie
On 1/25/22, 4:22 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
'On Tue, Jan 25, 2022 at 8:46 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Hi Nick,
Thanks for your submission, it's always nice to see support for a new platform.
I assume that you have a number of other drivers that are required for
an initial
support, at least to get you booting into a shell. I recommend to keep
those together
as a series, and we can merge them through the soc tree initially, with an Ack
from the corresponding subsystem maintainers. For later updates to the drivers,
you should send them to the maintainers directly, same for any
non-essential drivers
Krzysztof already commented on most issues I see, here are a few more things
to consider:
>
> +GXP ARCHITECTURE
Make this "ARM/HPE GXP ARCHITECTURE", so it does not get mistaken
for a separate instruction set architecture, or something else with that three
letter acronym.
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
> + model = "GXP";
Make this the specific machine rather than the SoC, unless you can guarantee
that there won't ever be another board revision made from the same SoC (family).
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
> + };
The bootargs should be set by the bootloader. In particular there should be
not 'earlyprintk' by default, and the console should be selected using the
'stdout-path' property.
You seem to be missing CPU nodes.
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
Add a custom compatible string as a specialization in case you ever
need to work around some quirk on these devices.
> + spifi0: spifi@c0000200 {
> + compatible = "hpe,gxp-spifi";
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
The partitions should ideally be set by the bootloader as well, or
at least be in the .dts file separately from the soc .dtsi file.
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
Do you have a strong reason for needing a custom defconfig file?
Usually this should
work with the normal multi_v7_defconfig.
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
Most of the symbols you select are implied by ARCH_MULTI_V7, so you
can remove them here.
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
We don't normally do custom mappings any more, these should come from
the device tree and get mapped by the corresponding drivers.
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
> + __raw_writel(0x00080002,
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
This belongs into the bootloader, or the EHCI driver, see the comment about a
custom compatible value above ;-)
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
This should be a reset driver, see
drivers/power/reset/syscon-reboot.c either as an example, or something you
can use directly.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-25 19:46 ` nick.hawkins
@ 2022-01-26 8:25 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-01-26 8:25 UTC (permalink / raw)
To: nick.hawkins, verdun
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Arnd Bergmann,
Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
On 25/01/2022 20:46, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> arch/arm/Kconfig | 2 +
> arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
> arch/arm/configs/gxp_defconfig | 243 ++++++
> arch/arm/mach-hpe/Kconfig | 20 +
> arch/arm/mach-hpe/Makefile | 1 +
> arch/arm/mach-hpe/gxp.c | 63 ++
> 8 files changed, 1039 insertions(+)
> create mode 100644 arch/arm/boot/dts/gxp.dts
> create mode 100644 arch/arm/configs/gxp_defconfig
> create mode 100644 arch/arm/mach-hpe/Kconfig
> create mode 100644 arch/arm/mach-hpe/Makefile
> create mode 100644 arch/arm/mach-hpe/gxp.c
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 294093d45a23..e8b0ec874aed 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -515,6 +515,8 @@ patternProperties:
> description: Jiangsu HopeRun Software Co., Ltd.
> "^hp,.*":
> description: Hewlett Packard
I guess this should be renamed/clarified to "Hewlett Packard
Incorporated", since these are two different companies.
Anyway, bindings go as separate patch, first in the series.
> + "^hpe,.*":
> + description: Hewlett Packard Enterprise
> "^hsg,.*":
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-26 8:25 ` Krzysztof Kozlowski
0 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-01-26 8:25 UTC (permalink / raw)
To: nick.hawkins, verdun
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Arnd Bergmann,
Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, devicetree,
linux-kernel, linux-arm-kernel
On 25/01/2022 20:46, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> arch/arm/Kconfig | 2 +
> arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
> arch/arm/configs/gxp_defconfig | 243 ++++++
> arch/arm/mach-hpe/Kconfig | 20 +
> arch/arm/mach-hpe/Makefile | 1 +
> arch/arm/mach-hpe/gxp.c | 63 ++
> 8 files changed, 1039 insertions(+)
> create mode 100644 arch/arm/boot/dts/gxp.dts
> create mode 100644 arch/arm/configs/gxp_defconfig
> create mode 100644 arch/arm/mach-hpe/Kconfig
> create mode 100644 arch/arm/mach-hpe/Makefile
> create mode 100644 arch/arm/mach-hpe/gxp.c
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 294093d45a23..e8b0ec874aed 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -515,6 +515,8 @@ patternProperties:
> description: Jiangsu HopeRun Software Co., Ltd.
> "^hp,.*":
> description: Hewlett Packard
I guess this should be renamed/clarified to "Hewlett Packard
Incorporated", since these are two different companies.
Anyway, bindings go as separate patch, first in the series.
> + "^hpe,.*":
> + description: Hewlett Packard Enterprise
> "^hsg,.*":
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-26 1:49 ` Verdun, Jean-Marie
@ 2022-01-26 8:41 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-01-26 8:41 UTC (permalink / raw)
To: Verdun, Jean-Marie, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
On 26/01/2022 02:49, Verdun, Jean-Marie wrote:
> Hello Arnd,
>
> I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
>
> We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
The current DTS patch won't pass checkpatch because you have around 30
undocumented compatibles. The process does not have to be sequential -
quite contrary - rather parallel with several submission happening the
same time. The point is that we need to see the bindings and check
whether your DTS complies with them. Actually the check should be done
by you with dtbs_check, but let's say we also look at it.
Your patch with full-blown DTS and drivers is also good approach, except
there are no drivers sent. For example:
https://lore.kernel.org/?q=hpe%2Cgxp-i2c
https://lore.kernel.org/?q=hpe%2Cgxp-wdt
If you want to avoid building DTS sequentially, no problem, just send
the bindings and DTS.
Andrew's approach is much more flexible because it allows you to discuss
the bindings while not postponing the core part of DTS.
>
> Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
>
> We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
The commit misses description, so I actually don't know how the
architecture looks like. For most of SoC, there is a DTSI because the
SoC is being put on different boards/products. It allows clear
separation between SoC (which could be reused) and board. If you have
only a DTS, then:
1. Where is the SoC here? How it can be re-used by different board?
2. Is it only one DTS per entire sub-architecture? No more boards? Only
one product? No even revisions or improved versions?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-26 8:41 ` Krzysztof Kozlowski
0 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-01-26 8:41 UTC (permalink / raw)
To: Verdun, Jean-Marie, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
On 26/01/2022 02:49, Verdun, Jean-Marie wrote:
> Hello Arnd,
>
> I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
>
> We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
The current DTS patch won't pass checkpatch because you have around 30
undocumented compatibles. The process does not have to be sequential -
quite contrary - rather parallel with several submission happening the
same time. The point is that we need to see the bindings and check
whether your DTS complies with them. Actually the check should be done
by you with dtbs_check, but let's say we also look at it.
Your patch with full-blown DTS and drivers is also good approach, except
there are no drivers sent. For example:
https://lore.kernel.org/?q=hpe%2Cgxp-i2c
https://lore.kernel.org/?q=hpe%2Cgxp-wdt
If you want to avoid building DTS sequentially, no problem, just send
the bindings and DTS.
Andrew's approach is much more flexible because it allows you to discuss
the bindings while not postponing the core part of DTS.
>
> Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
>
> We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
The commit misses description, so I actually don't know how the
architecture looks like. For most of SoC, there is a DTSI because the
SoC is being put on different boards/products. It allows clear
separation between SoC (which could be reused) and board. If you have
only a DTS, then:
1. Where is the SoC here? How it can be re-used by different board?
2. Is it only one DTS per entire sub-architecture? No more boards? Only
one product? No even revisions or improved versions?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-26 8:41 ` Krzysztof Kozlowski
@ 2022-01-31 18:52 ` Verdun, Jean-Marie
-1 siblings, 0 replies; 27+ messages in thread
From: Verdun, Jean-Marie @ 2022-01-31 18:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
Hi Krzysztof
We made some progress during the week-end and took the decision to breakdown the dts as you recommended (one dtsi for the SoC, and one dts per system board, we will start with the dl360 Gen10 server). We will send you some updates during the week, as I need to validate a few things with some of my colleagues regarding the partition tables definition which we kept (for the moment) into the ASIC definition, as all our implementation are using currently the same partition table.
We also removed many of the warning generated by the dtc compiler.
We will probably send the driver code at the same time than the dts update (or the next day). There will be a few of them including
- gpio
- hwmon
- udc / usb gadget
- umac
- i2c
- watchdog
- fbdev
- kcs
- vuart
- spifi
- clock
So as to simplify your understanding
- GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
- This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
It does support many features including:
- ARMv7 architecture, and it is based on a Cortex A9 core
- Use an AXI bus to which
- a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
- Multiple I2C engines to drive connectivity with a host infrastructure
- A video engine which support VGA and DP, as well as an hardware video encder
- Multiple PCIe ports
- A PECI interface, and LPC eSPI
- Multiple UART for debug purpose, and Virtual UART for host connectivity
- A GPIO engine
Hope this help,
vejmarie
On 1/26/22, 12:41 AM, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com> wrote:
On 26/01/2022 02:49, Verdun, Jean-Marie wrote:
> Hello Arnd,
>
> I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
>
> We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
The current DTS patch won't pass checkpatch because you have around 30
undocumented compatibles. The process does not have to be sequential -
quite contrary - rather parallel with several submission happening the
same time. The point is that we need to see the bindings and check
whether your DTS complies with them. Actually the check should be done
by you with dtbs_check, but let's say we also look at it.
Your patch with full-blown DTS and drivers is also good approach, except
there are no drivers sent. For example:
https://lore.kernel.org/?q=hpe%2Cgxp-i2c
https://lore.kernel.org/?q=hpe%2Cgxp-wdt
If you want to avoid building DTS sequentially, no problem, just send
the bindings and DTS.
Andrew's approach is much more flexible because it allows you to discuss
the bindings while not postponing the core part of DTS.
>
> Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
>
> We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
The commit misses description, so I actually don't know how the
architecture looks like. For most of SoC, there is a DTSI because the
SoC is being put on different boards/products. It allows clear
separation between SoC (which could be reused) and board. If you have
only a DTS, then:
1. Where is the SoC here? How it can be re-used by different board?
2. Is it only one DTS per entire sub-architecture? No more boards? Only
one product? No even revisions or improved versions?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-01-31 18:52 ` Verdun, Jean-Marie
0 siblings, 0 replies; 27+ messages in thread
From: Verdun, Jean-Marie @ 2022-01-31 18:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
Hi Krzysztof
We made some progress during the week-end and took the decision to breakdown the dts as you recommended (one dtsi for the SoC, and one dts per system board, we will start with the dl360 Gen10 server). We will send you some updates during the week, as I need to validate a few things with some of my colleagues regarding the partition tables definition which we kept (for the moment) into the ASIC definition, as all our implementation are using currently the same partition table.
We also removed many of the warning generated by the dtc compiler.
We will probably send the driver code at the same time than the dts update (or the next day). There will be a few of them including
- gpio
- hwmon
- udc / usb gadget
- umac
- i2c
- watchdog
- fbdev
- kcs
- vuart
- spifi
- clock
So as to simplify your understanding
- GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
- This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
It does support many features including:
- ARMv7 architecture, and it is based on a Cortex A9 core
- Use an AXI bus to which
- a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
- Multiple I2C engines to drive connectivity with a host infrastructure
- A video engine which support VGA and DP, as well as an hardware video encder
- Multiple PCIe ports
- A PECI interface, and LPC eSPI
- Multiple UART for debug purpose, and Virtual UART for host connectivity
- A GPIO engine
Hope this help,
vejmarie
On 1/26/22, 12:41 AM, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com> wrote:
On 26/01/2022 02:49, Verdun, Jean-Marie wrote:
> Hello Arnd,
>
> I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
>
> We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
The current DTS patch won't pass checkpatch because you have around 30
undocumented compatibles. The process does not have to be sequential -
quite contrary - rather parallel with several submission happening the
same time. The point is that we need to see the bindings and check
whether your DTS complies with them. Actually the check should be done
by you with dtbs_check, but let's say we also look at it.
Your patch with full-blown DTS and drivers is also good approach, except
there are no drivers sent. For example:
https://lore.kernel.org/?q=hpe%2Cgxp-i2c
https://lore.kernel.org/?q=hpe%2Cgxp-wdt
If you want to avoid building DTS sequentially, no problem, just send
the bindings and DTS.
Andrew's approach is much more flexible because it allows you to discuss
the bindings while not postponing the core part of DTS.
>
> Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
>
> We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
The commit misses description, so I actually don't know how the
architecture looks like. For most of SoC, there is a DTSI because the
SoC is being put on different boards/products. It allows clear
separation between SoC (which could be reused) and board. If you have
only a DTS, then:
1. Where is the SoC here? How it can be re-used by different board?
2. Is it only one DTS per entire sub-architecture? No more boards? Only
one product? No even revisions or improved versions?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-31 18:52 ` Verdun, Jean-Marie
(?)
@ 2022-01-31 19:01 ` Sam Ravnborg
-1 siblings, 0 replies; 27+ messages in thread
From: Sam Ravnborg @ 2022-01-31 19:01 UTC (permalink / raw)
To: Verdun, Jean-Marie
Cc: Krzysztof Kozlowski, Arnd Bergmann, Hawkins, Nick, Rob Herring,
Russell King, Shawn Guo, Stanislav Jakubek, Linus Walleij,
Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
Hi vejmarie,
> We will probably send the driver code at the same time than the dts update (or the next day). There will be a few of them including
>
> - gpio
> - hwmon
> - udc / usb gadget
> - umac
> - i2c
> - watchdog
> - fbdev
fbdev is only for old stuff, new display drivers should be made using
the drm framework. If you look in drivers/gpu/drm/tiny/ you fill find
plenty examples of very simple drivers.
Sam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-31 18:52 ` Verdun, Jean-Marie
@ 2022-02-01 7:37 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-02-01 7:37 UTC (permalink / raw)
To: Verdun, Jean-Marie, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
On 31/01/2022 19:52, Verdun, Jean-Marie wrote:
> Hi Krzysztof
>
> We made some progress during the week-end and took the decision to breakdown the dts as you recommended (one dtsi for the SoC, and one dts per system board, we will start with the dl360 Gen10 server). We will send you some updates during the week, as I need to validate a few things with some of my colleagues regarding the partition tables definition which we kept (for the moment) into the ASIC definition, as all our implementation are using currently the same partition table.
>
> We also removed many of the warning generated by the dtc compiler.
>
> We will probably send the driver code at the same time than the dts update (or the next day). There will be a few of them including
>
> - gpio
> - hwmon
> - udc / usb gadget
> - umac
> - i2c
> - watchdog
> - fbdev
> - kcs
> - vuart
> - spifi
> - clock
>
> So as to simplify your understanding
>
> - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
>
> It does support many features including:
> - ARMv7 architecture, and it is based on a Cortex A9 core
> - Use an AXI bus to which
> - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> - Multiple I2C engines to drive connectivity with a host infrastructure
> - A video engine which support VGA and DP, as well as an hardware video encder
> - Multiple PCIe ports
> - A PECI interface, and LPC eSPI
> - Multiple UART for debug purpose, and Virtual UART for host connectivity
> - A GPIO engine
>
> Hope this help,
>
Thanks, this helps, but it should be in the cover letter of the pathshet
plus some parts of it (subtract) in commit adding the new SoC support.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-02-01 7:37 ` Krzysztof Kozlowski
0 siblings, 0 replies; 27+ messages in thread
From: Krzysztof Kozlowski @ 2022-02-01 7:37 UTC (permalink / raw)
To: Verdun, Jean-Marie, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
On 31/01/2022 19:52, Verdun, Jean-Marie wrote:
> Hi Krzysztof
>
> We made some progress during the week-end and took the decision to breakdown the dts as you recommended (one dtsi for the SoC, and one dts per system board, we will start with the dl360 Gen10 server). We will send you some updates during the week, as I need to validate a few things with some of my colleagues regarding the partition tables definition which we kept (for the moment) into the ASIC definition, as all our implementation are using currently the same partition table.
>
> We also removed many of the warning generated by the dtc compiler.
>
> We will probably send the driver code at the same time than the dts update (or the next day). There will be a few of them including
>
> - gpio
> - hwmon
> - udc / usb gadget
> - umac
> - i2c
> - watchdog
> - fbdev
> - kcs
> - vuart
> - spifi
> - clock
>
> So as to simplify your understanding
>
> - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
>
> It does support many features including:
> - ARMv7 architecture, and it is based on a Cortex A9 core
> - Use an AXI bus to which
> - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> - Multiple I2C engines to drive connectivity with a host infrastructure
> - A video engine which support VGA and DP, as well as an hardware video encder
> - Multiple PCIe ports
> - A PECI interface, and LPC eSPI
> - Multiple UART for debug purpose, and Virtual UART for host connectivity
> - A GPIO engine
>
> Hope this help,
>
Thanks, this helps, but it should be in the cover letter of the pathshet
plus some parts of it (subtract) in commit adding the new SoC support.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-01-31 18:52 ` Verdun, Jean-Marie
(?)
@ 2022-02-01 8:59 ` Arnd Bergmann
-1 siblings, 0 replies; 27+ messages in thread
From: Arnd Bergmann @ 2022-02-01 8:59 UTC (permalink / raw)
To: Verdun, Jean-Marie
Cc: Krzysztof Kozlowski, Arnd Bergmann, Hawkins, Nick, Rob Herring,
Russell King, Shawn Guo, Stanislav Jakubek, Sam Ravnborg,
Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM, Joel Stanley,
OpenBMC Maillist
On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
>
> - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
Is there any more specific name of the chip that can be used to identify the
exact generation after a new one comes out? The normal way we handle
compatible strings for devices is to start with a specific model number of
the chip that integrates it, and then have later chips refer to the device by
its new name, with the old one as a fallback. This makes drivers work out of
the box when the device is unchanged, but gives you a way to distinguish them
if a difference gets noticed after both revisions are already used.
As with some of points that Krzysztof and others made previously, the goal
here is to avoid binding incompatibilities in the future: anything that works
in an upstream kernel should keep working in later versions, ideally
allowing any combination of old and new dtb blobs in the bootloader
with old or new kernel versions.
> It does support many features including:
> - ARMv7 architecture, and it is based on a Cortex A9 core
> - Use an AXI bus to which
> - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> - Multiple I2C engines to drive connectivity with a host infrastructure
> - A video engine which support VGA and DP, as well as an hardware video encder
> - Multiple PCIe ports
> - A PECI interface, and LPC eSPI
> - Multiple UART for debug purpose, and Virtual UART for host connectivity
> - A GPIO engine
Thanks for the description. This seems quite normal then, similar to the
aspeed and npcm BMC platforms that we support already. You can
probably drop some of the people on the Cc list, but I would suggest you add
the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel
would be the best person to review the parts that are BMC specific.
> vejmarie
>
> On 1/26/22, 12:41 AM, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com> wrote:
>...
Please follow the normal quoting style when replying to mailing list messages:
reply below the part you are quoting, and trim the parts of the original message
you are not quoting.
Arnd
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-02-01 8:59 ` Arnd Bergmann
0 siblings, 0 replies; 27+ messages in thread
From: Arnd Bergmann @ 2022-02-01 8:59 UTC (permalink / raw)
To: Verdun, Jean-Marie
Cc: Mark Rutland, Geert Uytterhoeven, Linus Walleij, Sam Ravnborg,
Ard Biesheuvel, Stanislav Jakubek, Hao Fang, Krzysztof Kozlowski,
OpenBMC Maillist, Russell King, Lukas Bulwahn, DTML,
Arnd Bergmann, Anshuman Khandual, Russell King (Oracle),
Rob Herring, Hawkins, Nick, Linux ARM, Linux Kernel Mailing List,
Shawn Guo, Masahiro Yamada
On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
>
> - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
Is there any more specific name of the chip that can be used to identify the
exact generation after a new one comes out? The normal way we handle
compatible strings for devices is to start with a specific model number of
the chip that integrates it, and then have later chips refer to the device by
its new name, with the old one as a fallback. This makes drivers work out of
the box when the device is unchanged, but gives you a way to distinguish them
if a difference gets noticed after both revisions are already used.
As with some of points that Krzysztof and others made previously, the goal
here is to avoid binding incompatibilities in the future: anything that works
in an upstream kernel should keep working in later versions, ideally
allowing any combination of old and new dtb blobs in the bootloader
with old or new kernel versions.
> It does support many features including:
> - ARMv7 architecture, and it is based on a Cortex A9 core
> - Use an AXI bus to which
> - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> - Multiple I2C engines to drive connectivity with a host infrastructure
> - A video engine which support VGA and DP, as well as an hardware video encder
> - Multiple PCIe ports
> - A PECI interface, and LPC eSPI
> - Multiple UART for debug purpose, and Virtual UART for host connectivity
> - A GPIO engine
Thanks for the description. This seems quite normal then, similar to the
aspeed and npcm BMC platforms that we support already. You can
probably drop some of the people on the Cc list, but I would suggest you add
the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel
would be the best person to review the parts that are BMC specific.
> vejmarie
>
> On 1/26/22, 12:41 AM, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com> wrote:
>...
Please follow the normal quoting style when replying to mailing list messages:
reply below the part you are quoting, and trim the parts of the original message
you are not quoting.
Arnd
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-02-01 8:59 ` Arnd Bergmann
0 siblings, 0 replies; 27+ messages in thread
From: Arnd Bergmann @ 2022-02-01 8:59 UTC (permalink / raw)
To: Verdun, Jean-Marie
Cc: Krzysztof Kozlowski, Arnd Bergmann, Hawkins, Nick, Rob Herring,
Russell King, Shawn Guo, Stanislav Jakubek, Sam Ravnborg,
Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM, Joel Stanley,
OpenBMC Maillist
On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
>
> - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
Is there any more specific name of the chip that can be used to identify the
exact generation after a new one comes out? The normal way we handle
compatible strings for devices is to start with a specific model number of
the chip that integrates it, and then have later chips refer to the device by
its new name, with the old one as a fallback. This makes drivers work out of
the box when the device is unchanged, but gives you a way to distinguish them
if a difference gets noticed after both revisions are already used.
As with some of points that Krzysztof and others made previously, the goal
here is to avoid binding incompatibilities in the future: anything that works
in an upstream kernel should keep working in later versions, ideally
allowing any combination of old and new dtb blobs in the bootloader
with old or new kernel versions.
> It does support many features including:
> - ARMv7 architecture, and it is based on a Cortex A9 core
> - Use an AXI bus to which
> - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> - Multiple I2C engines to drive connectivity with a host infrastructure
> - A video engine which support VGA and DP, as well as an hardware video encder
> - Multiple PCIe ports
> - A PECI interface, and LPC eSPI
> - Multiple UART for debug purpose, and Virtual UART for host connectivity
> - A GPIO engine
Thanks for the description. This seems quite normal then, similar to the
aspeed and npcm BMC platforms that we support already. You can
probably drop some of the people on the Cc list, but I would suggest you add
the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel
would be the best person to review the parts that are BMC specific.
> vejmarie
>
> On 1/26/22, 12:41 AM, "Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com> wrote:
>...
Please follow the normal quoting style when replying to mailing list messages:
reply below the part you are quoting, and trim the parts of the original message
you are not quoting.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
2022-02-01 8:59 ` Arnd Bergmann
(?)
@ 2022-02-21 8:39 ` Joel Stanley
-1 siblings, 0 replies; 27+ messages in thread
From: Joel Stanley @ 2022-02-21 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Verdun, Jean-Marie, Krzysztof Kozlowski, Hawkins, Nick,
Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM, OpenBMC Maillist
On Tue, 1 Feb 2022 at 09:00, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
> >
> > - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> > - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
>
> Is there any more specific name of the chip that can be used to identify the
> exact generation after a new one comes out? The normal way we handle
> compatible strings for devices is to start with a specific model number of
> the chip that integrates it, and then have later chips refer to the device by
> its new name, with the old one as a fallback. This makes drivers work out of
> the box when the device is unchanged, but gives you a way to distinguish them
> if a difference gets noticed after both revisions are already used.
>
> As with some of points that Krzysztof and others made previously, the goal
> here is to avoid binding incompatibilities in the future: anything that works
> in an upstream kernel should keep working in later versions, ideally
> allowing any combination of old and new dtb blobs in the bootloader
> with old or new kernel versions.
>
> > It does support many features including:
> > - ARMv7 architecture, and it is based on a Cortex A9 core
> > - Use an AXI bus to which
> > - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> > - Multiple I2C engines to drive connectivity with a host infrastructure
> > - A video engine which support VGA and DP, as well as an hardware video encder
> > - Multiple PCIe ports
> > - A PECI interface, and LPC eSPI
> > - Multiple UART for debug purpose, and Virtual UART for host connectivity
> > - A GPIO engine
>
> Thanks for the description. This seems quite normal then, similar to the
> aspeed and npcm BMC platforms that we support already. You can
> probably drop some of the people on the Cc list, but I would suggest you add
> the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel
> would be the best person to review the parts that are BMC specific.
I had a call with some of the HPE developers a while back. It's good
to hear from you again.
As Arnd said, please cc me on your submissions and I'll provide
review. You can also cc openbmc@lists.ozlabs.org to reach a wider
audience of BMC developers.
After our call the other month, I took a look at your latest kernel
tree and started teasing out something that could be submitted:
https://github.com/shenki/linux/commits/gxp
Hopefully this helps illustrate what we mean about breaking down the
patches into small logical chunks. Don't take what I've done there as
correct, but it's an indication. Feel free to re-use.
I encourage you to take a look at the aspeed device trees for
inspiration. The way they are organised into generations - 2400, 2500,
2600 - illistrate's Arnd's points about supporting multiple
generations of SoC with the one code base.
Cheers,
Joel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-02-21 8:39 ` Joel Stanley
0 siblings, 0 replies; 27+ messages in thread
From: Joel Stanley @ 2022-02-21 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, DTML, Hao Fang, Linux Kernel Mailing List,
Geert Uytterhoeven, Krzysztof Kozlowski, OpenBMC Maillist,
Sam Ravnborg, Verdun, Jean-Marie, Anshuman Khandual,
Russell King, Ard Biesheuvel, Russell King (Oracle),
Rob Herring, Linux ARM, Hawkins, Nick, Lukas Bulwahn,
Masahiro Yamada, Shawn Guo, Linus Walleij, Stanislav Jakubek
On Tue, 1 Feb 2022 at 09:00, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
> >
> > - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> > - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
>
> Is there any more specific name of the chip that can be used to identify the
> exact generation after a new one comes out? The normal way we handle
> compatible strings for devices is to start with a specific model number of
> the chip that integrates it, and then have later chips refer to the device by
> its new name, with the old one as a fallback. This makes drivers work out of
> the box when the device is unchanged, but gives you a way to distinguish them
> if a difference gets noticed after both revisions are already used.
>
> As with some of points that Krzysztof and others made previously, the goal
> here is to avoid binding incompatibilities in the future: anything that works
> in an upstream kernel should keep working in later versions, ideally
> allowing any combination of old and new dtb blobs in the bootloader
> with old or new kernel versions.
>
> > It does support many features including:
> > - ARMv7 architecture, and it is based on a Cortex A9 core
> > - Use an AXI bus to which
> > - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> > - Multiple I2C engines to drive connectivity with a host infrastructure
> > - A video engine which support VGA and DP, as well as an hardware video encder
> > - Multiple PCIe ports
> > - A PECI interface, and LPC eSPI
> > - Multiple UART for debug purpose, and Virtual UART for host connectivity
> > - A GPIO engine
>
> Thanks for the description. This seems quite normal then, similar to the
> aspeed and npcm BMC platforms that we support already. You can
> probably drop some of the people on the Cc list, but I would suggest you add
> the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel
> would be the best person to review the parts that are BMC specific.
I had a call with some of the HPE developers a while back. It's good
to hear from you again.
As Arnd said, please cc me on your submissions and I'll provide
review. You can also cc openbmc@lists.ozlabs.org to reach a wider
audience of BMC developers.
After our call the other month, I took a look at your latest kernel
tree and started teasing out something that could be submitted:
https://github.com/shenki/linux/commits/gxp
Hopefully this helps illustrate what we mean about breaking down the
patches into small logical chunks. Don't take what I've done there as
correct, but it's an indication. Feel free to re-use.
I encourage you to take a look at the aspeed device trees for
inspiration. The way they are organised into generations - 2400, 2500,
2600 - illistrate's Arnd's points about supporting multiple
generations of SoC with the one code base.
Cheers,
Joel
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
@ 2022-02-21 8:39 ` Joel Stanley
0 siblings, 0 replies; 27+ messages in thread
From: Joel Stanley @ 2022-02-21 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Verdun, Jean-Marie, Krzysztof Kozlowski, Hawkins, Nick,
Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM, OpenBMC Maillist
On Tue, 1 Feb 2022 at 09:00, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
> >
> > - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough.
> > - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines)
>
> Is there any more specific name of the chip that can be used to identify the
> exact generation after a new one comes out? The normal way we handle
> compatible strings for devices is to start with a specific model number of
> the chip that integrates it, and then have later chips refer to the device by
> its new name, with the old one as a fallback. This makes drivers work out of
> the box when the device is unchanged, but gives you a way to distinguish them
> if a difference gets noticed after both revisions are already used.
>
> As with some of points that Krzysztof and others made previously, the goal
> here is to avoid binding incompatibilities in the future: anything that works
> in an upstream kernel should keep working in later versions, ideally
> allowing any combination of old and new dtb blobs in the bootloader
> with old or new kernel versions.
>
> > It does support many features including:
> > - ARMv7 architecture, and it is based on a Cortex A9 core
> > - Use an AXI bus to which
> > - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII
> > - Multiple I2C engines to drive connectivity with a host infrastructure
> > - A video engine which support VGA and DP, as well as an hardware video encder
> > - Multiple PCIe ports
> > - A PECI interface, and LPC eSPI
> > - Multiple UART for debug purpose, and Virtual UART for host connectivity
> > - A GPIO engine
>
> Thanks for the description. This seems quite normal then, similar to the
> aspeed and npcm BMC platforms that we support already. You can
> probably drop some of the people on the Cc list, but I would suggest you add
> the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel
> would be the best person to review the parts that are BMC specific.
I had a call with some of the HPE developers a while back. It's good
to hear from you again.
As Arnd said, please cc me on your submissions and I'll provide
review. You can also cc openbmc@lists.ozlabs.org to reach a wider
audience of BMC developers.
After our call the other month, I took a look at your latest kernel
tree and started teasing out something that could be submitted:
https://github.com/shenki/linux/commits/gxp
Hopefully this helps illustrate what we mean about breaking down the
patches into small logical chunks. Don't take what I've done there as
correct, but it's an indication. Feel free to re-use.
I encourage you to take a look at the aspeed device trees for
inspiration. The way they are organised into generations - 2400, 2500,
2600 - illistrate's Arnd's points about supporting multiple
generations of SoC with the one code base.
Cheers,
Joel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2022-02-21 8:41 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-25 19:46 [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel nick.hawkins
2022-01-25 19:46 ` nick.hawkins
2022-01-25 20:41 ` Krzysztof Kozlowski
2022-01-25 20:41 ` Krzysztof Kozlowski
2022-01-25 22:30 ` Andrew Lunn
2022-01-25 22:30 ` Andrew Lunn
2022-01-25 22:46 ` Andrew Lunn
2022-01-25 22:46 ` Andrew Lunn
2022-01-26 0:22 ` Arnd Bergmann
2022-01-26 0:22 ` Arnd Bergmann
2022-01-26 1:49 ` Verdun, Jean-Marie
2022-01-26 1:49 ` Verdun, Jean-Marie
2022-01-26 8:41 ` Krzysztof Kozlowski
2022-01-26 8:41 ` Krzysztof Kozlowski
2022-01-31 18:52 ` Verdun, Jean-Marie
2022-01-31 18:52 ` Verdun, Jean-Marie
2022-01-31 19:01 ` Sam Ravnborg
2022-02-01 7:37 ` Krzysztof Kozlowski
2022-02-01 7:37 ` Krzysztof Kozlowski
2022-02-01 8:59 ` Arnd Bergmann
2022-02-01 8:59 ` Arnd Bergmann
2022-02-01 8:59 ` Arnd Bergmann
2022-02-21 8:39 ` Joel Stanley
2022-02-21 8:39 ` Joel Stanley
2022-02-21 8:39 ` Joel Stanley
2022-01-26 8:25 ` Krzysztof Kozlowski
2022-01-26 8:25 ` Krzysztof Kozlowski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.