• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1474 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.

AM572x load U-boot in OCM2 memory

Tom Antles
Intellectual 370 points

Other Parts Discussed in Thread: 4460

I would like to modify the SPL so that it loads the U-boot image into OCM 2 starting at address 0x4040 0000 instead of into SDRAM.

So I added the following to the /include/configs/am57xx_evm.h file:

/* load the u-boot image into the 1Mbyte OCMC_RAM2 */
#define CONFIG_SYS_TEXT_BASE 0x40400000

I compile using the following command and everything builds fine.

make O=am57xx_evm am57xx_evm_config  all

(I first deleted the output folder:  am57xx_evm before running the above make command)

However, when I create the SD card and plug it into the target,  the output in the serial window freezes like this and goes no further:

U-Boot SPL 2015.07-00064-g1c259e6-dirty (Aug 01 2016 - 15:36:36)
DRA752-GP ES2.0
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img

Any idea what I am doing wrong?  It seems this should be very easy to do!!!

I am running linux sdk 2.00.02.11 with u-boot 20015.07 for am57xx evm.

  • 0
    TI__Guru**** 393215 points
    I will ask the software team to look at this.
  • 0
    TI__Guru 65405 points

    Hi Tom,

    Could you enable u-boot Debug messaging to get more details about your issue. For example you can do this by adding:

    #ifndef DEBUG

    #define DEBUG

    #endif

    to ($uboot)/include/common.h file.

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    TI__Guru 65405 points
    Hi Tom,

    Could you verify weather the On-Chip memory is initialized properly. For details refer to TRM section 15.6.3 OCM Subsystem Functional Description.
    Also check the size of your u-boot image because the OCMC_RAM2 is address space of 1MB.

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 370 points
    I checked System.map and u-boot image size is only 0x8c2b4 (574132) including bss. I don't know how much stack or heap space it uses.

    I read section 15.6.3 and could not find any necessary initialization s that are not already done for the SPL to be loaded and already running in OCM1 (512K) memory which u-boot is being loaded.
  • 0 in reply to Tom Antles
    Intellectual 370 points
    correction: I read section 15.6.3 and could not find any necessary initialization s that are not already done for theSPL to be loaded and already running in OCM1 (512K) memory WHILE u-boot is being loaded.
  • 0 in reply to Cvetolin Shulev-XID
    Intellectual 370 points
    Here is the output with debug on:

    U-Boot SPL 2015.07-00064-g1c259e6-dirty (Aug 02 2016 - 10:28:00)
    DRA752-GP ES2.0
    boot device - 5
    mmc_init: 0, time 65
    spl: mmc boot mode: fs
    reading args
    VFAT Support enabled
    FAT32, fat_sect: 32, fatlength: 1112
    Rootdir begins at cluster: 2, sector: 2256, offset: 11a000
    Data begins at: 2254
    Sector size: 512, cluster size: 1
    FAT read(sect=2256, cnt:1), clust_size=1, DIRENTSPERBLOCK=16
    RootMismatch: |mlo||
    Rootvfatname: |u-boot.img|
    RootMismatch: |u-boot.img|u-boot.img|
    RootMismatch: |u-boot.img||
    RootDentname == NULL - 6
    spl_load_image_fat_os: error reading image args, err - -1
    reading u-boot.img
    VFAT Support enabled
    FAT32, fat_sect: 32, fatlength: 1112
    Rootdir begins at cluster: 2, sector: 2256, offset: 11a000
    Data begins at: 2254
    Sector size: 512, cluster size: 1
    FAT read(sect=2256, cnt:1), clust_size=1, DIRENTSPERBLOCK=16
    RootMismatch: |mlo||
    Rootvfatname: |u-boot.img|
    RootName: u-boot.img, start: 0x89e, size: 0x50c38
    Filesize: 330808 bytes
    64 bytes
    gc - clustnum: 2206, startsect: 4460
    Size: 330808, got: 64
  • 0 in reply to Tom Antles
    Intellectual 370 points
    Here is the output with debug turned on for a GOOD boot. (When u-boot image is loaded SDRAM instead of OCRAM:

    U-Boot SPL 2015.07-00064-g1c259e6-dirty (Aug 02 2016 - 12:08:51)
    DRA752-GP ES2.0
    boot device - 5
    mmc_init: 0, time 65
    spl: mmc boot mode: fs
    reading args
    VFAT Support enabled
    FAT32, fat_sect: 32, fatlength: 1112
    Rootdir begins at cluster: 2, sector: 2256, offset: 11a000
    Data begins at: 2254
    Sector size: 512, cluster size: 1
    FAT read(sect=2256, cnt:1), clust_size=1, DIRENTSPERBLOCK=16
    RootMismatch: |mlo||
    Rootvfatname: |u-boot.img|
    RootMismatch: |u-boot.img|u-boot.img|
    RootMismatch: |u-boot.img||
    RootDentname == NULL - 6
    spl_load_image_fat_os: error reading image args, err - -1
    reading u-boot.img
    VFAT Support enabled
    FAT32, fat_sect: 32, fatlength: 1112
    Rootdir begins at cluster: 2, sector: 2256, offset: 11a000
    Data begins at: 2254
    Sector size: 512, cluster size: 1
    FAT read(sect=2256, cnt:1), clust_size=1, DIRENTSPERBLOCK=16
    RootMismatch: |mlo||
    Rootvfatname: |u-boot.img|
    RootName: u-boot.img, start: 0x11e0, size: 0x50c30
    Filesize: 330800 bytes
    64 bytes
    gc - clustnum: 4576, startsect: 6830
    Size: 330800, got: 64
    spl: payload image: U-Bo load addr: 0x807fffc0 size: 330800
    reading u-boot.img
    VFAT Support enabled
    FAT32, fat_sect: 32, fatlength: 1112
    Rootdir begins at cluster: 2, sector: 2256, offset: 11a000
    Data begins at: 2254
    Sector size: 512, cluster size: 1
    FAT read(sect=2256, cnt:1), clust_size=1, DIRENTSPERBLOCK=16
    RootMismatch: |mlo||
    Rootvfatname: |u-boot.img|
    RootName: u-boot.img, start: 0x11e0, size: 0x50c30
    Filesize: 330800 bytes
    330800 bytes
    FAT32: entry: 0x11e0 = 4576, offset: 0x02e0 = 736
    FAT32: ret: 000011e1, offset: 02e0
    FAT32: entry: 0x11e1 = 4577, offset: 0x02e1 = 737
    FAT32: ret: 000011e2, offset: 02e1
    FAT32: entry: 0x11e2 = 4578, offset: 0x02e2 = 738
    FAT32: ret: 000011e3, offset: 02e2
    FAT32: entry: 0x11e3 = 4579, offset: 0x02e3 = 739
    FAT32: ret: 000011e4, offset: 02e3
    FAT32: entry: 0x11e4 = 4580, offset: 0x02e4 = 740
    FAT32: ret: 000011e5, offset: 02e4
    FAT32: entry: 0x11e5 = 4581, offset: 0x02e5 = 741
    FAT32: ret: 000011e6, offset: 02e5
    FAT32: entry: 0x11e6 = 4582, offset: 0x02e6 = 742
    FAT32: ret: 000011e7 ....
  • 0 in reply to Tom Antles
    Intellectual 370 points
    OK I discovered the problem from the debug logs above.

    when you specify a u-boot load address, for example, #define CONFIG_SYS_TEXT_BASE 0x80800000,
    spl actually starts loading at a lower address than specified by CONFIG_SYS_TEXT_BASE.
    see the log message below:

    spl: payload image: U-Bo load addr: 0x807fffc0 size: 330800

    So when I specified the bottom of OCRAM2, #define CONFIG_SYS_TEXT_BASE 0x40400000,
    spl instead started loading at 0x403fffc0, which is an invalid address.

    So to fix this problem, I just needed to increment the CONFIG_SYS_TEXT_BASE value to make sure that the lower address used by SPL to load the image was a valid OCRAM2 address.

    The REAL QUESTION here is why does SPL start loading from a different address than specified in CONFIG_SYS_TEXT_BASE ? It is obviously very unexpected and confusing that it does that.