Drivers/FPGA/DFL - Intel PAC N3000 missing modules select

[hwspeedy]

When adding the Intel PAC N3000 Nios interface a lot of modules that it depend on did not get selected.

UIO_DFL, MFD_INTEL_M10_BMC_CORE, MFD_INTEL_M10_BMC_SPI, SENSORS_INTEL_M10_BMC_HWMON, SPI_ALTERA, FPGA_DFL_FME, FPGA_DFL_FME_MGR, FPGA_DFL_FME_REGION, FPGA_DFL_FME_BRIDGE, FPGA_DFL_AFU, FPGA_DFL_PCI, ALTERA_FREEZE_BRIDGE, FPGA_M10_BMC_SEC_UPDATE, ALTERA_PR_IP_CORE, FPGA_MGR_ALTERA_CVP, FPGA_MGR_ALTERA_PS_SPI

[pcolberg]

Thanks @hwspeedy for your contribution! Your patch appears to be based on [RFC,4/6] ethernet: m10-retimer: add support for retimers on Intel MAX 10 BMC, which was later resubmitted as [RESEND PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC. I am not familiar with the history of the patch to explain why it was not included upstream.

For some background on the methodology, we don't submit to the master branch of this repository, which is the latest unmodified upstream commit upon which our development branch, fpga-ofs-dev is based (currently v6.7-rc1). Contributions are usually submitted to the fpga-ofs-dev-*-lts branch, where * is the latest supported upstream LTS version. From there, changes are synced to the fpga-ofs-dev branch by the linux-dfl maintainers, and eventually sent upstream. Please see the Linux DFL wiki for details on the branches.

As noted above, I am not familiar with the details yet, but maybe you could start by detailing your particular use case. Which functionality is working for you using the latest commit in fpga-ofs-dev-6.1-lts, and which isn't?

[pcolberg]

select should not be used to express dependencies in general since

select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over.

So then one might ask why not add these dependencies using depends on? If you take a look at dfl-n3000-nios.c, note how its minimal dependencies, FPGA_DFL and REGMAP, provide symbols used by the module, e.g., __dfl_driver_register() (through module_dfl_driver()) and regmap_read(), respectively. With only these dependencies selected, the dfl-n3000-nios module should load successfully since its symbols are satisfied. The dependencies you specified above may be useful to exploit the full functionality of the driver, but they are not needed to load the driver.

[hwspeedy]

Thank you very much for your feedback.

Here are my 5 cents to DFL/OPAE and what I think need to happen for OFS success.

State of OFS - DFL/OPAE.
DFL contains a bunch of modules and almost no-one understands it.
Partial reconfiguration (PR) is a messy business – keeping part of the FPGA running while stalling another part and changing that. Isolation bridges for freezing the registers towards the running part, ensuring that the running part do not use the part that is being changed and the other way around, when loading the new part.
Why do you have to partition in special way – that is known only by the FPGA manufacture – but it has to do with chains used to configure the FPGA. For Arria 10 FPGA it is keep it slim and wide. The schemes are different for Xilinx chips – more like Stratix. The PR needs to be compiled for exactly what is running – loading something else is a crash?
So that is why the FPGA loading is validating - that could be Kernel or BMC. When a FPGA part is running it would be nice to could verify who made this part and if it is valid.
A simple way – upload known good image, another way is to check public/private keys. Security is important both for data centers, companies and consumers and the implementations need maturity - open source is quite good at that.
But all of this does not make entirely sense to most kernel maintainers/users – its ugly hardware solutions mostly used because the PCIe interface, embedded CPU or memory in FPGA needs to continue running while we update or replace a function.

So DFL and OPAE is trying to address this situation – but it is also seams messy.
Looking at the linux-fpga patchworks board - it seams Redhat as maintainer mostly gave up and I see why.

What is this? How does it benefit Linux? Where is going? Is it really open source?

My experience
I have a couple of Intel FPGA cards and installs them in a machine. Nothing works – no drivers.
Hacking the kernel and adding the Intel PAC n3000 card and finding the OPAE in the OFS gives a little life but no flashing LED yet.
Now you need to debug the entire DFL and Intel PAC n3000 private to discover lots of missing modules. Then add these – more life and mostly running as root – only a retimer module is missing.

Trying to get it to work as an user on the PC – Trouble again – PHY are accessed trough the kernel debug interface on the regmaps – Nice new feature by the way. But this leaves the driver incomplete and probably why the PAC n3000V is not working at 10G instead of the 25G, when the FPGA is made for 10G but the retimers are still 25G.

When we look at the FPGA and OFS to setup the retimers you end up needing a missing BMC source and FPGA source. But as OFS says on the webpage - you can get this package by contacting Intel.

FAE manager at Arrow was not able to get this package.
I need it to change the messy retimer thing with SPI bridge in both directions along with removing, what I believe is a CVE security problem – The fast Core Cache IP, but still have the BMC with Powerup seq, temp, overheating protection, FPGA loading, etc.

Can you get the package consisting of BMC controller RTL+FW+qsf and FPGA RTL bridge part for me?

Back to the open source idea, which has bought the world the Linux we know.

So Intel wants to be in the kernel that runs all data centers and seams to be contributing to open source – but where are the Xilinx PAC/NAC cards?

My 5 cents:

1. DFL needs to be more user friendly and more complete, clear in the direction it is heading.
2. DFL should embrace FW/FPGA developers of functions with a nice platform – the community effort made by AMD and Intel will pay back – There is a long way to reduce Cuda – OFS? Community?
3. DFL needs to have lots of Intel and AMD FPGA cards – not just the PAC/NAC cards also a couple of other examples to enable the community.
4. DFL should not be for data centers only – it should be for all developers of other FPGA products – like PicoEVB, Aller A7, etc.
5. DFL should use standards already made in the Linux kernel – eg. use .dtb binary blobs in the FPGA instead of just a PR loading chain.
6. DFL loading and security should be open sources so that all developers can reuse the same framework and add more solutions.
7. DFL matters - if the same hardware can be different drivers - which is the case with FPGA solutions PAC/NAC or just a PCIe FPGA card - DFL could be the answer?

If the above succeeds so does Intel and AMD FPGA and we get more FPGA developers in the world.

Please share you comments and also let me know if I can get the above package, thanx.