• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 395 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.

AM3517 Bringup Problem

Clifton Barnes
Prodigy 155 points
Other Parts Discussed in Thread: AM3517

I'm having difficultly bringing up our custom board using the TI AM3517 part.  X-Loader is successfully loaded from the SD card, sets up the DDR, and runs a DDR test that passes successfully.  Then, U-Boot is loaded from the SD card to the DDR successfully.  U-Boot then TFTPs the Linux kernel into DDR and attempts to start Linux.  The Linux image is verified and decompressed but then fails to start.  The same Linux image starts fine on the AM3517 EVM.  I’m using the AM35x-OMAP35x-PSP-SDK-03.00.00.05 release.  I’ve followed the startup assembly code in the Linux kernel and it seems to fail when it’s trying to relocate some startup code and jump to it in arch/arm/boot/compressed/head.S.  This seems to indicate a problem with the DDR, however, U-Boot runs fine out of DDR.  What can I do to debug this issue?  Is there a standard DDR memory test that I should run?  Does anyone have any guidance as to where to look for the problem?

 

Thanks for any help

  • 0
    TI__Expert 5290 points

    Hi,

    U-Boot has a standard memory test command "mtest" which you could try.

    The problem could also be due to incorrect location of the downloaded uImage. There should be sufficient space for the kernel image to get decompressed. If this is not the case then the decompression stage will over-write the compressed image leading to corruption.

    Ex:

    Filename 'uImage'.

    Load address: 0x80000000

     

    bootm 0x80000000

    ## Booting kernel from Legacy Image at 80000000 ...

       Image Name:   Linux-2.6.32-rc2

       Image Type:   ARM Linux Kernel Image (uncompressed)

       Data Size:    1444552 Bytes =  1.4 MB

       Load Address: 80008000

       Entry Point:  80008000

       Loading Kernel Image ... OK

    OK

     

    Starting kernel ...

     

    Uncompressing Linux... done, booting the kernel.

     

    The kernel fails to start here due to wrong placement of uImage in DDR. If the same uImage is downloaded to a diff location like 0x81000000 which leaves sufficient space for decompression and relocation then it boots fine.

  • 0 in reply to Vaibhav Bedia
    Prodigy 155 points

    My load address is at 0x82000000, so I don't believe I should have a problem of not enough space for the decompression and relocation.  Also, using the same U-Boot and variables, this same kernel has run correctly on the EVM.  I've run the mtest but haven't found an error.

     

    ## Booting kernel from Legacy Image at 82000000 ...
       Image Name:   Linux-2.6.32
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    1929264 Bytes =  1.8 MB
       Load Address: 80008000
       Entry Point:  80008000
       Verifying Checksum ... OK
       Loading Kernel Image ... OK
    OK

    Starting kernel ...

    Uncompressing Linux.......................................................................................................................... done, booting the kernel.

    Nothing more happens.

     

  • 0 in reply to Clifton Barnes
    Prodigy 155 points

    It turned out to be an infinite loop in the omap_i2c_isr function in drivers/i2c/busses/i2c-omap.c.  There was a fix added for an errata that might not apply to the AM3517?

                    /*
                     * OMAP3430 Errata 1.153: When an XRDY/XDR
                     * is hit, wait for XUDF before writing data
                     * to DATA_REG. Otherwise some data bytes can
                     * be lost while transferring them from the
                     * memory to the I2C interface.
                     */

                    if (dev->rev <= OMAP_I2C_REV_ON_3430) {
                            while (!(stat & OMAP_I2C_STAT_XUDF)) {
                                if (stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
                                    omap_i2c_ack_stat(dev, stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
                                    err |= OMAP_I2C_STAT_XUDF;
                                    goto complete;
                                }
                                cpu_relax();
                                stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
                            }
                    }

    The underflow flag was never set and therefore it sat in the while loop forever.  Removing this code allowed me to boot successfully.