User interface test verification part 26

ATTEMPTED TO RUN OFF FLATTENED IMAGE SUPPORT BUT MAKE PROCESS FAILS

My boot files are the traditional compressed Linux kernel and a device tree blob (DTB), not the flattened tree that combines them into a different structure. I thought that the boot might be failing because the preloader (SPL) was looking for the flattened image file and wanted to eliminate that code as a stab in the dark.

I changed the default configuration file to specify CONFIG_FIT=n which would turn off all the code for flattened images. When I then tried to make U-boot and the SPL, it failed trying to build all the DTBs for the various types of boards that use the Altera/Intel SOCFPGA chips. The first it tried, the Agilex N6100, failed with an error that it couldn't find binman in the DTB it was processing. Binman is used for trusted boot, which we are not using with the Terasic DE-10 Nano board, but is required for the Agilex one.

I don't know why the make process insists on building every DTB for every SOCFPGA chip when we are in fact doing a build for one specific board, but it does. It has a very very convoluted process of scripts, makefiles and other tools that result in the attempt to build all the DTBs. There is no method I can find to block it and the SOCFPGA section of U-boot apparently cannot successfully complete a Make if FIT is deselected. 

This represents the issue with the System on a Chip products and toolchains. You can skim along doing almost exactly the same as the reference/example projects, but once you step off that cliff edge you plummet to where you need to understand virtually everything about complex subjects just to move forward. I am forced to gain considerable expertise in U-boot, for example, both the actual code and the make process, just to get a working loader. Getting features of the SoC chip to work required diving very deep into the chip architecture, the toolchain and other topics. Essentially this is a pool with one step at 6" depth and the next step is 10,000 feet down requiring deep sea diving gear. Nothing in between. 

DIGGING INTO OTHER DETAILS IN CONFIGURATION FILES

There are hundreds of configuration settings, any one of which might be the cause of the failure to boot up SPL. I will first look into every setting that explicitly mentions SPL, dig into the hundreds of source code files and work out what it does. As one example, the start address for SPL is set to 0x08000000 in the configuration file. Not sure why that is the number and more importantly what number it should be. Will report on what my research uncovers and whether I finally (or ever, it seems like) find the smoking gun.