Hi there,
I am seeking help in getting the F2S bridge up and running in the ‘right’ way.
I have seen in the hwlibs that there is a call, alt_bridge_init(), that can be used to do the right things using an assembly coded call. I have tried this and get a seg fault when the function is called.
I have moderate success by setting the registers appropriately, but occasionally get a system freeze, as the literature suggests will happen if the SDRAM is being accessed when these registers are set.
I have also tried setting registers in uboot late_init and in the boot arguments as well as adding the bridge to the device tree. When I added the bridge to the device tree and set up the handoff register in uboot(mw 0xffd0808c 0x3fff) it seemed to pull the device out of reset, but would freeze when the FPGA tried doing a DMA access unless we manually set the apply bit with devmem after boot (ie. devmem 0xffc2505c 8 0xa). Occasionally when we issue that devmem command we get a freeze, likely depending on if the SDRAM is being accessed by something at the time of the call.
In all these permutations I can often pull the F2S bridge out of reset (ie 0xFFC25080 is 0x3FFF) but the appycfg bit is not set (mw 0xFFC2505C 0xA) and if we do not set this register before doing a DMA access from the FPGA we get a kernel panic/freeze.
I see in the uboot driver that there is a method called socfpga_sdram_apply_static_cfg()(in misc_gen5.c) that appears it may set this register, but then when the kernel loads it seems to need to be set again, and the kernel driver (altera-fpga2sdram.c) does not appear to call this (or a similar) function.
I’ve tried setting registers as suggested in this thread, but still have issues once I get into the kernel in that the bridge is still in reset as evidenced by 0xFFC25080 then being 0x00000000 once I boot into the kernel. : FPGA to SDRAM - Cyclone V - Can write but cannot read - #3 by jakewong1992
Any ideas how to get this sorted out? We have had decent success pulling the bridge out of reset using two devmem calls once the kernel has booted for a while (ie 10 seconds) but that is not an optimal way to solve this, and some of the time we will run into issues.
Thanks,