User interface test verification part 21

DIGGING THROUGH EVIDENCE TRAIL OF U-BOOT AND ATTEMPTED KERNEL LAUNCH

I captured the output of the preloader (SPL) and then U-boot on two different SD cards. The old, good one is a card that launches Linux successfully but does not properly initialize the bridges I need for my project. The new, bad one is the latest try to build a working U-boot. In this case I copied a prebuilt binary for those files, not the one that should be honed by the build process for my exact design configuation.

The new, bad version will come up to the U-Boot console but will not launch Linux. The last line I see is that it is launching the Linux kernel, then nothing at all happens. There are many hundreds of parameters for U-boot and many dozens of environmental variables you can set for U-boot, which makes an exhaustive search of every combination infeasible. I have tried adjusting anything that seems remotely associate with the problem, but to no avail.

PRELOADER BEHAVIOR COMPARISON

Here are the two preloader (SPL) outputs, first the old good card and then the new bad card. 

GOOD OLD
U-Boot SPL 2013.01.01 (Oct 12 2016 - 10:38:03)
BOARD : Altera SOCFPGA Cyclone V Board
CLOCK: EOSC1 clock 25000 KHz
CLOCK: EOSC2 clock 25000 KHz
CLOCK: F2S_SDR_REF clock 0 KHz
CLOCK: F2S_PER_REF clock 0 KHz
CLOCK: MPU clock 925 MHz
CLOCK: DDR clock 400 MHz
CLOCK: UART clock 100000 KHz
CLOCK: MMC clock 50000 KHz
CLOCK: QSPI clock 3613 KHz
RESET: COLD
INFO : Watchdog enabled
SDRAM: Initializing MMR registers
SDRAM: Calibrating PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
SDRAM: 1024 MiB
ALTERA DWMMC: 0

BAD NEW
U-Boot SPL 2017.11 (Apr 24 2018 - 11:02:05)
drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
drivers/ddr/altera/sequencer.c: Calibration complete
Trying to boot from MMC1

First off I have to state that there are different levels of information printed by the preloader depending on the hundreds of parameters set and even the version of the code, so that we can't expect an exact match. However, there is board information that the old version prints out including configuration details that is missing from the new version. Without that same level of output I can't be certain that the preloader correctly understands our board and has configured it properly.

I do see that it uses some awareness of the memory on the board as it is able to calibrate the memory and make it ready for read/write during U-boot and onwards. It is the only commonality I can see here. 

The preloader works from a stripped down device tree produced by the build process. It is created by stripped and manipulating the binary version of the device tree to remove superfluous entries (things that U-boot won't need during its operation) and to ensure that U-boot is able to manage the board correctly. Because this process of generating the stripped down device tree is hugely opaque and ill documented, there is no easy way to check that it has the proper board definitions in the new version. 

Even worse, I am using the version of the binary from the github repository not a version I built with make, so I am certain that it does NOT have any of my project specific requirements such as mux pin settings. When I try to build a version myself I can't get any response at all from the board, while at least the prebuilt version brings up U-boot. 

U-BOOT BEHAVIOR COMPARISON

Again we start with the old, good U-boot that will launch my Linux system. It does not prepare the bridges thus it is unusable for the project but otherwise seems to work. This is all prebuilt with nothing from my design involved. 

GOOD OLD
U-Boot 2013.01.01 (Oct 12 2016 - 10:40:34)

CPU   : Altera SOCFPGA Platform
BOARD : Altera SOCFPGA Cyclone V Board
I2C:   ready
DRAM:  1 GiB
MMC:   ALTERA DWMMC: 0
In:    serial
Out:   serial
Err:   serial
Skipped ethaddr assignment due to invalid EMAC address in EEPROM
Net:   mii0
Warning: failed to set MAC address

BAD NEW

U-Boot 2017.11 (Apr 24 2018 - 11:02:05 +0900)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   dwmmc0@ff704000: 0
In:    serial
Out:   serial
Err:   serial
Model: Terasic DE10-Nano
Net:
Error: ethernet@ff702000 address not set.
No ethernet found.

Here we see some board information that seems to align between the two versions. As I mentioned, the new version won't launch the same Linux kernel that my old version does successfully. 

UNKNOWN CONFIGURATON BY THE LOADER SOFTWARE

Somewhere in the execution of the two software programs - preloader and U-boot - the key settings are applied to the pin multiplexing and other configuration registers to make the board match the design I built with Platform Designer and Quartus. I don't know where this occurs and I can't check what is applied to the board. This makes it hard to modify an existing preloader/U-boot to match my design.

MY BASIC PROBLEM REMAINS

The most fundamental problem I am facing here is that regardless of which version of the U-boot/preloader code I downloaded and regardless of which cross compile tools I use, when I make the preloader + U-boot and try to boot the SD card, I don't see ANYTHING. No flickering of the board, no U-boot SPL header messages at all. It does not appear to be executing anything. Since I install the prebuilt version that came from github in the same way onto the SD card, and those prebuilt versions run, I have to conclude that it is something foul in the code being generated by make. 

I have followed dozens of different procedures and 'recipes'. I have used different code bases and tools. Regardless, the preloader just won't run. I think I have to attack this problem first and solve it, as when that is working then I have control over what I put into U-Boot and I will have all the design specific settings from my project included in the code.