SPI in u-boot

[niklasmolin]

Hi.

I'm trying to activate the SPI in u-boot and have a based my code from the SabreSD.

In the SabreSD there is already a SPI1, which can be activated via #define CONFIG_MXC_SPI (also using CONFIG_CMD_SPI, to test the SPI interface).

I have modified the IOMUX setting for this SPI interface to match out board.

It seems to be working fine.

But I also added SPI4 to the code (including IOMUX setting etc.).

But when I try to us that one, it get stuck.

After some debugging it seems like the status register never get the TC bit set.

After some more debugging, it seems like the status register always says the TX FIFO is empty (bit 0 and 1 are set), even after I have written to the TXDATA register.

When I look at the status register when using SPI1, those bits are cleared.

Is there something I'm missing to add when I added SPI4 (is there another place I need to modify when I'm adding this extra SPI bus)?

Thanks,

Niklas

[niklasmolin]

I noticed a new problem.

It seems like my SS pin is always low.

Shouldn't this pin be high, when the SPI is not active?

I can see that the CLK works when I try to write data from the SPI port.

Is there anything else I need to setup to make sure the SS-pin is controlled by the SPI module?

Thanks,

Niklas

[fabio_estevam]

How do you configure your SPI chip select pin?

You need to make sure that it is being configured as GPIO functionality instead of SPI SS functionality.

Please check mx6qsabresd U-boot code as example.

If it still does not work, please post your patch that adds SPI support here so that we can investigate further.

[niklasmolin]

Fabio,

When I setup the IOMUX for the SPI unit, will SS pin go high or will it only do that when I enable the SPI core?

My modification of the sabreSD project files (U-boot):  (using different settings for the SPI1 bus, compared to the SabreSD project plus I also added another SPI bus)

@@ -124,15 +153,49 @@ iomux_v3_cfg_t const usdhc4_pads[] = {

};

iomux_v3_cfg_t const ecspi1_pads[] = {

-       MX6_PAD_KEY_COL0__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),

-       MX6_PAD_KEY_COL1__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),

-       MX6_PAD_KEY_ROW0__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),

-       MX6_PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL),

+       MX6_PAD_CSI0_DAT4__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),

+       MX6_PAD_CSI0_DAT6__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),

+       MX6_PAD_CSI0_DAT5__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),

+       MX6_PAD_CSI0_DAT7__GPIO5_IO25 | MUX_PAD_CTRL(NO_PAD_CTRL),

+};

+

+iomux_v3_cfg_t const ecspi4_pads[] = {

+       MX6_PAD_EIM_D21__ECSPI4_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),

+       MX6_PAD_EIM_D22__ECSPI4_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),

+       MX6_PAD_EIM_D28__ECSPI4_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),

+       MX6_PAD_EIM_A25__GPIO5_IO02 | MUX_PAD_CTRL(NO_PAD_CTRL),

+};

static void setup_spi(void)

{

        imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads));

+       imx_iomux_v3_setup_multiple_pads(ecspi4_pads, ARRAY_SIZE(ecspi4_pads));

}

@@ -493,6 +634,12 @@ static const struct boot_mode board_boot_modes[] = {

int board_late_init(void)

{

+       // Make sure we enable ECSPI4 clock

+       int reg;

+       struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;

+       reg = readl(&mxc_ccm->CCGR1);

+       reg |=  MXC_CCM_CCGR1_ECSPI4S_MASK;

+       writel(reg, &mxc_ccm->CCGR1);

#ifdef CONFIG_CMD_BMODE

        add_board_boot_modes(board_boot_modes);

#endif

[fabio_estevam]

How does your config file look like? Are you passing the SPI CS GPIO in the config file?

[niklasmolin]

I don't include any SPI CS GPIO in the config file, is there somewhere where I need to define I'm using GPIO as CS?

In my config file I'm including following defines:

#define CONFIG_MXC_SPI

#define MXC_ECSPI (I think this might be defined in a different file also)

#define CONFIG_CMD_SPI

Right now I'm passing the CS number when setting up the SPI bus with spi_setup_slave function (located in mxc_spi.c file).

[fabio_estevam]

You need to pass the SPI CS GPIO in the config file.

Take a look at include/configs/mx6sabresd.h:

#define CONFIG_CMD_SF

#ifdef CONFIG_CMD_SF

#define CONFIG_SPI_FLASH

#define CONFIG_SPI_FLASH_STMICRO

#define CONFIG_MXC_SPI

#define CONFIG_SF_DEFAULT_BUS        0

#define CONFIG_SF_DEFAULT_CS        (0 | (IMX_GPIO_NR(4, 9) << 8))

#define CONFIG_SF_DEFAULT_SPEED        20000000

#define CONFIG_SF_DEFAULT_MODE        SPI_MODE_0

#endif

[davidprice]

I encountered this same problem with iMX6 SPI yesterday using u-boot 2013.04 from the Freescale git.  The hardware SPI SS doesn't work, but the GPIO chip select does, at least for the initial SPI probe when u-boot first starts up.  For some reason the "sf probe" command doesn't work.  I turned on DEBUG in the SPI driver, and it looks like the same register values for the startup probe and sf probe command are being passed from the driver to the SPI controller hardware, but the "sf probe" always returns 0 data.  At least u-boot can fetch the env variables from SPI.

Note that the "CONFIG_SF_DEFAULT_CS   (0 | (IMX_GPIO_NR(4, 9) << 8))" is special magic in the driver where numbers in bits 8 and higher are interpreted as GPIO.  In this example  it is GPIO4_9. It needs to be adjusted to whatever GPIO pad was configured to be chip select.

[fabio_estevam]

Just to make my reply clearer: the SPI NOR specific bits are:

#ifdef CONFIG_CMD_SF

#define CONFIG_SPI_FLASH

#define CONFIG_SPI_FLASH_STMICRO

The other pieces:

#define CONFIG_SF_DEFAULT_BUS        0

#define CONFIG_SF_DEFAULT_CS        (0 | (IMX_GPIO_NR(4, 9) << 8))

#define CONFIG_SF_DEFAULT_SPEED        20000000

#define CONFIG_SF_DEFAULT_MODE        SPI_MODE_0

Need to be passed no matter the device you try to access.

In this example GPIO4_9 is used as the SPI1 chip select.

#define CONFIG_SF_DEFAULT_BUS        0  means that you will use the first SPI port (in the case of imx this is SPI1 port).

In your case it should be:

#define CONFIG_SF_DEFAULT_BUS        3

#define CONFIG_SF_DEFAULT_CS        (3 | (IMX_GPIO_NR(5, 25) << 8))

#define CONFIG_SF_DEFAULT_SPEED        20000000

#define CONFIG_SF_DEFAULT_MODE        SPI_MODE_0

Hope this helps.

[rans]

Hello Fabio,

I would please like to ask:

In the define below, is it that the meaning of first number (in this example it is 3) is logical number of CS (CS #3 in this example) ?

#define CONFIG_SF_DEFAULT_CS        (3 | (IMX_GPIO_NR(5, 25) << 8))

I see  in my kernel log that it uses spi3.0 ,but in u-boot I find flash with

sf probe 3:22787 (bu3, cs 3?) and the macro is:

#define CONFIG_SF_DEFAULT_CS        (3 | (IMX_GPIO_NR(5, 25) << 8))

which means bus 3, cs 3, so it seems to contradict kernel, is my understand is correct.

Thank you,

Ran

[fabio_estevam]

Hi Ran,

Please start a new thread and more context to your question. The original thread is from 2014 and not sure how your issue is related to the original one.

Regards,

Fabio Estevam

[rans]

Yes, of course.

I've done this here:

sf probe in u-boot 

Regards,

Ran

[niklasmolin]

Fabio.

Isn't these defines to access and include the SPI flash functionality.

In our case, we just want to use the SPI4 to communicate with an external chip.

Shouldn't it just be enough to call the spi_setup_slave function to setup that SPI bus (where I include the cs, bus, speed etc..)?

Or is there something more I need to setup in the background?

[fabio_estevam]

Yes, I thought you were trying to connect to a SPI NOR.

You would need a driver for the SPI peripheral you want to access.

[niklasmolin]

I'm using the cmd_spi to access the SPI bus.

But what I wonder is if the CS pin should be high when I configure IOMUX?

Or if I need to enable the SPI module (control reg, bit 0) for it to go

high?

Right now I don't see any activity on CS the pin, but I can see that the

clock pin toggles when I try to send data on that bus.

On Thu, May 22, 2014 at 4:17 PM, Fabio Estevam <

[niklasmolin · Accepted solution]

Found the problem.

It seems like only SPI1 was enabled in the CCM Clock Gating Register 1.

So I had to also enable SPI4 (included that in board_late_init function).