User interface test verification part 5

GETTING THE SDRAM BRIDGE OPERATIONAL BUT NOW H2F NEEDS HELP

When configuring the HPS using the Platform Designer tool, a ton of data is entered about the memory - timings and how the address bits are assigned across banks, chips, rows and columns. In another spot one requests the F2SDRAM bridge that allows the FPGA to read and write the RAM using the level 4 interface of the Hard Processor System (HPS) ARM based computer. 

I guess I naively believed all that information was carried over so that the bridge merely needed to be activated in order to issue requests to it. What I face is a long list of registers with values that must be correct and zero guidance on what is needed to move from the Platform Designer entered information to a working bridge. 

control registers for the F2SDRAM from the HPS side

I spit out the current contents of all of those registers as I initialized things. As far as I can tell the values are good but my attempts to access SDRAM were still failing. Just in case it was an issue with writing to the RAM, I flipped around to use the unload process which first reads from RAM via F2SDRAM bridge and then makes that data available to read from the H2F bridge. Same type of issue, stalled. 

Digging through the thousands of pages relevant to the bridges I find all sorts of registers and bits that might be related to the problem. There are bits in registers to force the use of secure masters or slaves only. There are fields that specify how deep the write FIFO will get before an output is executed over the bridge. Essentially several hundred fields related to the bridges.

I worked out the method to turn on the bridge allowing my FPGA logic to write to the SDRAM. It involves making some settings in control registers during initialization of my application. Now that works but my H2F bridge, the link that my application uses to transfer blocks of four 1130 words between Linux and FPGA sides, is also not working. The wait request signal is on immediately which blocks the FPGA side from sending anything. Worse, when I attempt to read or write from the Linux side, we hang and have to power cycle. Same basic problem as the F2SDRAM bridge issue, but now for H2F instead.

I dug through mountains of documents, various posts by people I discovered through searches, reviewed code and the best I could come up with was to flip on bit 3 of a particular register called l3remap. I gained accessibility by memory mapping this but whenever I attempted to write to it I generated a bus error terminating the application.

Other places have mentioned the provided command - bridge_enable_handoff - run during U-boot as the system begins to come up.  That attempts to branch to an address that is labeled as something to enable F2SDRAM but the code terminates blocking the rest of the scripted commands from executing. Thus, crappy quality code which blocks the enabling of the bridges which otherwise would have presumably been done automatically.

I entered U-boot and used a command editenv to edit bridge_enable_handoff  but even after I issue a saveenv to save the changes to nonvolatile memory, the next time we power up it is back to the same old defective code. 

So many things to debug. So damn many things that have zero, zip, nada, nothing to do with my project, my code, my logic. Just a giant burn of time and energy to use the capabilities of these products as they are described.