[PATCH 3/4] mtd/fpga: add fpga directory to mtd (with Cyclone 10)

[Michael Walle]

Am 2023-02-21 11:42, schrieb Ulf Samuelsson:
> Den 2023-02-21 kl. 10:08, skrev Michael Walle:
>>>> If it is right or wrong to use that as an MTD is a matter of 
>>>> opinion.
>>> I am still hoping the MTD maintainer would provide input here.
>> I might be missing something, but what is the reasoning here, to add 
>> this
>> to the mtd subsystem? One is saving space, but I agree with Marek, 
>> this
>> isn't a valid argument to just put any (unrelated) stuff into the MTD
>> subsystem.
>> 
>> Also, as Marek pointed out, there are many different 'programming'
>> solutions for CPLDs/FPGAs and most of them don't share anything with
>> MTD. You seem to be just focusing on the "passive serial" one.
> Yes, the passive serial is very different from the other ways of
> configuring an FPGA.
> 
> It is write only. You cannot read back the configuration and no
> partial reconfiguration.
> 
> You do not have to go through AXI/PCIe busses.
> 
> You access through an SPI device, but todays solution does not support
> using the SPI driver.

I can't follow you here.

>> Now, I saw you mentioned that
>> 
>>   | the current passive serial solutions does not use the existing SPI
>>   | drivers.
>> 
>> What do you mean with SPI drivers? SPI flash drivers or SPI controller
>> drivers? Does the "passive serial solution" expose an SPI bus and you
>> can access the SPI flash on it in a generic way? Then the solution
>> should be to write a SPI (controller) driver, the flash should then
>> be automatically be detected.
> 
> The proposed solution is similar to an SPI flash driver.
> 
> The FPGA bitstream is typically stored in the CPU boot flash.
> 
> The CPU reads the bitstream and does an SPI transfer to the FPGA.
> 
> The FPGA is not connected to any flash memory.

Ah I missed that. So you don't want to program the SPI flash behind
the FPGA, but the FPGA directly. You are loading a bitstream from
somewhere and configure the FPGA. Using a SPI like interface, i.e.
it is write only as it lacks the DO.

> The FPGA chip exposes (in SPI terms) SCK, nCS and MOSI, but not MISO
> so you cannot read back anything.

it should read "This FPGA chip". I expect there are much more variants
how to configure an FPGA. Would these also use your proposed solution?

> The driver will return an empty block on read.
> 
> The SPI transfer to configure the FPGA is doing
> 
> * toggle a GPIO signal (nCONFIG)
> 
> * Do an SPI write (using the SPI controller driver)
> 
> * After the SPI transfer complete, you check the status of some GPIO
> (nSTATUS etc.).
> 
> This is all hidden from the MTD.
> 
> What the MTD subsystem sees is a "write-only memory" that has to be
> written with exactly 'n' bytes.

MTD is mainly around erasable blocks, although there are some exotic
things like mtdram. I fail to see how this would apply to your FPGA.

> The additional features of MTD simplifies the user interaction by
> exposing a device and
> providing info on the device.

Which would that be? What are the features of MTD which you need
here? You've mentioned MTD partitions, but I'm not sure these really
apply to partial reconfigurations. I know that Linux has a different
device tree binding for it. So making u-boot use mtd partitions (if
thats possible at all) and not the linux bindings means they'll
diverge, which is something we want to avoid.

> The only difference the MTD subsystem would see is
> that there is a new subdirectory "fpga" with drivers
> and the Kconfig + Makefile changes to support the directory.
> Otherwise it plugs right in.

 From a user point of view this is really confusing. Why would
you sometimes configure an fpga with the mtd command and sometimes
with the fpga command depening whether it is using this passive
programming thingy.

> The current solutions for passive serial cannot use the SPI controller 
> driver
> so each board implements SPI controller inside their 'board' files.
> You cannot reuse this code in practice, so every one that wants to
> have passive serial has to write their own SPI access routines.

Sorry, I didn't follow this too closely. Do you have some pointers?

-michael

> ====
> The FPGA manager does not support device tree, and I will not
> be able to spend time on introducing this, as Marek advices.
> 
> Best Regards
> Ulf Samuelsson
> 
>> 
>> -michael