AM3354 configure and enable caching of SRAM in U-Boot SPL

Hi Andy,

I will forward this to the SW team.

Andy,

Which version of u-boot are you using? Did you start from SDK6 orSDK7?

Steve K.

Hi Steve,

I started with the generic version u-boot-2014.07 from the Denx FTP site as it included the necessary changes for U-Boot Falcon mode using SPI NOR devices.

My custom board is a hybrid of various parts of the EVM, Starterkit and Beaglebone Black reference platforms and my U-Boot board configuration is likewise a hybrid of the pre-existing TI support.

Andy.

Hi Steve,

Did you manage to get a chance to look into this yet?

Thanks,

Andy.

Started to look at it yesterday. I'll post when I have more information.

Steve K.

I've cloned the tree and applied the patch. My next step will be to debug this.

Steve K.

Hi Steve,

To give you a little more background on what I am trying to achieve...

The board we have uses the 600MHz AM3354 and has a Spansion S25FL164K (8MByte) SPI NOR flash device for holding U-Boot-SPL, U-Boot and the Linux kernel.  The datasheet for that device quotes a transfer rate of 6.25MBytes/sec with a 50MHz SPI clock.  As the McSPI interface only supports a max clock rate of 48MHz I have set CONFIG_SF_DEFAULT_SPEED and CONFIG_ENV_SPI_MAX_HZ to 48000000.

In U-Boot if I run the following command:

U-Boot> time sf read ${loadaddr} 0x00200000 ${loadsize}

It tells me it has read 3391528 bytes in 2.089 seconds which equates to around 1.5MBytes/sec.  In order to get to this level of performance I had to add the OMAP3_MCSPI_CHCONF_TURBO flag to the channel configuration in omap3_spi_read() in drivers/spi/omap3_spi.c.

The ultimate goal is to to use Falcon mode but when testing it the read time for the same Linux kernel image appeared to be 2-3 times longer.  I appreciate that U-Boot-SPL is running from SRAM and not DDR and may be slower and searching around on Google for answers led me to the mailing list question from 2013 referenced in the original post.

I think there may be two issues that need to be looked at here, one is getting the cache enabled in U-Boot-SPL to improve its performance generally but also to look at why the SPI interface performs so poorly even from U-Boot itself.

Regards.

Andy.

Hi Steve,

Just wondering if you had got anywhere with looking into this.

Thanks,

Andy.

Andy,
I've got something working but haven't had the time to post it. I'll post later today or tomorrow. I've been working with NAND and not SPI since I'm more familiar with the NAND code.
Steve K.

Hi Steve,

Hope things are going well with the changes and the testing. Any update on when something will be available to test this end?

Thanks,

Andy.

Hi Andy,

I have gzipped a patch that boots from NAND. For some reason I can't add the DDR to the mmu table, only the internal RAM works.

Steve K.

mmu.patch.gz

Hi Steve,

I have incorporated the patch and it has made a big difference (about 1.2 seconds) to the speed of execution of Falcon mode within U-Boot-SPL on my platform.

With the issue you are having with the DDR and the mmu table what value do you have CONFIG_NR_DRAM_BANKS set to in the board configuration header file as this defines the size of the array gd->bd->bi_dram used for the mmu.

I still haven't reached my target boot time (still got to remove another 0.25 seconds) but that now seems to be directly related to the throughput and performance of the SPI driver as implemented in omap3_spi.c where I appear to be getting about 1.7MB/s throughput rather than the 6.25MB/s the flash device datasheet quotes.

Thanks for your help on this.

Regards,

Andy.

Hi Andy,

CONFIG_NR_DRAM_BANKS is set to 1. I changed it to 2 before trying to initialize DDR but it still didn't work so I took out DDR initialization and set it back to 1.

Steve K.