• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1769 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352 reset stuck at reading u-boot

Jun Sheng
Prodigy 160 points
Other Parts Discussed in Thread: AM3352

Hello Everyone,

I confront a problem about system reset these days. My platform is based on AM3352. We found that when we enter reset in uboot stage or push the reset button in uboot or kernel stage, the system will be stuck at  reading u-boot. The console info shows that the system is stuck at the end of MLO and error info is spl: fat register err - -1. The system runs OK when I use reboot command in kernel stage. The hardware seems OK. Does anyone have any idea of debugging this problem?  Thanks.

Best regards,

Jason

  • 0
    TI__Guru**** 393215 points
    Hi Jason,
    How do you apply reset? Do you use the warmreset pin?
  • 0 in reply to Biser Gatchev-XID
    Prodigy 160 points

    Hi Biser,

    I used two methods. One is to enter the command "reset" in uboot, and the other is to press the reset button, which is the warmreset pin. The results of these two approaches are same-stuck at reading partition table of MMC device and returning error flag -1. Thanks.

    Best regards,

    Jason

  • 0 in reply to Biser Gatchev-XID
    Prodigy 160 points

    Currently, I heavily doubt maybe the problem is rooted in DDR. Actually, we are using inappropriate DDR parameters. Reset problem occurs although the kernel can be booted successfully when the board is powered on with these parameters.

    When I changed the DDR parameters to some calculated values, which I suppose are correct, with TI tools, I found out that the system was stuck at trying to load MLO or uboot sometimes. I am debugging this as well. The error message is same with reset error as "spl: fat register err - -1". I would like to focus on DDR tuning in order to solve this reset problem. I really appreciate if anybody can give some suggestions. Thanks.

  • 0 in reply to Jun Sheng
    TI__Guru**** 393215 points

    DDR tuning procedures can be found here: http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips. For DDR3 PHY tuning there is also this wiki: http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3 and this tutorial: http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_Tuning_the_DDR3_Timings_on_BeagleBoneBlack

  • 0 in reply to Biser Gatchev-XID
    Prodigy 160 points

    Thanks, Biser. I have obtained the optimal parameters for our DDR3 with those tools and CCS provided by TI. But the reset problem still existed with these tuned parameters. After adding debug information, I solved this problem by adding a time delay in the beginning of the function board_init_f in arch/arm/lib/spl.c. The code shows that C environment is set in arch/arm/lib/crt0.S before calling board_init_f. I cannot figure out why such a delay is needed in our custom board, although everything seems OK now. Is it a hardware problem related to DDR? Could anyone given some opinions? Thanks.

    Best regards,

    Jason

  • 0 in reply to Jun Sheng
    Prodigy 160 points

    In the first edition of our custom board, we used Hynix DDR3, and we adopted Sumsung DDR3 in the second edition of our custom board. I have checked the procedures of tuning DDR settings and confirmed settings are correct. To solve the reset problem, a minimal of 1.5ms delay must be added after the configuration of DDR3 in board/ti/am335x/board.c and before BSS clearance in arch/arm/lib/spl.c. It means that after configuring DDR, the board must wait for a period of time before using DDR. However this situation doesn't exist in our first edition with Hynix DDR3. I guess this phenomenon is rooted from the difference between Hynix and Sumsung. Maybe after each reset, Hynix DDR can reconfigure itself more quickly than Sumsung DDR, so the delay is not required in our first edition of source code.