[RFC] FPGA configuration as MTD using Device Tree

Michal Simek monstr at monstr.eu
Mon Sep 14 13:49:40 CEST 2020


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





More information about the U-Boot mailing list