• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 2211 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 can not reboot after linux boot up

changbing zhao
Prodigy 50 points
Other Parts Discussed in Thread: AM3352

Hi, 

We have a customized board based on AM3352 CPU. We are using main stream uboot and TI's SDK (am335x PSP 04.06.00.08). Everything looks good except we can not reboot the board after linux boot up. Our board use SPI flash.

1. It works in uboot, when we use "reset" command.

2. We have reset button which connected to nRESET_IN_OUT (A10) pin. The button works fine when we are in uboot. i.e. when we are in uboot console, we press the button, the whole board reset and reboot correctly. But after Linux boot up, the system will just hang there after we press the button.

3.We manged to add another button to give a pulse feed to PORZ pin, which is the power reset pin. Still, it works fine when we are in uboot, boot it just hang the CPU when we are in linux.

4. Linux is actually works fine. We can run applications on it. We can ping it etc. But reboot command won't work. When we run reboot command, the system just hang after a few line output in console:

[ 32.708526] musb-hdrc musb-hdrc.1: remove, state 1
[ 32.737976] usb usb1: USB disconnect, device number 1
[ 32.769805] musb-hdrc musb-hdrc.1: USB bus 1 deregistered
[ 32.803741] Restarting system.
[ 32.822448]
[ 32.822479] RaymondDBI:I am rebooting...  (I add this debug information just before it write bit 1 into the PRM_RSTCTR register)

My questions is, in what scenario, AM3352 will fall into such a situation, even hardware reset can not reset the processor? Since it works in uboot, looks like Linux kernel did something to cause it. Did anyone know any hints?

thanks,

Raymond

  • 0
    Prodigy 50 points

    Oh, Another hint is that. If we boot up from MMC0, not SPI0. We actually can reboot from linux. So something wrong related with SPI flash.

  • 0 in reply to changbing zhao
    TI__Guru* 86160 points

    Raymond, is it possible for you to connect with JTAG after the failure and read the CONTROL_STATUS register @0x44E10040?  I would like to see what SYSBOOT settings are latched in.  Maybe these are getting latched incorrectly because the kernel is changing things at the board level

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 50 points

    Hi, James

    Thanks for the suggestion. There is no JTAG in my board. But I agree with you, that is the right direction. Because I found out that if I have a SD card in MMC0, the reboot actually works fine. That means:

    1. There is a possibility that somehow BOOT[4:0] are changed during the reboot procedure. My hardware default value is 10111b. So it boot from MMC0 first, and then look for SPI0. I used a scope to monitor the BOOT[4:0] pins, there are NOT changed at all in all the time. So, the SYSBOOT should be latched correctly. Also, according to the fact that my board can reboot from SD card. Looks like that CPU is works fine.

    2. So, since the above possibility is proved not happen. It must be the SPI flash. Somehow after reset, SPI flash is in a "wrong" status? So that CPU read back some garbage data from flash, then it tried to run it and, it hangs there. I am going to use a logic analyzer to monitor the SPI bus to see what it is read there.

    Please let me know if you have any other thought.

    thanks,

    Ray

  • 0 in reply to changbing zhao
    Prodigy 50 points

    Hi, 

    Now I kind of know what happened. When I reboot from Linux, somehow either my SPI flash in a wrong status or the CPU's SPI ports in a wrong status. Every time I read from SPI flash, the first byte is always 0xff. Then the following bytes are correct data.

    This explained why the system can not reboot from SPI flash. 

    But, I still do not know how to fix it. My flash is spansion S25FL256S. I know it is pretty new chip. And, it is 32M chip. So we have to use spansion's extension command to access it. I am not sure if Linux support this chip very well. 

    If anyone has any idea, please let me know.

    Thanks,

  • 0 in reply to changbing zhao
    Intellectual 370 points

    Hi All,

    We're facing the same problem. We've a customized board with am3352 and we're booting from nand flash. For the command reboot I got the same behavior, ie hardware reset does not work anymore and only power off,power on will reboot the system.

    Since we're not using SPI flash, I guess it is not directly related to SPI flash. 

    I also observed that we don't have any problem with poweroff command. 

    I'll further analyze this.

    Kind regards

    Sam

  • 0 in reply to Samuel Egli
    Intellectual 370 points

    Hi All,

    I had a look how reset is implemented in u-boot since it's working there. It looks like u-boot uses the WARM reset. The work around / solution is then to use in linux kernel the mask OMAP4430_RST_GLOBAL_WARM_SW_MASK (0x1) instead. 

    Then we have the same implementation in linux kernal and u-boot. 

    Kind regards

    Sam

  • 0 in reply to changbing zhao
    Prodigy 10 points

    I think I found the problem.

    We have the same problem and a readback of the Bank Register showed why. It returns 0x80.

    The manual of the S25FL256S contains states that bit 7 of the BR is the Extended Address Enable:

    1 = 4-byte (32-bits) addressing required from command.
    0 = 3-byte (24-bits) addressing from command + Bank Address

    What means, that the read(0x03) needs a four byte address and the bootrom sends a 3-byte address.

    After I reset the BR (transfer: 0x17 0x00) the read succeded and the bootrom was able to load the bootloader.

    This means that before a reset of the board, the BR should be reset to 0x00.

    Michael