From: Nick Hawkins <[email protected]>
Description: Adding the configuration file for the upcoming
hpe gxp soc.
Note: This patch is part of a set with patches:
[v4] arch: arm: boot: dts: Create HPE GXP Device Tree
[v1] dt-bindings: timer: Add HPE GXP Timer binding
[v1] dt-bindings: watchdog: Add HPE GXP Watchdog timer binding
[v1]dt-bindings: vendor-prefixes: add HPE Prefix
[v1] dt-bindings: soc: Add HPE GXP SOC binding
Additional Note: Maintainers will be updated in separate patch
to cover all of the above patches.
Information: GXP is the name of the HPE SoC.
This SoC is used to implement BMC features of HPE servers
(all ProLiant, Synergy, and 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 encoder
Multiple PCIe ports
A PECI interface, and LPC eSPI
Multiple UART for debug purpose, and Virtual UART for
host connectivity
A GPIO engine.
Signed-off-by: Nick Hawkins <[email protected]>
---
arch/arm/configs/gxp_defconfig | 243 +++++++++++++++++++++++++++++++++
1 file changed, 243 insertions(+)
create mode 100644 arch/arm/configs/gxp_defconfig
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
--
2.17.1
On Wed, Mar 16, 2022 at 7:54 PM Verdun, Jean-Marie <[email protected]> wrote:
> > If you get unknown instruction exceptions, that is clearly a bug that has to be
> > fixed somewhere. Turning the options off should not be necessary, but we have
> > to figure out why these crash, and make sure we have correct runtime detection
> > in place that ensures that any driver code runs only on platforms that have the
> > corresponding hardware.
>
> > Do you have any more information about how and why these crash? My first
> > guess would be that there is something in your DT that describes hardware
> > that is not actually there. With a correct DTB file, the two options should
> > not cause any code to run that wouldn't otherwise.
>
> I think I found part of the issue regarding the PERF_EVENTS. In ./arch/arm/kernel/hw_breakpoint.c, the function core_has_os_save_restore is calling the mrc p14 instruction to determine ARM_OSLSR_OSLM0 value. Unfortunately per the ARM Cortex A9 documentation that call is not implemented on such core
> ( https://developer.arm.com/documentation/ddi0388/i/debug/debug-register-summary )
>
> which is leading to an unknown instruction on our ASIC.
>
> Need to figuring out how to workaround that. I will check what ARM_DEBUG_ARCH_V7_ECP14 is supposed to support. We might have either a bug into the way we report the ASIC id or something is weird into the kernel which is assuming that Cortex A9 support this PMU access.
I'm not familiar with the hw_breakpoint.c code, but I can see that the
get_debug_arch()
and core_has_os_save_restore() functions are at least eight years old,
and Cortex-A9
is one of the most common CPU cores, so it would be unlikely that this
is a problem
with the CPU core in general. My best guess would be that your boot
loader code is
missing a bit of initialization that is required to put this into the
correct state.
Arnd
Hi Arnd,
> I'm not familiar with the hw_breakpoint.c code, but I can see that the
> get_debug_arch()
> and core_has_os_save_restore() functions are at least eight years old,
> and Cortex-A9
> is one of the most common CPU cores, so it would be unlikely that this
> is a problem
> with the CPU core in general. My best guess would be that your boot
> loader code is
> missing a bit of initialization that is required to put this into the
> correct state.
I kept digging, and there is an ARM errata https://developer.arm.com/documentation/uan0009/d/ (764319) which is heading into the direction of the issue we face. The challenge is that the DBGSWENABLE signal is not accessible through software (I am still digging to confirm that), it has to be switched from the external debugger. What is weird is that many vendors are referring this errata, they shall be facing the same kind of challenges in some way.
vejmarie
Hi,
> I'm not familiar with the hw_breakpoint.c code, but I can see that the
> get_debug_arch()
> and core_has_os_save_restore() functions are at least eight years old,
> and Cortex-A9
> is one of the most common CPU cores, so it would be unlikely that this
> is a problem
> with the CPU core in general. My best guess would be that your boot
> loader code is
> missing a bit of initialization that is required to put this into the
> correct state.
I spent additional time to analyze the issue. We are clearly affected by the errata 764319 mentioned here. (checked with our silicon team and validated with JTAG debugger access) https://developer.arm.com/documentation/uan0009/latest/ and can't change the hardware as it is a production silicon. With that said, I also checked a few things on our PMU, and the main reason why we didn't put it into the initial DTSI is because we are "disabling" it, and its interrupt is not connected to our VIC subsystem. So even if we find a workaround to ARM errata (we asked them the question), the PMU will still not be functional and having it preloaded and initialized is probably not what we intent to.
GXP Asic is a SoC designed for Baseboard Management Controller purpose. It is in some way a dedicated SoC not designed for general purpose computing. We implemented it with security in mind, and have debug systems (which are not shipped outside HPE), and production systems (without PMU active) which are what you can find in many of our servers. Our intent is to offer full linux support on this SoC family as to bring OpenBMC benefit and more software choices to our end users.
With that said, we clearly do not want to overload the linux kernel with specific code and will always promote flexible abstraction usage, as well avoid unnecessary configuration files.
We initially created a dedicated gxp_defconfig as we took inspiration from aspeed implementation, but I think using the generic armv7 is way nicer and better. It will also provide better benefit to the kernel team by identifying the various bottlenecks that SoC vendors like we are, are facing when enabling linux kernel support.
The PERF_EVENTS entry from the multi_v7_defconfig is the only issue that we face to use that default configuration file. I made some tests, and if this defconfig file is configuring PERF_EVENTS as a module, it will allow us to compile from it a perfectly working kernel. I don't think this would impact any other implementation which will have to load the module instead of assuming it is integrated. From a kernel feature perspective I do not find any good reason why perf events shall be activated by default, and I'll be interested to understand why it is from a pure intellectual reason.
Would you accept a patch which is switching PERF_EVENTS=y to PERF_EVENTS=m into multi_v7_defconfig ? Then we could add our GXP definition into it like other chips are. This could also help other chip vendors affected by the same bug. I am pretty sure we are not the only one. Reducing defconfig file and relying on general purpose one per architecture revision make totally sense to me.
vejmarie
Hi,
> Unfortunately that is not possible at the moment, as this is a 'bool'
> option rather than
> a 'tristate'. I don't know if it might be possible to change that, but
> this is probably
> done for a good reason.
You are right.
> I think it should be possible to detect this erratum at runtime, especially now
> that we understand what the hardware issue is.
> We should probably add a CONFIG_ARM_ERRATA_764319 Kconfig
> option that controls whether a workaround is enabled or not. One
> way that I think this can be handled is to have a custom inline asm
> for the trapping register CP14 accesses, using a __ex_table fixup,
> similar to what we do for trapping user space memory access.
I like this idea. Let me try to implement it and propose something.
Thanks for the feedbacks.
> Another option would be to detect affected systems by the CPU
> revision register or from some DT properties.
ARM might be able to provide that. Let me ask them
vejmarie
On Tue, Mar 22, 2022 at 11:41 PM Verdun, Jean-Marie <[email protected]> wrote:
> I spent additional time to analyze the issue
Thank you for putting the work into the analysis!
> Would you accept a patch which is switching PERF_EVENTS=y to
> PERF_EVENTS=m into multi_v7_defconfig ?
Unfortunately that is not possible at the moment, as this is a 'bool'
option rather than
a 'tristate'. I don't know if it might be possible to change that, but
this is probably
done for a good reason.
> Then we could add our GXP definition into it like other chips are. This could also
> help other chip vendors affected by the same bug. I am pretty sure we are not the
> only one. Reducing defconfig file and relying on general purpose one per architecture
> revision make totally sense to me.
I think it should be possible to detect this erratum at runtime, especially now
that we understand what the hardware issue is.
We should probably add a CONFIG_ARM_ERRATA_764319 Kconfig
option that controls whether a workaround is enabled or not. One
way that I think this can be handled is to have a custom inline asm
for the trapping register CP14 accesses, using a __ex_table fixup,
similar to what we do for trapping user space memory access.
Another option would be to detect affected systems by the CPU
revision register or from some DT properties.
Arnd