User interface test verification part 28

STILL HUNTING FOR THE PROBLEM

I began to dig through the binary objects that were generated by my failed U-boot make process and one that worked successfully, hoping to find a clue as to the problem Looking at the header of the object provides a few bits of information, such as a fixed validation word, version, flags, length of the program in 32 bit words, checksum of the program, the entry point to begin execution, and some areas used during execution.

Two variations between the good and bad preloader objects I noticed. First, the entry point to begin executing the preloader was x0007EA00 for the good code and xF000E320 for the failing code. Second, the program length for the bad code was 3A2C while the good code had a length of 2540. 

The way that the boot process works in the Cyclone V processor at a cold reset is to execute some flash code that fetches the preloader and executes it. The chip has 64KB of onboard RAM initially mapped to the high 64KB address for the processor - 0xFFFF0000 to 0xFFFFFFFF - where the preloader will be stored.  Of that space, the top 4K is reserved as the stack and buffer area, leaving 60KB for the preloader to fit, minus a bit for CRC, header and other fields. 

The good object has a length of x2540 32 bit words, which is 9,536 decimal. Since there are four bytes in a 32 bit word, this corresponds to a size of 38,144 bytes. The failing object has a length of x3A2C words, which is 14,892 decimal. Converting to bytes, that is 59,568, stored starting at xFFFF0050 and running to xFFFFE900 which even with the four byte CRC will just fit in the space. I am assuming that the minimized device tree blob (DTB) is included in the object. If not, then there is definitely not enough room for the DTB to fit adjacent to the preloader code. 

Understanding the entry point took more work. This is the address that the boot rom code will branch to once the preloader is loaded into the upper 4K space - the onchip RAM. Neither of these values is in the range of xFFFF0050 to xFFFFF000 where the code is placed. However, the technical reference manual for the Cyclone V chip indicates that when the ROM passes control to the preloader it has mirrored the onchip RAM to address 0. Thus, the 64KB of on chip RAM is accessible at both 0xFFFF0000-0xFFFFFFF and 0x00000000-0x0000FFFF which is still not consistent with those entry point addresses. 

Nothing in the memory map is at address 0x0007EA00 which is the start point of the working preloader. The range from 0x00010000 to 0x00100000 is marked as unused. If the only anomaly was the 0xF000E320 start address I would assume the flaw was in the process of building the image and setting the entry point address. However, with an address on the properly working preloader to also appear invalid, there is something here that doesn't make sense that I must resolve before doing more debugging.