• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 1598 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] Re-Flashing Images to the SPI Flash

Joe Tijerina
Intellectual 680 points
Other Parts Discussed in Thread: OMAP-L138, OMAP-L137, OMAPL138

 

The Getting Started Guide (http://tiexpressdsp.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures) section "Flashing images to SPI Flash" describes two methods for flashing images to SPI Flash.  Method 1 using the Serial Flashing Host Utility (sfh_OMAP-L138.exe) and the other method is using the CCS SPI flasher tool.  

This section mentions that either of these utilities can be used to write the UBL and U-Boot images to SPI Flash, however I'm wondering if these utilities can also handle writing kernel and root file system images to the Flash as well?  I will not be using an ethernet so the method described in (http://tiexpressdsp.com/index.php/Booting_Linux_kernel_using_U-Boot) will not work for me.

  1. Select the serial flash device:
U-Boot> sf probe 0
  • Download uImage and copy it to the SPI flash partition:
U-Boot> tftp 0xc0700000 uImage
U-Boot> sf erase 0x80000 0x200000
U-Boot> sf write 0xc0700000 0x80000 0x200000
  • Download ramdisk-base.gz and copy it to the SPI flash partition:
U-Boot> tftp 0xc1180000 ramdisk-base.gz
U-Boot> sf erase 0x280000 0x400000
U-Boot> sf write 0xc1180000 0x280000 0x400000
  • 0
    TI__Mastermind 24340 points

    Hi Joe,

    What is failing with the procedure in the page http://tiexpressdsp.com/index.php/Booting_Linux_kernel_using_U-Boot#SPI_Flash ?

    Try typing it again checking for typos... I was able to make it work.

    In order to check if it is working, you can check the memory contents:

    U-Boot> sf probe 0

    Make sure the the name of the file is correct:

    U-Boot>tftp 0xc0700000 uImage               

    Read the memory to see what was copied:

    U-Boot>md.b 0xc0700000

    U-Boot> sf erase 0x80000 0x200000

    U-Boot> sf write 0xc0700000 0x80000 0x200000

    U-Boot> sf read 0xc0700000 0x80000 0x200000

    Read the memory to see what was copied:

    U-Boot>md.b 0xc0700000

    Do the same for the file system...

  • 0 in reply to Mariana
    TI__Mastermind 25876 points

    >>U-Boot> tftp 0xc1180000 ramdisk-base.gz

    Don't you need to untar the file system first?  Or can tftp handle a compressed filesystem?

  • 0 in reply to Joe G.
    TI__Mastermind 24340 points

    No need to untar. It can handle it.

     

     

  • 0 in reply to Mariana
    TI__Mastermind 25876 points

    Mariana,

    Which dspubl/armubl/uboot version are you using?

    I'm using the ones from PSP_02_20_00_05 (that can boot uImage from USB).  When I program ramdisk.gz on OMAP-L137 Starter Kit, it corrupts the uboot.

    Is there some kind of SPI Flash map conflict/overwrite going on with dspubl/armubl/uboot + uImage + ramdisk.gz?

    I can boot ramdisk.gz over tftp with the uImage in SPI Flash successfully.  I can even read back (as you recommended above) the beginning of ramdisk.gz.  But booting gives a kernal panic meaning something at the end of ramdisk.gz in SPI Flash is probably corrupted.  And the "sf write" commands are pretty open loop in uboot.

    Do we document the SPI Flash map anywhere?

     

  • 0 in reply to Joe G.
    TI__Mastermind 25876 points

    Just realized I am using:

    >>>For Montavista for OMAP-L137, use the file: /opt/mv_pro_5.0/montavista/pro/devkit/arm/v5t_le/images/ramdisk.gz
    from PSP_02_20_00_01 or maybe even an older beta.

    Maybe the ramdisk file is too big and wrapping over the SPI Flash memory map and corrupting dspubl/armubl/uboot at 0x0?

    Are you using from ramdisk.gz from: http://tiexpressdsp.com/index.php/GSG:_Installing_the_Software_for_OMAP-L138#About_the_PSP_package ?

    I can quickly retry with a newer ramdisk.gz.

  • 0 in reply to Joe G.
    TI__Mastermind 24340 points

    Joe,

    I tried the procedures in the page http://tiexpressdsp.com/index.php/Booting_Linux_kernel_using_U-Boot with OMAP-L138, with the:

    /home/<user>/OMAP_L138_arm_1_00_00_04/DaVinci-PSP-SDK-03.20.00.05/images/fs/ramdisk-base.gz

    The OMAP-L138 board has 8 MB of spi flash, while the board for OMAP-L137 has only 4MB, so it could be a space problem indeed.

  • 0 in reply to Mariana
    Intellectual 680 points

    I'm currently having self rebooting issues on my OMAPL138 eXperimenter running Timesys Linux.  I had been using the same kernel and  RFS, booting with TFTP and NFS, for some time until I started having NFS server issues(separate topic), so as a workaround I am now attempting to boot from the SPI Flash.  I first copy the kernel and ramdisk images to flash by following http://tiexpressdsp.com/index.php/Booting_Linux_kernel_using_U-Boot.  However,  after I successfully bootup and get to the linux prompt, the arm reboots itself.   Sometimes it reboots after running simple linux cmds (ls, cd dir, etc), and more consistently after inserting a linux device driver module, such as dsplinkk.ko, and running a DSP Link related application.   I was able to run dsplink drivers and apps before with NFS and never had a problem, which makes me think that I may have a problem with my ramdisk.  I am using these instructions, http://wiki.davincidsp.com/index.php/Creating_a_RAMDISK, to create the ramdisk.gz file that I copy into flash.  Is this a correct method? 

    The size of my RFS including my dsplink driver module and apps is ~8MB, hence I'm creating a 10MB ramdisk.  Could my ramdisk size be the culprit of the reboots i'm seeing?  Should I increase the size?  And should it match the U-boot 'bootargs' 'mem' variable (What does this 'mem' variable specify?     

    # dd if=/dev/zero of=ramdisk bs=1M count=10                     
    # mkfs ramdisk

    # mkdir mnt
    # mount -o loop ramdisk mnt
    #cp -r filesys/* mnt
    #umount mnt
    #gzip ramdisk

     

  • 0 in reply to Joe Tijerina
    Intellectual 680 points

    Well, I tried increasing the size of my RAMDISK to 32MB, but the ARM processor continues to reboot itself after running simple linux commands (i.e. ls) on the shell. 

    I have also tried reflashing the first stage bootloader (UBL AIS) and U-boot but same thing.  Any ideas on what could be causing the processor to reboot itself like this?

  • 0 in reply to Mariana
    Intellectual 315 points

    Mariana,

    I have tar this:

    sudo tar xvfz arago-demo-image-da850-omapl138-evm.tar.gz

    But there is no ramdisk-base.gz

    Where I can get the ramdisk-base.gz?

    I'm using L138 EVM

    Thanks

    Shaul

     

     

     

  • 0 in reply to shauly
    TI__Mastermind 25876 points

    Revisited this and found ramdisk-base.gz  from OMAP-L138_PSP_1_00_00_04\LSP\OMAP_L138_arm_1_00_00_04\DaVinci-PSP-SDK-03.20.00.05\images\fs.

    Not sure why ramdisk-base.gz  is not included in later PSP's.

    >>Is there some kind of SPI Flash map conflict/overwrite going on with dspubl/armubl/uboot + uImage + ramdisk.gz?

    I looked closer at the numbers and realized that a 2 MByte uImage + 3 Mbyte ramdisk-base.gz  was not going to fit into a 4 MByte SPI Flash (dspubl/armubl/uboot is under 1/2 Mbyte).  I do know of someone who has made a smaller uImage and minimal RAMDISK and will try to fit into 4 MByte SPI Flash.

    But for us mortals, a co-worker came up with a nice workaround to boot RAMDISK standalone.  You can put ramdisk-base.gz  along with uImage into a USB stick.  So the following boot command worked for me (no network or SD card needed.  Just a FAT32 USB memoru stick:

    setenv bootargs console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0xc1180000,4M mem=32M ip=192.168.1.111:192.168.1.1:255.255.255.0:::off; usb reset;fatload usb 0:1 0xC0700000 uImage ;fatload usb 0:1 0xc1180000 ramdisk-base.gz; bootm

    Enjoy! But don't forget that a RAMDISK is not persistent and you lose any changes to the filesystem when the power goes off.  But it makes for a nice standalone demo to get login prompt and basic functionality.