• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 842 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.

OMAP L138 boot problem

Mathias Schmitz
Prodigy 120 points

Other Parts Discussed in Thread: OMAP-L138

Hi,

prelude:

I have followed the instructions from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/latest/index_FDS.html, including setting up a virtual machine, of course. I then tried to follow the latest SDK-Guide. I went from "creating an SD-card" to "flashing it" and back all steps were successful. (I used an 1GB SD-card.)
At step 5 I tried to run the script: host $ ${DVSDK}/bin/setup-uboot-env.sh
This failed, at least nothing happened. It appears to me that minicom 2.4 can't connect to the board.


OPTIONS: I18n
Compiled on Jan 25 2010, 06:49:09.
Port /dev/ttyS2

Press CTRL-A Z for help on special keys

PuTTy works with the same settings though.

After trying a few times I decided to run the commands from the script via PuTTy myself. This included editing the original environment variables, which I unfortunately didn't back up. The board used to boot up by just turning it on. I tried to fix it by setting but it didn't really help:
setenv bootargs 'mem=32M console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0xc1180000,4M ip=off'
setenv bootcmd 'sf probe 0;sf read 0xc0700000 0x80000 0x200000;sf read 0xc1180000 0x280000 0x300000;bootm 0xc0700000'

variables:

U-Boot > printenv
ethaddr=00:08:ee:03:70:2c
ipaddr=192.168.227.196
bootfile=uImage
serverip=192.168.227.123
bootdelay=4
baudrate=115200
oldbootargs=${bootargs}
oldbootcmd=${bootcmd}
bootargs=mem=32M console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0xc1180000,4M ip=off
bootcmd=sf probe 0;sf read 0xc0700000 0x80000 0x200000;sf read 0xc1180000 0x280000 0x300000;bootm 0xc0700000
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.11 (Mar 24 2011 - 23:24:35)

booting:

U-Boot 2009.11 (Mar 24 2011 - 23:24:35)

I2C:   ready
DRAM:  64 MB
MMC:   davinci: 0
In:    serial
Out:   serial
Err:   serial
ARM Clock : 300000000 Hz
DDR Clock : 132000000 Hz
Net:   Ethernet PHY: GENERIC @ 0x00

Hit any key to stop autoboot:  0
8192 KiB M25P64 at 0:0 is now current device
## Booting kernel from Legacy Image at c0700000 ...
   Image Name:   Linux-2.6.33-rc4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2113688 Bytes =  2 MB
   Load Address: c0008000
   Entry Point:  c0008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

 

Could anyone please provide me with the correct settings?
Just in case this doesn't work out, what would be the quickest way to get the system back running?

Any help would be very appreciated,

Mathias

  • 0
    Guru 26430 points

    The TI Wiki has some notes that wipe out the env memory and restore from defaults:

    http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_factory_default_U-Boot_environment_variables

    It mentions the u-boot source file "include/configs/da850_evm.h". That file sets CONFIG_ENV_SIZE=0x10000 and CONFIG_ENV_OFFSET=0x40000.

    Wiping an arbitrary section seems a bit scary to me. On my platform, the board defaults were different than the u-boot soruce defaults. Something changed from source to production. Maybe first try the defaults bootcmd and bootargs in "include/configs/da850_evm.h".

    setenv bootargs 'mem=32M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait ip=off'
    setenv bootcmd 'if mmc rescan 0; then if fatload mmc 0 0xc0600000 boot.scr; then source 0xc0600000; else fatload mmc 0 0xc0700000 uImage; bootm c0700000; fi; else sf probe 0; sf read 0xc0700000 0x80000 0x220000; bootm 0xc0700000; fi'

    The setting above assume Linux uses a SD Card for it's file system and env vars can be on the SD Card. In your bootcmd example it assume a ramdisk for it's filesystem. Not the same board? Is your board one of TI's EVMs? Maybe someone with the same board can print out their environment variables.

     

  • 0 in reply to Norman Wong
    Prodigy 120 points

    Hello Norman,

    first off, thanks for your reply. This got me a little further.

    Norman Wong said:

    The TI Wiki has some notes that wipe out the env memory and restore from defaults:

    http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_factory_default_U-Boot_environment_variables

    It mentions the u-boot source file "include/configs/da850_evm.h". That file sets CONFIG_ENV_SIZE=0x10000 and CONFIG_ENV_OFFSET=0x40000.

    setenv bootargs 'mem=32M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait ip=off'
    setenv bootcmd 'if mmc rescan 0; then if fatload mmc 0 0xc0600000 boot.scr; then source 0xc0600000; else fatload mmc 0 0xc0700000 uImage; bootm c0700000; fi; else sf probe 0; sf read 0xc0700000 0x80000 0x220000; bootm 0xc0700000; fi'

    This information was very useful as it solved my CRC-problem.

    Norman Wong said:

    Wiping an arbitrary section seems a bit scary to me. On my platform, the board defaults were different than the u-boot soruce defaults. Something changed from source to production. Maybe first try the defaults bootcmd and bootargs in "include/configs/da850_evm.h".

    My da850_evm.h uses the same offset:

    #ifdef CONFIG_USE_SPIFLASH
    #undef CONFIG_ENV_IS_IN_FLASH
    #undef CONFIG_ENV_IS_IN_NAND
    #define CONFIG_ENV_IS_IN_SPI_FLASH
    #define CONFIG_ENV_SIZE            (64 << 10)
    #define CONFIG_ENV_OFFSET        (256 << 10)
    #define CONFIG_ENV_SECT_SIZE        (64 << 10)   
    #define CONFIG_SYS_NO_FLASH
    #endif

    But experiencing the trouble I have, I will try to avoid erasing this section as long as I can until I really know what I'm doing there.

    I still would like to boot the OMAP up without the SD-card before I messed things up. I assume that would mean booting from SPI-Flash. So I would need the correct environment variables for that. I don't know if ram0 is the correct setting as a device - probably not. When I run:

        setenv bootcmd 'sf probe 0;sf read 0xc0700000 0x80000 0x220000;bootm 0xc0700000'
        setenv bootargs mem=32M console=ttyS2,115200n8 root=/dev/mmcblk0p1 rw rootdelay=3 ip=off
        setenv bootfile "uImage"
        saveenv

        VFS: Unable to mount root fs via NFS, trying floppy.
        VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)
        Please append a correct "root=" boot option; here are the available partitions:
        1f00             256 mtdblock0 (driver?)
        1f01              64 mtdblock1 (driver?)
        1f02            7808 mtdblock2 (driver?)
        1f03              64 mtdblock3 (driver?)
        Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
        Backtrace:
        [<c0031730>] (dump_backtrace+0x0/0x114) from [<c0320420>] (dump_stack+0x18/0x1c)
         r7:00008000 r6:c1c13000 r5:c0025a08 r4:c0446f38
        [<c0320408>] (dump_stack+0x0/0x1c) from [<c0320488>] (panic+0x64/0x13c)
        [<c0320424>] (panic+0x0/0x13c) from [<c0008fec>] (mount_block_root+0x1e0/0x220)
         r3:00000001 r2:00000001 r1:c1c23f60 r0:c03b5856
        [<c0008e0c>] (mount_block_root+0x0/0x220) from [<c00090f0>] (mount_root+0xc4/0xfc)
         r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:00200000
        [<c000902c>] (mount_root+0x0/0xfc) from [<c0009298>] (prepare_namespace+0x170/0x1c8)
         r5:c0025a08 r4:c0446a20
        [<c0009128>] (prepare_namespace+0x0/0x1c8) from [<c00084c8>] (kernel_init+0xf0/0x12c)
         r5:00000000 r4:c04467e0
        [<c00083d8>] (kernel_init+0x0/0x12c) from [<c0045424>] (do_exit+0x0/0x6b4)
         r5:00000000 r4:00000000

        I got this information from http://processors.wiki.ti.com/index.php/GSG:_Booting_the_OMAP-L138/AM18x_Out_of_the_Box
        If someone could verify that these instructions are correct I would run those:

        U-Boot> sf probe 0
        U-Boot> sf erase 40000 10000
        reset
        U-Boot> saveenv

    Norman Wong said:

    The setting above assume Linux uses a SD Card for it's file system and env vars can be on the SD Card. In your bootcmd example it assume a ramdisk for it's filesystem. Not the same board? Is your board one of TI's EVMs? Maybe someone with the same board can print out their environment variables.

    Yes, I tried to run an image from my SD-card. The SD-card will boot until it loads the CMEMK-module. It just stops right after this:

    CMEMK module: built on Mar 24 2011 at 23:44:42
      Reference Linux version 2.6.33
      File /sdk/build/DVSDK_4_02/4_02_00_06/arago-install/arago-tmp/work/da850-omapl138-evm-none-linux-gnueabi/ti-linuxutils-1_2_26_01_02-r52d/linuxutils_2_26_01_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.c
    CMEM Range Overlaps Kernel Physical - allowing overlap
    CMEM phys_start (0xc2000000) overlaps kernel (0xc0000000 -> 0xc6000000)
    allocated heap buffer 0xc9000000 of size 0x1200000
    heap fallback enabled - will try heap if pool buffer is not available

    For this problem I will try to go through the SDK-Guide once again.

    As far as I can tell it is a "ZOOM OMAP-L138 eXperimenter Kit based on Texas Instruments' OMAP-L138 applications processor".

     

    Regards,

    Mathias

  • 0 in reply to Mathias Schmitz
    Guru 26430 points

    I can't quite tell which direction you are going and which problem to consider. Any reason for avoiding the SD Card? Using SPI flash for both kernel and FS can be a bit unwieldy. The ramdisk means that any changes you make to the FS during runtime will be lost on reboot.

    It is strange that the CMEMK error would prevent boot. Maybe leave out CMEMK on boot for now. Load up CMEMK manually after boot. Did this fail "out-of-the-box" with the factory SD Card?

     

  • 0 in reply to Norman Wong
    Prodigy 120 points

    Norman Wong said:
    I can't quite tell which direction you are going and which problem to consider. Any reason for avoiding the SD Card? Using SPI flash for both kernel and FS can be a bit unwieldy. The ramdisk means that any changes you make to the FS during runtime will be lost on reboot.

    I'm not trying to avoid the SD-card but i just like to have the possibility to go back where I came from. I wasn't clear on my aim, sorry for confusion.

     

    Norman Wong said:
    It is strange that the CMEMK error would prevent boot. Maybe leave out CMEMK on boot for now. Load up CMEMK manually after boot. Did this fail "out-of-the-box" with the factory SD Card?

    Re-running through everything didn't help. It seems to me that my terminal program didn't print the last few lines of the boot process. This is why it looked like CMEMK was causing the hangup which it actually didn't.
    The system on the SD-card tried to calibrate the touchscreen which is not available with my kit. This was causing the hangup.
    All i did was renaming one file to avoid any further hangups:
    "mv S99matrix-gui-e K99matrix-gui-e" in "ROOTFS/etc/rc5.d" on the SD-card filesystem.

    Thanks for your input Norman, helped me a great deal.

    Mathias

  • 0 in reply to Mathias Schmitz
    Intellectual 280 points

    hi mathias

    i am facing a similar problem, my booting stops after this calibration process, i also have the old zoom EVM omap l138 board, can be pls explain in detail how you were able to go forward.

    Thanks 

    Hitesh