This subsystem will configure an FPGA attached to your host by sending it a bitstream you provide. You still have to use your FPGAs vendor tools to generate the bitstream.
One popular use case is for System-on-Chip (SoC) designs that pair a Processor System (PS) with Programmable Logic (PL); once the PS is running the kernel, the FPGA Manager can be used to program the PL fabric from kernel space.
FPGA Manager has another handy feature for FPGA images that implement new peripherals on buses like SPI, I2C, PCI, AXI, etc. These devices are not "discoverable" in the sense that they are capable of communicating to the kernel what driver must be loaded to support them. So in along with a bitstream, FPGA Manager accepts a device tree overlay which indicates to the kernel what drivers to load for the new resources implemented by the configured FPGA. This causes the kernel to probe the requisite drivers after the FPGA configuration has completed. The FPGA manager can also unload drivers for devices implemented in an FPGA that is being reconfigured.
Unfortunately, in LTS kernels 4.9 and 4.14, while SoC vendors include support for their own PL targets, the FPGA Manager subsystem was written as a singleton; once you've configured e.g, the PL, you can't configure additional peripheral FPGAs.
The FPGA Manager in K4.9 and K4.14 worked fine to fully manage a single FPGA through multiple configuration cycles through both the sysfs and the configfs interfaces.
On a system with multiple FPGAs, FPGA Manager would fully manage any one of them, as long as it was the first device it probed. The second probe would partially fail after creating nodes on sysfs, and a third probe would crash the kernel.
For that particular system, the upstream vendor hasn't rolled out K4.19 support yet. My initial impression of the FPGA Manager code in 4.19 is that this may be fixed (that an FPGA Manager looks to be allocated per driver instead of one global singleton) but I haven't backported it for testing yet.
I think the interfaces FPGA Manager are well designed, its seems to be adequately expressive for even exotic uses, but I would love to see the implementation mature a bit.
I know the term but I can’t quite understand how to interpret it in this specific context. Does it mean you can only program an FPGA once? Only one FPGA? One object per bus?
One popular use case is for System-on-Chip (SoC) designs that pair a Processor System (PS) with Programmable Logic (PL); once the PS is running the kernel, the FPGA Manager can be used to program the PL fabric from kernel space.
FPGA Manager has another handy feature for FPGA images that implement new peripherals on buses like SPI, I2C, PCI, AXI, etc. These devices are not "discoverable" in the sense that they are capable of communicating to the kernel what driver must be loaded to support them. So in along with a bitstream, FPGA Manager accepts a device tree overlay which indicates to the kernel what drivers to load for the new resources implemented by the configured FPGA. This causes the kernel to probe the requisite drivers after the FPGA configuration has completed. The FPGA manager can also unload drivers for devices implemented in an FPGA that is being reconfigured.
Unfortunately, in LTS kernels 4.9 and 4.14, while SoC vendors include support for their own PL targets, the FPGA Manager subsystem was written as a singleton; once you've configured e.g, the PL, you can't configure additional peripheral FPGAs.