Required LPDDR4 Calibration Tool where the External Oscillator is used as the source of clock

[Brijesh_Thakkar]

Hi,

We have designed the custom board by referring to the design guide of S32G. Please note the following is an important difference: 

• The S32G EVK is being designed using the 40MHz Crystal as a source of the Clock

• The Custom boards are designed with a 40MHz oscillator as the source of the Clock.

We are using the precompiled binaries for DDR calibration and looks like they are generated by considering the crystal as the source of the clock - which does not allow the custom board’s processor to get the clock (as the clock should be given from the external oscillator and the precompiled binaries are trying to provide clock from external crystal). 

Please help with the DDR calibration tool which generates the clock from the external oscillator instead of the external crystal.

• Based on the reference manual, we can achieve the same by setting the values in the FXOSC CTRL register as follows:

• The OSC_BYP field is set to 1b, and 

• The COMP_EN field is set to 0b 

Please find the sample patch:

Subject: [PATCH] Customboard: Bypass the internal oscillator

Based on the reference manual, the FXOSC CTRL register should have the

OSC_BYP field set to 1b and the COMP_EN field set to 0b when using an

external oscillator instead of an external crystal.

diff --git a/drivers/clk/s32/enable_clk.c b/drivers/clk/s32/enable_clk.c

--- a/drivers/clk/s32/enable_clk.c

+++ b/drivers/clk/s32/enable_clk.c

@@ -35,8 +35,12 @@ static void setup_fxosc(struct s32gen1_clk_priv *priv)

if (readl(FXOSC_CTRL(fxosc)) & FXOSC_CTRL_OSCON)

  return;

+#if defined(CONFIG_TARGET_CUSTOM_BOARD)

+ ctrl = FXOSC_CTRL_OSC_BYP;

+#else

  ctrl = FXOSC_CTRL_COMP_EN;

  ctrl &= ~FXOSC_CTRL_OSC_BYP;

+#endif

  ctrl |= FXOSC_CTRL_EOCV(0x1);

  ctrl |= FXOSC_CTRL_GM_SEL(0x7);

  writel(ctrl, FXOSC_CTRL(fxosc));

-- 

With the above register changes - the board started booting, however, we would like to do DDR calibration and looking for LPDDR4 Calibration binaries which do generate/consider the source of CLK from the external oscillator.  

It will be a great help if you can add the above small change (refer to the patch - above) in the source code of the DDR calibration tool and share the binaries.

Thank you for your support and help. Really appreciate it. 

Regards.

[gse31]

Hi,

We have a S32G2 custom board with a 40MHz external oscillator.

We did not try the DDR tool yet but we should have the same issue ?

Differences between RDB2 and our custom board:

- oscillator vs quartz

- byte swapping

- DRAM ODT impedance and DRAM driver strenght

Is a new DDR tool version released with FXOSC bypass mode ?

Thanks

[nilavchoksi]

@st_ra: Can you please Generate a new ticket for your queries in community? This is different thread and DDR which we are using for the custom board.

@AjeshKumar: Kindly find our reply on your questions and let us know if more information is required,

1. Does your board has the option to work in crystal mode also? 

[Reply]: No, the board does not have option to work in crystal mode as crystal FP implementation support is not available on the board.

1. What is the DRAM part number on the customer board? if it is different from the NXP EVB DRAM part, please share the DRAM datasheet also.

[Reply]: DRAM part number of the Custom board is MT53D1024M32D4DT-046 AAT:D   It is as close as it could get to the exact part number on the reference design due to the sourcing challenges right now.  It its only a temp grade difference from what is on the rdb2 platform. 

1. How do you ensure that the given uboot clock patch shared above works well without any issue? did you run any application from SRAM using FXOSC in bypass mode as the clock source for the application?

[Reply]: We are sure that the patch works well as the custom board boots smooth without hang when we are bypassing the internal oscillator using FXOSC in the u-boot.

1. Which BSP version is used where you did modifications for FXOSC in uboot? 

 [Reply]: Currently, we have below details from the Design studio and SDK that I've been using:

S32 Design Studio for S32 Platform

Build id: 201217 (Update 3)

OS: Windows 10, v.10.0, x86_64 / win32

Java version: 1.8.0_202

S32 Design Studio Platform package

version 3.4.3

 Platform_Software_Integration_S32G2XX_2021_09

Kindly suggest the option to calibrate LPDDR4 with the same custom board instead to use the RDB2 as it will be moved in the production.

Regards,

Nilav Choksi

[Bio_TICFSL]

Hello Brijesh,

May I know what is "the DDR calibration tool" means, do you mean the "DDR TOOL" integrated in S32DS?

I've checked the configuration in "DDR TOOL", only the XOSC source frequency value is required, the source clock type "Crystal" or "Oscillator"  seems does not affect the DDR calibration result.

Regards

[nilavchoksi]

Hi,

I am adding details on behalf of Brijesh as he is on leave.

Yes, I mean the "DDR TOOL" integrated in S32DS.

• We have used the design studio software S32DS.v3.4
• We have run the LPDDR4 stress tool available in the design studio software S32DS.v3.4 and due to Oscillator implementation, Both jtag and serial hang, while the setup does work when using the RDB2 reference design (meaning stress tools/debuggers are functional).

So, kindly consider the S32DS.v3.4 software to test the LPDDR4 stress tool but it hangs both jtag and serial hang. while the setup does work when using the RDB2 reference design (meaning my tools/debuggers are functional). 

we suspect the bridge programs being loaded into the M7's do not properly support oscillators as the main clock source. I would verify this, but for some reason did not put down a crystal footprint on this revision going to the S32G. Reasons for this assumption are every example and the u-boot source acted exactly the same way until I went in to update the FXOSC_CTRL register to change the configuration to use the external Oscillator. I did not find the sources for the M7 bridge applications in the design studio code anywhere to rebuild and test with either. Can you please guide to find the source?

Also, I am curious then how the tool will detect the external cystal (diffrential) and oscillator (Single ended) ? Is it done automatically? If yes, then why it hangs both jtag and serial hang in our custom board(Hardware implementation is ok)?

Hope this will give better idea of query and we need Oscillator support based DDR stress tool binary so that it can work without hang issue.

Thanks you.

[Bio_TICFSL]

Hello,

Thanks for your feedback!

we have the DDR tool for S32G which can be integrated in S32DS. The attached DDR_tool.jpg shows the appearance of this tool.

to support enable this tool, the patch "S32G development package" and "RTD" are needed. I've attached an image here shows the installation details of my S32DS for your information.

RTD is available at: 

https://nxp.flexnetoperations.com/control/frse/product?child_plneID=832137

for S32G development package, it can be downloaded from:

https://nxp.flexnetoperations.com/control/frse/product?child_plneID=827187

please let me know if the above does not answer your question or I misunderstood something.

Thanks

[nilavchoksi]

Hi,

You misunderstood our requirements.

We already have the DDR tool for S32G which is integrated into S32DS with RTD and S32G development package and we have good exposure to use.

We need a binary to validate the LPDDR4, with the FXOSC clock bypassed for the custom board. The default DDR validation binary has considered the FXOSC clock due to crystal support on the RDB boards. So, DDR validation is not getting successful on the custom board.

Thus, kindly provide us the DDR Validation/stress tool binary with the FXOSC clock bypassed so that we can use it on the custom board which has external Oscillator used to validate and calibrate the RAM on the custom board.

Let me know if more information is required.

Thanks & Regard,

Nilav Choksi.

[AjeshKumar]

Dear Nilav,

The S32 design studio DDR Tool does not generate code with FXOSC and DDR clock configurations, user has to configure the FXOSC and DDR PLL configurations in the application/uboot.

To enable DDR/LPDDR4 on your board, can i request to share following information:

1.  Does your board has option to work in crystal mode also? 

2.  What is DRAM part number on customer board? if it is different from NXP EVB DRAM part, please share the DRAM datasheet also.

3.  How you ensure that with the given uboot clock patch shared above working well without any issue? did you run any application from SRAM using FXOSC in bypass mode as clock source for application?

4.  Which BSP version is used where you did modifications for FXOSC in uboot? 

In case your board does not have option to work in crystal mode, and your board has exactly same DRAM which is present on NXP EVB, then you can run the DDR tool on NXP EVB and configure desired frequency/data rate and generate DDR init code. And put the generated code inside uboot ddr configurations directory.

Please note, you have to configure DDR clock in uboot and the DDR clock should be aligned with the tool configurations so that the frequency with which code is generated and uboot ddr clock should be same.

If your board has different DRAM from NXP EVB DRAM, then S32 design studio tool must be run on your board to generate ddr initialization code and that should be put under uboot.

Thanks,

Ajesh 

[st_ra]

Hi,

I already asked on offical support but did not get any answer. From datasheet of DDR density per channel is 12G, but that option is not available from DDR tool. Is there any workaround or that is normal? Should I set something other? We are using MT53E768M32D4DE-046.

[AjeshKumar]

Hi,

Thanks for sharing information about total density of DRAM, it would be good if you could share datasheet of DRAM part number to know about DRAM ranks information.

One quick question, Is there any specific reason to consider 3GB density DRAM, not as 4GB/2GB density?

Regarding support for odd density like 3GB in DDR tool, I will check internally for odd density support present in DDR tool OR it may take time to implement the new request.

Thanks and Regards,

Ajesh 

[st_ra]

Hi, here is datasheet for the ddr. Total density is 24GB and density per channel is 12Gb which I cannot select from DDR tool.

[AjeshKumar]

Hi Nilav,

Thanks for your feedback on requested information.

The custom board designed for current project has no option for crystal oscillator and has same DRAM part MT53D1024M32D4DT with respect to NXP EVB/RDB2.

We always recommend to run DDR tool on the custom board because customer board may has different DRAM part which has different internal configurations (density per channel, ranks) and also may have bits/bytes swapping on board/PCB traces for DDR signal lines.

Here, DRAM is same with RDB2 DRAM so the generated code from RDB2 can be used for custom board if custom board has NO DQ bits/bytes lines swapping on board and meeting layout recommendations provided in hardware design guidelines during board design.

Also, need to ensure that DDR clock configurations in uboot should be aligned with the tool generated code. for example, if a user want to run DDR at 3200Mbps then the DDR tool should run at DDR clock as 800MHz (Clock Cycle Freq  - 1600MHz) and uboot clock settings for DDR should be 800MHz.

Thanks,

Ajesh

[nilavchoksi]

Hi AjeshKumar,

Thank you for sharing the idea of using the RDB to generate the DDR calibration files for the custom board. Really appreciate it. The team is planning to validate the same.

In order to avoid any surprises due to other factors on the custom board - it will be great if you can share the DDR tool binary for the custom board with the smaller change (bypass internal Oscillator and Comparator disable). Which gives us more confidence to go ahead with production. Thank you for your support and help. Really appreciate it. 

Thank you,

Nilav Choksi

[AjeshKumar]

Hi Nilav,

The S32 design studio DDR tool does not support FXOSC bypass mode currently.

Thanks,

Ajesh  

[nilavchoksi]

Hi AjeshKumar,

Noted.

Is there any future plan to support FXOSC bypass mode in S32 design studio?

It would be a good if you can support to add so that we can directly use it for custom board and helpful for the production.

Regards,

Nilav Choksi

[AjeshKumar]

Hi Nilav,

Yes, we take the request for this requirement and will discuss internally to provide oscillator bypass mode support with DDR tool. It is difficult to share any timeline for providing this feature in DDR tool for now, can be shared after internal discussion.

Thanks and Regards,

Ajesh 

[nilavchoksi]

Hi AjeshKumar,

Thank you for your positive response.

Hope you received multiple queries regarding the same DDR tool requirements with bypass functionality.

Please keep us posted regarding the implementation.

Thanks & Regards,

Nilav Choksi

[AjeshKumar]

Hi Nilav,

Just to share, this is the first time we receive FXOSC oscillator bypass mode support in DDR Tool. The requirement is discussed internally and can be implemented in the tool for the next release of DDR Tool. The next DDR Tool release is planned during October'2022.

Could you please share your tool update requirement timeline when you expect the updated DDR tool release or patch with oscillator bypass mode?

Also, just to know about one more point found in the thread above - Do you need odd density DRAM support like 3GB/24Gb support in the S32DS S32G DDR Tool? OR that requirement is for another project with another SOC (nothing for S32G2/S32G3)?

The NXP DDR tool does not support odd density configurations currently.

Thanks and Regards,

Ajesh 

[gse31]

Hi,

Do you have an update regarding the S32 DDR tool ext oxcillator option ?

We need it following DDR reference modification on our S32 custom board with external oscillator.

Thanks

[noahf]

I too am interested in an update on the availability for external osc option for the S32 DDR Tool.

[nilavchoksi]

Hi AjeshKumar,

I was not able to follow those steps as our baseboard also has DQ swapped on some of the bytes.  When I made these changes and attempted to validate them on the goldbox/rdb2 eval board the training failed and it didn't generate any code that I could include in our project.  

Right now we don't plan on using an odd density of DRAM.  We will initially ship with 4GB like is on the reference designs.  

The timeline for production is as follows,

1) Dec 2021 - First 5 boards of RevA

2) June 2022 - First 5 boards of RevB 

3) Q4 2022 - 40 additional units

4) Q1 2023 - 300 units

We need your support to resolve this issue.

Looking forward to your reply.

Thanks,

Nilav.