Snags getting the FPGA image loaded and my cross compile producing wrong ARM architecture

CROSS COMPILE FROM UBUNTU UNDER VMWARE ON LAPTOP TO DE10-NANO BOARD

I have set up the gcc cross compilation environment to create binary files to run on ARM processors under Linux. On my windows laptop, I have Vmware installed and an Ubuntu Linux image set up. In that Linux environment I run the various Quartus tools and the cross compilation tasks.

The Gnu cross compile environment was installed to support the ARM instruction set, versions of the standard library modules that are generated for the ARM processors and all the appropriate parts to run under Linux. My makefile specifies the cross compile location automatically invoking the gcc and ld programs for the target environment. 

SOFT VERSUS HARD FLOATING POINT PROCESSORS

ARM has evolved over the years from its original Acorn and there are variants that do not have floating point instructions implemented. For those, a software environment will be invoked to simulate the floating point operations. ARM uses the terms soft and hard to delineate processors that use the software simulation assist from those that have the floating point instructions in silicon. 

The cross compile environment obviously varies for these two variants. The makefile points at the relevant files, in the case of Ubuntu those are at /usr/gcc-arm-linux-gnueabi for soft and /usr/gcc-arm-linux-gnueabihf for the hard version. My makefile points there which should cause the gcc and ld to be executed from /usr/gcc-arm-linux-gnueabihf/bin in order to produce the correct outputs. 

WILL HAVE TO FIGURE OUT HOW TO GET THIS WORKING PROPERLY

I issue the make command and produce binary files as output but when I interrogate the format using the readelf command, it identifies it as a soft floating point format, not the hard format I intend. This causes the binary to be rejected when I try to execute it on the Linux on my DE10-Nano board because that is a hard floating point system. 

I suspect there is some path variable or other issue that is confounding the toolchain because it is not producing the intended flavor of ARM binary. That is a task to address later today.

LINUX WON'T START WHEN I SUBSTITUTE MY FPGA LOAD FILE

As part of the startup of the Linux image on the SD Card on my DE10-Nano board, it copies a file de10-nano.rbf into the FPGA to configure it with the logic to support connections such as the HDMI buffer running in FPGA for the Linux desktop to display on a monitor. I am using only a USB serial port connection in text mode, although there are alternatives using GUI I could activate over ethernet. Since I still have not set up a wifi to ethernet adapter to connect the board to my home network, I am restricted to USB UART connections. 

The straightforward method I attempted was to replace the current de10-nano.rbf file with my FPGA configuration file but under the same name. When my design was generated and compiled by Quartus, it created a file with a .sof suffix. A tool within Quartus converts this to a raw binary file format, .rbf, which is the file that I renamed to de10-nano.rbf. I expected this to load the FPGA side with my logic and then continue to boot up Linux so that I could log in and run my tests. 

Sadly, Linux failed to come up. I tried both the graphical desktop version that came with the DE10-Nano board and a so called console only version. Both fail, although in different ways. 

THE LONG AND WINDING ROAD I COULD GO DOWN

It appears that I have to regenerate the Linux and boot environment specific to my logic design, which is going to require quite a bit of study and experimentation to get this right. There appear to be preboot loader, Uboot, device tree and Linux generation requirements. 

THE SHORTCUT I TRIED INSTEAD

As an alternative, the configuration file for the FPGA can be loaded into flash on the board via the Quartus programming environment, after which I can set up the board slide switches to have it load the FPGA from the flash. I was assuming that Linux would boot up and as long as I renamed the FPGA configuration file that it would load (de10-nano.rbf) it would skip over loading FPGA and complete initialization. 

Sadly this went into a boot loop so the claims in Rocketboard.org that the script allows it to boot if the .rbf file is missing are out of date and incorrect. I am back to the long tedious process. Hopefully I can complete tests of functions that don't depend on my FPGA logic being installed, while I work on what I hope will not be a Sisyphean journey.