AM3352 cannot boot the linux kernel

Hi Marlon,

   在这个本土的论坛上，你可以使用中文，如果对简体中文阅读有困难，我可以继续用英文回复你。

  首先，AM3352和AM3358仅在PRU和3D这两个模块上面有区别，所以这两个模块在板卡启动，NAND flash启动的时候配置应该都是完全一致的。所以请先帮忙确认你目前的的AM3352的设计和之前的AM3358的设计在硬件上是否完全一致，包括DDR芯片型号、layout是否有换过，还有一个是NAND flash型号有换过吗？然后再确认使用的软件开发板是否完全一致。

 因为在你给出的AM3358的启动log中，DRAM:  256 MiB。但是AM3352中：DRAM:  128 MiB。并且在你给出的启动信息中，Loading Device Tree 的地址也不一样。所以请先确认上述我提到的问题，硬件和软件上面都具体的做了哪些改动。

另外一个小建议：可以先尝试使用SD卡来启动板卡，看是否能成功，以先排除DDR方面的问题，然后再测试NAND启动的问题，这样有助于把系统问题和NAND ecc的设置问题孤立开来，方便debug。

Hi Steven,

As per our hardware engineer:

1. Layout are not the same. AM3358 use ZCZ packet while AM3352 use ZCE packet.
2. NAND Flash the models are the Same. Only memory size is different. For NAND flash 128MB, it uses A0-A12. But 256MB, it uses A0-A13.

Here are the other changes:

I was actually booting from the SDCARD (in the attachment, see files  boot-log-am3358-working.txt and boot-log-am3352-not-working.txt). I only tried booting from NAND to see if it's an SDCARD problem.

Regards,

Marlon

你需要确认一下128M和256M两种nand的bank size是不是一样的

Hi Marlon,

  I saw that, you used the UART4 as the debug port in the latest board version. Could you help to check whether your system could boot up normally?

  From your log "boot-log-am3352-not-working.txt", it stopped at the "Starting kernel ...". It could be the UART output issue or DDR issue. So please help to check whether the system is boot up or not. 

   Additionally, it is highly recommended that you should do the DDR3 software leveling on your latest board. For details, please refer to this link: http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling

We are using exactly the same NAND flash between the 2 versions (MT29F2G08ABAEAH4:E). It is a 2Gbit flash (256Mx8).

Only RAM size is different: changed from 2Gbit (128Mx16) to 1Gbit (64Mx16), but configuration should be exactly the same.

Hi Steven,

I also realized yesterday that the UART port setting is wrong so we corrected that but still the issue persists after changing the console to UART4. I'll take a look at the DDR3 software leveling link.

Regards,

Marlon

Hi Steven,

When we change the debug port, we updated the following files:

• U-Boot Bootloader (to alter the console variable to ttyO4)
• Device Tree file (to add the UART4 pins)

Are there other files that wee need to update?

Regards,

Marlon

Hi Marlon,

   I'm not aware of the porting steps for the UART4 working as debug port. But here is an article which I searched in the google.  For your reference:

    http://blog.pignology.net/2013/05/getting-uart2-devttyo1-working-on.html

   I think you need to check whether your board is already booting or not first. Did you have any GPIO output when your board is booting or some events triggering ( such as button down)? If yes, please check first, which could help you to understand your board status. If it works, your issue is the UART4 debug port porting issue. If not, check the DDR settings and the porting work related to your hardware change. 

Steven,

No the board is not booting. for now we can use UART 0 or 1 for debug port this is not a problem.

But again the issue is the board is not starting. it stop at the kernel level.

We have no change on the way the DDR is handled (hardware or software).

We need onsite support we are not moving anywhere.

If DDR3 is used, it is a must for the board layout and silicon package is changed. Have you done the DDR3 software leveling? 

A simple way for you to check your DDR status is following this thread: http://www.deyisupport.com/question_answer/dsp_arm/sitara_arm/f/25/t/53263.aspx

to see whether you can pass the DDR3 software leveling. 

After verifying the DDR3 stability, please see this thread for the next debugging steps: http://www.deyisupport.com/question_answer/dsp_arm/sitara_arm/f/25/t/51326.aspx

we do not have access to the JTAG.

WE might have a problem with ODT pin. we are now using a power management IC TPS650250while using TPS65910 on previous design.

We need to set ODT registers and configure ODT pin. DDR is not set in the device tree. can you please help to show us where to change this configuration?

we need to set as below:

Hi Mickael,

    According to your previous reply, you should have the SD boot and UART0 as debug port,which is great for the DDR3 software leveling MLO.

http://www.deyisupport.com/question_answer/dsp_arm/sitara_arm/f/25/t/53263.aspx

   Could you help to download the MLO and copy it to the SD card, boot the board to see whether you can get the output from the debug port -- UART0?

    If yes, it works the same as the JTAG does. 

Hi Mickael,

  I couldn't see your picture and I don't know what is the concern. ODT pin is directly connected to the AM3352. The PMIC you used should not affect this PIN's design.

  Step1: You need the related parameters from the DDR3 spec you're using to complete this excel, to get the EMIF TIMING 1,2,3.  The EMIF excel can be download from here: http://processors.wiki.ti.com/images/a/a4/AM335x_DDR_register_calc_tool.zip  You can directly searched the related parameters in the DDR3 spec. After finishing, you'll get the TIMING 1,2,3.

Reference: http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips#AC_timing_registers

 Step 2: Measure the DDR_CK/DDR_CKn,  DQS0/DQS0n, DQS1/DQS1n trace. Then finish this excel: http://processors.wiki.ti.com/images/e/e6/RatioSeed_AM335x_boards.zip You'll get the ratio seed values. 

Reference: http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling

 Step 3: According to your DDR3 spec, finish the SDRAM_CONFIG register settings. AM335x TRM, 7.3.5 EMIF4D Registers, 0x8h SDRAM_CONFIG.

 Step 4: Run the MLO I show you in the last thread, and input the related values according to the prompting. 

If you get the result, you pass the DDR3 software leveling and get the right ratio values. If there're all ZEROs, you failed, which means there's something wrong with your DDR configuration.  

Hi Steven,

If we are able to run the program, where do we put the values? I can't seem to find the source code where we will update these values.

Regards,

Marlon

P.S.

After searching I found that include/linux/ti_emif.h might be the file. Please confirm.

Hi Marlon,

  One thing I want to clarify is that this MLO is different from the general MLO you're using for Linux booting. I made it specially with the DDR3 software leveling algorithm integration. You don't need modify anything. You just need to copy it to the SD card, it should work. 

  After booting, you should see things like below, I use the uart console to make it able to input the DDR3 parameters. (The red part). 

Hi Steven,

While we're trying to make the MLO work, my question, we cannot seem to make the kernel print any debug info. I have already enabled the following in the menuconfig:

• Low level debugging
• earlyprintk

Is it expected that we won't be able to see any debug text if we haven't done the memory leveling?

Regards,

Marlon

Hi Marlon,

  I think there may be some misunderstanding here, for I see you mentioned the kernel menuconfig. 

  Are you be able to see the UART0 console output as below when running the MLO?

This MLO is not for Linux booting. It's a software leveling tool.

When using this MLO, there's no need to have the u-boot.img or the uImage. We won't boot the board to kernel stage or u-boot stage. All you need is copy this single MLO to the SD card to boot (there's no u-boot.img, no uImage..etc), then if you can use the UART0 console, you could do the software leveling after input the related parameters.  

Hi Steven,

We've now solved the kernel loading issue. Our next problem is even though u-boot reports that it was able to write to our NAND partitions, when we boot, it doesn't show anything. We've confirmed that our boot pins configuration is correct. 

Regards,

Marlon

Hi Marlon,

  May I know what's the root cause for the kernel loading issue?

  When the board failed booting, could you help to attach the console output log? 

  If there's nothing on the console, I think you may get stunk in the SPL stage. It's better to check whether the MLO worked all right. 

Hi Steven,

We found out that there were hardware issues causing the kernel to not load.  This issue is now resolved.

Regards,

Marlon