mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Chris Metcalf <cmetcalf@mellanox.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Grant Likely <Grant.Likely@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Thierry Reding <treding@nvidia.com>, Nishanth Menon <nm@ti.com>,
	Jean Delvare <jdelvare@suse.de>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Subject: Re: [PATCH] firmware: bluefield: add boot control driver
Date: Tue, 10 Oct 2017 11:15:39 +0100	[thread overview]
Message-ID: <3dd93269-04b9-e7a6-245f-3886440cfa4c@arm.com> (raw)
In-Reply-To: <1507569397-25656-1-git-send-email-cmetcalf@mellanox.com>

(+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 <cmetcalf@mellanox.com>
> ---
> 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

  reply	other threads:[~2017-10-10 10:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-09 17:16 Chris Metcalf
2017-10-10 10:15 ` Sudeep Holla [this message]
2017-10-10 10:23   ` Mark Rutland
2017-10-10 11:30     ` Ard Biesheuvel
2017-10-10 11:58     ` Leif Lindholm
2017-10-10 12:23       ` Grant Likely
2017-10-11 23:49 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3dd93269-04b9-e7a6-245f-3886440cfa4c@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=Grant.Likely@arm.com \
    --cc=cmetcalf@mellanox.com \
    --cc=jdelvare@suse.de \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=nm@ti.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®