• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1094 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 EVM SPI Flash read performance and boot time

Delio Brignoli
Intellectual 500 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

I am looking at the reducing boot time for the OMAP-L138 SoM. The current bottleneck is the SPI Flash read speed in U-Boot of about 0.6 Mb/s. U-Boot sets the SPI clock at 50MHz, so I would expect a faster transfer rate. Is there a reason for keeping the transfer rate low or is it simply lack of optimization?

Thank you

--

Delio

  • 0
    TI__Guru 62975 points

    Delio,

    Is the bottleneck that you refer to taking place while U-Boot is being copied from SPI into internal memory or when U-Boot is copying application code from SPI to memory?

    -Tommy

  • 0 in reply to tlee
    Intellectual 500 points

    Hello Tommy,

    I was referring to U-Boot copying the application code from SPI Flash into RAM. In my case it's the linux kernel + initial ramdisk image. The total size is around 6.3 Mb and at 0.6 Mb/s it takes about 10 seconds to copy.

    Thanks

    --Delio

  • 0 in reply to Delio Brignoli
    TI__Mastermind 25311 points

    My guess is unoptimized copies of data from flash to system memory.  See the following wiki article for explanation of how other users have optimized this process. 

    http://wiki.davincidsp.com/index.php/All_This_For_1_Second_Boot

    The wiki article deals with DM6446 and targets NOR flash boot, but I believe the concepts should be similar.  Note this statement:

    "u-boot memory copy code is not optimal. CPU does byte by byte copy. "

  • 0 in reply to Gus Martinez
    Genius 3235 points

    We have scoped the SPI clock and have discovered that each SPI byte read takes ~160ns (correct for 50MHz SPI clock).  Then there is a ~1us delay between the next SPI read.  SO the question is whats going on here?.  Is the mDDR not setup correctly?.  Is it the fact that (we believe) the L2 cache is not enabled?.

    We also want to make sure that someone else in the community is not working on this, before we embark on finding a fix.

    Steve Turner (AudioScience)

  • 0 in reply to Stephen Turner
    TI__Guru 62975 points

    Steve,

    Is the 1us delay taking place during uboot?

    -Tommy

  • 0 in reply to tlee
    Genius 3235 points

    Hi Tommy

     

    We see the 1us delay (per byte) when u-boot is copying the linux kernel into RAM.

     

    We have looked at the u-boot code for doing this and don't see anything that jumps out at us as being wrong.

     

    We are going to try repeating this from a linux app to see if the SPI linux driver has the same problem, or its u-boot specific.

     

    -steve

  • 0 in reply to Stephen Turner
    TI__Guru 62975 points

    Steve,

    I think the problem is that the uboot read request to SPI only asks for 1 byte per request (loop iteration) when the SPI flash is capable of supporting multiple bytes per request.  Reading in multiple bytes at a time would reduce the number of 1us dead time occurrences.  While the 1 byte per request is inefficient, it will work with just about any application and flash.

    -Tommy