[RFC] FPGA configuration as MTD using Device Tree

[Ulf Samuelsson]

Den 2020-09-14 kl. 15:45, skrev Rob Westfall:
> Great idea Ulf.
> 
> We (Xerox Corp) load the FPGAs in uBoot because they have the PCIe
> interface "hardware" and Linux comes up much easier if the PCIe
> hardware exists and is operational on boot instead of attempting to
> add it it later when Linux is up and you have to do a hot plug
> install.
> 
> If we have FPGAs that don't have PCIe hardware, then we load them from
> Linux after the board is booted.
> 
> The FPGA images are loaded from a network server by fetching the file
> using TFTP instead of a SPI device which adds cost and complexity to
> the hardware design. They are then load into the FPGA using a serial
> bitblt process.
> 
> Yes, it does slow down the boot by a couple of seconds, but life is
> all about trade offs, and for us this is a good one.
> 

Which FPGAs are You using?
We are using Cyclone 10, so that is what my driver supports.


BR
Ulf

> Rob Westfall
> Xerox Corporation
> 
> On Mon, Sep 14, 2020 at 7:49 AM Michal Simek <monstr at monstr.eu> wrote:
>>
>> Hi,
>>
>> On 07. 09. 20 19:03, Ulf Samuelsson wrote:
>>> Hi,
>>> The FPGA support in u-boot looks a bit old-fashioned to me.
>>> I would like to have device-tree support and would
>>> like comments on my approach.
>>
>> Definitely there is a space for improvement.
>> In connection to DT - we should likely create fpga DM class for it.
>>
>>>
>>>
>>> ====================================================================
>>> BACKGROUND
>>> Need to support loading 2 x Cyclone-10 LP FPGAs using Passive Serial.
>>> Raw binary files (RBF) are stored in boot flash, and
>>> u-boot will load both FPGAs before booting the OS.
>>> The OS should be able to update the FPGAs as well.
>>> The FPGAs must be independently configurable.
>>>
>>> Hardwarewise, I have an SPI bus with 4 chip selects.
>>> SPI MOSI, SCK, CS2 and CS3 are connected to the synchronous serial bus
>>> of the FPGA (DATA0, DCLK, the FPGA1.nCS0 and the FPGA2.nCS0)
>>>
>>> Intel normally connect FPGA nCS0 to ground but I connect this to the SPI
>>> CS. The advantage is that I can have several FPGAs which are programmed
>>> independent to each other.
>>>
>>> The FPGAs require three other signals (nCONFIG, nSTATUS and CONF_DONE).
>>> Each FPGA have their own set of those signals.
>>> ====================================================================
>>>
>>> I have not found device-tree support for FPGAs in u-boot.
>>> Since the FPGAs are connected to the SPI, I thought adding them as MTD
>>> devices would result in a nice interface.
>>>
>>> ====================================================================
>>> Example Device tree connected to a bit-bang SPI driver supporting
>>> multiple chip select.
>>>
>>> The MTD configuration supplies
>>> * Name of the FPGA (fpga property)
>>> * The size of the configuration data
>>> * Sideband signals for starting and checking configuration.
>>>
>>> &soft_mcspi {
>>>      compatible = "mcspi-gpio";
>>>      pinctrl-names = "default";
>>>      pinctrl-0 = <&soft_mcspi1_pins>;
>>>      status = "okay";
>>>      gpio-sck  = <&gpio0 7 GPIO_ACTIVE_LOW>;
>>>      gpio-miso = <&gpio1 8 GPIO_ACTIVE_HIGH>;
>>>      gpio-mosi = <&gpio1 9 GPIO_ACTIVE_HIGH>;
>>>      cs-gpios =
>>>         <&gpio0 12 GPIO_ACTIVE_LOW>,
>>>         <&gpio0 13 GPIO_ACTIVE_LOW>,
>>>         <&gpio0 17 GPIO_ACTIVE_LOW>,
>>>         <&gpio0 16 GPIO_ACTIVE_LOW>;
>>>      num-chipselects = <4>;
>>>      #address-cells = <1>;
>>>      #size-cells = <0>;
>>>      ...
>>>      sspy-fpga-cfg at 3 {    /* Intel Cyclone 10, 10CL025 */
>>>          #address-cells = <1>;
>>>          #size-cells = <1>;
>>>          compatible = "intel,cyclone10";
>>>          reg = <3>; /* Chip select 0 */
>>>          spi-max-frequency = <1000000>;
>>>          fpga = "spyf";
>>>          config-size    = <718569>;
>>>          gpio-nconfig    = <&gpio3 21 GPIO_ACTIVE_HIGH>;
>>>          gpio-nstatus    = <&gpio3 17 GPIO_ACTIVE_HIGH>;
>>>          gpio-conf_done    = <&gpio0 18 GPIO_ACTIVE_HIGH>;
>>>          gpio-crc_error    = <&gpio2 18 GPIO_ACTIVE_HIGH>;
>>>      };
>>> };
>>> ====================================================================
>>>
>>> With a Cyclone 10 MTD driver, is would appear in the "mtd list" command
>>> and configuring the fpga would be done using
>>>
>>> $ mtd write.raw spyf <ram-addr>
>>>
>>> The driver would have to implement dummy read and erase commands.
>>>
>>> An alternative would be to add flags which would be tested by the mtd
>>> command which would block the read and erase if the mtd device is an
>>> FPGA or simply test for that in the mtd command.
>>>
>>> What would be best?
>>> ====================================================================
>>>
>>> The MTD driver would start configuration by toggling gpio-nconfig low
>>> and then wait for gpio-nstatus to go high.
>>>
>>> If OK, it would call the spi_xfer routine for the parent spi slave
>>> (soft-mcspi)
>>>
>>> When the spi write returns, the FPGA MTD driver would await the
>>> CONF_DONE signal before returning.
>>>
>>> ====================================================================
>>>
>>> What do you guys think of such an approach?
>>
>> You are writing that fpga should be loaded before OS. You likely have
>> any reason for it but I think that make sense to take a look at it from
>> different angle.
>> You have 4 fpgas and when you load all of them in u-boot you are slowing
>> down boot.
>> Anyway I think that make sense to take a look at Linux first.
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/fpga
>>
>> I see 4 spi based drivers where I expect none is using MTD layer for
>> programming. You will find out dt binding for these devices and the same
>> binding should be used also in u-boot.
>>
>> Thanks,
>> Michal
>>
>> --
>> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
>> w: www.monstr.eu p: +42-0-721842854
>> Maintainer of Linux kernel - Xilinx Microblaze
>> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
>> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
>>
>>
>>