New firmware-load case for the firmware subsystem?
From: Russ Weight
Date: Wed Aug 04 2021 - 20:23:33 EST
Hi Luis,
I have been working on a driver to allow updates to an Intel FPGA PCIe card.
In a recent email exchange, it was suggested that I investigate whether
this functionality could be provided in the existing firmware subsystem. I
have been looking at the firmware subsystem. I don't think there is much
overlap between what I need to do and what is already provided. I would
appreciate your thoughts on the following.
For background information, this is the email thread I referred to:
https://marc.info/?l=linux-fpga&m=162810644009070&w=2
and this is the last submission of the driver in it's current form:
https://marc.info/?l=linux-fpga&m=162742505425902&w=2
In a nutshell, these are features that I believe are not currently in the
the firmware subsystem.
(1) Updates don't take place during driver probe / initialization. The
updates need to be applied while the FPGA device is up and fully
functional. FPGA image updates and firmware updates are stored to FLASH
and do not take affect until the card is rebooted.
(2) Need an API to allow the user to initiate the update and specify
the image file. The images are signed/authenticated files that are
authenticated by the device using installed keys. Some image types
are expected to be provided by the end-user. For example, the image
file may contain a new Root Hash Entry for Partial Reconfigurations
(which are under control of the end-user).
(3) We have one update case that can take up to 45 minutes. In order to be
able to provide some sort of progress indication to the user, we would
like to do the update in the context of a kernel worker thread, with
progress status available through a user API.
I think I have the following options:
(1) Continue to develop an FPGA-specific image update driver
(2) Consider a more generic firmware update mechanism that others
may be able to use.
(3) Consider integrating this functionality into the existing firmware
subsystem.
Do you see any opportunity to share code? Do you think this functionality
would fit in the existing firmware subsystem?
Thanks,
- Russ