PolarFire SoC Auto Update Support

From: Conor Dooley <[email protected]>

The system controller "shares" a SPI flash device with a QSPI controller in the MSS. This flash is used to store FPGA bitstreams & other metadata. IAP and Auto Upgrade both write images to this flash that the System Controller will use to re-program the FPGA.

Add a phandle property signifying which flash device is connected to the system controller.

Signed-off-by Conor Dooley <[email protected]>

---
 .../soc/microchip/microchip,mpfs-sys-controller.yaml   | 10 ++++++++++
 1 file changed, 10 insertions(+)

Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml +0 -0

index 04ffee3a7c59..97a7cb74cbf9 100644

Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml +8 -0

+    description:
+      The SPI flash connected to the system controller's QSPI controller.
+      The system controller may retrieve FPGA bitstreams from this flash to
+      perform In-Application Programming (IAP) or during device initialisation
+      for Auto Update. The MSS and system controller have separate QSPI
+      controllers and this flash is connected to both. Software running in the
+      MSS can write bitstreams to the flash.
+
 required:
   - compatible
   - mboxes

Signature · 1 line

2.39.1

From: Conor Dooley <[email protected]>

Add support for Auto Update reprogramming of the FPGA fabric on PolarFire SoC.

Signed-off-by Conor Dooley <[email protected]>

---
 drivers/fpga/Kconfig                 |   9 +
 drivers/fpga/Makefile                |   1 +
 drivers/fpga/microchip-auto-update.c | 495 +++++++++++++++++++++++++++
 3 files changed, 505 insertions(+)
 create mode 100644 drivers/fpga/microchip-auto-update.c

drivers/fpga/Kconfig +9 -0

index 6ce143dafd04..0cdd6978a440 100644
@@ -257,6 +257,15 @@ 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_MGR_MICROCHIP_AUTO_UPDATE
+	tristate "Microchip PolarFire SoC AUTO UPDATE"
+	depends on POLARFIRE_SOC_SYS_CTRL
+	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

drivers/fpga/Makefile +1 -0

index 72e554b4d2f7..a67903edf976 100644
@@ -19,6 +19,7 @@ obj-$(CONFIG_FPGA_MGR_XILINX_SPI)	+= xilinx-spi.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)	+= zynq-fpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA)	+= zynqmp-fpga.o
 obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA)	+= versal-fpga.o
+obj-$(CONFIG_FPGA_MGR_MICROCHIP_AUTO_UPDATE)	+= microchip-auto-update.o
 obj-$(CONFIG_FPGA_MGR_MICROCHIP_SPI)	+= microchip-spi.o
 obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG)	+= lattice-sysconfig.o
 obj-$(CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI)	+= lattice-sysconfig-spi.o

drivers/fpga/microchip-auto-update.c new file +109 -0

new file mode 100644
index 000000000000..d90085f86b8b
@@ -0,0 +1,495 @@
+// 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/fpga/fpga-mgr.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)
+
+struct mpfs_auto_update_config {
+	u8 feature_response_size;
+};
+
+struct mpfs_auto_update_priv {
+	struct mpfs_sys_controller *sys_controller;
+	struct device *dev;
+	struct fpga_region *region;
+	struct mpfs_auto_update_config *config;
+	struct mtd_info *flash;
+	struct dentry *debugfs_dir;
+};
+
+static struct device *mpfs_auto_update_debug_dev;
+
+static enum fpga_mgr_states mpfs_auto_update_state(struct fpga_manager *mgr)
+{
+	struct mpfs_auto_update_priv *priv = mgr->priv;
+	struct mpfs_mss_response *response;
+	struct mpfs_mss_msg *message;
+	u32 *response_msg;
+	int ret;
+	enum fpga_mgr_states rc = FPGA_MGR_STATE_WRITE_INIT_ERR;
+
+	response_msg = devm_kzalloc(priv->dev, AUTO_UPDATE_FEATURE_RESP_SIZE * sizeof(response_msg),
+				    GFP_KERNEL);
+	if (!response_msg)
+		return FPGA_MGR_STATE_WRITE_INIT_ERR;
+
+	response = devm_kzalloc(priv->dev, sizeof(struct mpfs_mss_response), GFP_KERNEL);
+	if (!response) {
+		rc = FPGA_MGR_STATE_WRITE_INIT_ERR;
+		goto free_response_msg;

drivers/fpga/microchip-auto-update.c new file +118 -0

+	 * Request" is performed. Bit 5 of byte 1 is "UL_Auto Update" & if it is
+	 * set, Auto Update is not possible.
+	 * This service has no command data & does not overload mbox_offset.
+	 * The size of the response varies between PolarFire & PolarFire SoC.
+	 */
+	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 | response->resp_status) {
+		rc = FPGA_MGR_STATE_UNKNOWN;
+		goto free_message;
+	}
+
+	if (!(response_msg[1] & AUTO_UPDATE_FEATURE_ENABLED))
+		rc = FPGA_MGR_STATE_OPERATING;
+
+free_message:
+	devm_kfree(priv->dev, message);
+free_response:
+	devm_kfree(priv->dev, response);
+free_response_msg:
+	devm_kfree(priv->dev, response_msg);
+
+	return rc;
+}
+
+static int mpfs_auto_update_write_init(struct fpga_manager *mgr, struct fpga_image_info *info,
+				       const char *buf, size_t count)
+{
+	/*
+	 * 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.
+	 */
+	return 0;
+}
+
+static int mpfs_auto_update_write(struct fpga_manager *mgr, const char *buf, size_t count)
+{
+	/*
+	 * No parsing etc of the bitstream is required. The system controller
+	 * will do all of that itself - including verifying that the bitstream
+	 * is valid.
+	 */
+	struct mpfs_auto_update_priv *priv = mgr->priv;
+	struct erase_info erase;
+	char *buffer;
+	loff_t directory_address = AUTO_UPDATE_UPGRADE_DIRECTORY;
+	size_t bytes_written = 0, bytes_read = 0;
+	size_t erase_size = AUTO_UPDATE_DIRECTORY_SIZE;
+	size_t size_per_bitstream = 0;
+	u32 image_address;
+	int ret;
+
+	priv->flash = mpfs_sys_controller_get_flash(priv->sys_controller);
+	if (!priv->flash)
+		return -EIO;
+
+	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.
+	 */
+	size_per_bitstream = priv->flash->size - SZ_1K - SZ_1M;
+	size_per_bitstream = round_down(size_per_bitstream / 3, erase_size);
+	if (size_per_bitstream > 20 * SZ_1M)
+		size_per_bitstream = 20 * SZ_1M;
+
+	if (size_per_bitstream < count) {
+		dev_err(priv->dev,
+			"flash device has insufficient capacity to store this bitstream\n");
+		return -EINVAL;
+	}
+
+	image_address = AUTO_UPDATE_BITSTREAM_BASE + AUTO_UPDATE_UPGRADE_INDEX * size_per_bitstream;
+
+	buffer = devm_kzalloc(priv->dev, erase_size, GFP_KERNEL);
+	if (!buffer)
+		return -ENOMEM;
+
+	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.
+	 */
+	ret = mtd_read(priv->flash, AUTO_UPDATE_DIRECTORY_BASE, erase_size, &bytes_read,
+		       (u_char *)buffer);
+	if (ret)
+		goto out;
+
+	if (bytes_read != erase_size) {
+		ret = -EIO;
+		goto out;
+	}
+
+	ret = mtd_erase(priv->flash, &erase);

drivers/fpga/microchip-auto-update.c new file +76 -0

+
+	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)
+		goto out;
+
+	if (bytes_written != erase_size) {
+		ret = -EIO;
+		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(count, (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;
+
+	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, count, &bytes_written, buf);
+	if (ret)
+		goto out;
+
+	if (bytes_written != count)
+		ret = -EIO;
+
+out:
+	devm_kfree(priv->dev, buffer);
+	return ret;
+}
+
+static int mpfs_auto_update_write_complete(struct fpga_manager *mgr, struct fpga_image_info *info)
+{
+	struct mpfs_auto_update_priv *priv = mgr->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) {
+		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;

drivers/fpga/microchip-auto-update.c new file +25 -0

+	}
+
+	dev_info(priv->dev, "Verification of Upgrade Image passed!\n");
+//	/*
+//	 * If the validation has passed, initiate Auto Update.
+//	 * 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.
+//	 * Once we attempt Auto Update either:
+//	 * - it passes and the board reboots
+//	 * - it fails and the board reboots to recover
+//	 * - the system controller aborts and we exit "gracefully".
+//	 *   "gracefully" since there is no interrupt produced & it just times
+//	 *   out.
+//	 */
+//	response->resp_msg = response_msg;
+//	response->resp_size = AUTO_UPDATE_PROGRAM_RESP_SIZE;
+//	message->cmd_opcode = AUTO_UPDATE_PROGRAM_CMD_OPCODE;
+//	message->cmd_data_size = AUTO_UPDATE_PROGRAM_CMD_DATA_SIZE;
+//	message->response = response;
+//	message->cmd_data = AUTO_UPDATE_PROGRAM_CMD_DATA;
+//	message->mbox_offset = 0; //field is ignored
+//	message->resp_offset = AUTO_UPDATE_DEFAULT_RESP_OFFSET;
+//
+//	dev_info(priv->dev, "Running Auto Update command\n");

drivers/fpga/microchip-auto-update.c new file +127 -0

+
+	devm_kfree(priv->dev, message);
+free_response:
+	devm_kfree(priv->dev, response);
+free_response_msg:
+	devm_kfree(priv->dev, response_msg);
+
+	return ret;
+}
+
+static const struct fpga_manager_ops mpfs_auto_update_ops = {
+	.state = mpfs_auto_update_state,
+	.write_init = mpfs_auto_update_write_init,
+	.write = mpfs_auto_update_write,
+	.write_complete = mpfs_auto_update_write_complete,
+};
+
+static int mpfs_auto_update_run(struct device *dev)
+{
+	struct fpga_manager *mgr;
+	struct fpga_image_info *info;
+	int ret;
+
+	mgr = fpga_mgr_get(dev);
+	info = fpga_image_info_alloc(dev);
+
+	info->firmware_name = devm_kstrdup(dev, "mpfs_bitstream.spi", GFP_KERNEL);
+
+	ret = fpga_mgr_lock(mgr);
+	if (ret)
+		goto free_info;
+
+	ret = fpga_mgr_load(mgr, info);
+	if (ret) {
+		dev_err(dev, "Failed to write the bitstream\n");
+		goto unlock_mgr;
+	}
+
+unlock_mgr:
+	fpga_mgr_unlock(mgr);
+free_info:
+	fpga_image_info_free(info);
+	fpga_mgr_put(mgr);
+
+	return ret;
+}
+
+static ssize_t mpfs_auto_update_exec(struct file *file, const char __user *data, size_t count,
+				     loff_t *ppos)
+{
+	int ret;
+
+	ret = mpfs_auto_update_run(mpfs_auto_update_debug_dev);
+	if (ret)
+		dev_err_probe(mpfs_auto_update_debug_dev, ret, "Auto Update failed");
+
+	return count;
+}
+
+static const struct file_operations mpfs_auto_update_fops = {
+	.owner = THIS_MODULE,
+	.open = simple_open,
+	.write = mpfs_auto_update_exec
+};
+
+static int mpfs_auto_update_debugfs_setup(struct mpfs_auto_update_priv *priv)
+{
+	priv->debugfs_dir = debugfs_create_dir("fpga", NULL);
+
+	if(IS_ERR(priv->debugfs_dir))
+		return PTR_ERR(priv->debugfs_dir);
+
+	debugfs_create_file("microchip_exec_update", 0200, priv->debugfs_dir, NULL,
+			    &mpfs_auto_update_fops);
+
+	return 0;
+}
+
+static int mpfs_auto_update_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mpfs_auto_update_priv *priv;
+	struct fpga_manager *mgr;
+	enum fpga_mgr_states state;
+	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);
+
+	mgr = devm_fpga_mgr_register(dev, "Microchip MPFS Auto Update FPGA Manager",
+				     &mpfs_auto_update_ops, priv);
+	if (IS_ERR(mgr))
+		return dev_err_probe(dev, PTR_ERR(mgr), "Could not register FPGA manager.\n");
+
+	state = mpfs_auto_update_state(mgr);
+	if (state != FPGA_MGR_STATE_OPERATING)
+		return -EIO;
+
+	ret = mpfs_auto_update_debugfs_setup(priv);
+	if (ret && ret != -ENODEV)
+		return ret;
+
+	mpfs_auto_update_debug_dev = priv->dev;
+
+	return 0;
+}
+
+static struct platform_driver mpfs_auto_update_driver = {
+	.driver = {
+		.name = "mpfs-auto-update",
+	},
+	.probe = mpfs_auto_update_probe,
+};
+module_platform_driver(mpfs_auto_update_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Conor Dooley <[email protected]>");
+MODULE_DESCRIPTION("PolarFire SoC Auto Update FPGA reprogramming");

Signature · 1 line

2.39.1

Quoted 5 lines · Conor Dooley

From: Conor Dooley <[email protected]>

Add support for Auto Update reprogramming of the FPGA fabric on PolarFire SoC.

drivers/fpga/microchip-auto-update.c line 119

Quoted 9 lines

Signed-off-by Conor Dooley <[email protected]>

---
 drivers/fpga/Kconfig                 |   9 +
 drivers/fpga/Makefile                |   1 +
 drivers/fpga/microchip-auto-update.c | 495 +++++++++++++++++++++++++++
 3 files changed, 505 insertions(+)
 create mode 100644 drivers/fpga/microchip-auto-update.c

drivers/fpga/microchip-auto-update.c new file +2 -0

+	/*
+	 * To verify that Auto Update is possible, the "Query Security Service

Why verify the possibility here, if Auto Update is not possible, the Auto Update device should not be populated, is it?

drivers/fpga/microchip-auto-update.c line 247

Quoted 7 lines

drivers/fpga/microchip-auto-update.c new file +7 -0

+	/*
+	 * 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);

I'm wondering why the image address should be written for every updating? Seems it is only related to the flash size, not related to the to-be-programmed bitstream.

drivers/fpga/microchip-auto-update.c line 333

Quoted 5 lines

drivers/fpga/microchip-auto-update.c new file +5 -0

+	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;

If verification failed, what happens to the written flash? Auto roll back?

Quoted 29 lines

drivers/fpga/microchip-auto-update.c new file +29 -0

+	}
+
+	dev_info(priv->dev, "Verification of Upgrade Image passed!\n");
+//	/*
+//	 * If the validation has passed, initiate Auto Update.
+//	 * 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.
+//	 * Once we attempt Auto Update either:
+//	 * - it passes and the board reboots
+//	 * - it fails and the board reboots to recover
+//	 * - the system controller aborts and we exit "gracefully".
+//	 *   "gracefully" since there is no interrupt produced & it just times
+//	 *   out.
+//	 */
+//	response->resp_msg = response_msg;
+//	response->resp_size = AUTO_UPDATE_PROGRAM_RESP_SIZE;
+//	message->cmd_opcode = AUTO_UPDATE_PROGRAM_CMD_OPCODE;
+//	message->cmd_data_size = AUTO_UPDATE_PROGRAM_CMD_DATA_SIZE;
+//	message->response = response;
+//	message->cmd_data = AUTO_UPDATE_PROGRAM_CMD_DATA;
+//	message->mbox_offset = 0; //field is ignored
+//	message->resp_offset = AUTO_UPDATE_DEFAULT_RESP_OFFSET;
+//
+//	dev_info(priv->dev, "Running Auto Update command\n");
+//	ret = mpfs_blocking_transaction(priv->sys_controller, message);
+//	if (ret && ret != -ETIMEDOUT)
+//		goto out;
+//

drivers/fpga/microchip-auto-update.c line 368

Quoted 6 lines

drivers/fpga/microchip-auto-update.c new file +6 -0

+//	/* *remove this for auto update*
+//	 * This return 0 is dead code. Either the Auto Update will fail, or it will pass
+//	 * & the FPGA will be rebooted in which case mpfs_blocking_transaction()
+//	 * will never return and Linux will die.
+//	 */
+//	return 0;

Why comment out this code block?

From: Conor Dooley <[email protected]>

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://patchwork.kernel.org/project/linux-riscv/list/?series=714160

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.

The other caveat here I guess is that this uses debugfs to trigger the write, as we do not yet have a userspace for this yet!

Cheers,
Conor.

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 [email protected]

CC [email protected]

CC [email protected]

CC [email protected]

Conor Dooley (6):
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: 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                          |   9 +
 drivers/fpga/Makefile                         |   1 +
 drivers/fpga/microchip-auto-update.c          | 495 ++++++++++++++++++
 drivers/soc/microchip/Kconfig                 |   1 +
 drivers/soc/microchip/mpfs-sys-controller.c   |  33 +-
 include/soc/microchip/mpfs.h                  |   2 +
 9 files changed, 586 insertions(+), 10 deletions(-)
 create mode 100644 drivers/fpga/microchip-auto-update.c

Signature · 1 line

2.39.1

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

Quoted 10 lines · Xu Yilun

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

A lack of interest in opening up the system controller to userspace! You're right in that the writing of the image can be done that way, and while I was testing I used the userspace bits of mtd along the way - but for validating that the image we are writing we rely on the system controller.
I'm really not interested in exposing the system controller's functionality, especially the bitstream manipulation parts, to userspace due to the risk of input validation bugs, so at least that side of things should remain in the kernel.
I suppose I could implement something custom in drivers/soc that does the validation only, and push the rest out to userspace. Just seemed fitting to do the whole lot in drivers/fpga.

Cheers,
Conor.

Quoted 11 lines · Conor Dooley

Quoted 10 lines · Xu Yilun

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

Quoted 12 lines

A lack of interest in opening up the system controller to userspace! You're right in that the writing of the image can be done that way, and while I was testing I used the userspace bits of mtd along the way - but for validating that the image we are writing we rely on the system controller.
I'm really not interested in exposing the system controller's functionality, especially the bitstream manipulation parts, to userspace due to the risk of input validation bugs, so at least that side of things should remain in the kernel.
I suppose I could implement something custom in drivers/soc that does the validation only, and push the rest out to userspace. Just seemed fitting to do the whole lot in drivers/fpga.

In case you haven't already looked at the new firmware-upload support in the firmware-loader, I'll give you some references here to see if it fit you needs. This would only support the write (not the read) but it would allow the controller to do validation on the write.

The is the cover letter which shows a usage example:
https://lore.kernel.org/lkml/[email protected]/

And this is a pointer to the latest documentation for it:
https://docs.kernel.org/driver-api/firmware/fw_upload.html

The only current user is: drivers/fpga/intel-m10-bmc-sec-update.c

Hey Russ,

Quoted 36 lines · Russ Weight

Quoted 11 lines · Conor Dooley

Quoted 10 lines · Xu Yilun

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

Quoted 12 lines

A lack of interest in opening up the system controller to userspace! You're right in that the writing of the image can be done that way, and while I was testing I used the userspace bits of mtd along the way - but for validating that the image we are writing we rely on the system controller.
I'm really not interested in exposing the system controller's functionality, especially the bitstream manipulation parts, to userspace due to the risk of input validation bugs, so at least that side of things should remain in the kernel.
I suppose I could implement something custom in drivers/soc that does the validation only, and push the rest out to userspace. Just seemed fitting to do the whole lot in drivers/fpga.

In case you haven't already looked at the new firmware-upload support in the firmware-loader, I'll give you some references here to see if it fit you needs. This would only support the write (not the read) but it would allow the controller to do validation on the write.

The is the cover letter which shows a usage example:
https://lore.kernel.org/lkml/[email protected]/

And this is a pointer to the latest documentation for it:
https://docs.kernel.org/driver-api/firmware/fw_upload.html

Quoted 1 line

The only current user is: drivers/fpga/intel-m10-bmc-sec-update.c

Sounds interesting, I shall go and take a look. Just quickly, when you say it wouldn't support the read, what exactly do you mean? The only read that I am really interested in doing is reading the first 1K of flash as I need to RMW it, but I don't think that that's what you mean.
Do you mean that I would not be able to dump the firmware using your fw_upload interface? If so, that's an acceptable constraint IMO.

Your interface also circumvents us (Microchip) defining yet another method for interacting with the FPGA, since from my nosing around, everyone seems to do something different.

Cheers,
Conor.

Quoted 39 lines · Conor Dooley

Hey Russ,

Quoted 36 lines · Russ Weight

Quoted 11 lines · Conor Dooley

Quoted 10 lines · Xu Yilun

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

Quoted 12 lines

A lack of interest in opening up the system controller to userspace! You're right in that the writing of the image can be done that way, and while I was testing I used the userspace bits of mtd along the way - but for validating that the image we are writing we rely on the system controller.
I'm really not interested in exposing the system controller's functionality, especially the bitstream manipulation parts, to userspace due to the risk of input validation bugs, so at least that side of things should remain in the kernel.
I suppose I could implement something custom in drivers/soc that does the validation only, and push the rest out to userspace. Just seemed fitting to do the whole lot in drivers/fpga.

In case you haven't already looked at the new firmware-upload support in the firmware-loader, I'll give you some references here to see if it fit you needs. This would only support the write (not the read) but it would allow the controller to do validation on the write.

The is the cover letter which shows a usage example:
https://lore.kernel.org/lkml/[email protected]/

And this is a pointer to the latest documentation for it:
https://docs.kernel.org/driver-api/firmware/fw_upload.html

Quoted 8 lines

Quoted 1 line

The only current user is: drivers/fpga/intel-m10-bmc-sec-update.c

Sounds interesting, I shall go and take a look. Just quickly, when you say it wouldn't support the read, what exactly do you mean? The only read that I am really interested in doing is reading the first 1K of flash as I need to RMW it, but I don't think that that's what you mean.
Do you mean that I would not be able to dump the firmware using your fw_upload interface? If so, that's an acceptable constraint IMO.

Yes - I mean that you couldn't dump the firmware image from userspace using the fw_upload interface. The sysfs interface allows you to read and write a temporary buffer, but once you "echo 0 > loading", there is no sysfs interface associated with the firmware-loader that would allow you to read the image from flash. Your controller actually does the writes, so RMW in that context is fine.

Quoted 47 lines · Russ Weight

Quoted 37 lines · Conor Dooley

Quoted 36 lines · Russ Weight

Quoted 11 lines · Conor Dooley

Quoted 10 lines · Xu Yilun

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

Quoted 12 lines

A lack of interest in opening up the system controller to userspace! You're right in that the writing of the image can be done that way, and while I was testing I used the userspace bits of mtd along the way - but for validating that the image we are writing we rely on the system controller.
I'm really not interested in exposing the system controller's functionality, especially the bitstream manipulation parts, to userspace due to the risk of input validation bugs, so at least that side of things should remain in the kernel.
I suppose I could implement something custom in drivers/soc that does the validation only, and push the rest out to userspace. Just seemed fitting to do the whole lot in drivers/fpga.

In case you haven't already looked at the new firmware-upload support in the firmware-loader, I'll give you some references here to see if it fit you needs. This would only support the write (not the read) but it would allow the controller to do validation on the write.

The is the cover letter which shows a usage example:
https://lore.kernel.org/lkml/[email protected]/

And this is a pointer to the latest documentation for it:
https://docs.kernel.org/driver-api/firmware/fw_upload.html

Quoted 8 lines

Quoted 1 line

The only current user is: drivers/fpga/intel-m10-bmc-sec-update.c

Sounds interesting, I shall go and take a look. Just quickly, when you say it wouldn't support the read, what exactly do you mean? The only read that I am really interested in doing is reading the first 1K of flash as I need to RMW it, but I don't think that that's what you mean.
Do you mean that I would not be able to dump the firmware using your fw_upload interface? If so, that's an acceptable constraint IMO.

Quoted 6 lines

Yes - I mean that you couldn't dump the firmware image from userspace using the fw_upload interface. The sysfs interface allows you to read and write a temporary buffer, but once you "echo 0 > loading", there is no sysfs interface associated with the firmware-loader that would allow you to read the image from flash. Your controller actually does the writes, so RMW in that context is fine.

Ahh cool. I don't really care about dumping the firmware via such a mechanism, so that sounds good to me.
I'll check out your approach, the immediate thought is that it sounds suitable to my use case, so thanks!

Hey Russ,

Quoted 53 lines · Conor Dooley

Quoted 46 lines · Russ Weight

Quoted 37 lines · Conor Dooley

Quoted 36 lines · Russ Weight

Quoted 11 lines · Conor Dooley

Quoted 10 lines · Xu Yilun

Quoted 3 lines · Conor Dooley

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.

I haven't fully checked the patches yet, just some quick comments:

Since this feature is just to R/W the flash, and would not affect the runtime FPGA region, I don't think an FPGA manager is actually needed. Why not just use the MTD uAPI? There is a set of exsiting MTD uAPI & MTD tool if I remember correctly.

Quoted 12 lines

A lack of interest in opening up the system controller to userspace! You're right in that the writing of the image can be done that way, and while I was testing I used the userspace bits of mtd along the way - but for validating that the image we are writing we rely on the system controller.
I'm really not interested in exposing the system controller's functionality, especially the bitstream manipulation parts, to userspace due to the risk of input validation bugs, so at least that side of things should remain in the kernel.
I suppose I could implement something custom in drivers/soc that does the validation only, and push the rest out to userspace. Just seemed fitting to do the whole lot in drivers/fpga.

In case you haven't already looked at the new firmware-upload support in the firmware-loader, I'll give you some references here to see if it fit you needs. This would only support the write (not the read) but it would allow the controller to do validation on the write.

The is the cover letter which shows a usage example:
https://lore.kernel.org/lkml/[email protected]/

And this is a pointer to the latest documentation for it:
https://docs.kernel.org/driver-api/firmware/fw_upload.html

Quoted 8 lines

Quoted 1 line

The only current user is: drivers/fpga/intel-m10-bmc-sec-update.c

Sounds interesting, I shall go and take a look. Just quickly, when you say it wouldn't support the read, what exactly do you mean? The only read that I am really interested in doing is reading the first 1K of flash as I need to RMW it, but I don't think that that's what you mean.
Do you mean that I would not be able to dump the firmware using your fw_upload interface? If so, that's an acceptable constraint IMO.

Quoted 6 lines

Yes - I mean that you couldn't dump the firmware image from userspace using the fw_upload interface. The sysfs interface allows you to read and write a temporary buffer, but once you "echo 0 > loading", there is no sysfs interface associated with the firmware-loader that would allow you to read the image from flash. Your controller actually does the writes, so RMW in that context is fine.

Quoted 4 lines

Ahh cool. I don't really care about dumping the firmware via such a mechanism, so that sounds good to me.
I'll check out your approach, the immediate thought is that it sounds suitable to my use case, so thanks!

Taken me a while to get around to it, but thanks for your suggestion. Looks like it is suitable for what I am trying to do, so in the middle of working on another version of this using fw_upload.
The enum return codes from write are a little clumsy, but oh well, could be worse I suppose.

Just one thing I noted (although I rarely pay much attention to/rely on the driver-api docs when recent drivers exist as usable examples) is that the docs for this stuff is a wee bit out of date due to some API changes.
In the code example in this document:
https://docs.kernel.org/driver-api/firmware/fw_upload.html
firmware_upload_register() has fewer arguments than it does when you look at the signature of the function in the documentation right below it.

Cheers,
Conor.