DRAM training and calibration

Hi,
I need DRAM training and calibration code or any tool used for VisionFive2 board.
I have VisionFive2 board and I’m currently going through the u-boot and Linux porting to that board.
I need to understand the DRAM training and DRAM initialization code flow in u-boot source code.
It is highly appreciated if anyone could help me to achieve my present milestone.

Thanks & Regards
Novice

Hi @novice - I don’t know exactly what you’re asking, but perhaps this will help:

But this is pretty heady stuff for a novice! If there is specific code that you’re struggling with you can provide it and ask a question - ‘we’ might be able to help.

2 Likes

HI @tunagenes
Thanks for your response. Presently I have two queries:

  1. I want to know whether any DRAM training and calibration code or tool has has been used for VisionFive2 board. So, if you have any similar code or tool please let me know.

  2. Is there any DRAM initialization code flow for the VisionFive2 board in u-boot?

Thanks,
Novice

1 Like

You will probably find the hexadecimal values that are used for the process, for the exact DDR memory on the VisionFive 2 board, but without the actual meaning behind the hexadecimal codes.

u-boot/drivers/ram/starfive/ddrphy_train.c or
JH7100_ddrinit/ddrc_cfg/lpddr4_1600_cl28_bl16/orbit_boot_training.c_origin
The first 363 lines hexadecimal values in both files above look the same to me. The second file, which is older, has a lot more than just 363 lines.

starfive-tech/u-boot/drivers/ram/starfive/ddrphy_start.c or
starfive-tech/JH7100_ddrinit/ddrphy_cfg/lpddr4_1600_cl28_bl16/regconfig_pi_start_3200.c

The best place to look for the most current code is in starfive-tech/u-boot/drivers/ram/starfive/
And then the best place to look for some comments that might help you decipher the meaning with help from the link posted by @tunagenes will probably be by searching (rgrep string *) a local copy the slightly older code in starfive-tech/JH7100_ddrinit/ for an exact or partial match to the most recent code.

Unfortunately most current DDR initialisation code is covered by NDA’s (Non Disclosure Agreement’s), so detailed information is usually hard to find.

P.S. I know that the JH7100 is not the JH7110 used in the VF2 board, but most of the DDR code will be close enough, just a lot more compact, with almost no comments, in the U-Boot code.

3 Likes

Hi @mzs
Thanks for your valuable response as it is very useful.

I have already gone through the below mentioned file:
**boot/drivers/ram/starfive/
ddrcsr_boot.c, ddrphy_start.c, ddrphy_train.c, ddrphy_utils.c, starfive_ddr.c starfive_ddr.h
The function in these files get called after starfive_ddr_probe() function gets called from device tree.
I want to know how this starfive_ddr_probe() function gets called in SPL/u-boot source code as well as DDR PHY Regs description and DDR controller TRM of Startfive JH7110 SoC.

It will be very helpful if could let me know something regarding this.

Thanks,
Novice

All I know is what I have learned speed reading the source code.

I would read this document (focus on the word “probe” - make a device ready for use):
https://github.com/starfive-tech/u-boot/blob/JH7110_VisionFive2_devel/doc/develop/driver-model/design.rst#declaring-drivers
While looking at these line of code:

EDIT: In the root directory of a git clone of the starfive u-boot a quick “rgrep CONFIG_SPL_STARFIVE_DDR *” might give a clue as to why it ends up in the SPL binary.

P.S. Eventually I hope to do some bare metal programming on the VF2, so I am absorbing as much information about the VF2 as I possibly can.

2 Likes

Upstream u-boot has a slightly different implementation of ddr initialization, you can check it here:[v5,09/17] ram: starfive: add ddr driver - Patchwork

3 Likes

Thanks @mzs and @Stat_headcrabed for the information!

@mzs - I don’t doubt that is true, but I would like to find out more about it. Specific questions:
Who would the NDA be between - VisionFive and the DRAM manufacturer, or someone else?
What is the motivation for keeping this ‘secret’?
How do you know this?

Thank you for any insight you can provide. It seems a shame to have binary blobs showing up so early on a RISC-V based system.

I tried a Google search on “DRAM training and calibration nda” but didn’t find any useful results.

The information you seek would all be contained in “JEDEC Standard JESD209-4D”

The security to prevent companies who have not paid to have JEDEC documents is simple, JEDEC will physically ship your company a hard copy of their documentation in a number of ring binders and then email updates for a yearly subscription fee. And I’m sure that everything is digitally water marked these days. So you are pretty much guaranteed not to find much of their documentation online.

As for the motivation to keep things secret. In my opinion it is to keep small players on the outside (unless they can pay enough yearly to join). The members of JEDEC create the standards in committees formed by the member companies, each would be pushing to move the standard towards their preferred solution. I also think of it as an anti-competitive agreement between members. It is also a cheap way to keep time wasters away (companies that will not be shipping 10k to 100M product units a year). They have been about for nearly a century, formed in 1924 by the Radio Manufacturers Association. Then in 1944 became JETEC - Joint Electron Tube Engineering Council. And finally in 1958 they renamed to JEDEC - Joint Electron Device Engineering Council. So I’m sure part of the reason for not giving away their documentation for free is historic, creating documentation costs money, physically shipping documentation costs money. Historically there would have been a lot of travel, which would require accommodation, and physical meetings involved in creating standards, money for that needed to come from somewhere. Selling NDA documentation is also an additional revenue stream, that would reduce the membership fees for the very largest companies who can afford to assign “free” resources into committees to create and update the documentation of the standards.

3 Likes

Thanks for the info and your opinions-insight @mzs ! I don’t disagree with anything you said, but I think there’s gotta be a better way to do this so that how the basic technology works is less hidden. But I’ll stop whining-preaching and get back to the real world now. I appreciate you taking the time to answer.

1 Like

NDA stuff is DRAM controller’s control registers, limited by IP designers, not chip designers.

1 Like

Hi All,

Thanks for your response.
Presently, I’m going through the Starfive2 board’s DDR training and initialization code but to understand it properly I need JH7110 SoC’s DDR controller TRM and DRAM device datasheet.
So, please let me know if there is any such document which provides the details of the registers and programing flow for DRAM initialization and training .

Thanks,
Novice

Hi, I can tell you that the controller comes from OpenEdges and is called Orbit.

I have translated the C code forthe oreboot project; see:
https://github.com/oreboot/oreboot/blob/main/src/mainboard/starfive/visionfive2/bt0/src/dram.rs and the files it pulls in

The controller is the same as in the previous SoC, JH7100, just getting different parameters. I went through this in development live streams; see the playlist:

The previous implementation was a separate repo, and that had all the register names. While still very complex, it is probably useful to those who have access to the JEDEC PDFs (which you … can find ;)).

3 Likes

Love the rust code in there ! Congrats!