Battle with toolchain software part 14

ABSOLUTELY NO INDICATION OF LIFE FROM PRELOADER AND U-BOOT BECAUSE . . .

The configuration set up in the Altera opensource distribution of U-boot generates it to use flattened uImage tree (FIT) files rather than the separate kernel, U-boot and device tree blob files we used before. Without a proper FIT file the loader will do nothing - as it does supremely well in this case. 

At this point however I discovered that the recipes on Rocketboard.org and in the various repositories for the Terasic DE10-Nano board are not correct. They have me configure for the generic development board (socfpga_cyclone5_config) instead of the socfpga_de10_nano_config that relates to my board. I redid the build of the preloader and U-boot with the correct configuration and that gave me some signs of life.

U-BOOT BEGINS BUT DOESN'T CONTINUE TO RUN THE SCRIPT NOR BOOT LINUX

I was delighted. Preloader came up, initialized everything and then branched to U-boot. I got the proper messages consistent with prior successful boots except that it stopped at a prompt rather than trying to autoboot. This means that the problems are solely in the script and/or the environmental variables for U-boot. Both of these are easy to change.

I will use an old SD card to boot but stop autoboot, then list out all the environmental variables. In addition I will list out the contents of the working u-boot.scr script file. The only challenge I will have is that I must modify things to address the change from a 2017 version of U-boot to the current version I am working with. Since the documentation is sketchy and not set up to educate someone, it will take some poking into source code and experimentation. However, I hope to succeed incrementally.

INCREMENTAL PLAN FOR U-BOOT OPERATION

First I want to check that my commands to load the FPGA bitstream into the hardware will work, so I will manually issue them at the prompt. This is the first action we take before we start enabling bridges and before we try to load Linux.

Second I will work on the u-boot.scr script to make sure it issues its commands, first by manually proving them and then altering things until this executes when we start up. This is the key to the rest of the bootup sequence.

Third I will work on the changes I need to issue the modern bridge enable command instead of the broken bridge-enable-handoff version from 2017. This is key to being able to use the F2SDRAM and H2FLW bridges from my design. 

Last I will manually test the commands that must be issued to start the Linux bootup, get them configured in the proper environmental variables, manually trigger them once to see Linux come up and then verify I get an autoboot from powerup to login prompt for Linux.

CHANGES THAT HAD TO BE MADE

The environmental variables for the new U-boot does not have a bootcmd variable set. Instead it depends on the script file to execute a script that searches in order and boot from different device types. It also has no capability to fetch my FPGA bitstream file and load it as it should. 

I added some scripts to do what I wanted and tested them. I am now able to find and run the u-boot.scr file, which in turn correctly finds and loads the FPGA bitstream file. We also find the proper device tree blob file. 

REMAINING ISSUE IS COMPLETING THE KERNEL STARTUP

The commands work and begin to run the kernel initialization which starts to bring up Linux, however it stops partway through. I believe this is due to a change in the location in RAM where the old scripts stored the kernel image and device tree blob, compared to the higher location used by the new version of U-boot. I suspect that the kernel initialization is stepping on some of U-boot or vice versa because of the changed addresses. I will modify them and see what happens, but I am pleased with the steady progress.