Did the SPI bus definition change somewhere between LTIB's uboot and current uboot?

[EdSutter]

Until today I had been using u-boot as it comes with LTIB (u-boot-2009.08).

I'm trying to get a little more up-to-date, so I updated to u-boot-2013.10-rc4 today.

In the older version I was able to do an sf probe on bus 1 and bus 5 (I have a sabersd board

with U14 populated (ECSPI-1) and I also have a second device on ECSPI-5 that we are

using to boot from).

Now that I've updated it appears that the bus definitions have shifted down by one because

an array is used to carry ECSPI[1-5] base addresses.  The function spi_setup_slave()

takes an incoming 'bus' value as an argument and used it as an offset into a 5-element table

containing each of the ECSPI[1-5] base addresses.  This means that bus 0 now refers to

ECSPI1, etc...  Is this a known change or am I doing something wrong?

[EdSutter · Accepted solution]

Ok, I think I can answer my own question here.  The LTIB based u-boot for SABRESD has the following code in board/freescale/mx6q_sabresd/mx6q_sabresd.c...

s32 spi_get_cfg(struct imx_spi_dev_t *dev)

{

    switch (dev->slave.cs) {

    case 0:

        /* SPI-NOR */

        dev->base = ECSPI1_BASE_ADDR;

        dev->freq = 25000000;

        dev->ss_pol = IMX_SPI_ACTIVE_LOW;

        dev->ss = 0;

        dev->fifo_sz = 64 * 4;

        dev->us_delay = 0;

        break;

    case 1:

        /* SPI-NOR */

        dev->base = ECSPI1_BASE_ADDR;

        dev->freq = 25000000;

        dev->ss_pol = IMX_SPI_ACTIVE_LOW;

        dev->ss = 1;

        dev->fifo_sz = 64 * 4;

        dev->us_delay = 0;

        break;

    default:

        printf("Invalid Bus ID!\n");

    }

    return 0;

}

I assume that the notion of a 'bus' in this case is the SPI controller (ECSPI1-ECSPI5); but this code just ignores the bus

and always uses ECSPI1.  I added code to support ECSPI5, and may have erroneously assumed that the bus # directly

corresponded to the ECSPI controller number.  In other words bus 1 = ECSPI1.

Apparently for the newer u-boot, which is set up quite different, the assumption is that bus 0 corresponds to ECSPI1, etc...