Battle with toolchain software part 11

RESOLVING SD CARD IMAGE

I first worked out the right incantation to have the Linux build understand which processor I am using. That added the ARCH_CFLAG entry to add -march=armv7-a for the compilations. Everything built so i was on to the next step, which is creating the root filesystem.

Now, it strikes me as sketchy to build the root filesystem with all its libraries and binaries without it being closely synchronized to the kernel I just generated. However, I began working on it. Oddly, it is set up with a Makefile that depends on a independent gcc instance rather than the gcc that is part of the Soc EDS toolsuite. I couldn't trick it into building with the software on my Ubuntu system. 

Building root filesystems for embedded Linux systems is apparently done using one of several tools designed for the purpose, including Yocto and Buildroot. One might imagine that if a Linux kernel needs to be recompiled in order to handle changes made to the SoC, all one need do is recompile the kernel from the source of the known image, drop it in and go. Instead, apparently, it is expected that you have to create an entirely new Linux system on your own. Amazing to me that one doesn't have the 'golden' Linux image to change minimally. 

I therefore had to download and install the Linaro ARM toolchain just for this step, then build the root filesystem for my embedded Linux system. Sounds easy? Well, Linaro no longer hosts this. Clues led me to ARM who hosted some versions but not the one that supported Linux with hard floating point, thus to a secondary spot where only one release was available. The configuration for building the root filesystem with buildroot requires me to enter choices from a narrow range of GCC versions, kernel head file versions and so forth, not of which are available with the toolchains and downloads now available.

Next up as I configured the buildroot configuration, the recipe describes running a make command to configure the busybox, which is the set up startup scripts and actions that the new Linux system will execute on startup. However, error messages and no sign of busybox anywhere in the downloaded files. 

My level of confidence continues to sink into the abyss given all the mismatched versions, discrepancies and deviations. This seems like a fruitless journey that is certain to lead to a bad end.

THROWING AWAY THE RECIPES AND STRIKING OUT ON MY OWN

The difficulty with taking this approach is that it forces me to deeply and fully understand every bit of what has to be in place for the embedded Linux to run properly. Way further than I do now and frankly much more than I really want to have to deal with. 

I have a few Linux images on SD Cards that are self consistent, they just won't boot up correctly with my FPGA programming and give me the H2FLW and F2SDRAM bridges in operational status. There are a number of items on the card but not every part should need to be regenerated or built from scratch. 

• Linux kernal
• Root file system
• Startup scripts and commands
• Packages and libraries
• Preloader
• U-boot. 
• U-boot variables and commands
• U-boot start script
• FPGA bitstream
• Device tree blob
• Flattened tree compilation of kernel and DTB possible

The kernel, root file system, startup, packages and libraries should NOT need to be recompiled. There is no new device driver or new function that needs to be added. 

The device tree blob is what links the components on the DE10-Nano board with possible Linux drivers. That is updated because of the changes I made to the System on a Chip (SOC) design using Platform Designer. 

The FPGA bitstream contains my new FPGA design so that is changed. There may be some changes to the U-boot start script and its variables and commands to support my new files. 

I have learned that the preloader and U-boot themselves must be updated as you make changes to the SoC design. My F2SDRAM and H2F bridges did not come up properly because the preloader and U-boot weren't correct on the existing SD card images. 

Therefore I should only need to build the preloader and U-boot, then tweak the variables, commands and U-boot start script. I also generated a new device tree blob representing my design. Nothing else should have to change. 

To test this theory, I scrubbed away all the attempts to build kernels and root file systems, giving me a clean environment to work on building U-boot and preloader. I had previously created the device tree blob and FPGA bitstream as part of the generation of my design. Once I have the two systems generated, I will copy an existing SD card image, replace just the FPGA bitstream and device tree blob before I update the preloader and U-boot. 

Fingers crossed, this will give me a running Linux system, with working H2FLW and F2SDRAM bridges, on a board that has my FPGA logic loaded. That is the work for the rest of today.