From: Russ Weight <russell.h.weight@intel.com>
To: Conor Dooley <conor@kernel.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
Xu Yilun <yilun.xu@intel.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 0/6] PolarFire SoC Auto Update Support
Date: Mon, 27 Feb 2023 14:42:30 -0800 [thread overview]
Message-ID: <cc6176cb-6792-ef11-f42a-d2d5b12d04b4@intel.com> (raw)
In-Reply-To: <Y/0r1aR6Wik2KYBd@spud>
On 2/27/23 14:16, Conor Dooley wrote:
> Hey Russ,
>
> On Mon, Feb 27, 2023 at 02:04:36PM -0800, Russ Weight wrote:
>> On 2/24/23 00:28, Conor Dooley wrote:
>>> On Fri, Feb 24, 2023 at 03:57:09PM +0800, Xu Yilun wrote:
>>>> On 2023-02-17 at 16:40:17 +0000, Conor Dooley wrote:
>>>>> 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.
>> 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/20220421212204.36052-1-russell.h.weight@intel.com/
>>
>> 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
> 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.
- Russ
>
> 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.
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-02-27 22:43 UTC|newest]
Thread overview: 18+ 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 ` [PATCH v1 1/6] soc: microchip: mpfs: add a prefix to rx_callback() 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-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 ` [PATCH v1 4/6] soc: microchip: mpfs: add auto-update subdev to system controller Conor Dooley
2023-02-17 16:40 ` [PATCH v1 5/6] fpga: add PolarFire SoC Auto Update support Conor Dooley
2023-03-04 16:38 ` Xu Yilun
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-24 7:57 ` [PATCH v1 0/6] PolarFire SoC Auto Update Support Xu Yilun
2023-02-24 8:28 ` Conor Dooley
2023-02-27 22:04 ` Russ Weight
2023-02-27 22:16 ` Conor Dooley
2023-02-27 22:42 ` Russ Weight [this message]
2023-02-27 22:56 ` Conor Dooley
2023-03-22 18:51 ` Conor Dooley
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=cc6176cb-6792-ef11-f42a-d2d5b12d04b4@intel.com \
--to=russell.h.weight@intel.com \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).