From: Conor Dooley <conor@kernel.org>
To: Xu Yilun <yilun.xu@intel.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
Daire McNamara <daire.mcnamara@microchip.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Moritz Fischer <mdf@kernel.org>, Wu Hao <hao.wu@intel.com>,
Tom Rix <trix@redhat.com>,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org
Subject: Re: [PATCH v1 5/6] fpga: add PolarFire SoC Auto Update support
Date: Sat, 4 Mar 2023 17:01:53 +0000 [thread overview]
Message-ID: <59750d1a-de31-4e89-b8a9-d97ef66aa5f6@spud> (raw)
In-Reply-To: <ZANz6NLgSja2pfYa@yilunxu-OptiPlex-7050>
[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]
On Sun, Mar 05, 2023 at 12:38:00AM +0800, Xu Yilun wrote:
> On 2023-02-17 at 16:40:22 +0000, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Add support for Auto Update reprogramming of the FPGA fabric on
> > PolarFire SoC.
> >
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > 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
> > + /*
> > + * 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?
Good point, I'll check this in probe instead.
> > + /*
> > + * 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.
Yah, it doesn't need to be. I'll check it against the expected value &
only write it if needed.
> > + 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?
Nope, that should be left up to userspace to decide what to do. I've got
some improvement to do to the mailbox driver that sits behind
mpfs_blocking_transaction() that I thought was not allowed by the
mailbox framework, so should be able to report better errors for this in
the future.
> > + }
> > +
> > + 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;
> > +//
> > +// /* *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?
It was meant to be removed & must have snuck back in a rebase. This is my
test code that initiates the update from Linux, rather than at reboot.
I'm going to take a look at Russ' driver before I submit another version
of this (and the underlying mailbox stuff also needs changes).
Thanks for taking a look,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Xu Yilun <yilun.xu@intel.com>
Cc: Conor Dooley <conor.dooley@microchip.com>,
Daire McNamara <daire.mcnamara@microchip.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Moritz Fischer <mdf@kernel.org>, Wu Hao <hao.wu@intel.com>,
Tom Rix <trix@redhat.com>,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org
Subject: Re: [PATCH v1 5/6] fpga: add PolarFire SoC Auto Update support
Date: Sat, 4 Mar 2023 17:01:53 +0000 [thread overview]
Message-ID: <59750d1a-de31-4e89-b8a9-d97ef66aa5f6@spud> (raw)
In-Reply-To: <ZANz6NLgSja2pfYa@yilunxu-OptiPlex-7050>
[-- Attachment #1.1: Type: text/plain, Size: 4239 bytes --]
On Sun, Mar 05, 2023 at 12:38:00AM +0800, Xu Yilun wrote:
> On 2023-02-17 at 16:40:22 +0000, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Add support for Auto Update reprogramming of the FPGA fabric on
> > PolarFire SoC.
> >
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > 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
> > + /*
> > + * 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?
Good point, I'll check this in probe instead.
> > + /*
> > + * 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.
Yah, it doesn't need to be. I'll check it against the expected value &
only write it if needed.
> > + 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?
Nope, that should be left up to userspace to decide what to do. I've got
some improvement to do to the mailbox driver that sits behind
mpfs_blocking_transaction() that I thought was not allowed by the
mailbox framework, so should be able to report better errors for this in
the future.
> > + }
> > +
> > + 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;
> > +//
> > +// /* *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?
It was meant to be removed & must have snuck back in a rebase. This is my
test code that initiates the update from Linux, rather than at reboot.
I'm going to take a look at Russ' driver before I submit another version
of this (and the underlying mailbox stuff also needs changes).
Thanks for taking a look,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-03-04 17:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 16:40 [PATCH v1 0/6] PolarFire SoC Auto Update Support Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-02-17 16:40 ` [PATCH v1 1/6] soc: microchip: mpfs: add a prefix to rx_callback() Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-02-17 16:40 ` [PATCH v1 2/6] dt-bindings: soc: microchip: add a property for system controller flash Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-02-26 18:01 ` Rob Herring
2023-02-26 18:01 ` Rob Herring
2023-02-17 16:40 ` [PATCH v1 3/6] soc: microchip: mpfs: enable access to the system controller's flash Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-02-17 16:40 ` [PATCH v1 4/6] soc: microchip: mpfs: add auto-update subdev to system controller Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-02-17 16:40 ` [PATCH v1 5/6] fpga: add PolarFire SoC Auto Update support Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-03-04 16:38 ` Xu Yilun
2023-03-04 16:38 ` Xu Yilun
2023-03-04 17:01 ` Conor Dooley [this message]
2023-03-04 17:01 ` Conor Dooley
2023-02-17 16:40 ` [PATCH v1 6/6] riscv: dts: microchip: add the mpfs' system controller qspi & associated flash Conor Dooley
2023-02-17 16:40 ` Conor Dooley
2023-02-24 7:57 ` [PATCH v1 0/6] PolarFire SoC Auto Update Support Xu Yilun
2023-02-24 7:57 ` Xu Yilun
2023-02-24 8:28 ` Conor Dooley
2023-02-24 8:28 ` Conor Dooley
2023-02-27 22:04 ` Russ Weight
2023-02-27 22:04 ` Russ Weight
2023-02-27 22:16 ` Conor Dooley
2023-02-27 22:16 ` Conor Dooley
2023-02-27 22:42 ` Russ Weight
2023-02-27 22:42 ` Russ Weight
2023-02-27 22:56 ` Conor Dooley
2023-02-27 22:56 ` Conor Dooley
2023-03-22 18:51 ` Conor Dooley
2023-03-22 18:51 ` Conor Dooley
2023-03-30 0:11 ` Russ Weight
2023-03-30 0:11 ` Russ Weight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59750d1a-de31-4e89-b8a9-d97ef66aa5f6@spud \
--to=conor@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=daire.mcnamara@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=hao.wu@intel.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mdf@kernel.org \
--cc=robh+dt@kernel.org \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.