Hi,

From what I remember when working with imx6d, the ecspi controller had a special behavior that it insisted on toggling the CS line for each 8-bit transfer. U-Boot has a workaround for this: using additional pin as "bit-banged CS". Here's how it worked on a project of mine:

static iomux_v3_cfg_t const spi1_pads[] = { MX6_PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL), // <= this is the new CS 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_COL0__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL) };

...and here's what I defined in my board-config-file:

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

Then you need to double-check your ecspi config options, like speed, mode. You can check with a scope whether the clock pulses are within supported timing of your SPI chip.

Kind regards, Nikolay

On 4/11/2014 8:55 AM, u-boot-request@lists.denx.de wrote:

Message: 28 Date: Thu, 10 Apr 2014 12:20:58 -0300 From: Fabio Estevam festevam@gmail.com Subject: Re: [U-Boot] board/freescale/mx6slevk: Add support for SPI NOR on the Freescale MCIMX6SLEVK Board To: Sam Catch dsblue.spam@gmail.com Cc: Marek Va?ut marex@denx.de, U-Boot-Denx u-boot@lists.denx.de Message-ID: CAOMZO5DvBqqAAzb5LwDNajMDj=+jm-nTz+FjQyGYLPXgKq-A2g@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Thu, Apr 10, 2014 at 12:05 PM, Sam Catch dsblue.spam@gmail.com wrote:

...

...

I hope this email is now in the right format.

Hi All,

I am trying to add support for the SPI NOR device on the Freescale MCIMX6SLEVK Board. I have created a patch that should enable support but the u-boot probe command still does not find the device. The process fails during the ECSPI transfer.

I have tried the following patch to the latest git master of u-boot:

http://pastebin.com/hamK7Ybb

U-Boot Output:

=> sf probe SF: Unsupported flash IDs: manuf 00, jedec 0000, ext_jedec 0000 Failed to initialize SPI flash at 0:27392

Does anyone have any insight as to why the Probe may be failing? I modeled the changes on the mx6sabresd board.

I see the same error here. I measured with a scope and the chip select signal behaves very differently compared to the mx6qsabresd board.

When I do 'sf probe' on a mx6qsabresd the chip select line stays low for 10us and then stays high.

On mx6slevk the chip select line stays low for 0.5us, then it goes high, goes low for 2us and they stays high.

So there is something very wrong with the timings on mx6sl, but I haven't had a chance to debug this yet.

Regards,

Fabio Estevam