linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sourav Poddar <sourav.poddar@ti.com>
To: <u-boot@lists.denx.de>, <linux-mtd@lists.infradead.org>
Cc: Tom Rini <trini@ti.com>,
	jagannadha.sutradharudu-teki@xilinx.com,
	Felipe Balbi <balbi@ti.com>, Rajendra nayak <rnayak@ti.com>
Subject: Re: U-boot: Erase/read/write issue with S25fl256S flash device
Date: Fri, 14 Jun 2013 20:03:09 +0530	[thread overview]
Message-ID: <51BB29A5.3000100@ti.com> (raw)
In-Reply-To: <51B82388.2000909@ti.com>


Hi,

On Wednesday 12 June 2013 01:00 PM, Sourav Poddar wrote:
> Hi,
>
> I am working on qspi flash device S25FL256S at u-boot level. I am 
> trying to
> make use of the existing spi_flash.c framework available at u-boot for 
> erasing/reading/writing
> into the flash device.
>
> There are several issues(mentioned below), which I faced while using 
> S25FL256s flash device
> with my dra7xx board which has a qspi controller to which the above 
> mentioned flash device is attached.
>
> 1. Erase (spi_flash_cmd_erase)
>
> Issuing a command something like this..
>
> sf erase 0x0 0x50000
>  - erases only first 0x20000 bytes of flash device, anything above 
> that is not erase. I need to
>    issue separate commands after 0x20000 for every 0x10000 bytes.
>
> Am i missing anything here?
>
> 2. read
>
> sf read 81000000 0 0x10000
>
> Read is not happening properly. The last few byte along the 4k 
> boundary always shows zero.
> Above 4k bytes, read is not happening.
>
> For ex:
>  DRA752 EVM # md 81000f00
> 81000f00: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f10: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f20: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f30: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f40: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f50: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f60: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f70: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f80: ffffffff ffffffff ffffffff ffffffff    ................
> 81000f90: ffffffff ffffffff ffffffff ffffffff    ................
> 81000fa0: ffffffff ffffffff ffffffff ffffffff    ................
> 81000fb0: ffffffff ffffffff ffffffff ffffffff    ................
> 81000fc0: ffffffff ffffffff ffffffff ffffffff    ................
> 81000fd0: ffffffff ffffffff ffffffff ffffffff    ................
> 81000fe0: ffffffff ffffffff ffffffff ffffffff    ................
> 81000ff0: ffffffff ffffffff 00ffffff 00000000    ................
>
> In this dump, if you see 81000ff0 the last column shows 000000 which is
> not expected. and it happens along every 4k bytes.
>
>
> So, to get rid of the above issue, I switched to page read with the 
> below patch[1],
> which is giving me the correct result.
> [1]:
> @@ -147,17 +153,40 @@ int spi_flash_read_common(struct spi_flash 
> *flash, const u8 *cmd,
>  int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 offset,
>                 size_t len, void *data)
>  {
> -       u8 cmd[5];
> +       unsigned long page_addr, byte_addr, page_size;
> +       size_t chunk_len, actual;
> +       int ret = 0;
> +       u8 cmd[4];
>
>         /* Handle memory-mapped SPI */
>         if (flash->memory_map)
>                 memcpy(data, flash->memory_map + offset, len);
> +       page_size = flash->page_size;
> +       page_addr = offset / page_size;
> +       byte_addr = offset % page_size;
> +
> +       cmd[0] = CMD_READ_ARRAY_SLOW;
> +       for (actual = 0; actual < len; actual += chunk_len) {
> +               chunk_len = min(len - actual, page_size - byte_addr);
> +
> +               cmd[1] = page_addr >> 8;
> +               cmd[2] = page_addr;
> +               cmd[3] = byte_addr;
> +
> +               ret = spi_flash_read_common(flash, cmd, sizeof(cmd), 
> data + actual, chunk_len);
> +               if (ret < 0) {
> +                       debug("SF: read failed");
> +                       break;
> +               }
>
> -       cmd[0] = CMD_READ_ARRAY_FAST;
> -       spi_flash_addr(offset, cmd);
> -       cmd[4] = 0x00;
> +               byte_addr += chunk_len;
> +               if (byte_addr == page_size) {
> +                       page_addr++;
> +                       byte_addr = 0;
> +               }
> +       }
>
> -       return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
> +       return ret;
>  }
>
> Any idea about this?
>
> 3.  write (spi_flash_cmd_write_multi)
>   write not happening properly.
>
> observations: only able to write single page, anything after a page is 
> not getting
>         written.
> Workaround:
> I did a write disable latch at the end of every write cycle(page 
> program) and enable it
> again for the next loop. With this, I see I get rid of the above issue.
>
>  @@ -117,6 +117,12 @@ int spi_flash_cmd_write_multi(struct spi_flash 
> *flash, u32 offset,
>                 if (ret)
>                         break;
>
> +               ret = spi_flash_cmd_write_disable(flash);
> +               if (ret < 0) {
> +                       printf("SF: disabling write failed\n");
> +                       break;
> +               }
> +
>
>
> Have anyone seen the above mentioned issues regarding 
> read/write/erase? OR is there any
> configurations that I might be missing ?
>
Any Input on this?

  reply	other threads:[~2013-06-14 14:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-12  7:30 U-boot: Erase/read/write issue with S25fl256S flash device Sourav Poddar
2013-06-14 14:33 ` Sourav Poddar [this message]
2013-06-14 14:38   ` [U-Boot] " Jagan Teki
2013-06-14 14:43     ` Sourav Poddar
2013-06-15 16:17       ` Jagan Teki
2013-06-17  6:14         ` Sourav Poddar
2013-06-17  6:47           ` Jagan Teki
2013-06-17  6:58             ` Sourav Poddar
2013-06-17  7:05               ` Jagan Teki
2013-06-17  7:11                 ` Sourav Poddar
2013-06-17  7:14                   ` Jagan Teki
2013-06-17  7:19                     ` Sourav Poddar
2013-06-17  7:34                       ` Jagan Teki
2013-06-17  7:41                         ` Sourav Poddar
2013-06-17  8:39                           ` Jagan Teki
2013-06-17  8:45                             ` Sourav Poddar
2013-06-17  9:58                               ` Jagan Teki
2013-06-17 10:20                                 ` Sourav Poddar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51BB29A5.3000100@ti.com \
    --to=sourav.poddar@ti.com \
    --cc=balbi@ti.com \
    --cc=jagannadha.sutradharudu-teki@xilinx.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rnayak@ti.com \
    --cc=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).