New ContributorWe have an Arria 10 board with bad traces between the DDR memory and the hard memory controller for the PS. The PL has additional DDR memory not connected to the PS that works fine. Does a workaround exist that allows us to route the DDR memory connected to the PL and use it for Linux on the PS?
Occasional Contributorhi,
Are you specifically asking to do the following?
HPS CPU (ARM) <--AXI Bridge--> FPGA Interconnect <---> DDR Controller (in FPGA fabric) <---> DDR chips (physically connected to FPGA pins)
If so, it could be possible to get the HPS CPU to access the DDR connected to the PL. We need to have some RTL magic/implementation to expose the memory controller interface in the FPGA as a slave memory device and then, configure the HPS to use it as the system memory. There lies many challenges that I can't confirm. We may have coherency issues (IO Cache coherency but the SCU anyways does not support IO Cache coherency from other initiators or DMA agents). And also performance issues like higher memory latencies. Since the memory interface is routed through the HPS to FPGA bridge, HPS running an OS like Linux which requires MMU and Cache enablement may run into coherency issues. UBOOT SPL or bare-metal running on HPS could run without enabling DCache/ICache. Having said that, if it is just the HPS CPU cores which relies on the SCU, this could be possible as the memory coherency between the cores are maintained by SCU and the cache managment may be fine. You will also have to ensure that, no other agents in FPGA or DMA devices writes to the DDR/memory (This could be solvable easily by SW intervention, SW cache coherency management). From a SW standpoint, you have to modify the UBOOT/Linux device tree to use the memory mapped addresses at the HPS to FPGA bridge. The FPGA has to be configured before starting the HPS.
*Add-on on SW, the UBOOT SPL SDRAM device driver or module may need to be altered/hacked to bypasss the default drivers which runs the hard memory controller in A10. Else it will throw an error during boot-up if there are any. If no errors, you can ignore this. You need to ensure the PL/FPGA memory controller is up and in user-mode in the FSBL UBOOT SPL before it starts to load the secondary boot images to DDR.
Memory map changes required for the arch\arm\boot\dts\intel\socfpga\socfpga_arria10_socdk.dtsi
#include "socfpga_arria10.dtsi"
/ {
model = "Altera SOCFPGA Arria 10";
compatible = "altr,socfpga-arria10-socdk", "altr,socfpga-arria10", "altr,socfpga";
aliases {
ethernet0 = &gmac0;
serial0 = &uart1;
};
chosen {
bootargs = "earlyprintk";
stdout-path = "serial0:115200n8";
};
memory@0 {
name = "memory";
device_type = "memory";
reg = <0xC0000000 0x40000000>; /* 1GB <- Changed from 0x0 to 0xC0000000. The base address of the memory should be based on the FPGA fabric design where the slave memory device to DDR is at. And, you should use the SOC2FPGA bridge interface. */
};
This is the tentative reply to your question. A readily available workaround does not exist today as it may requires some POC or exploration by your team.
We will consult more experts and if we have anything extra or corrections, we will reply later to this discussion thread.
Thanks
New ContributorThank you for the tentative reply. Based on this link that we found after my initial post (https://www.intel.com/content/www/us/en/docs/programmable/683461/current/hps-external-memory-interface-connections-in.html), the HPS memory interface is fixed to specific I/O banks. We are under the impression that my original question is not possible because the FPGA memory is not connected to the required I/O banks.
Occasional ContributorThe link you posted is the ideal way to enable the external memory to HPS using the hard memory controller. However, you asked if the HPS could use the other external memory connected to the FPGA fabric. That is technically possible but not the recommended way. Hope this makes sense.
