On Wed, Feb 16, 2022 at 7:36 PM <[email protected]> wrote:
>
> 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.
Please have a look at other patch series for the style of the submission.
All the information above doesn't really go in the individual patches, as it
is not meant as part of the permanent git history. Instead, keep the
series together as one thread the way that git-format-patch generates it,
and put information about the patch series into the cover letter.
One bit of information that I would like to see in the defconfig patch
is an explanation about why you need a custom defconfig in the
first place, rather than using multi_v7_defconfig. Please also add
a patch to enable your platform in the multi_v7_defconfig, along with
the drivers you need (as loadable modules).
See Documentation/process/submitting-patches.rst for more detail.
> 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.
More whitespace damage here, probably from a copy-paste mistake.
> 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
Try to trim the bits that you don't actually rely on, such as hostname
> +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
You probably don't need BLK_DEV_INITRD if you
use initramfs instead, and you should not need EMBEDDED either.
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLAB=y
> +CONFIG_ARCH_MULTI_V6=y
Since there is only one ARMv7 SoC enabled in here, there is no need for enabling
ARMv6. A v7-only kernel will run more efficiently and allow you to
build with more
features such as THUMB2.
> +CONFIG_ZBOOT_ROM_TEXT=0x0
> +CONFIG_ZBOOT_ROM_BSS=0x0
These are just the default
> +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
No need to mention all these, leaving them default-enabled is fine.
> +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
Maybe leave out the custom drivers for now, and only
enable the drivers that are already merged, or added as
part of the same series.
> +CONFIG_WATCHDOG=y
> +CONFIG_GXP_WATCHDOG=y
> +CONFIG_MFD_SYSCON=y
> +CONFIG_FB=y
> +CONFIG_FB_THUMBNAIL=y
> +CONFIG_FB_SIMPLE=y
I would keep CONFIG_FB disabled for new platforms.
> +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
Better leave out the debugging options here, and only list the ones
that you would
enable in a production device.
Arnd
Hi Arnd,
On 2/16/22, 1:58 PM, "Arnd Bergmann" <[email protected]> wrote:
> One bit of information that I would like to see in the defconfig patch
> is an explanation about why you need a custom defconfig in the
> first place, rather than using multi_v7_defconfig. Please also add
> a patch to enable your platform in the multi_v7_defconfig, along with
> the drivers you need (as loadable modules).
I took some time to look at the defconfig "challenge". Nick has updated the multi_v7_defconfig with our GXP in a new series of patches, but this won't execute on our ASIC (compilation is ok). The challenge is that we are missing a few features which are enabled by default, and I was wondering if the community would accept to disable them by default.
This is this
CONFIG_PERF_EVENTS=y
CONFIG_ARCH_VIRT=y
Both of them generate unknown instruction on our platform which lead to kernel crash.
With these options disabled, we can use the defconfig and add only
CONFIG_ARCH_HPE=y
CONFIG_ARCH_HPE_GXP=y
CONFIG_GXP_WATCHDOG=y
CONFIG_ATAGS=y
To it, as to get everything setup and get our new platform booting without any issues, assuming the associated code is present. The ATAGS is not mandatory it removed some warning messages during kernel boot.
I know this is removing some standard feature, but, I probably can't easily fix the missing instructions. I can dig a little bit if needed without any issue. If we want to have a working defconfig on HPE GXP platform, then we need to either take this modification, or change the code from perf_events and arch_virt to properly work if the required underlying hardware is unable to support these features (could be probably a dummy test to identify the asic at compilation time), or create a specific defconfig.
I am fully open to all options, just let me know the preferred one.
vejmarie
On Mon, Mar 14, 2022 at 11:47 PM Verdun, Jean-Marie <[email protected]> wrote:
> On 2/16/22, 1:58 PM, "Arnd Bergmann" <[email protected]> wrote:
>
>
> > One bit of information that I would like to see in the defconfig patch
> > is an explanation about why you need a custom defconfig in the
> > first place, rather than using multi_v7_defconfig. Please also add
> > a patch to enable your platform in the multi_v7_defconfig, along with
> > the drivers you need (as loadable modules).
>
> I took some time to look at the defconfig "challenge". Nick has updated the multi_v7_defconfig with our GXP in a new series of patches, but this won't execute on our ASIC (compilation is ok). The challenge is that we are missing a few features which are enabled by default, and I was wondering if the community would accept to disable them by default.
>
> This is this
>
> CONFIG_PERF_EVENTS=y
> CONFIG_ARCH_VIRT=y
>
> Both of them generate unknown instruction on our platform which lead to kernel crash.
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.
> With these options disabled, we can use the defconfig and add only
>
> CONFIG_ARCH_HPE=y
> CONFIG_ARCH_HPE_GXP=y
These are obviously ok
> CONFIG_GXP_WATCHDOG=y
> CONFIG_ATAGS=y
>
> To it, as to get everything setup and get our new platform booting
> without any issues, assuming the associated code is present. The
> ATAGS is not mandatory it removed some warning messages during
> kernel boot.
Ok, good. I assume you need the watchdog driver to be built-in because
the watchdog timer is active before we enter the kernel? In this case it
is ok, otherwise it should be =m, like any other drivers for your hardware.
I don't think we should enable CONFIG_ATAGS here, the multi_v7_defconfig
intentionally only supports DTB based booting. What is the warning you see
without it?
> I know this is removing some standard feature, but, I probably can't easily fix
> the missing instructions. I can dig a little bit if needed without any issue.
> If we want to have a working defconfig on HPE GXP platform, then we need
> to either take this modification, or change the code from perf_events and
> arch_virt to properly work if the required underlying hardware is unable to
> support these features (could be probably a dummy test to identify the asic
> at compilation time), or create a specific defconfig.
ARCH_VIRT doesn't do anything itself but only enables a couple of other drivers:
config ARCH_VIRT
bool "Dummy Virtual Machine"
depends on ARCH_MULTIPLATFORM
select ARM_AMBA
select ARM_GIC
select ARM_GIC_V2M if PCI
select ARM_GIC_V3
select ARM_GIC_V3_ITS if PCI
select ARM_PSCI
select HAVE_ARM_ARCH_TIMER
select ARCH_SUPPORTS_BIG_ENDIAN
Aside from the big-endian option, these all just enable the compilation
of drivers that in turn check the device tree before running any code.
Invalid instructions point to either PSCI or ARCH_TIMER, so try
disabling those first to narrow it down to one option causing the
problem, and make sure you actually run with the DTB that you
submitted, not a DTB that may contain incorrect nodes.
Arnd
Hi,
> 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.
vejmarie