User interface test verification failures part 8

MANAGING THE WAITREQUEST BETTER TO AVOID STALLS

I did a lot of thinking about how to increase ruggedness, detect and properly recover from errors and manage the synchronization between the Hard Processor System (HPS dual ARM Linux system) and Field Programmable Gate Array (FPGA) sides of the chip. 

I have careful control over the waitrequest signals as they can stall the ARM processors if the application attempts a read or write and the signal is held high. I ensure that reads and writes over the bridge channel don't stall, but are just thrown away if we are not actively in a load or unload operation. 

I developed a method of returning the loop count in the status word on H2F LW channel 1 to let the application on HPS determine when to issue its read or write on H2F LW channel 2. 

All this was useful but to work the bridge to RAM must work first. 

CAN'T GET ANY BRIDGE BUT H2F LW OPERATING - DEFECTIVE ENVIRONMENT

The default for the System on a Chip is to have the HPS to FPGA Lightweight (H2F LW) bridge operational. The boot process for the HPS involves several steps - preloader, U-boot and then Linux bootup. The Terasic DE10-Nano environment and the toolchains from Altera/Intel come with Linux images, preloader and U-boot set up. 

They don't work right. In particular, the version shipped executes a command in U-boot called bridge_enable_handoff that should switch on the bridges we are using in our implementation. It terminates in the middle of running and never finishes turning on bridges. 

I thought I had overcome this by modifying it to skip the troublesome step in the command, but I have been absolutely unable to communicate over either the H2F (full width HPS to FPGA) or F2SDRAM (FPGA to SDRAM) bridges. They just won't work. 

While there are ways to kick on the H2F bridge, supposedly, while in Linux I couldn't get that to work. This is why I moved to using dual channels on the H2F LW bridge that is indeed operational. Sadly there is no easy way to replace the F2SDRAM bridge with another channel of H2F LW nor to directly move my image file from the Linux application to the last 1MB of physical SDRAM. 

Newer versions of U-boot for Cyclone V chips like mine changes that to a bridge_enable command. It might work better. The issue in the existing command (kind of a script actually) is that it branches to a routine called FPGA_SDRAM_APPLY that should be code copied into a fixed place in RAM which will configure and turn on the SDRAM bridge. When we branch it terminates, although giving an unhelpful return code of 0. Since it terminates, the remainder of the bridge_enable_handoff script isn't executed. This means no H2F bridge and of course no F2SDRAM bridge. 

It appears that I will need to create my own bootloader and U-boot just to get the darned bridges operational. More time spent fighting tools I am not skilled with, grabbing github repositories, compiling objects and building the parts that should have been black boxes for my use. Kind of like having to use lathes to form your own screws and nuts because the basic parts don't work. Aaarrrrrrgggggghhhhhh.