Honored Contributor
Honored ContributorIf i understand correctly: If you are using SoCEDS 13.1 or later the bridges are indeed initialized during boot. If your u-boot.scr contains the line "run bridge_enable_handoff;" the bridges should be initialised. (all bridges except for the fpga2sdram bridge, read on)
from: https://github.com/mathworks/altera-uboot/blob/master/doc/readme.socfpga --- Quote Start --- Usage of registers SYSMGR.ISWGRP.HANDOFF ---------------------------------------- Below are "Preloader to bootloader" handoff register and handoff value. These handoff value are provided by the tools (to Preloader) based on user Qsys design. As of now, these handoff registers mainly contain the info for bridges between the HPS and FPGA as below SYSMGR.ISWGRP.HANDOFF0 - hps axi bridges (RSTMGR.BRGMODRST) SYSMGR.ISWGRP.HANDOFF1 - hps l3 remap (L3REGS.REMAP) SYSMGR.ISWGRP.HANDOFF2 - hps peripheral controller to fpga bridge (SYSMGR.FPGAINTF.MODULE) SYSMGR.ISWGRP.HANDOFF3 - fpga to hps sdram bridge (SDR.CTRLGRP.FPGAPORTRST) SYSMGR.ISWGRP.HANDOFF4 - row bits handed off by Altera tools SYSMGR.ISWGRP.HANDOFF5 - unused SYSMGR.ISWGRP.HANDOFF6 - unused SYSMGR.ISWGRP.HANDOFF7 - unused If user reprogram the FPGA at U-Boot, all the HPS and FPGA bridges will be disabled. This is to prevent the noise generated during FPGA programming from going into HPS domain. But U-Boot will not enable back the bridge later as U-Boot won't have the knowledge about the bridges used by SOF file. User need to release the HPS and FPGA bridges based on their design. But if the SOF programmed by U-Boot matched with the design to generate Preloader handoff files, user can program the bridges at U-Boot based on these handoff value. It provide a faster mean for user to re-enable the bridges. These additional steps can be saved as series of action for FPGA programming (which as part of U-Boot environment too). --- As example, below are steps if U-Boot programming the FPGA with the same design that used to generate Preloader handoff. > fatload mmc 0:1 $fpgadata my_design.rbf > fpga load 0 $fpgadata $filesize > run bridge_enable_handoff where bridge_enable_handoff will execute below steps > mw $fpgaintf $fpgaintf_handoff > go $fpga2sdram_apply > mw $fpga2sdram $fpga2sdram_handoff > mw $axibridge $axibridge_handoff > mw $l3remap $l3remap_handoff > md $fpgaintf > md $fpga2sdram > md $axibridge * For your info, below U-Boot environment are referring to particular address - "fpgaintf" - SYSMGR.FPGAINTF.MODULE - "fpga2sdram" - SDR.CTRLGRP.FPGAPORTRST - "axibridge" - RSTMGR.BRGMODRST - "l3remap" - L3REGS.REMAP --- Quote End --- also usefull: https://www.altera.com/support/support-resources/knowledge-base/embedded/2016/how-and-when-can-i-enable-the-fpga2sdram-bridge-on-cyclone-v-soc.html?utm_source=altera&utm_medium=newsletter&utm_campaign=facts&utm_content=na_how_can_i_enable_ki_15_08_2016 However, I just realise I also have a design where the waitrequest signal is always high. If somebody has a fix for this, that would be helpful EDIT: you, my friend are a lifesaver. thanks to your waitrequestremark i was able to debug something that has been troubling me for weeks! you will most likely find this topic very handy http://www.alteraforum.com/forum/showthread.php?t=51200 a small remark on what is mentioned in this topic; I ran :setenv fpga2sdram_handoff 0x311;
saveenv
run bridge_enable_handoff;
