[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9FE3F625-39FC-4ED7-A2CC-567EF0181886@hpe.com>
Date: Mon, 14 Mar 2022 22:47:57 +0000
From: "Verdun, Jean-Marie" <verdun@....com>
To: Arnd Bergmann <arnd@...db.de>,
"Hawkins, Nick" <nick.hawkins@....com>
CC: Russell King <linux@...linux.org.uk>,
Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...id.au>,
Olof Johansson <olof@...om.net>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [v1] arch: arm: configs: gxp_defconfig
Hi Arnd,
On 2/16/22, 1:58 PM, "Arnd Bergmann" <arnd@...db.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
Powered by blists - more mailing lists