User interface test verification part 3

SELECTION TOGGLE BUTTON NOW CHANGES STATE APPROPRIATELY

I did find the problem with the routine to open the filename. I had forgotten to append the absolute file path to the directory where the cartridge images are held. That corrected, it did open the file, map it into memory and then proceed to the next step which is the load routine. 

It was at this point that execution went awry and the Linux system hung. This is understandable as the load routine is sending the 521,304 words of 16 bits each down to the FPGA which wrote them to the last physical 1MB of RAM. I however had not yet informed Linux to avoid that last block. This means that Linux was using the upper megabyte at the same time that my FPGA was writing things in it. 

The process of reserving the upper RAM is a boot time parameter I set up from the U-boot loader that precedes the loading of the Linux kernel. I can enter U-Boot, set a command that gives Linux only 1023MB of RAM and then save it for every subsequent boot by issuing saveenv. I performed this step, verified that it was permanent and then went back to testing with my design. 

I see during the loading of Linux that it rejected the 1023MB memory and downgraded to 768M for RAM. This is pretty wasteful but I still have enough memory for Linux to handle this work so I won't be digging into the cause and possible solutions. A message mentioned having a HIMEM enabled Linux kernel, which may be a way to overcome this limit.

The system is hanging - it acts as if the H2F highspeed bridge is not operational. I was successfully using the lightweight H2FLW to send and receive commands, but this is the first attempt to use the 128 bit wide H2F pathway. 

What should be occurring here is a loop which reads through the recently opened SD card file with the virtual cartridge selected, writing four 16 bit words at a time of the 521, 304 total in an image. This will be 130,326 iterations through the loop. Each time we store the four words we read from the memory mapped SD card file into the location for the H2F bridge. 

The FPGA logic I wrote is listening to the H2F bridge and will read each block of four words as it is sent from the Linux side. It then writes those four words out to the last 1MB of RAM on the board. To ensure that we don't over run the FPGA side since the RAM is slower than our loop, we have a hold off signal that the FPGA sets that holds the Linux side bridge from accepting any more blocks. I suspect that my H2F bridge sees the hold off signal and waits perpetually. 

I plan to debug the load and unload next, so I substituted a fake set of load and unload modules that simply return with a success indication. Given that, I completed my testing and was certain that pushing the Selection Toggle pushbutton did flip back and forth between selected and simply highlighted status.