Regarding kernel crash of T1042 based board

[anilks]

Hi,

We are working on a board with a NXP-based processor (T1042: 4 core) and 8GB of BGA mounted RAM. The system operates correctly at the U-Boot level but crashes when booting the kernel. We have attached the Kernel logs for your reference.

Notably, the same kernel works fine on another board with the same configuration (T1042-based processor, 8GB RAM Sodimm module)."

[yipingwang]

Please use QCVS DDRv tool to connect to the target board to do DDR validation and optimization. The refine DDR controller configuration parameters in u-boot.

You could create a QCVS DDR project with "read from target" method.

[anilks]

Hi Yiping Wang,

Thank you for your suggestion. We are currently using the evaluation version of the QCVS tool (QCVS_4.5.001). Unfortunately, the "read from target method" feature is not supported in this version. Could you please provide a link to the latest evaluation version of the QCVS tool?

Best regards,

[anilks]

Also, we have some observations while evaluating with the available QCVS software tool.

The current SDRAM which we are using are 5 nos. of Micron MT40A1G16 (16Gb : 1Gb x 16). (4 + 1 ECC).

1) As per the datasheet of the said SDRAM, there are in total 17 row addressing bits A[16:0] and 10 column address bits A[9:0]. But the current QCVS tool which we are using has support of maximum 16 row address bits only. Evaluation failed too.

2) When we configured the QCVS tool with 16 row address bits, there was successful completion of the evaluation. (wherein we configured this same SDRAM in QCVS as 8Gb : 512 Mb x 16).

Could it be that the unavailability of 17th row address bit option in the tool is the reason behind the evaluation failure in case 1? Please help with this.

[yipingwang]

Using the MT40A1G16 (16Gb TwinDie) DRAM configuration in the DDRv wizard select 8Gb: 1G x8 configuration. the reset should remain the same. This means when you are getting a pass in DDRv it was configuring/using half of the available memory. this time it will use the full memory.

If no SPD on the target, please create a QCVS DDR project with auto configuration, the modify properties panel according to your DDR data sheet.

Then connect to the target board to do validation and optimization.

[anilks]

Hello,

We evaluated the DDRs along with the configuration you suggested ,i.e., 8Gb x 8. All the tests were successfully passed except the "BIST-Write-then-Read-No-Turnaround" and "DMA Test" operational DDR tests.

We exported the configured registers from t1042_v1_0ds_ddr.c in our uboot code, the processor did not boot from u-boot level itself. In the u-boot , we have used the DDR SPD parameters pertaining to the DDR datasheet of 16Gb : 1Gb x 16.

Observing this, we have two queries:

a) We have validated the 8Gb: 1Gb x 8 as said above but how can we validate the entire SDRAM which is 16Gb : 1Gb x 16?

b) In spite of using the DDR SPD parameters matching the DDR datasheet like changing specific bytes 4 (to 0x46) and 5(to 0x29) to take 17 row addressing bits and 10 column addressing bits but the u-boot did not work. Also configured the SPD bytes for running 8Gb : 512Mb x 16 ,i.e, Byte 4 to 0x45 and Byte 5 to 0x21, but still did not work. What could be the reason?

[yipingwang]

Please changed the DDR setting 'Partial Array Self Refresh' to 'HalfArray", then do validation.

If there is SPD on your custom board, you need to modify "static const struct board_specific_parameters udimm0" in board/freescale/t104xrdb/ddr.h according to the parameters generated by QCVS DDRv tool.

        /*

         * memory controller 0

         *   num|      hi|rank|    clk| wrlvl |   wrlvl   |  wrlvl

          * ranks| mhz| GB  |adjst| start |   ctl2    |  ctl3

After validation, please click Project->Generate Processor expert code, then use parameters provided in "Genrated_Code" folder.

[anilks]

Hi,

We have implemented the settings and incorporated the generated parameters into the U-Boot source code as per your recommendations. Our observations are as follows:

1. DDR Setting: Partial Array Self Refresh (Half array BA[1:0] = 00 & 01)
     The QCVS tools passed all tests.
However, the system failed to boot at the U-Boot level.

2. DDR Setting: Partial Array Self Refresh (Half array BA[1:0] = 10 & 11)
     The QCVS tools passed all tests.
Again, the system failed to boot at the U-Boot level.

Please note that in both cases, the value for partial array decoding is set to 'Normal address decoding.'

We would appreciate your guidance on how to proceed. Additionally, we have noted that the DDR4 datasheet mentions row addressing bits as [16:0] which means using 17 row bits, but there is no option for this in the QCVS.

Please find the attached screenshots for your reference.

Thank you for your assistance.

[yipingwang]

Please confirm whether  there is DDR SPD on your custom board.

Would you also send your u-boot source code and CodeWarrior generated file to me to do more investigation?

[anilks]

Hi,

There are no SPD EEPROMs on the DDR4 RAM mounted on our custom board. We have made the necessary changes to the SPD parameters in the U-Boot source code. For more details, please refer to the function fsl_ddr_get_spd in main.c.

Additionally, I have attached two files for your reference:

1. source_code_u_boot.zip – contains the relevant U-Boot source files.
2. generated_code_partial_array_self_refresh_00&01.zip  contains the generated source code by the QCVS tool.

[yipingwang]

If there is no SPD, please don't use the method provided in board/freescale/t104xrdb/ddr.c(ddr.h).

Please use fixed DDR controller configuration parameters.

Please refer to board/freescale/p1010rdb/ddr.c and include/configs/P1010RDB.h

Please don't modify DDR driver code in drivers/ddr/fsl/.

[anilks]

Hi,

As per your suggestion, we made the necessary modifications and incorporated the changes for fixed RAM. We configured the system for 4 GB of RAM. we observed,that U-Boot is getting stuck during the second stage of bootloading. The logs are attached for your reference.

We noticed that the values for dq_map_0, dq_map_1, dq_map_2, and dq_map_3 are all set to 0x00000000 even after applying the following configurations:

#define DDRmc1_DQ_MAP0_VAL 0x06106104
#define DDRmc1_DQ_MAP1_VAL 0x84184184
#define DDRmc1_DQ_MAP2_VAL 0x06106104
#define DDRmc1_DQ_MAP3_VAL 0x84184001

could you please suggest what may be the reason ?

previously the system works OK when configured for 4G but the kernel crashes when configured for 8G.

[yipingwang]

I checked your u-boot console log, the DDR controller registers configurations are different from the parameters generated by QCVS DDRv tool.

Please use the parameters generated by QCVS DDRv tool, please refer to t1042_v1_0ds_ddr.c provided by you previously.

In addition, DQ mappings are required, please refer to the following in "fsl_ddr_cfg_regs_t" definition in include/fsl_ddr_sdram.h.

unsigned int dq_map_0;
unsigned int dq_map_1;
unsigned int dq_map_2;
unsigned int dq_map_3;