| Message ID | 20220216183704.42084-1-nick.hawkins@hpe.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] arch: arm: configs: gxp_defconfig | expand |
On Wed, Feb 16, 2022 at 7:36 PM <nick.hawkins@hpe.com> wrote: > > From: Nick Hawkins <nick.hawkins@hpe.com> > > 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 <nick.hawkins@hpe.com> > --- > 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" <arnd@arndb.de> 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 <verdun@hpe.com> wrote: > On 2/16/22, 1:58 PM, "Arnd Bergmann" <arnd@arndb.de> 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
On Wed, Mar 16, 2022 at 7:54 PM Verdun, Jean-Marie <verdun@hpe.com> 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
On Tue, Mar 22, 2022 at 11:41 PM Verdun, Jean-Marie <verdun@hpe.com> 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
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
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