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

[Ulf Samuelsson]

Den 2023-02-21 kl. 12:19, skrev 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.
> 

You have a chip that is connected to an SPI bus using SCK, MOSI, nCS.
All the accesses are handled by the SPI controller driver outside the chip.


>>> 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.
> 
Exactly.

>> 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?
> 

There are the following methods I am aware of.

Active Serial - the FPGA is connected to an SPI flash, and loads this
	flash at reset. The CPU may or may not have the capability
	to program the flash, and then it is a normal MTD SPI Flash.
         The FPGA manager is not involved at all.

Passive Serial: The CPU SPI controller (or similar) is connected to
	pins on the FPGA and the only operation allowed is writing
	a fixed size to the FPGA.
	The user needs to know the size of the FPGA.
	The support for this in u-boot is very old-fashioned
	and new users get very little help.
	The user needs to write an SPI access routine as the SPI
	driver structure is incompatible with the FPGA manager
	code for passive serial.

Passive Parallel: The CPU loads the FPGA through the parallell bus.
	I doubt this is rarely used.

SOC:	The Intel/Altera and AMD/Xilinx have internal FPGA
	configuration interfaces. It is parallell.
	They are supported in the FPGA manager.

If the use of MTD is restricted to passive serial, this is OK with me.

>> 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.

These are the things I want to achieve.

* transfer data using the SPI driver and not use board files.
   For that, the FPGA should be under the SPI in the device tree.
* The size of the FPGA bitstream should be specified in the device tree.
* The FPGA should be accessed as a device, not an address.
* I want a list of the FPGAs connected in the system
* Minimize code.
* Simplify user interface.

 From the CPU point of view, the FPGA is just a RAM location on the SPI 
bus. It cannot be read, but it can be written.

This is not surprising, because it is simply a RAM.
It happens to have side effects, but that is not important.

The MTD subsystem supplies everything I need, and adding the driver
there is much less work than anything else.


> 
>> 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.

You cannot do partial reconfiguration on passive serial,
so it is only of interest if someone feels a need to expand
the MTD to other configuration methods.

Here is how an FPGA region looks in Linux.
If I understand things correctly, you have one memory region per
partial configuration. This looks quite a lot like partitions.

&fpga_region0 {
	#address-cells = <1>;
	#size-cells = <1>;

	firmware-name = "soc_system.rbf";
	fpga-bridges = <&fpga_bridge1>;
	ranges = <0x20000 0xff200000 0x100000>,
		 <0x0 0xc0000000 0x20000000>;

	gpio at 10040 {
		compatible = "altr,pio-1.0";
		reg = <0x10040 0x20>;
		altr,ngpio = <4>;
		#gpio-cells = <2>;
		clocks = <2>;
		gpio-controller;
	};

	onchip-memory {
		device_type = "memory";
		compatible = "altr,onchipmem-15.1";
		reg = <0x0 0x10000>;
	};
};

> 
>> 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.

I think that most board designers would select one method of configuring
the FPGA and they would only have either the FPGA or the MTD command 
set. I would be surprised if an engineer would be confused by this.


> 
>> 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