User interface test verification part 24

MORE TOOLCHAIN FUN AND  GAMES

I have six ways to make U-boot, three cross compiler chains and two versions of U-boot source. The older SOC_EDS (System on a Chip Embedded Design Suite), we will call A, a version of Gnu for Ubuntu for ARM chip cross compilation we term B, and a separately downloaded ARM GNU cross compilation chain as C to round out the ways that we can compile assemble and link code. The two source versions are the latest official U-Boot source plus some Altera and DE10 modified source I found on Github.

I tried the Ubuntu chain, setting up both of the source code directories to make with these tools. I did bump into a well know flaw where the device tree compiler DTC gets errors on duplicate definitions of a global variable YYLLOC but deleting one of them in the source is the workaround. I then found the GCC compiler complaining about a parameter passed to it, -march=armv5, which it didn't know how to support. 

My chip should be the armv7-a architecture level since they implemented Cortex A7 processors on the chip. The configuration process should have set this up to build for the A7 processors, I can see the settings in the related configuration files, but when it drops into the lib subdirectory to compile libraries it somehow lost the architecture setting and picked armV5. This could well be the reason that the code doesn't successfully execute to the point of issuing the welcome banner on the console. 

Apparently the two other toolchains do support armV5, issue no messages but build defective code. What this happens is the subject of forensic investigation. U-boot source consists of many hundreds of files and quite a few interlocked Makefiles, thus this is not trivial to debug. 

I attempted to set up a user gcc override, passing in the -march=armv7 parameter but then ran into some errors in the assembler with instructions that didn't match the architecture. Setting it as -march=armv7-a solved those problems. However, when it was time to link SPL, the preloader, it specified a file eabi_compat.o that is needed for certain toolchains (per the comments in its source code) but was not set up for this build. Toolchain B will not work with the official repository. 

I shifted to use the external toolchain C with the official repository, but overriding the -march=armv7-a parameter. This built with no error messages but once again the card won't boot on the DE10-Nano board. 

I did a quick test using chain A just to prove to myself that even with the -march=armv7-a flag, it will sit on the board doing absolutely nothing. In desperation I looked for another toolchain - the embedded Cortex compiler from ARM - which we will call toolchain D.  Absolutely the same results - no signs of life.