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
next prev parent 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®