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.

  • TI Thinks Resolved

OMAP-L138 EVM SPI Flash read performance and boot time

Intellectual 460 points

Replies: 7

Views: 5430

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

  • Guru 51745 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

  • In reply to tlee:

    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

  • In reply to Delio Brignoli:

    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. "

    Gus Martinez

  • In reply to Gus Martinez:

    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)

    Stephen Turner

    AudioScience, Inc

  • Guru 51745 points

    In reply to Stephen Turner:

    Steve,

    Is the 1us delay taking place during uboot?

    -Tommy

  • In reply to tlee:

    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

    Stephen Turner

    AudioScience, Inc

  • Guru 51745 points

    In reply to Stephen Turner:

    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

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.