If the use of MTD is restricted to passive serial, this is OK with me.
Yeah, but that is not how upstream things work. You need to also think
of any other use cases.
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.
So to me it sounds like you actually want a "altera passive spi"
driver which uses the spi subsytem (and not the MTD layer).
* The size of the FPGA bitstream should be specified in the device
tree.
I'm not experienced with the fpga bindings, but maybe they have
something like that. Or you can deduce it from the compatible string.
What's your usecase here? It sounds like a u-boot limitation to me (if
you don't use files).
* 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.
agreed.
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.
Can't follow you here. How can the FPGA be a location in RAM if it's
behind an SPI bus? Thats not how SPI works.
The MTD subsystem supplies everything I need, and adding the driver
there is much less work than anything else.
Yeah but just because it has everything you need, doesn't mean
it is a good fit for your use case.
Again. I think you want to have a passive serial driver which
represents your fpga as a device which then can be configured.
There is already an empty (sigh) FPGA_UCLASS. That should probably
be extended. Ideally, this should be probed by the linux fpga
bindings.
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.
So.. what MTD features are then used by your approach?
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@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.
As a user I'd expect one command for any similar devices. As a board
integrator, the fpga would be loaded by the board file anyway if needed
during u-boot/bootup.
Just my two cents as a spi-nor reviewer in linux. You'd have to
convince the u-boot maintainers. There is already an FPGA subsystem
in linux so I doubt your approach would make it into linux.
-michael
