2023-03-31 07:22:05

by Conor Dooley

[permalink] [raw]

Subject: [PATCH v2 0/7] PolarFire SoC Auto Update Support

---

Hey all,

This patchset adds support for the "Auto Update" feature on PolarFire
SoC that allows for writing an FPGA bistream to the SPI flash connected
to the system controller.
On powercycle (or reboot depending on how the firmware implements the
openSBI SRST extension) "Auto Update" will take place, and program the
FPGA with the contents of the SPI flash - provided that that image is
valid and an actual upgrade from that already programmed!

Unfortunately, this series is not really testable yet - the Engineering
Sample silicon on most dev boards has a bug in the QSPI controller
connected to the system controller's flash and cannot access it.
Pre-production and later silicon has this bug fixed.

I previously posted an RFC about my approach in this driver, since as a
flash-based FPGA we are somewhat different to the existing
self-reprogramming drivers here. That RFC is here:
https://lore.kernel.org/linux-fpga/[email protected]/

This series depends on the following fixes:
https://lore.kernel.org/all/d7c3ec51-8493-444a-bdec-2a30b0a15bdc@spud/

The patch adding the driver depends on the soc patches earlier in the
series, so taking both through the same tree makes sense. Depending on
sequencing with the dependencies, me taking it through the soc tree
(with Acks etc of course) may make the most sense.

Cheers,
Conor.

Changes in v2:
- per Russ' suggestion, the driver has been switched to using the
firmware-upload API rather than the fpga one
- as a result of that change, the structure of the driver has changed
significantly, although most of that is reshuffling existing code
around
- check if the upgrade is possible in probe and fail if it isn't
- only write the image index if it is not already set
- delete the now unneeded debugfs bits

CC: Conor Dooley <[email protected]>
CC: Daire McNamara <[email protected]>
CC: Rob Herring <[email protected]>
CC: Krzysztof Kozlowski <[email protected]>
CC: Moritz Fischer <[email protected]>
CC: Wu Hao <[email protected]>
CC: Xu Yilun <[email protected]>
CC: Tom Rix <[email protected]>
CC; Russ Weight <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: [email protected]

Conor Dooley (7):
soc: microchip: mpfs: add a prefix to rx_callback()
dt-bindings: soc: microchip: add a property for system controller
flash
soc: microchip: mpfs: enable access to the system controller's flash
soc: microchip: mpfs: print service status in warning message
soc: microchip: mpfs: add auto-update subdev to system controller
fpga: add PolarFire SoC Auto Update support
riscv: dts: microchip: add the mpfs' system controller qspi &
associated flash

.../microchip,mpfs-sys-controller.yaml | 10 +
.../boot/dts/microchip/mpfs-icicle-kit.dts | 21 +
arch/riscv/boot/dts/microchip/mpfs.dtsi | 24 +-
drivers/fpga/Kconfig | 11 +
drivers/fpga/Makefile | 3 +-
drivers/fpga/microchip-auto-update.c | 494 ++++++++++++++++++
drivers/soc/microchip/Kconfig | 1 +
drivers/soc/microchip/mpfs-sys-controller.c | 37 +-
include/soc/microchip/mpfs.h | 2 +
9 files changed, 591 insertions(+), 12 deletions(-)
create mode 100644 drivers/fpga/microchip-auto-update.c

--
2.39.2

2023-03-31 07:22:15

by Conor Dooley

[permalink] [raw]

Subject: [PATCH v2 6/7] fpga: add PolarFire SoC Auto Update support

---

Add support for Auto Update reprogramming of the FPGA fabric on
PolarFire SoC, using the fw_upload mechanism a la the
intel-m10-bmc-sec-update driver.

This driver only writes the image to the spi flash & performs
validation on it, as the entire FPGA becomes unusable during the actual
reprogramming of a bitstream. To initiate the reprogramming itself, a
device reset is required.
The SBI SRST extension's "cold reboot" can trigger such a device reset,
by means of a "Tamper Macro" in the FPGA fabric, provided corresponding
support has been enabled in the HSS (Hart Software Services).

Signed-off-by: Conor Dooley <[email protected]>
---
drivers/fpga/Kconfig | 11 +
drivers/fpga/Makefile | 3 +-
drivers/fpga/microchip-auto-update.c | 494 +++++++++++++++++++++++++++
3 files changed, 507 insertions(+), 1 deletion(-)
create mode 100644 drivers/fpga/microchip-auto-update.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 0a00763b9f28..2838ce7ddafe 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -257,6 +257,17 @@ config FPGA_M10_BMC_SEC_UPDATE
(BMC) and provides support for secure updates for the BMC image,
the FPGA image, the Root Entry Hashes, etc.

+config FPGA_MICROCHIP_AUTO_UPDATE
+ tristate "Microchip PolarFire SoC AUTO UPDATE"
+ depends on POLARFIRE_SOC_SYS_CTRL
+ select FW_LOADER
+ select FW_UPLOAD
+ help
+ FPGA manager driver support for reprogramming PolarFire SoC from
+ within Linux, using the Auto Upgrade feature of the system controller.
+
+ If built as a module, it will be called microchip-auto-update.
+
config FPGA_MGR_MICROCHIP_SPI
tristate "Microchip Polarfire SPI FPGA manager"
depends on SPI
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 72e554b4d2f7..0b1ba6db860d 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -25,8 +25,9 @@ obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI) += lattice-sysconfig-spi.o
obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o

-# FPGA Secure Update Drivers
+# FPGA Firmware Upload Drivers
obj-$(CONFIG_FPGA_M10_BMC_SEC_UPDATE) += intel-m10-bmc-sec-update.o
+obj-$(CONFIG_FPGA_MICROCHIP_AUTO_UPDATE) += microchip-auto-update.o

# FPGA Bridge Drivers
obj-$(CONFIG_FPGA_BRIDGE) += fpga-bridge.o
diff --git a/drivers/fpga/microchip-auto-update.c b/drivers/fpga/microchip-auto-update.c
new file mode 100644
index 000000000000..5fa920b659c6
--- /dev/null
+++ b/drivers/fpga/microchip-auto-update.c
@@ -0,0 +1,494 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip Polarfire SoC "Auto Update" FPGA reprogramming.
+ *
+ * Documentation of this functionality is available in the "PolarFire® FPGA and
+ * PolarFire SoC FPGA Programming" User Guide.
+ *
+ * Copyright (c) 2022-2023 Microchip Corporation. All rights reserved.
+ *
+ * Author: Conor Dooley <[email protected]>
+ */
+#include <linux/debugfs.h>
+#include <linux/firmware.h>
+#include <linux/math.h>
+#include <linux/module.h>
+#include <linux/mtd/mtd.h>
+#include <linux/of_device.h>
+#include <linux/sizes.h>
+
+#include <soc/microchip/mpfs.h>
+
+#define AUTO_UPDATE_DEFAULT_MBOX_OFFSET 0u
+#define AUTO_UPDATE_DEFAULT_RESP_OFFSET 0u
+
+#define AUTO_UPDATE_FEATURE_CMD_OPCODE 0x05u
+#define AUTO_UPDATE_FEATURE_CMD_DATA_SIZE 0u
+#define AUTO_UPDATE_FEATURE_RESP_SIZE 33u
+#define AUTO_UPDATE_FEATURE_CMD_DATA NULL
+#define AUTO_UPDATE_FEATURE_ENABLED BIT(5)
+
+#define AUTO_UPDATE_AUTHENTICATE_CMD_OPCODE 0x22u
+#define AUTO_UPDATE_AUTHENTICATE_CMD_DATA_SIZE 0u
+#define AUTO_UPDATE_AUTHENTICATE_RESP_SIZE 1u
+#define AUTO_UPDATE_AUTHENTICATE_CMD_DATA NULL
+
+#define AUTO_UPDATE_PROGRAM_CMD_OPCODE 0x46u
+#define AUTO_UPDATE_PROGRAM_CMD_DATA_SIZE 0u
+#define AUTO_UPDATE_PROGRAM_RESP_SIZE 1u
+#define AUTO_UPDATE_PROGRAM_CMD_DATA NULL
+
+/*
+ * SPI Flash layout example:
+ * |------------------------------| 0x0000000
+ * | 1 KiB |
+ * | SPI "directories" |
+ * |------------------------------| 0x0000400
+ * | 1 MiB |
+ * | Reserved area |
+ * | Used for bitstream info |
+ * |------------------------------| 0x0100400
+ * | 20 MiB |
+ * | Golden Image |
+ * |------------------------------| 0x1500400
+ * | 20 MiB |
+ * | Auto Upgrade Image |
+ * |------------------------------| 0x2900400
+ * | 20 MiB |
+ * | Reserved for multi-image IAP |
+ * | Unused for Auto Upgrade |
+ * |------------------------------| 0x3D00400
+ * | ? B |
+ * | Unused |
+ * |------------------------------| 0x?
+ */
+#define AUTO_UPDATE_DIRECTORY_BASE 0u
+#define AUTO_UPDATE_DIRECTORY_WIDTH 4u
+#define AUTO_UPDATE_GOLDEN_INDEX 0u
+#define AUTO_UPDATE_UPGRADE_INDEX 1u
+#define AUTO_UPDATE_BLANK_INDEX 2u
+#define AUTO_UPDATE_GOLDEN_DIRECTORY (AUTO_UPDATE_DIRECTORY_WIDTH * AUTO_UPDATE_GOLDEN_INDEX)
+#define AUTO_UPDATE_UPGRADE_DIRECTORY (AUTO_UPDATE_DIRECTORY_WIDTH * AUTO_UPDATE_UPGRADE_INDEX)
+#define AUTO_UPDATE_BLANK_DIRECTORY (AUTO_UPDATE_DIRECTORY_WIDTH * AUTO_UPDATE_BLANK_INDEX)
+#define AUTO_UPDATE_DIRECTORY_SIZE SZ_1K
+#define AUTO_UPDATE_RESERVED_SIZE SZ_1M
+#define AUTO_UPDATE_BITSTREAM_BASE (AUTO_UPDATE_DIRECTORY_SIZE + AUTO_UPDATE_RESERVED_SIZE)
+
+#define AUTO_UPDATE_TIMEOUT_MS 60000
+
+struct mpfs_auto_update_priv {
+ struct mpfs_sys_controller *sys_controller;
+ struct device *dev;
+ struct mtd_info *flash;
+ struct fw_upload *fw_uploader;
+ struct completion programming_complete;
+ size_t size_per_bitstream;
+ bool cancel_request;
+};
+
+static enum fw_upload_err mpfs_auto_update_prepare(struct fw_upload *fw_uploader, const u8 *data,
+ u32 size)
+{
+ struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
+ size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
+
+ /*
+ * Verifying the Golden Image is idealistic. It will be evaluated
+ * against the currently programmed image and thus may fail - due to
+ * either rollback protection (if its an older version than that in use)
+ * or if the version is the same as that of the in-use image.
+ * Extracting the information as to why a failure occurred is not
+ * currently possible due to limitations of the system controller
+ * driver. If those are fixed, verification of the Golden Image should
+ * be added here.
+ */
+
+ priv->flash = mpfs_sys_controller_get_flash(priv->sys_controller);
+ if (!priv->flash)
+ return FW_UPLOAD_ERR_HW_ERROR;
+
+ erase_size = round_up(erase_size, (u64)priv->flash->erasesize);
+
+ /*
+ * We need to calculate if we have enough space in the flash for the
+ * new image.
+ * First, chop off the first 1 KiB as it's reserved for the directory.
+ * The 1 MiB reserved for design info needs to be ignored also.
+ * All that remains is carved into 3 & rounded down to the erasesize.
+ * If this is smaller than the image size, we abort.
+ * There's also no need to consume more than 20 MiB per image.
+ */
+ priv->size_per_bitstream = priv->flash->size - SZ_1K - SZ_1M;
+ priv->size_per_bitstream = round_down(priv->size_per_bitstream / 3, erase_size);
+ if (priv->size_per_bitstream > 20 * SZ_1M)
+ priv->size_per_bitstream = 20 * SZ_1M;
+
+ if (priv->size_per_bitstream < size) {
+ dev_err(priv->dev,
+ "flash device has insufficient capacity to store this bitstream\n");
+ return FW_UPLOAD_ERR_INVALID_SIZE;
+ }
+
+ priv->cancel_request = false;
+
+ return FW_UPLOAD_ERR_NONE;
+}
+
+static void mpfs_auto_update_cancel(struct fw_upload *fw_uploader)
+{
+ struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
+
+ priv->cancel_request = true;
+}
+
+static enum fw_upload_err mpfs_auto_update_poll_complete(struct fw_upload *fw_uploader)
+{
+ struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
+ int ret;
+
+ /*
+ * There is no meaningful way to get the status of the programming while
+ * it is in progress, so attempting anything other than waiting for it
+ * to complete would be misplaced.
+ */
+ ret = wait_for_completion_timeout(&priv->programming_complete,
+ msecs_to_jiffies(AUTO_UPDATE_TIMEOUT_MS));
+ if (ret)
+ return FW_UPLOAD_ERR_TIMEOUT;
+
+ return FW_UPLOAD_ERR_NONE;
+}
+
+static int mpfs_auto_update_verify_image(struct fw_upload *fw_uploader)
+{
+ struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
+ struct mpfs_mss_response *response;
+ struct mpfs_mss_msg *message;
+ u32 *response_msg;
+ int ret;
+
+ response_msg = devm_kzalloc(priv->dev, AUTO_UPDATE_FEATURE_RESP_SIZE * sizeof(response_msg),
+ GFP_KERNEL);
+ if (!response_msg)
+ return -ENOMEM;
+
+ response = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_response), GFP_KERNEL);
+ if (!response) {
+ ret = -ENOMEM;
+ goto free_response_msg;
+ }
+
+ message = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_msg), GFP_KERNEL);
+ if (!message) {
+ ret = -ENOMEM;
+ goto free_response;
+ }
+
+ /*
+ * The system controller can verify that an image in the flash is valid.
+ * Rather than duplicate the check in this driver, call the relevant
+ * service from the system controller instead.
+ * This service has no command data and no response data. It overloads
+ * mbox_offset with the image index in the flash's SPI directory where
+ * the bitstream is located.
+ */
+ response->resp_msg = response_msg;
+ response->resp_size = AUTO_UPDATE_AUTHENTICATE_RESP_SIZE;
+ message->cmd_opcode = AUTO_UPDATE_AUTHENTICATE_CMD_OPCODE;
+ message->cmd_data_size = AUTO_UPDATE_AUTHENTICATE_CMD_DATA_SIZE;
+ message->response = response;
+ message->cmd_data = AUTO_UPDATE_AUTHENTICATE_CMD_DATA;
+ message->mbox_offset = AUTO_UPDATE_UPGRADE_INDEX;
+ message->resp_offset = AUTO_UPDATE_DEFAULT_RESP_OFFSET;
+
+ dev_info(priv->dev, "Running verification of Upgrade Image\n");
+ ret = mpfs_blocking_transaction(priv->sys_controller, message);
+ if (ret | response->resp_status) {
+ dev_warn(priv->dev, "Verification of Upgrade Image failed!\n");
+ ret = ret ? ret : -EBADMSG;
+ }
+
+ dev_info(priv->dev, "Verification of Upgrade Image passed!\n");
+
+ devm_kfree(priv->dev, message);
+free_response:
+ devm_kfree(priv->dev, response);
+free_response_msg:
+ devm_kfree(priv->dev, response_msg);
+
+ return ret;
+}
+
+static int mpfs_auto_update_set_image_address(struct mpfs_auto_update_priv *priv, char *buffer,
+ u32 image_address, loff_t directory_address)
+{
+ struct erase_info erase;
+ size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
+ size_t bytes_written = 0, bytes_read = 0;
+ int ret;
+
+ erase_size = round_up(erase_size, (u64)priv->flash->erasesize);
+
+ erase.addr = AUTO_UPDATE_DIRECTORY_BASE;
+ erase.len = erase_size;
+
+ /*
+ * We need to write the "SPI DIRECTORY" to the first 1 KiB, telling
+ * the system controller where to find the actual bitstream. Since
+ * this is spi-nor, we have to read the first eraseblock, erase that
+ * portion of the flash, modify the data and then write it back.
+ * There's no need to do this though if things are already the way they
+ * should be, so check and save the write in that case.
+ */
+ ret = mtd_read(priv->flash, AUTO_UPDATE_DIRECTORY_BASE, erase_size, &bytes_read,
+ (u_char *)buffer);
+ if (ret)
+ return ret;
+
+ if (bytes_read != erase_size)
+ return -EIO;
+
+ if ((*(u32 *)(buffer + AUTO_UPDATE_UPGRADE_DIRECTORY) == image_address) &&
+ !(*(u32 *)(buffer + AUTO_UPDATE_BLANK_DIRECTORY)))
+ return 0;
+
+ ret = mtd_erase(priv->flash, &erase);
+ if (ret)
+ return ret;
+
+ /*
+ * Populate the image address and then zero out the next directory so
+ * that the system controller doesn't complain if in "Single Image"
+ * mode.
+ */
+ memcpy(buffer + AUTO_UPDATE_UPGRADE_DIRECTORY, &image_address,
+ AUTO_UPDATE_DIRECTORY_WIDTH);
+ memset(buffer + AUTO_UPDATE_BLANK_DIRECTORY, 0x0, AUTO_UPDATE_DIRECTORY_WIDTH);
+
+ dev_info(priv->dev, "Writing the image address (%x) to the flash directory (%llx)\n",
+ image_address, directory_address);
+
+ ret = mtd_write(priv->flash, 0x0, erase_size, &bytes_written, (u_char *)buffer);
+ if (ret)
+ return ret;
+
+ if (bytes_written != erase_size)
+ return ret;
+
+ return 0;
+}
+
+static int mpfs_auto_update_write_bitstream(struct fw_upload *fw_uploader, const u8 *data,
+ u32 offset, u32 size, u32 *written)
+{
+ struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
+ struct erase_info erase;
+ char *buffer;
+ loff_t directory_address = AUTO_UPDATE_UPGRADE_DIRECTORY;
+ size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
+ size_t bytes_written = 0;
+ u32 image_address;
+ int ret;
+
+ erase_size = round_up(erase_size, (u64)priv->flash->erasesize);
+
+ image_address = AUTO_UPDATE_BITSTREAM_BASE +
+ AUTO_UPDATE_UPGRADE_INDEX * priv->size_per_bitstream;
+
+ buffer = devm_kzalloc(priv->dev, erase_size, GFP_KERNEL);
+ if (!buffer)
+ return -ENOMEM;
+
+ ret = mpfs_auto_update_set_image_address(priv, buffer, image_address, directory_address);
+ if (ret) {
+ dev_err(priv->dev, "failed to set image address in the SPI directory: %d\n", ret);
+ goto out;
+ }
+
+ /*
+ * Now the .spi image itself can be written to the flash. Preservation
+ * of contents here is not important here, unlike the spi "directory"
+ * which must be RMWed.
+ */
+ erase.len = round_up(size, (size_t)priv->flash->erasesize);
+ erase.addr = image_address;
+
+ dev_info(priv->dev, "Erasing the flash at address (%x)\n", image_address);
+ ret = mtd_erase(priv->flash, &erase);
+ if (ret)
+ goto out;
+
+ /*
+ * No parsing etc of the bitstream is required. The system controller
+ * will do all of that itself - including verifying that the bitstream
+ * is valid.
+ */
+ dev_info(priv->dev, "Writing the image to the flash at address (%x)\n", image_address);
+ ret = mtd_write(priv->flash, (loff_t)image_address, size, &bytes_written, data);
+ if (ret)
+ goto out;
+
+ if (bytes_written != size) {
+ ret = -EIO;
+ goto out;
+ }
+
+ *written = bytes_written;
+
+out:
+ devm_kfree(priv->dev, buffer);
+ return ret;
+}
+
+static enum fw_upload_err mpfs_auto_update_write(struct fw_upload *fw_uploader, const u8 *data,
+ u32 offset, u32 size, u32 *written)
+{
+ struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
+ enum fw_upload_err err = FW_UPLOAD_ERR_NONE;
+ int ret;
+
+ reinit_completion(&priv->programming_complete);
+
+ ret = mpfs_auto_update_write_bitstream(fw_uploader, data, offset, size, written);
+ if (ret) {
+ err = FW_UPLOAD_ERR_RW_ERROR;
+ goto out;
+ }
+
+ if (priv->cancel_request) {
+ err = FW_UPLOAD_ERR_CANCELED;
+ goto out;
+ }
+
+ ret = mpfs_auto_update_verify_image(fw_uploader);
+ if (ret)
+ err = FW_UPLOAD_ERR_HW_ERROR;
+
+out:
+ complete(&priv->programming_complete);
+
+ return err;
+}
+
+static const struct fw_upload_ops mpfs_auto_update_ops = {
+ .prepare = mpfs_auto_update_prepare,
+ .write = mpfs_auto_update_write,
+ .poll_complete = mpfs_auto_update_poll_complete,
+ .cancel = mpfs_auto_update_cancel,
+};
+
+static int mpfs_auto_update_available(struct mpfs_auto_update_priv *priv)
+{
+ struct mpfs_mss_response *response;
+ struct mpfs_mss_msg *message;
+ u32 *response_msg;
+ int ret;
+
+ response_msg = devm_kzalloc(priv->dev, AUTO_UPDATE_FEATURE_RESP_SIZE * sizeof(response_msg),
+ GFP_KERNEL);
+ if (!response_msg)
+ return -ENOMEM;
+
+ response = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_response), GFP_KERNEL);
+ if (!response)
+ return -ENOMEM;
+
+ message = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_msg), GFP_KERNEL);
+ if (!message)
+ return -ENOMEM;
+
+ /*
+ * To verify that Auto Update is possible, the "Query Security Service
+ * Request" is performed.
+ * This service has no command data & does not overload mbox_offset.
+ */
+ response->resp_msg = response_msg;
+ response->resp_size = AUTO_UPDATE_FEATURE_RESP_SIZE;
+ message->cmd_opcode = AUTO_UPDATE_FEATURE_CMD_OPCODE;
+ message->cmd_data_size = AUTO_UPDATE_FEATURE_CMD_DATA_SIZE;
+ message->response = response;
+ message->cmd_data = AUTO_UPDATE_FEATURE_CMD_DATA;
+ message->mbox_offset = AUTO_UPDATE_DEFAULT_MBOX_OFFSET;
+ message->resp_offset = AUTO_UPDATE_DEFAULT_RESP_OFFSET;
+
+ ret = mpfs_blocking_transaction(priv->sys_controller, message);
+ if (ret)
+ return ret;
+
+ /*
+ * Currently, the system controller's firmware does not generate any
+ * interrupts for failed services, so mpfs_blocking_transaction() should
+ * time out & therefore return an error.
+ * Hitting this check is highly unlikely at present, but if the system
+ * controller's behaviour changes so that it does generate interrupts
+ * for failed services, it will be required.
+ */
+ if (response->resp_status)
+ return -EIO;
+
+ /*
+ * Bit 5 of byte 1 is "UL_Auto Update" & if it is set, Auto Update is
+ * not possible.
+ */
+ if (response_msg[1] & AUTO_UPDATE_FEATURE_ENABLED)
+ return -EPERM;
+
+ return 0;
+}
+
+static int mpfs_auto_update_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mpfs_auto_update_priv *priv;
+ struct fw_upload *fw_uploader;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->sys_controller = mpfs_sys_controller_get(dev);
+ if (IS_ERR(priv->sys_controller))
+ return dev_err_probe(dev, PTR_ERR(priv->sys_controller),
+ "Could not register as a sub device of the system controller\n");
+
+ priv->dev = dev;
+ platform_set_drvdata(pdev, priv);
+
+ ret = mpfs_auto_update_available(priv);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "The current bitstream does not support auto-update\n");
+
+ init_completion(&priv->programming_complete);
+
+ fw_uploader = firmware_upload_register(THIS_MODULE, dev, "mpfs_bitstream",
+ &mpfs_auto_update_ops, priv);
+ if (IS_ERR(fw_uploader))
+ return dev_err_probe(dev, PTR_ERR(fw_uploader),
+ "Failed to register the bitstream uploader\n");
+
+ priv->fw_uploader = fw_uploader;
+
+ return 0;
+}
+
+static void mpfs_auto_update_remove(struct platform_device *pdev)
+{
+ struct mpfs_auto_update_priv *priv = platform_get_drvdata(pdev);
+
+ firmware_upload_unregister(priv->fw_uploader);
+}
+
+static struct platform_driver mpfs_auto_update_driver = {
+ .driver = {
+ .name = "mpfs-auto-update",
+ },
+ .probe = mpfs_auto_update_probe,
+ .remove_new = mpfs_auto_update_remove,
+};
+module_platform_driver(mpfs_auto_update_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Conor Dooley <[email protected]>");
+MODULE_DESCRIPTION("PolarFire SoC Auto Update FPGA reprogramming");
--
2.39.2

2023-03-31 07:22:31

by Conor Dooley

[permalink] [raw]

Subject: [PATCH v2 7/7] riscv: dts: microchip: add the mpfs' system controller qspi & associated flash

---

The system controller's flash can be accessed via an MSS-exposed QSPI
controller sitting, which sits between the mailbox's control & data
registers. On Icicle, it has an MT25QL01GBBB8ESF connected to it.

The system controller and MSS both have separate QSPI controllers, both
of which can access the flash, although the system controller takes
priority.
Unfortunately, on engineering sample silicon, such as that on Icicle
kits, the MSS' QSPI controller cannot write to the flash due to a bug.
As a workaround, a QSPI controller can be implemented in the FPGA
fabric and the IO routing modified to connect it to the flash in place
of the "hard" controller in the MSS.

Signed-off-by: Conor Dooley <[email protected]>
---
.../boot/dts/microchip/mpfs-icicle-kit.dts | 21 ++++++++++++++++
arch/riscv/boot/dts/microchip/mpfs.dtsi | 24 ++++++++++++++-----
2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
index 90b261114763..2dae3f8f33f6 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
@@ -199,6 +199,27 @@ &syscontroller {
status = "okay";
};

+&syscontroller_qspi {
+ /*
+ * The flash *is* there, but Icicle kits that have engineering sample
+ * silicon (write?) access to this flash to non-functional. The system
+ * controller itself can actually access it, but the MSS cannot write
+ * an image there. Instantiating a coreQSPI in the fabric & connecting
+ * it to the flash instead should work though. Pre-production or later
+ * silicon does not have this issue.
+ */
+ status = "disabled";
+
+ sys_ctrl_flash: flash@0 { // MT25QL01GBBB8ESF-0SIT
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <1>;
+ reg = <0>;
+ };
+};
+
&usb {
status = "okay";
dr_mode = "host";
diff --git a/arch/riscv/boot/dts/microchip/mpfs.dtsi b/arch/riscv/boot/dts/microchip/mpfs.dtsi
index 0a9bb84af438..568da2b570c0 100644
--- a/arch/riscv/boot/dts/microchip/mpfs.dtsi
+++ b/arch/riscv/boot/dts/microchip/mpfs.dtsi
@@ -173,11 +173,6 @@ refclk: mssrefclk {
#clock-cells = <0>;
};

- syscontroller: syscontroller {
- compatible = "microchip,mpfs-sys-controller";
- mboxes = <&mbox 0>;
- };
-
soc {
#address-cells = <2>;
#size-cells = <2>;
@@ -498,11 +493,28 @@ usb: usb@20201000 {

mbox: mailbox@37020000 {
compatible = "microchip,mpfs-mailbox";
- reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318C 0x0 0x40>;
+ reg = <0x0 0x37020000 0x0 0x58>, <0x0 0x2000318C 0x0 0x40>,
+ <0x0 0x37020800 0x0 0x100>;
interrupt-parent = <&plic>;
interrupts = <96>;
#mbox-cells = <1>;
status = "disabled";
};
+
+ syscontroller_qspi: spi@37020100 {
+ compatible = "microchip,mpfs-qspi", "microchip,coreqspi-rtl-v2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x37020100 0x0 0x100>;
+ interrupt-parent = <&plic>;
+ interrupts = <110>;
+ clocks = <&clkcfg CLK_QSPI>; /* this is probably wrong, consult the docs! */
+ status = "disabled";
+ };
+ };
+
+ syscontroller: syscontroller {
+ compatible = "microchip,mpfs-sys-controller";
+ mboxes = <&mbox 0>;
};
};
--
2.39.2

2023-03-31 07:23:11

by Conor Dooley

[permalink] [raw]

Subject: [PATCH v2 5/7] soc: microchip: mpfs: add auto-update subdev to system controller

---

The PolarFire SoC's system controller offers the ability to re-program
the FPGA from a user application via two, related, mechanisms.
In-Application Programming (IAP) is not ideal for use in Linux, as it
will immediately take down the system when requested. Auto Update is
preferred, as it will only take affect at device power up*, allowing the
OS (and potential applications in AMP) to be shut down gracefully.

* Auto Update occurs at device initialisation, which can also be
triggered by device reset - possible with the v2023.02 version of the
Hart Software Services (HSS) and reference design.

Signed-off-by: Conor Dooley <[email protected]>
---
drivers/soc/microchip/mpfs-sys-controller.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/microchip/mpfs-sys-controller.c b/drivers/soc/microchip/mpfs-sys-controller.c
index 1b7680e05cc0..0b94fdcc805d 100644
--- a/drivers/soc/microchip/mpfs-sys-controller.c
+++ b/drivers/soc/microchip/mpfs-sys-controller.c
@@ -118,7 +118,11 @@ static struct platform_device subdevs[] = {
{
.name = "mpfs-generic-service",
.id = -1,
- }
+ },
+ {
+ .name = "mpfs-auto-update",
+ .id = -1,
+ },
};

static int mpfs_sys_controller_probe(struct platform_device *pdev)
@@ -160,7 +164,6 @@ static int mpfs_sys_controller_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, sys_controller);

- dev_info(&pdev->dev, "Registered MPFS system controller\n");

for (i = 0; i < ARRAY_SIZE(subdevs); i++) {
subdevs[i].dev.parent = dev;
@@ -168,6 +171,8 @@ static int mpfs_sys_controller_probe(struct platform_device *pdev)
dev_warn(dev, "Error registering sub device %s\n", subdevs[i].name);
}

+ dev_info(&pdev->dev, "Registered MPFS system controller\n");
+
return 0;
}

--
2.39.2

2023-03-31 07:23:20

by Conor Dooley

[permalink] [raw]

Subject: [PATCH v2 4/7] soc: microchip: mpfs: print service status in warning message

---

Now that resp_status is set for failed services, print the status in the
error path's warning.

Signed-off-by: Conor Dooley <[email protected]>
---
drivers/soc/microchip/mpfs-sys-controller.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/microchip/mpfs-sys-controller.c b/drivers/soc/microchip/mpfs-sys-controller.c
index 5270630c52bf..1b7680e05cc0 100644
--- a/drivers/soc/microchip/mpfs-sys-controller.c
+++ b/drivers/soc/microchip/mpfs-sys-controller.c
@@ -66,7 +66,9 @@ int mpfs_blocking_transaction(struct mpfs_sys_controller *sys_controller, struct
*/
if (!wait_for_completion_timeout(&sys_controller->c, timeout)) {
ret = -EBADMSG;
- dev_warn(sys_controller->client.dev, "MPFS sys controller service failed\n");
+ dev_warn(sys_controller->client.dev,
+ "MPFS sys controller service failed with status: %d\n",
+ msg->response->resp_status);
} else {
ret = 0;
}
--
2.39.2

2023-04-02 08:15:18

by Xu Yilun

[permalink] [raw]

Subject: Re: [PATCH v2 0/7] PolarFire SoC Auto Update Support

---

On 2023-03-31 at 08:18:16 +0100, Conor Dooley wrote:
> Hey all,
>
> This patchset adds support for the "Auto Update" feature on PolarFire
> SoC that allows for writing an FPGA bistream to the SPI flash connected
> to the system controller.
> On powercycle (or reboot depending on how the firmware implements the
> openSBI SRST extension) "Auto Update" will take place, and program the
> FPGA with the contents of the SPI flash - provided that that image is
> valid and an actual upgrade from that already programmed!
>
> Unfortunately, this series is not really testable yet - the Engineering
> Sample silicon on most dev boards has a bug in the QSPI controller
> connected to the system controller's flash and cannot access it.
> Pre-production and later silicon has this bug fixed.
>
> I previously posted an RFC about my approach in this driver, since as a
> flash-based FPGA we are somewhat different to the existing
> self-reprogramming drivers here. That RFC is here:
> https://lore.kernel.org/linux-fpga/[email protected]/
>
> This series depends on the following fixes:
> https://lore.kernel.org/all/d7c3ec51-8493-444a-bdec-2a30b0a15bdc@spud/

Is that series already merged? If yes, just remove this line.
If no, either put all of them in one series, or still make this series
as RFC until the dependency is resolved.

Thanks,
Yilun

>
> The patch adding the driver depends on the soc patches earlier in the
> series, so taking both through the same tree makes sense. Depending on
> sequencing with the dependencies, me taking it through the soc tree
> (with Acks etc of course) may make the most sense.
>
> Cheers,
> Conor.
>
> Changes in v2:
> - per Russ' suggestion, the driver has been switched to using the
> firmware-upload API rather than the fpga one
> - as a result of that change, the structure of the driver has changed
> significantly, although most of that is reshuffling existing code
> around
> - check if the upgrade is possible in probe and fail if it isn't
> - only write the image index if it is not already set
> - delete the now unneeded debugfs bits
>
> CC: Conor Dooley <[email protected]>
> CC: Daire McNamara <[email protected]>
> CC: Rob Herring <[email protected]>
> CC: Krzysztof Kozlowski <[email protected]>
> CC: Moritz Fischer <[email protected]>
> CC: Wu Hao <[email protected]>
> CC: Xu Yilun <[email protected]>
> CC: Tom Rix <[email protected]>
> CC; Russ Weight <[email protected]>
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
> CC: [email protected]
>
> Conor Dooley (7):
> soc: microchip: mpfs: add a prefix to rx_callback()
> dt-bindings: soc: microchip: add a property for system controller
> flash
> soc: microchip: mpfs: enable access to the system controller's flash
> soc: microchip: mpfs: print service status in warning message
> soc: microchip: mpfs: add auto-update subdev to system controller
> fpga: add PolarFire SoC Auto Update support
> riscv: dts: microchip: add the mpfs' system controller qspi &
> associated flash
>
> .../microchip,mpfs-sys-controller.yaml | 10 +
> .../boot/dts/microchip/mpfs-icicle-kit.dts | 21 +
> arch/riscv/boot/dts/microchip/mpfs.dtsi | 24 +-
> drivers/fpga/Kconfig | 11 +
> drivers/fpga/Makefile | 3 +-
> drivers/fpga/microchip-auto-update.c | 494 ++++++++++++++++++
> drivers/soc/microchip/Kconfig | 1 +
> drivers/soc/microchip/mpfs-sys-controller.c | 37 +-
> include/soc/microchip/mpfs.h | 2 +
> 9 files changed, 591 insertions(+), 12 deletions(-)
> create mode 100644 drivers/fpga/microchip-auto-update.c
>
> --
> 2.39.2
>

2023-04-02 08:29:36

by Conor Dooley

[permalink] [raw]

Subject: Re: [PATCH v2 0/7] PolarFire SoC Auto Update Support

---

On 2 April 2023 09:00:34 IST, Xu Yilun <[email protected]> wrote:
>On 2023-03-31 at 08:18:16 +0100, Conor Dooley wrote:
>> Hey all,
>>
>> This patchset adds support for the "Auto Update" feature on PolarFire
>> SoC that allows for writing an FPGA bistream to the SPI flash connected
>> to the system controller.
>> On powercycle (or reboot depending on how the firmware implements the
>> openSBI SRST extension) "Auto Update" will take place, and program the
>> FPGA with the contents of the SPI flash - provided that that image is
>> valid and an actual upgrade from that already programmed!
>>
>> Unfortunately, this series is not really testable yet - the Engineering
>> Sample silicon on most dev boards has a bug in the QSPI controller
>> connected to the system controller's flash and cannot access it.
>> Pre-production and later silicon has this bug fixed.
>>
>> I previously posted an RFC about my approach in this driver, since as a
>> flash-based FPGA we are somewhat different to the existing
>> self-reprogramming drivers here. That RFC is here:
>> https://lore.kernel.org/linux-fpga/[email protected]/
>>
>> This series depends on the following fixes:
>> https://lore.kernel.org/all/d7c3ec51-8493-444a-bdec-2a30b0a15bdc@spud/
>
>Is that series already merged? If yes, just remove this line.
>If no, either put all of them in one series, or still make this series
>as RFC until the dependency is resolved.

Merged into what?
I'll be applying the dependencies tomorrow probably.

>
>Thanks,
>Yilun
>
>>
>> The patch adding the driver depends on the soc patches earlier in the
>> series, so taking both through the same tree makes sense. Depending on
>> sequencing with the dependencies, me taking it through the soc tree
>> (with Acks etc of course) may make the most sense.
>>
>> Cheers,
>> Conor.
>>
>> Changes in v2:
>> - per Russ' suggestion, the driver has been switched to using the
>> firmware-upload API rather than the fpga one
>> - as a result of that change, the structure of the driver has changed
>> significantly, although most of that is reshuffling existing code
>> around
>> - check if the upgrade is possible in probe and fail if it isn't
>> - only write the image index if it is not already set
>> - delete the now unneeded debugfs bits
>>
>> CC: Conor Dooley <[email protected]>
>> CC: Daire McNamara <[email protected]>
>> CC: Rob Herring <[email protected]>
>> CC: Krzysztof Kozlowski <[email protected]>
>> CC: Moritz Fischer <[email protected]>
>> CC: Wu Hao <[email protected]>
>> CC: Xu Yilun <[email protected]>
>> CC: Tom Rix <[email protected]>
>> CC; Russ Weight <[email protected]>
>> CC: [email protected]
>> CC: [email protected]
>> CC: [email protected]
>> CC: [email protected]
>>
>> Conor Dooley (7):
>> soc: microchip: mpfs: add a prefix to rx_callback()
>> dt-bindings: soc: microchip: add a property for system controller
>> flash
>> soc: microchip: mpfs: enable access to the system controller's flash
>> soc: microchip: mpfs: print service status in warning message
>> soc: microchip: mpfs: add auto-update subdev to system controller
>> fpga: add PolarFire SoC Auto Update support
>> riscv: dts: microchip: add the mpfs' system controller qspi &
>> associated flash
>>
>> .../microchip,mpfs-sys-controller.yaml | 10 +
>> .../boot/dts/microchip/mpfs-icicle-kit.dts | 21 +
>> arch/riscv/boot/dts/microchip/mpfs.dtsi | 24 +-
>> drivers/fpga/Kconfig | 11 +
>> drivers/fpga/Makefile | 3 +-
>> drivers/fpga/microchip-auto-update.c | 494 ++++++++++++++++++
>> drivers/soc/microchip/Kconfig | 1 +
>> drivers/soc/microchip/mpfs-sys-controller.c | 37 +-
>> include/soc/microchip/mpfs.h | 2 +
>> 9 files changed, 591 insertions(+), 12 deletions(-)
>> create mode 100644 drivers/fpga/microchip-auto-update.c
>>
>> --
>> 2.39.2
>>

2023-04-02 12:09:31

by Xu Yilun

[permalink] [raw]

Subject: Re: [PATCH v2 6/7] fpga: add PolarFire SoC Auto Update support

---

On 2023-03-31 at 08:18:22 +0100, Conor Dooley wrote:
> Add support for Auto Update reprogramming of the FPGA fabric on
> PolarFire SoC, using the fw_upload mechanism a la the
> intel-m10-bmc-sec-update driver.

I'm not an expert of MTD and have several concerns about the mtd
writing part:

- This seems a generic case that writing a file content into the
driver restricted offset on mtd.

- Seems the firmware update interface could be created for mtd device,
like the nvmem interface?

- I assume the purpose of the fw upload interface is to protect
unexpected writing from user. So how to protect the mtd be
written by other user interfaces like mtdchar/block or nvmem?


For other parts:

- directory block check, fw upload don't touch this block, so why check
it in fw upload process.

- image verification, no matter pass or fail, fw upload is actually done,
the flash is written and no way to rollback. So may remove from fw
upload process.

Thanks,
Yilun

>
> This driver only writes the image to the spi flash & performs
> validation on it, as the entire FPGA becomes unusable during the actual
> reprogramming of a bitstream. To initiate the reprogramming itself, a
> device reset is required.
> The SBI SRST extension's "cold reboot" can trigger such a device reset,
> by means of a "Tamper Macro" in the FPGA fabric, provided corresponding
> support has been enabled in the HSS (Hart Software Services).
>
> Signed-off-by: Conor Dooley <[email protected]>
> ---
> drivers/fpga/Kconfig | 11 +
> drivers/fpga/Makefile | 3 +-
> drivers/fpga/microchip-auto-update.c | 494 +++++++++++++++++++++++++++
> 3 files changed, 507 insertions(+), 1 deletion(-)
> create mode 100644 drivers/fpga/microchip-auto-update.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 0a00763b9f28..2838ce7ddafe 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -257,6 +257,17 @@ config FPGA_M10_BMC_SEC_UPDATE
> (BMC) and provides support for secure updates for the BMC image,
> the FPGA image, the Root Entry Hashes, etc.
>
> +config FPGA_MICROCHIP_AUTO_UPDATE
> + tristate "Microchip PolarFire SoC AUTO UPDATE"
> + depends on POLARFIRE_SOC_SYS_CTRL
> + select FW_LOADER
> + select FW_UPLOAD
> + help
> + FPGA manager driver support for reprogramming PolarFire SoC from
> + within Linux, using the Auto Upgrade feature of the system controller.
> +
> + If built as a module, it will be called microchip-auto-update.
> +
> config FPGA_MGR_MICROCHIP_SPI
> tristate "Microchip Polarfire SPI FPGA manager"
> depends on SPI
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 72e554b4d2f7..0b1ba6db860d 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -25,8 +25,9 @@ obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI) += lattice-sysconfig-spi.o
> obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
> obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o
>
> -# FPGA Secure Update Drivers
> +# FPGA Firmware Upload Drivers
> obj-$(CONFIG_FPGA_M10_BMC_SEC_UPDATE) += intel-m10-bmc-sec-update.o
> +obj-$(CONFIG_FPGA_MICROCHIP_AUTO_UPDATE) += microchip-auto-update.o
>
> # FPGA Bridge Drivers
> obj-$(CONFIG_FPGA_BRIDGE) += fpga-bridge.o
> diff --git a/drivers/fpga/microchip-auto-update.c b/drivers/fpga/microchip-auto-update.c
> new file mode 100644
> index 000000000000..5fa920b659c6
> --- /dev/null
> +++ b/drivers/fpga/microchip-auto-update.c
> @@ -0,0 +1,494 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Microchip Polarfire SoC "Auto Update" FPGA reprogramming.
> + *
> + * Documentation of this functionality is available in the "PolarFire? FPGA and
> + * PolarFire SoC FPGA Programming" User Guide.
> + *
> + * Copyright (c) 2022-2023 Microchip Corporation. All rights reserved.
> + *
> + * Author: Conor Dooley <[email protected]>
> + */
> +#include <linux/debugfs.h>
> +#include <linux/firmware.h>
> +#include <linux/math.h>
> +#include <linux/module.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/of_device.h>
> +#include <linux/sizes.h>
> +
> +#include <soc/microchip/mpfs.h>
> +
> +#define AUTO_UPDATE_DEFAULT_MBOX_OFFSET 0u
> +#define AUTO_UPDATE_DEFAULT_RESP_OFFSET 0u
> +
> +#define AUTO_UPDATE_FEATURE_CMD_OPCODE 0x05u
> +#define AUTO_UPDATE_FEATURE_CMD_DATA_SIZE 0u
> +#define AUTO_UPDATE_FEATURE_RESP_SIZE 33u
> +#define AUTO_UPDATE_FEATURE_CMD_DATA NULL
> +#define AUTO_UPDATE_FEATURE_ENABLED BIT(5)
> +
> +#define AUTO_UPDATE_AUTHENTICATE_CMD_OPCODE 0x22u
> +#define AUTO_UPDATE_AUTHENTICATE_CMD_DATA_SIZE 0u
> +#define AUTO_UPDATE_AUTHENTICATE_RESP_SIZE 1u
> +#define AUTO_UPDATE_AUTHENTICATE_CMD_DATA NULL
> +
> +#define AUTO_UPDATE_PROGRAM_CMD_OPCODE 0x46u
> +#define AUTO_UPDATE_PROGRAM_CMD_DATA_SIZE 0u
> +#define AUTO_UPDATE_PROGRAM_RESP_SIZE 1u
> +#define AUTO_UPDATE_PROGRAM_CMD_DATA NULL
> +
> +/*
> + * SPI Flash layout example:
> + * |------------------------------| 0x0000000
> + * | 1 KiB |
> + * | SPI "directories" |
> + * |------------------------------| 0x0000400
> + * | 1 MiB |
> + * | Reserved area |
> + * | Used for bitstream info |
> + * |------------------------------| 0x0100400
> + * | 20 MiB |
> + * | Golden Image |
> + * |------------------------------| 0x1500400
> + * | 20 MiB |
> + * | Auto Upgrade Image |
> + * |------------------------------| 0x2900400
> + * | 20 MiB |
> + * | Reserved for multi-image IAP |
> + * | Unused for Auto Upgrade |
> + * |------------------------------| 0x3D00400
> + * | ? B |
> + * | Unused |
> + * |------------------------------| 0x?
> + */
> +#define AUTO_UPDATE_DIRECTORY_BASE 0u
> +#define AUTO_UPDATE_DIRECTORY_WIDTH 4u
> +#define AUTO_UPDATE_GOLDEN_INDEX 0u
> +#define AUTO_UPDATE_UPGRADE_INDEX 1u
> +#define AUTO_UPDATE_BLANK_INDEX 2u
> +#define AUTO_UPDATE_GOLDEN_DIRECTORY (AUTO_UPDATE_DIRECTORY_WIDTH * AUTO_UPDATE_GOLDEN_INDEX)
> +#define AUTO_UPDATE_UPGRADE_DIRECTORY (AUTO_UPDATE_DIRECTORY_WIDTH * AUTO_UPDATE_UPGRADE_INDEX)
> +#define AUTO_UPDATE_BLANK_DIRECTORY (AUTO_UPDATE_DIRECTORY_WIDTH * AUTO_UPDATE_BLANK_INDEX)
> +#define AUTO_UPDATE_DIRECTORY_SIZE SZ_1K
> +#define AUTO_UPDATE_RESERVED_SIZE SZ_1M
> +#define AUTO_UPDATE_BITSTREAM_BASE (AUTO_UPDATE_DIRECTORY_SIZE + AUTO_UPDATE_RESERVED_SIZE)
> +
> +#define AUTO_UPDATE_TIMEOUT_MS 60000
> +
> +struct mpfs_auto_update_priv {
> + struct mpfs_sys_controller *sys_controller;
> + struct device *dev;
> + struct mtd_info *flash;
> + struct fw_upload *fw_uploader;
> + struct completion programming_complete;
> + size_t size_per_bitstream;
> + bool cancel_request;
> +};
> +
> +static enum fw_upload_err mpfs_auto_update_prepare(struct fw_upload *fw_uploader, const u8 *data,
> + u32 size)
> +{
> + struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
> + size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
> +
> + /*
> + * Verifying the Golden Image is idealistic. It will be evaluated
> + * against the currently programmed image and thus may fail - due to
> + * either rollback protection (if its an older version than that in use)
> + * or if the version is the same as that of the in-use image.
> + * Extracting the information as to why a failure occurred is not
> + * currently possible due to limitations of the system controller
> + * driver. If those are fixed, verification of the Golden Image should
> + * be added here.
> + */
> +
> + priv->flash = mpfs_sys_controller_get_flash(priv->sys_controller);
> + if (!priv->flash)
> + return FW_UPLOAD_ERR_HW_ERROR;
> +
> + erase_size = round_up(erase_size, (u64)priv->flash->erasesize);
> +
> + /*
> + * We need to calculate if we have enough space in the flash for the
> + * new image.
> + * First, chop off the first 1 KiB as it's reserved for the directory.
> + * The 1 MiB reserved for design info needs to be ignored also.
> + * All that remains is carved into 3 & rounded down to the erasesize.
> + * If this is smaller than the image size, we abort.
> + * There's also no need to consume more than 20 MiB per image.
> + */
> + priv->size_per_bitstream = priv->flash->size - SZ_1K - SZ_1M;
> + priv->size_per_bitstream = round_down(priv->size_per_bitstream / 3, erase_size);
> + if (priv->size_per_bitstream > 20 * SZ_1M)
> + priv->size_per_bitstream = 20 * SZ_1M;
> +
> + if (priv->size_per_bitstream < size) {
> + dev_err(priv->dev,
> + "flash device has insufficient capacity to store this bitstream\n");
> + return FW_UPLOAD_ERR_INVALID_SIZE;
> + }
> +
> + priv->cancel_request = false;
> +
> + return FW_UPLOAD_ERR_NONE;
> +}
> +
> +static void mpfs_auto_update_cancel(struct fw_upload *fw_uploader)
> +{
> + struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
> +
> + priv->cancel_request = true;
> +}
> +
> +static enum fw_upload_err mpfs_auto_update_poll_complete(struct fw_upload *fw_uploader)
> +{
> + struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
> + int ret;
> +
> + /*
> + * There is no meaningful way to get the status of the programming while
> + * it is in progress, so attempting anything other than waiting for it
> + * to complete would be misplaced.
> + */
> + ret = wait_for_completion_timeout(&priv->programming_complete,
> + msecs_to_jiffies(AUTO_UPDATE_TIMEOUT_MS));
> + if (ret)
> + return FW_UPLOAD_ERR_TIMEOUT;
> +
> + return FW_UPLOAD_ERR_NONE;
> +}
> +
> +static int mpfs_auto_update_verify_image(struct fw_upload *fw_uploader)
> +{
> + struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
> + struct mpfs_mss_response *response;
> + struct mpfs_mss_msg *message;
> + u32 *response_msg;
> + int ret;
> +
> + response_msg = devm_kzalloc(priv->dev, AUTO_UPDATE_FEATURE_RESP_SIZE * sizeof(response_msg),
> + GFP_KERNEL);
> + if (!response_msg)
> + return -ENOMEM;
> +
> + response = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_response), GFP_KERNEL);
> + if (!response) {
> + ret = -ENOMEM;
> + goto free_response_msg;
> + }
> +
> + message = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_msg), GFP_KERNEL);
> + if (!message) {
> + ret = -ENOMEM;
> + goto free_response;
> + }
> +
> + /*
> + * The system controller can verify that an image in the flash is valid.
> + * Rather than duplicate the check in this driver, call the relevant
> + * service from the system controller instead.
> + * This service has no command data and no response data. It overloads
> + * mbox_offset with the image index in the flash's SPI directory where
> + * the bitstream is located.
> + */
> + response->resp_msg = response_msg;
> + response->resp_size = AUTO_UPDATE_AUTHENTICATE_RESP_SIZE;
> + message->cmd_opcode = AUTO_UPDATE_AUTHENTICATE_CMD_OPCODE;
> + message->cmd_data_size = AUTO_UPDATE_AUTHENTICATE_CMD_DATA_SIZE;
> + message->response = response;
> + message->cmd_data = AUTO_UPDATE_AUTHENTICATE_CMD_DATA;
> + message->mbox_offset = AUTO_UPDATE_UPGRADE_INDEX;
> + message->resp_offset = AUTO_UPDATE_DEFAULT_RESP_OFFSET;
> +
> + dev_info(priv->dev, "Running verification of Upgrade Image\n");
> + ret = mpfs_blocking_transaction(priv->sys_controller, message);
> + if (ret | response->resp_status) {
> + dev_warn(priv->dev, "Verification of Upgrade Image failed!\n");
> + ret = ret ? ret : -EBADMSG;
> + }
> +
> + dev_info(priv->dev, "Verification of Upgrade Image passed!\n");
> +
> + devm_kfree(priv->dev, message);
> +free_response:
> + devm_kfree(priv->dev, response);
> +free_response_msg:
> + devm_kfree(priv->dev, response_msg);
> +
> + return ret;
> +}
> +
> +static int mpfs_auto_update_set_image_address(struct mpfs_auto_update_priv *priv, char *buffer,
> + u32 image_address, loff_t directory_address)
> +{
> + struct erase_info erase;
> + size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
> + size_t bytes_written = 0, bytes_read = 0;
> + int ret;
> +
> + erase_size = round_up(erase_size, (u64)priv->flash->erasesize);
> +
> + erase.addr = AUTO_UPDATE_DIRECTORY_BASE;
> + erase.len = erase_size;
> +
> + /*
> + * We need to write the "SPI DIRECTORY" to the first 1 KiB, telling
> + * the system controller where to find the actual bitstream. Since
> + * this is spi-nor, we have to read the first eraseblock, erase that
> + * portion of the flash, modify the data and then write it back.
> + * There's no need to do this though if things are already the way they
> + * should be, so check and save the write in that case.
> + */
> + ret = mtd_read(priv->flash, AUTO_UPDATE_DIRECTORY_BASE, erase_size, &bytes_read,
> + (u_char *)buffer);
> + if (ret)
> + return ret;
> +
> + if (bytes_read != erase_size)
> + return -EIO;
> +
> + if ((*(u32 *)(buffer + AUTO_UPDATE_UPGRADE_DIRECTORY) == image_address) &&
> + !(*(u32 *)(buffer + AUTO_UPDATE_BLANK_DIRECTORY)))
> + return 0;
> +
> + ret = mtd_erase(priv->flash, &erase);
> + if (ret)
> + return ret;
> +
> + /*
> + * Populate the image address and then zero out the next directory so
> + * that the system controller doesn't complain if in "Single Image"
> + * mode.
> + */
> + memcpy(buffer + AUTO_UPDATE_UPGRADE_DIRECTORY, &image_address,
> + AUTO_UPDATE_DIRECTORY_WIDTH);
> + memset(buffer + AUTO_UPDATE_BLANK_DIRECTORY, 0x0, AUTO_UPDATE_DIRECTORY_WIDTH);
> +
> + dev_info(priv->dev, "Writing the image address (%x) to the flash directory (%llx)\n",
> + image_address, directory_address);
> +
> + ret = mtd_write(priv->flash, 0x0, erase_size, &bytes_written, (u_char *)buffer);
> + if (ret)
> + return ret;
> +
> + if (bytes_written != erase_size)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int mpfs_auto_update_write_bitstream(struct fw_upload *fw_uploader, const u8 *data,
> + u32 offset, u32 size, u32 *written)
> +{
> + struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
> + struct erase_info erase;
> + char *buffer;
> + loff_t directory_address = AUTO_UPDATE_UPGRADE_DIRECTORY;
> + size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
> + size_t bytes_written = 0;
> + u32 image_address;
> + int ret;
> +
> + erase_size = round_up(erase_size, (u64)priv->flash->erasesize);
> +
> + image_address = AUTO_UPDATE_BITSTREAM_BASE +
> + AUTO_UPDATE_UPGRADE_INDEX * priv->size_per_bitstream;
> +
> + buffer = devm_kzalloc(priv->dev, erase_size, GFP_KERNEL);
> + if (!buffer)
> + return -ENOMEM;
> +
> + ret = mpfs_auto_update_set_image_address(priv, buffer, image_address, directory_address);
> + if (ret) {
> + dev_err(priv->dev, "failed to set image address in the SPI directory: %d\n", ret);
> + goto out;
> + }
> +
> + /*
> + * Now the .spi image itself can be written to the flash. Preservation
> + * of contents here is not important here, unlike the spi "directory"
> + * which must be RMWed.
> + */
> + erase.len = round_up(size, (size_t)priv->flash->erasesize);
> + erase.addr = image_address;
> +
> + dev_info(priv->dev, "Erasing the flash at address (%x)\n", image_address);
> + ret = mtd_erase(priv->flash, &erase);
> + if (ret)
> + goto out;
> +
> + /*
> + * No parsing etc of the bitstream is required. The system controller
> + * will do all of that itself - including verifying that the bitstream
> + * is valid.
> + */
> + dev_info(priv->dev, "Writing the image to the flash at address (%x)\n", image_address);
> + ret = mtd_write(priv->flash, (loff_t)image_address, size, &bytes_written, data);
> + if (ret)
> + goto out;
> +
> + if (bytes_written != size) {
> + ret = -EIO;
> + goto out;
> + }
> +
> + *written = bytes_written;
> +
> +out:
> + devm_kfree(priv->dev, buffer);
> + return ret;
> +}
> +
> +static enum fw_upload_err mpfs_auto_update_write(struct fw_upload *fw_uploader, const u8 *data,
> + u32 offset, u32 size, u32 *written)
> +{
> + struct mpfs_auto_update_priv *priv = fw_uploader->dd_handle;
> + enum fw_upload_err err = FW_UPLOAD_ERR_NONE;
> + int ret;
> +
> + reinit_completion(&priv->programming_complete);
> +
> + ret = mpfs_auto_update_write_bitstream(fw_uploader, data, offset, size, written);
> + if (ret) {
> + err = FW_UPLOAD_ERR_RW_ERROR;
> + goto out;
> + }
> +
> + if (priv->cancel_request) {
> + err = FW_UPLOAD_ERR_CANCELED;
> + goto out;
> + }
> +
> + ret = mpfs_auto_update_verify_image(fw_uploader);
> + if (ret)
> + err = FW_UPLOAD_ERR_HW_ERROR;
> +
> +out:
> + complete(&priv->programming_complete);
> +
> + return err;
> +}
> +
> +static const struct fw_upload_ops mpfs_auto_update_ops = {
> + .prepare = mpfs_auto_update_prepare,
> + .write = mpfs_auto_update_write,
> + .poll_complete = mpfs_auto_update_poll_complete,
> + .cancel = mpfs_auto_update_cancel,
> +};
> +
> +static int mpfs_auto_update_available(struct mpfs_auto_update_priv *priv)
> +{
> + struct mpfs_mss_response *response;
> + struct mpfs_mss_msg *message;
> + u32 *response_msg;
> + int ret;
> +
> + response_msg = devm_kzalloc(priv->dev, AUTO_UPDATE_FEATURE_RESP_SIZE * sizeof(response_msg),
> + GFP_KERNEL);
> + if (!response_msg)
> + return -ENOMEM;
> +
> + response = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_response), GFP_KERNEL);
> + if (!response)
> + return -ENOMEM;
> +
> + message = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_msg), GFP_KERNEL);
> + if (!message)
> + return -ENOMEM;
> +
> + /*
> + * To verify that Auto Update is possible, the "Query Security Service
> + * Request" is performed.
> + * This service has no command data & does not overload mbox_offset.
> + */
> + response->resp_msg = response_msg;
> + response->resp_size = AUTO_UPDATE_FEATURE_RESP_SIZE;
> + message->cmd_opcode = AUTO_UPDATE_FEATURE_CMD_OPCODE;
> + message->cmd_data_size = AUTO_UPDATE_FEATURE_CMD_DATA_SIZE;
> + message->response = response;
> + message->cmd_data = AUTO_UPDATE_FEATURE_CMD_DATA;
> + message->mbox_offset = AUTO_UPDATE_DEFAULT_MBOX_OFFSET;
> + message->resp_offset = AUTO_UPDATE_DEFAULT_RESP_OFFSET;
> +
> + ret = mpfs_blocking_transaction(priv->sys_controller, message);
> + if (ret)
> + return ret;
> +
> + /*
> + * Currently, the system controller's firmware does not generate any
> + * interrupts for failed services, so mpfs_blocking_transaction() should
> + * time out & therefore return an error.
> + * Hitting this check is highly unlikely at present, but if the system
> + * controller's behaviour changes so that it does generate interrupts
> + * for failed services, it will be required.
> + */
> + if (response->resp_status)
> + return -EIO;
> +
> + /*
> + * Bit 5 of byte 1 is "UL_Auto Update" & if it is set, Auto Update is
> + * not possible.
> + */
> + if (response_msg[1] & AUTO_UPDATE_FEATURE_ENABLED)
> + return -EPERM;
> +
> + return 0;
> +}
> +
> +static int mpfs_auto_update_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mpfs_auto_update_priv *priv;
> + struct fw_upload *fw_uploader;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->sys_controller = mpfs_sys_controller_get(dev);
> + if (IS_ERR(priv->sys_controller))
> + return dev_err_probe(dev, PTR_ERR(priv->sys_controller),
> + "Could not register as a sub device of the system controller\n");
> +
> + priv->dev = dev;
> + platform_set_drvdata(pdev, priv);
> +
> + ret = mpfs_auto_update_available(priv);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "The current bitstream does not support auto-update\n");
> +
> + init_completion(&priv->programming_complete);
> +
> + fw_uploader = firmware_upload_register(THIS_MODULE, dev, "mpfs_bitstream",
> + &mpfs_auto_update_ops, priv);
> + if (IS_ERR(fw_uploader))
> + return dev_err_probe(dev, PTR_ERR(fw_uploader),
> + "Failed to register the bitstream uploader\n");
> +
> + priv->fw_uploader = fw_uploader;
> +
> + return 0;
> +}
> +
> +static void mpfs_auto_update_remove(struct platform_device *pdev)
> +{
> + struct mpfs_auto_update_priv *priv = platform_get_drvdata(pdev);
> +
> + firmware_upload_unregister(priv->fw_uploader);
> +}
> +
> +static struct platform_driver mpfs_auto_update_driver = {
> + .driver = {
> + .name = "mpfs-auto-update",
> + },
> + .probe = mpfs_auto_update_probe,
> + .remove_new = mpfs_auto_update_remove,
> +};
> +module_platform_driver(mpfs_auto_update_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Conor Dooley <[email protected]>");
> +MODULE_DESCRIPTION("PolarFire SoC Auto Update FPGA reprogramming");
> --
> 2.39.2
>

2023-04-03 19:49:22

by Conor Dooley

[permalink] [raw]

Subject: Re: (subset) [PATCH v2 0/7] PolarFire SoC Auto Update Support

---

From: Conor Dooley <[email protected]>

On Fri, 31 Mar 2023 08:18:16 +0100, Conor Dooley wrote:
> Hey all,
>
> This patchset adds support for the "Auto Update" feature on PolarFire
> SoC that allows for writing an FPGA bistream to the SPI flash connected
> to the system controller.
> On powercycle (or reboot depending on how the firmware implements the
> openSBI SRST extension) "Auto Update" will take place, and program the
> FPGA with the contents of the SPI flash - provided that that image is
> valid and an actual upgrade from that already programmed!
>
> [...]

Gonna take this one patch, since it's got ~nothing to do with the rest
of the series really, so:

Applied to riscv-soc-for-next, thanks!

[1/7] soc: microchip: mpfs: add a prefix to rx_callback()
https://git.kernel.org/conor/c/4dd472bdafcb

Thanks,
Conor.

2023-04-11 11:52:51

by Conor Dooley

[permalink] [raw]

Subject: Re: [PATCH v2 6/7] fpga: add PolarFire SoC Auto Update support

---

On Sun, Apr 02, 2023 at 06:57:18PM +0800, Xu Yilun wrote:
> On 2023-03-31 at 08:18:22 +0100, Conor Dooley wrote:
> > Add support for Auto Update reprogramming of the FPGA fabric on
> > PolarFire SoC, using the fw_upload mechanism a la the
> > intel-m10-bmc-sec-update driver.
>
> I'm not an expert of MTD and have several concerns about the mtd
> writing part:
>
> - This seems a generic case that writing a file content into the
> driver restricted offset on mtd.

Right, writing at an offset is pretty generic.

> - Seems the firmware update interface could be created for mtd device,
> like the nvmem interface?

I'm not entirely sure what you mean by this one.
Are you saying that there should be a generic way to do "firmware"
uploads to mtd devices, based on some sort of structure defined in
devicetree etc?
And perhaps then, this driver would register as a consumer of that
interface, pushing all of the direct mtd stuff out to that interface?

> - I assume the purpose of the fw upload interface is to protect
> unexpected writing from user. So how to protect the mtd be
> written by other user interfaces like mtdchar/block or nvmem?

I'm not very good with the security knobs so I don't have an answer for
you here (yet). But your assumption about the rationale here is correct
and I would like to block access.

> For other parts:
>
> - directory block check, fw upload don't touch this block, so why check
> it in fw upload process.

I don't know what you mean. The mtd device could be empty and the
directory would need to be populated with the image address etc.
Or, it could previously have been used for something else, and then it
would be required to reconfigure it correctly for Auto Upgrade.

Maybe I am misunderstanding you?

>
> - image verification, no matter pass or fail, fw upload is actually done,
> the flash is written and no way to rollback. So may remove from fw
> upload process.

The FPGA is flash based, so writing to the mtd device is not going to
actually program the FPGA with this content. The original image/bitstream
in the mtd device is either going to be a) equivalent to what is already
programmed in the FPGA, b) not an upgrade over what is current in the
FPGA, c) something that was uploaded since the last time the device was
restarted.
I don't think that overwriting any of those is problematic, as if the
verification fails, the original bitstream will continue being used
until an image that does actually pass is provided.

Without doing the verification though, there's no way to tell for certain
if the FPGA is actually going to perform an upgrade to this new bitstream
once it is restarted, so I think there is value in keeping this.

If you're still very sceptical about whether this belongs in
drivers/fpga, I can always dump it in drivers/soc instead I guess.

Cheers,
Conor.

---

Attachments:

(No filename) (2.85 kB)
signature.asc (235.00 B)
Download all attachments

2023-04-14 04:41:56

by Xu Yilun

[permalink] [raw]

Subject: Re: [PATCH v2 6/7] fpga: add PolarFire SoC Auto Update support

---

On 2023-04-11 at 12:51:34 +0100, Conor Dooley wrote:
> On Sun, Apr 02, 2023 at 06:57:18PM +0800, Xu Yilun wrote:
> > On 2023-03-31 at 08:18:22 +0100, Conor Dooley wrote:
> > > Add support for Auto Update reprogramming of the FPGA fabric on
> > > PolarFire SoC, using the fw_upload mechanism a la the
> > > intel-m10-bmc-sec-update driver.
> >
> > I'm not an expert of MTD and have several concerns about the mtd
> > writing part:
> >
> > - This seems a generic case that writing a file content into the
> > driver restricted offset on mtd.
>
> Right, writing at an offset is pretty generic.
>
> > - Seems the firmware update interface could be created for mtd device,
> > like the nvmem interface?
>
> I'm not entirely sure what you mean by this one.
> Are you saying that there should be a generic way to do "firmware"
> uploads to mtd devices, based on some sort of structure defined in

Yes, I think if the firmware upload interface could be generic, then add
it to the mtd devices, rather than creating a "virtual mtd management"
device as this patch does.

> devicetree etc?
> And perhaps then, this driver would register as a consumer of that
> interface, pushing all of the direct mtd stuff out to that interface?
>
> > - I assume the purpose of the fw upload interface is to protect
> > unexpected writing from user. So how to protect the mtd be
> > written by other user interfaces like mtdchar/block or nvmem?
>
> I'm not very good with the security knobs so I don't have an answer for
> you here (yet). But your assumption about the rationale here is correct
> and I would like to block access.
>
> > For other parts:
> >
> > - directory block check, fw upload don't touch this block, so why check
> > it in fw upload process.
>
> I don't know what you mean. The mtd device could be empty and the
> directory would need to be populated with the image address etc.
> Or, it could previously have been used for something else, and then it
> would be required to reconfigure it correctly for Auto Upgrade.
>
> Maybe I am misunderstanding you?

This directory block content is unrelated to the firmware image, so
could be written before firmware upload interface is created. The
firmware image uploading could be done without touching directory
blocks. That means directory blocks could be set by driver as
no-touch area for firmware uploading interface.

>
> >
> > - image verification, no matter pass or fail, fw upload is actually done,
> > the flash is written and no way to rollback. So may remove from fw
> > upload process.
>
> The FPGA is flash based, so writing to the mtd device is not going to
> actually program the FPGA with this content. The original image/bitstream
> in the mtd device is either going to be a) equivalent to what is already
> programmed in the FPGA, b) not an upgrade over what is current in the
> FPGA, c) something that was uploaded since the last time the device was
> restarted.
> I don't think that overwriting any of those is problematic, as if the
> verification fails, the original bitstream will continue being used
> until an image that does actually pass is provided.
>
> Without doing the verification though, there's no way to tell for certain
> if the FPGA is actually going to perform an upgrade to this new bitstream
> once it is restarted, so I think there is value in keeping this.

I don't mean to remove the support of verification from driver. I say
remove the verification from MTD firmware upload process. You can
use another interface in your driver to verify if FPGA could load the
content in user block at any time.

In my opinion, generic firmware upload interface for MTD could be used
out of FPGA cases, it just deals with writing the image file to the MTD.
Once you have nothing more to write for the image file, the job for the
interface could be successfully done.

>
> If you're still very sceptical about whether this belongs in
> drivers/fpga, I can always dump it in drivers/soc instead I guess.

I actually don't think this belongs to FPGA domain. My pereference is a
generic MTD firmware upload interface for MTD domain.

But this is just my opinion. You may talk to MTD or SoC maintainers for
final solution.

Thanks,
Yilun

>
> Cheers,
> Conor.
>