topic Re: Regarding kernel crash of T1042 based board in PowerQUICC Processors

Regarding kernel crash of T1042 based board

anilks — Tue, 20 Aug 2024 08:39:40 GMT

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)."

Re: Regarding kernel crash of T1042 based board

yipingwang — Thu, 22 Aug 2024 05:50:45 GMT

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.

Re: Regarding kernel crash of T1042 based board

anilks — Tue, 27 Aug 2024 11:08:07 GMT

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,

Re: Regarding kernel crash of T1042 based board

anilks — Wed, 28 Aug 2024 10:27:17 GMT

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.

Re: Regarding kernel crash of T1042 based board

yipingwang — Thu, 29 Aug 2024 07:08:19 GMT

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.

Re: Regarding kernel crash of T1042 based board

anilks — Mon, 02 Sep 2024 06:17:15 GMT

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?

Re: Regarding kernel crash of T1042 based board

yipingwang — Tue, 03 Sep 2024 03:43:49 GMT

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.

Re: Regarding kernel crash of T1042 based board

anilks — Wed, 04 Sep 2024 10:01:58 GMT

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.

Re: Regarding kernel crash of T1042 based board

yipingwang — Thu, 05 Sep 2024 08:59:16 GMT

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?

Re: Regarding kernel crash of T1042 based board

anilks — Mon, 09 Sep 2024 08:57:50 GMT

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.

Re: Regarding kernel crash of T1042 based board

yipingwang — Wed, 11 Sep 2024 09:33:47 GMT

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/.

Re: Regarding kernel crash of T1042 based board

anilks — Fri, 04 Oct 2024 06:16:14 GMT

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.

Re: Regarding kernel crash of T1042 based board

yipingwang — Tue, 08 Oct 2024 06:05:41 GMT

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;