Marek Vasut wrote:
Please always CC the list. Do NOT top-post.
You do realize I was replying to an email you sent to my personal address and you didn't even send to the list?
What is your goal here ?
To put things in context, my larger goal is to update u-boot from the old version altera integrates into Quartus to a reasonably recent version of mainline u-boot being provided by the distro we are using. My naive hope was the new version of u-boot would work at least as well as the old altera one. Experience so far: infinite reboot loop due to broken cadence driver:
https://lists.denx.de/pipermail/u-boot/2017-December/313470.html
No response except from author responsible for breaking the driver insisting his changes be kept.
And now: DMA peripheral requests for FPGA are non-functional due to mainline u-boot ignoring the reset_config.h in the handoff files generated by Quartus. Apparently, the mainline uboot position is that it is inappropriate to provide any more support for initializing the resets than providing the ability to write to memory addresses with "mw".
Going back to my initial question -- what is your usecase and your aim here ? Usually you use FPGA manager in Linux to load the FPGA.
But you can really just do mw to the correct address or create a U-Boot script , so this command is not really needed, is it ?
Ok, I am running Linux on the board. I don't see how it would help to load the FPGA from Linux rather than u-boot. The dma peripheral requests would still be just as disabled. The only difference would be that I would be forced to deassert the resets from Linux rather than u-boot, which I guess would make it not your problem? In principle, the fpga manager provides a write_complete hook that the socfpga fpga manager could use to deassert resets (perhaps based on device tree settings), but looking at my 4.1.33 fpga/ socfpga.c it doesn't seem to.