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 with 64M Bytes SDRAM hangs at U-Boot

Other Parts Discussed in Thread: AM3352

I am debugging a AM3352 board with only 64M bytes DDR2.

I start that modification based on the source code "ti-processor-sdk-linux-am335x-evm-02.00.02.11" with the configuration file of "am335x_evm_defconfig".

I have change the DDR2 configuration and it can start U-Boot SPL from UART. The U-Boot SPL can load the U-Boot without problem. But U-boot always hangs after showing "DRAM:  64MiB". I have added a lot of puts() to trace it, and finally it is found it hanged at "memset((void *)mem_malloc_start, 0x0, size);" inside mem_malloc_init() function of "dlmalloc.c".

I suspect that it is related to the memory usage conflict. Since the original am335x_evm_defconfig assumes the system has 512M bytes memory, how to modify the #define inside the files (e.g. ti_armv7_common.h, am335x_evm.h, etc) to make it run under 64M bytes.

Regards,

Colman

  • Hi Colman,

    Have you verified your DDR2 memory is set up correctly? Are you able to access/read/write this DDR2 memory from CCS?

    I would recommend you to remove the puts() as these will increase the size of u-boot and debug with CCS instead. See the below wiki page how:
    processors.wiki.ti.com/.../Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5_sdk7
    processors.wiki.ti.com/.../Sitara_Linux_SDK_Training - see u-boot debug with CCS ppt

    BR
    Pavel
  • Can you also share which toolchain you are using, the steps you are using to create u-boot-spl.bin and u-boot.img?

    Can you also try with the default u-boot code base?

    See also the below wiki pages:

     http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User's_Guide

    BR
    Pavel

  • Check if you have configured the DDR parameters and timings correctly: processors.wiki.ti.com/.../AM335x_EMIF_Configuration_tips
  • I have checked the DDR2 setup, I follow AM335x EMIF Configuration tips from processors.wiki.ti.com, the setting is OK. It can boot up to U-Boot environment sometimes, but most of the time it stop after showing DRAM size.
    I don't have the JTAG tools, so I cannot use CCS to debug it.
  • I am using the whole set of "ti-processor-sdk-linux-am335x-evm-02.00.02.11-Linux-x86-Install.bin", including the toolchain.
    The default u-boot code will not work because there is no EEPROM storing the board ID, it will not start.

    The default u-boot assumes having 512Mbyte SDRAM, it use 16Mbyte area for malloc, and spl loads the u-boot at 32M bytes offset. But my board only have 64M bytes, these setup seems does not fit the system. I want to know how to change the address where the SPL and U-Boot load and how to make U-Boot use smaller memory. 

    Regards,

    Colman

  • Dear all,

    I change the CONFIG_SYS_MALLOC_LEN from 16M bytes to 256K bytes, U-boot can boot up without problem. I have tried to set it to 512K bytes or 1M bytes, they all fails to boot up, it hangs at mem_malloc_int function. This proves that the DDR2 configurations is fine, the only issue is the memory size problem. 256K bytes for malloc is too small for me, I want it around 1M bytes. Another issue is the kernel and FDT loading location, From the ti_armv7_common.h, it states:
    /*
    * We setup defaults based on constraints from the Linux kernel, which should
    * also be safe elsewhere. We have the default load at 32MB into DDR (for
    * the kernel), FDT above 128MB (the maximum location for the end of the
    * kernel), and the ramdisk 512KB above that (allowing for hopefully never
    * seen large trees). We say all of this must be within the first 256MB
    * as that will normally be within the kernel lowmem and thus visible via
    * bootm_size and we only run on platforms with 256MB or more of memory.
    */
    It clearly say that the current setup only run on platforms with 256MB or more of memory, how to change it to run under 64MB memory?

    Regards,
    Colman
  • Colman Lai said:
    I start that modification based on the source code "ti-processor-sdk-linux-am335x-evm-02.00.02.11" with the configuration file of "am335x_evm_defconfig".

    According to the u-boot user guide (link below), you should use am335x_evm_config

    http://processors.wiki.ti.com/index.php/Linux_Core_U-Boot_User's_Guide#Compiling_MLO_and_u-boot

    Colman Lai said:
    I have change the DDR2 configuration and it can start U-Boot SPL from UART. The U-Boot SPL can load the U-Boot without problem.

    Do you pass any DDR2 address from console for loading the 2nd stage u-boot.img?

    Regards,
    Pavel

  • The latest status is I reduce the CONFIG_SYS_MALLOC_LEN to 256K, it works fine and it hangs if it is set to 512K or more. But I need to reserve around IM bytes. I believe that some constants have to be change, but I don't know what it is. Please note that my system only have 64M, but the SDK assume it has 256M or more.

    Colman
  • Colman,

    Can you provide full console log for the working case and for the non-working case?

    Note that u-boot-spl.bin start at internal addr of 0x402F0400 and u-boot.img start from DDR address 0x80800000.

    You should explore u-boot.map and u-boot.cfg files.

    Regards,
    Pavel
  • By default, CONFIG_SYS_SPL_MALLOC_SIZE = CONFIG_SYS_MALLOC_LEN. If I set CONFIG_SYS_MALLOC_LEN to 1M and set CONFIG_SYS_SPL_MALLOC_SIZE to 256K, it works fine. I know CONFIG_SYS_MALLOC_LEN is used to set the malloc area size for U-boot. But what is the CONFIG_SYS_SPL_MALLOC_SIZE for? Is it only used by SPL? Will the claimed area of CONFIG_SYS_SPL_MALLOC_SIZE be freed after U-boot is running?

    Colman
  • Colman Lai said:
    it hangs at mem_malloc_int function

    In which u-boot file?

    Colman Lai said:
    /*
    * We setup defaults based on constraints from the Linux kernel, which should
    * also be safe elsewhere. We have the default load at 32MB into DDR (for
    * the kernel), FDT above 128MB (the maximum location for the end of the
    * kernel), and the ramdisk 512KB above that (allowing for hopefully never
    * seen large trees). We say all of this must be within the first 256MB
    * as that will normally be within the kernel lowmem and thus visible via
    * bootm_size and we only run on platforms with 256MB or more of memory.
    */
    It clearly say that the current setup only run on platforms with 256MB or more of memory, how to change it to run under 64MB memory?

    I think this limitation is valid only when you want to load u-boot (1st and 2nd stage), linux kernel, FDT and ramdsik. For only loading u-boot (1st stage and 2nd stage), 64MB of DDR should be enough.

    Regarding malloc issue, you can try to remove or adjust the compression support, which is using malloc, see:

    u-boot/README

    u-boot/common.bootm.c

    Also you can disable USB EHCI and MTD UBI support from the u-boot, as it seems USB EHCI and MTD UBI are also using malloc:

    u-boot/drivers/usb/host/ehci-hcd.c

    u-boot/mtd/ubi/build.c

    Regards,
    Pavel

  • Colman Lai said:
    By default, CONFIG_SYS_SPL_MALLOC_SIZE = CONFIG_SYS_MALLOC_LEN. If I set CONFIG_SYS_MALLOC_LEN to 1M and set CONFIG_SYS_SPL_MALLOC_SIZE to 256K, it works fine. I know CONFIG_SYS_MALLOC_LEN is used to set the malloc area size for U-boot. But what is the CONFIG_SYS_SPL_MALLOC_SIZE for? Is it only used by SPL? Will the claimed area of CONFIG_SYS_SPL_MALLOC_SIZE be freed after U-boot is running?

    CONFIG_SYS_SPL_MALLOC_SIZE - The size of the malloc pool used in SPL.

    See the below pointers for more info:

    u-boot/README

    Regards,
    Pavel

  • Pavel,

    Can I change u-boot.img start address to 0x80400000? If can, how?

    Regards,
    Colman
  • Colman,

    This is configured from u-boot/include/configs/ti_armv7_common.h
    #define CONFIG_SYS_TEXT_BASE 0x80800000

    You can change 0x80800000 with 0x80400000. This should work fine for UART boot, as UART boot does not have image header (like NAND, MMC has). See the below e2e thread for more info:
    e2e.ti.com/.../1166617

    Regards,
    Pavel
  • Pavel,

    I asked this question because the CONFIG_SYS_TEXT_BASE has been defined somewhere else before the include of "ti_armv7_common.h". Will there be a problem if I un-define it and change it?

    Regards,
    Colman

  • Colman Lai said:
    I asked this question because the CONFIG_SYS_TEXT_BASE has been defined somewhere else

    Where exactly? I can not find such place

    Colman Lai said:
    Will there be a problem if I un-define it and change it?

    I have not tested this on my side

  • Pavel,

    I put a #error statement inside the #ifndef... #endif statement and proved that it has been defined. I cannot find it out so I ask for help.

    Colman

  • Colman,

    I just test on my side, when I change CONFIG_SYS_TEXT_BASE from 0x80800000 to 0x80400000 (in u-boot/include/configs/ti_armv7_common.h) and it seems to work fine. I can see the change in the newly generated u-boot.map and u-boot.cfg files.

    The configuration files in u-boot/include/configs/ that effect the AM335x u-boot are:

    am335x_evm.h

    ti_am335x_common.h

    ti_armv7_omap.h

    ti_armv7_common.h

    The only place that effect the CONFIG_SYS_TEXT_BASE value is in the am335x_evm.h, if you build u-boot for NOR boot:

    /*

    * For NOR boot, we must set this to the start of where NOR is mapped

    * in memory.

    */

    #ifdef CONFIG_NOR_BOOT

    #define CONFIG_SYS_TEXT_BASE 0x08000000

    #endif

    Note that CONFIGS_SYS_SPL_ARGS_ADDR (in ti_am335x_common.h) is defined at 0x88000000 which might not fit your DDR2, so you might change it also.

    Regards,
    Pavel