From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756017AbdJJKPs (ORCPT ); Tue, 10 Oct 2017 06:15:48 -0400 Received: from foss.arm.com ([217.140.101.70]:41768 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751435AbdJJKPq (ORCPT ); Tue, 10 Oct 2017 06:15:46 -0400 Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Sudeep Holla , "Paul E. McKenney" , Kevin Brodsky , Thierry Reding , Nishanth Menon , Jean Delvare , Lorenzo Pieralisi Subject: Re: [PATCH] firmware: bluefield: add boot control driver To: Chris Metcalf , Mark Rutland , Grant Likely References: <1507569397-25656-1-git-send-email-cmetcalf@mellanox.com> From: Sudeep Holla Organization: ARM Message-ID: <3dd93269-04b9-e7a6-245f-3886440cfa4c@arm.com> Date: Tue, 10 Oct 2017 11:15:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1507569397-25656-1-git-send-email-cmetcalf@mellanox.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (+Mark, Grant) On 09/10/17 18:16, Chris Metcalf wrote: > The Mellanox BlueField SoC firmware supports a safe upgrade mode as > part of the flow where users put new firmware on the secondary eMMC > boot partition (the one not currently in use), tell the eMMC to make > the secondary boot partition primary, and reset. This driver is > used to request that the firmware start the ARM watchdog after the > next reset, and also request that the firmware swap the eMMC boot > partition back again on the reset after that (the second reset). > This means that if anything goes wrong, the watchdog will fire, the > system will reset, and the firmware will switch back to the original > boot partition. If the boot is successful, the user will use this > driver to put the firmware back into the state where it doesn't touch > the eMMC boot partition at reset, and turn off the ARM watchdog. > > The firmware allows for more configurability than that, as can > be seen in the code, but the use case above is what the driver > primarily supports. > > It is structured as a simple sysfs driver that is loaded based on > an ACPI table entry, and allows reading/writing text strings to > various /sys/bus/platform/drivers/mlx-bootctl/* files. > > Signed-off-by: Chris Metcalf > --- > Ingo, since there isn't an overall maintainer for drivers/firmware, > does it make sense for this to go through your tree? Thanks! > > drivers/firmware/Kconfig | 12 +++ > drivers/firmware/Makefile | 1 + > drivers/firmware/mlx-bootctl.c | 222 +++++++++++++++++++++++++++++++++++++++++ > drivers/firmware/mlx-bootctl.h | 103 +++++++++++++++++++ > 4 files changed, 338 insertions(+) > create mode 100644 drivers/firmware/mlx-bootctl.c > create mode 100644 drivers/firmware/mlx-bootctl.h > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > index 6e4ed5a9c6fd..1f2adbcc5acc 100644 > --- a/drivers/firmware/Kconfig > +++ b/drivers/firmware/Kconfig > @@ -230,6 +230,18 @@ config TI_SCI_PROTOCOL > This protocol library is used by client drivers to use the features > provided by the system controller. > > +config MLX_BOOTCTL > + tristate "Mellanox BlueField Firmware Boot Control" > + depends on ARM64 > + help > + The Mellanox BlueField firmware implements functionality to > + request swapping the primary and alternate eMMC boot > + partition, and to set up a watchdog that can undo that swap > + if the system does not boot up correctly. This driver > + provides sysfs access to the firmware, to be used in > + conjunction with the eMMC device driver to do any necessary > + initial swap of the boot partition. > + For me, this looks like any other distro upgrade use-case which requires to set some variable that must persist across reset (i.e. in non volatile memory) ARM is proposing Embedded Base Boot Requirements (EBBR)[1] and it covers this IIUC. I am not sure if we need to achieve that using SMCCC as proposed in the patch. I may be wrong, but just wanted to check. -- [1] https://developer.arm.com/products/architecture/system-architecture/embedded-system-architecture -- Regards, Sudeep