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.
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?
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?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to tlee:
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.
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.
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.
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)
In reply to Stephen Turner:
Is the 1us delay taking place during uboot?
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.