Message-ID: <4CD3E272-3C69-441E-B4DE-7004701614EB@hpe.com>
Date:   Tue, 22 Mar 2022 22:41:48 +0000
From:   "Verdun, Jean-Marie" <verdun@....com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     "Hawkins, Nick" <nick.hawkins@....com>,
        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,

    > 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

Powered by blists - more mailing lists