DRAM Initialization in U-Boot for VisionFive2 (SoC JH7110) Board

In the DRAM initialization code https://github.com/starfive-tech/u-boot/blob/JH7110_VisionFive2_devel/drivers/ram/starfive/ the functions are called as follows:

To initialize the DRAM the folllowing functions are using predefined hex valuse directly:

So I have some queries regarding these values:

  1. Where from are we getting these hex values?
  2. Are those trained values getting from somewhere else?
  3. What kind of calibration and training is happing in this code

In the ddrcsr_boot.c file ddrcsr_boot() function is also using predefined value as well as it is also preforming something within do-while loops and while loop.
So, is this performing any calibration or training here?
If yes, then what kind of training is happening here?

Thanks & Regards,

Your question, as I understand it, is: “What do these numbers mean?”

“Training” ram is done by the designers of the JEDEC chips and circuits to make them respond to the shapes of the copper traces and all kinds of other nerdy things. RAM is a lot more complicated than it used to be. Just hardcoding the relationships on each end of the signals on that bus doesn’t work in modern times.

So this code looks to be programming the RAM controllers for the board. They’re probably raw register values that just come as a sequence of values to be stabbed into registers once and so disconnected from our world as to not be worth documenting or trying to manipulate in RISC world. Kind of like programming a video controller or even LCD where you just have a bunch of numbers that come from a chip’s data sheets. You don’t have to understand them, you just have to do them.

Because of patent and IP hysteria, it’s possible that whomever DOES understand these values may be prohibited from documenting them well enough to allow others to do so. (It’s kind of the opposite of ‘open’ but that’s reality. High-speed memory remains a landmine of IP issues.)

It’s U-Boot’s job to configure the system’s clocks and refresh and any other voodoo for the system to be in a sane and stable state when it’s ready to execute our first opcode.

My guess is that if you don’t understand what it does, you don’t need to understand what it does.

the dtb
RAM: starting address 0x100000000, length 0x100000000 (4 GB)

memory@100000000 {
device_type = “memory”;
reg = <0x000000001 0x00000000 0x00000001 0x00000000>;
from 202308 jh7110-visionfive-v2.dtb
memory@40000000 {
device_type = “memory”;
reg = <0x00 0x40000000 0x01 0x00>;
right down the end of the .dtb after the various registers, etc