T2080RDB SPI Flash

[hawkkim]

Hello,

While evaluating T2080RDB, I came across an issue related with SPI flash.

The thing is , upon power up, it works quite well. I can probe, create JFFS2 file system, mount it, and use it.
But when I reboot (not power off/power on), the system fails to read JEDEC ID of the SPI flash.

And if this happens, no matter what I do, the SPI flash doesn't work. But if I power off/on again, the flash starts working again.

Adding one more thing, while investigating this issue suspecting chip reset upon reboot, I found out that there is no RESET pin on the n25q512ax3 flash chip.

I'm using V1.7 SDK with DTB patch on n25q512ax3 flash chip.

Any idea will be appreciated.

Thanks,

H.Kim

[Pavel]

It looks like that problem can be solved using TN from Micron (https://www.micron.com/~/media/documents/products/technical-note/nor-flash/tn1229_n25q_n25w_reset_co...).

The TN from Micron shows that hard or soft reset is needed for N25Q and N25W Flash Memory Devices.

Usually SPI Flashes do not require hard or soft reset. Freescale SDK 1.7 contains common driver for SPI Flash.

[hawkkim]

Hello Pavel,

thanks for the response.

And I understand your point. In my opinion, we shouldn't have to do any reset to the SPI flash.

But with vanilla SDK 1.7, if I mount SPI flash as JFFS2 file system, then reboot, I see SPI probing error
as shown in the kernel log above. And yes this doesn't always happen. Sometimes it does, sometimes it doesn't.

I really wonder what's really going wrong.

H.Kim

[hawkkim]

In my experiment,

adding a chip reset logic as described in Micron's TN (https://www.google.co.kr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CBwQFjAA&url=h...

seems to solve the problem.

I just added the following chip reset code to spi_nor.c before JEDEC probing and haven't seen any probing failure for a day.

#define SPINOR_OP_RSTEN     0x66    /* Reset enable command */

#define SPINOR_OP_RSTMEM    0x99    /* Reset device, follows reset enable */

static void

spi_nor_soft_reset(struct spi_nor* nor)

{

    dev_err(nor->dev, "XXX hkim back: performing reset\n");

    // 8 clock cycle, DQ0 high, DQ3 is already high through VCC.

    nor->write_reg(nor, 0xff, NULL, 0, 0);

    // soft-reset command

    nor->write_reg(nor, SPINOR_OP_RSTEN, NULL, 0, 0);

    nor->write_reg(nor, SPINOR_OP_RSTMEM, NULL, 0, 0);

    // XXX FSR or just SR???

    //(void)wait_till_ready(nor);

    spi_nor_wait_till_fsr_ready(nor);

}

int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,

                        enum read_mode mode)

{

        struct flash_info               *info;

        struct flash_platform_data      *data;

        struct device *dev = nor->dev;

        struct mtd_info *mtd = nor->mtd;

        struct device_node *np = dev->of_node;

        int ret;

        int i;

        ret = spi_nor_check(nor);

        if (ret)

                return ret;

        spi_nor_soft_reset(nor);

...

...

...

I know this is just an experiment and not a clean solution.

Thanks

[hawkkim]

for the sake of saving evidence, here is the kernel log for SPI probing failure.

[    1.537185] fsl_espi ffe110000.spi: master is unqueued, this is deprecated

[    1.542990] m25p80 spi32766.0: unrecognized JEDEC id ffffff

[    1.547271] fsl_espi ffe110000.spi: at 0x80000800801a6000 (irq = 53)

This happens when I reboot the system after I mount SPI flash as JFFS2 file system.