Wednesday, August 30, 2023

User interface test verification part 27

THE EVIDENCE IS PILING UP THAT THE DEVICE TREE FOR U-BOOT IS BAD

The U-boot archives that get downloaded in order to generate a new version of U-boot to reflect the settings you want in your System on a Chip (SOC) such as the Cyclone V in my Terasic DE10-Nano board, generate a stripped down device tree that is used by the preloader and by U-boot to know how to execute on the ARM processors, how to get to and initialize the DRAM memory and how to communicate over the serial port. 

Somebody, usually the maker of the board, provides the base device tree source for the board and the default configuration settings to allow the make process to build a working preloader and U-boot. Over time as the tools that manipulate the device trees evolve in newer versions of U-boot, one would hope that somebody was responsible for verifying that they still work properly. That may not be correct.

I have two archives I am working with. One is the official U-boot code stream and another is a version of U-boot that was modified by Altera, the original designer of the Cyclone V SOC chip. Neither of these create an image that boots up on my board, not even to issuing the first messages on the console. 

I grabbed the two device tree blobs that were created for the preloader, converted them back to device tree source using the device tree compiler dtc, and looked closely at them. Neither of them seems complete enough to allow the preloader to work. 

DTS FILE FROM OFFICIAL U-BOOT ARCHIVE AFTER MAKE OF PRELOADER

One issues only two commands to build a preloader and U-boot. First, run the vendor provided default configuration file. Second, run a make all. The file socfpga_de10_nano_defconfig is the file that is run to set up for a U-boot that should run on the Terasic board. After the make all is run, it has created a folder SPL that holds the preloader. In that, a number of transformations are run on the files from the archive in order to produce u-boot-spl.dtb a device tree blob for the preloader. 

Here is what was produced when I ran this through dtc to recreate a device tree source. 

/dts-v1/;

/memreserve/ 0x0000000000000000 0x0000000000001000;
/ {
#address-cells = <0x1>;
#size-cells = <0x1>;
model = "Terasic DE10-Nano";
compatible = "altr,socfpga-cyclone5", "altr,socfpga";

aliases {
serial0 = "/soc/serial0@ffc02000";
};

soc {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "simple-bus";
device_type = "soc";
ranges;

clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
};

l2-cache@fffef000 {
compatible = "arm,pl310-cache";
reg = <0xfffef000 0x1000>;
cache-unified;
cache-level = <0x2>;
arm,tag-latency = <0x1 0x1 0x1>;
arm,data-latency = <0x2 0x1 0x1>;
prefetch-data = <0x1>;
prefetch-instr = <0x1>;
arm,shared-override;
arm,double-linefill = <0x1>;
arm,double-linefill-incr = <0x0>;
arm,double-linefill-wrap = <0x1>;
arm,prefetch-drop = <0x0>;
arm,prefetch-offset = <0x7>;
phandle = <0x1>;
};

dwmmc0@ff704000 {
compatible = "altr,socfpga-dw-mshc";
reg = <0xff704000 0x1000>;
fifo-depth = <0x400>;
#address-cells = <0x1>;
#size-cells = <0x0>;
resets = <0x6 0x36>;
status = "okay";
broken-cd;
bus-width = <0x4>;
cap-mmc-highspeed;
cap-sd-highspeed;
};

rstmgr@ffd05000 {
#reset-cells = <0x1>;
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
altr,modrst-offset = <0x10>;
phandle = <0x6>;
};

sdr@ffc20000 {
compatible = "altr,sdr-ctl", "syscon";
reg = <0xffc20000 0x6000>;
resets = <0x6 0x3d>;
phandle = <0x2f>;
};

sysmgr@ffd08000 {
compatible = "altr,sys-mgr", "syscon";
reg = <0xffd08000 0x4000>;
cpu1-start-addr = <0xffd080c4>;
phandle = <0x25>;
};

serial0@ffc02000 {
compatible = "snps,dw-apb-uart";
reg = <0xffc02000 0x1000>;
reg-shift = <0x2>;
reg-io-width = <0x4>;
dmas = <0x32 0x1c 0x32 0x1d>;
dma-names = "tx", "rx";
resets = <0x6 0x30>;
clock-frequency = <0x5f5e100>;
};
};

memory {
device_type = "memory";
reg = <0x0 0x40000000>;
};

chosen {
bootargs = "console=ttyS0,115200";
stdout-path = "serial0:115200n8";
};
};

DTS FILE FROM ALTERA U-BOOT ARCHIVE AFTER MAKE OF PRELOADER

The resulting device tree source from the Altera version of U-boot is:

/dts-v1/;

/memreserve/ 0x0000000000000000 0x0000000000001000;
/ {
#address-cells = <0x1>;
#size-cells = <0x1>;
model = "Terasic DE10-Nano";
compatible = "altr,socfpga-cyclone5", "altr,socfpga";

chosen {
bootargs = "console=ttyS0,115200";
};

soc {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "simple-bus";
device_type = "soc";
ranges;
u-boot,dm-pre-reloc;

dwmmc0@ff704000 {
compatible = "altr,socfpga-dw-mshc";
reg = <0xff704000 0x1000>;
interrupts = <0x0 0x8b 0x4>;
fifo-depth = <0x400>;
#address-cells = <0x1>;
#size-cells = <0x0>;
num-slots = <0x1>;
broken-cd;
bus-width = <0x4>;
cap-mmc-highspeed;
cap-sd-highspeed;
drvsel = <0x3>;
smplsel = <0x0>;
status = "okay";
u-boot,dm-pre-reloc;
};
};
};

This file does not even have an entry for memory, which fully explains why nothing takes place when I boot this preloader. It can't find DRAM in order to initialize it, copy in its code and continue execution. It refers to ttyS0 for the console but does not contain any entries defining that. At least the top file has an alias for serial0 to an entry for the serial port where the messages should be issued. 

This appear to me as fragments of what would be needed to make the preloader actually function. I need to investigate a few things in order to figure this out and then find a way to correct it. It would have been helpful to have documentation that tells you what the parameters must be in the device tree for the preloader, but that doesn't exist. 

FIGURING OUT WHAT IS MISSING AND HOW TO FIX IT COMES NEXT

Somehow I need to see a working device tree source for this board. It may be that the transformation tools in U-boot have evolved and no longer process it correctly but that it did work at some time in the past with an earlier version. Too, I might be able to locate and dump the device tree blob from within the working preloader I have from the Terasic distributions, allowing me to see what should be in there. 

The harder method would be to read through and understand the hundreds and hundreds of source code files in the U-boot archive and then study all the hardware configuration steps and register configurations that would be needed to run the preloader. Again, no documentation that spells this out, so it requires digging through many thousands of pages of Cyclone V and other documentation. Possible but very high work effort. 

No comments:

Post a Comment