AM3352 cannot boot the linux kernel

Hi,

We were using a customized AM3358 board previously and we have a working linux kernel. Now, we have a new version of the device and we are now using AM3352. We tried booting using the same linux kernel and upon kernel loading, U-Boot restarts. I have also tried booting the kernel from NAND but we got ECC errors. I am new to this and I don't have much knowledge troubleshooting U-Boot and the linux kernel.

Regards,

Marlon

Steven Liu1：

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。

Marlon Hacla：

回复 Steven Liu1:

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:

 
Version 1
Version 2

core
AM3358
AM3352

packet
ZCZ
ZCE

USB
USB1
USB0

debug
UART1
UART4

MBUS
not function
UART1/prepare

ethernet
RGMII1
MII1

real time clock
not include
VRTC for real time clock

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

leo chen：

回复 Marlon Hacla:

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

Steven Liu1：

回复 Marlon Hacla:

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

Mickael Bouffaut：

回复 Steven Liu1:

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.

Marlon Hacla：

回复 Steven Liu1:

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

Marlon Hacla：

回复 Steven Liu1:

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

Steven Liu1：

回复 Marlon Hacla:

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. 

Mickael Bouffaut：

回复 Steven Liu1:

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.

Steven Liu1：

回复 Mickael Bouffaut:

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