All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Meng <bmeng.cn@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 1/9] sf: Update SST flash params
Date: Mon, 20 Apr 2015 17:32:50 +0800	[thread overview]
Message-ID: <CAEUhbmWBfpg_c5oQ7NziCOK0U0YTSjb16mKj2+HQq_TjuxC6gQ@mail.gmail.com> (raw)
In-Reply-To: <CAD6G_RSoUtaWZihJLEnyDTxsBVZ_xdxut72=kFYdntAsGn7dUg@mail.gmail.com>

Hi Jagan,

On Fri, Apr 17, 2015 at 4:48 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 17 April 2015 at 07:14, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Jagan,
>>
>> On Fri, Apr 17, 2015 at 2:09 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>> Hi Bin,
>>>
>>> I think you have a different interpretation of sector size here-
>>>
>>> /* The size listed here is what works with SPINOR_OP_SE, which isn't
>>>  * necessarily called a "sector" by the vendor.
>>>  */
>>> Say for example SST25VF040B has 8 sectors of which each sector size is
>>> 64 * 1024 out of this we can use 4K sector erase or 32K sector erase or
>>> 64K sector erase through flags.
>>>
>>> Linux does follow the same-
>>>         /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>>>         { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K |
>>> SST_WRITE) },
>>>         { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K |
>>> SST_WRITE) },
>>>         { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K |
>>> SST_WRITE) },
>>>         { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K |
>>> SST_WRITE) },
>>>
>>> Please check it.
>>
>>
>> Yes, I know this pretty well. And I want to change this behavior, as
>> my cover letter says.
>>
>> Currently the 'sf erase' command operates on a 64KB granularity, while
>> the actual erase command is 4KB granularity, which is inconsistent and
>> causes confusion.
>
> It never related to 'sf erase' instead based on the 'params->flags'
> sf_probe will decide which erase_cmd with erase_size will use.

No, it is related. See cmd_sf.c:

static int sf_parse_len_arg(char *arg, ulong *len)
{
    char *ep;
    char round_up_len; /* indicates if the "+length" form used */
    ulong len_arg;

    round_up_len = 0;
    if (*arg == '+') {
        round_up_len = 1;
        ++arg;
    }

    len_arg = simple_strtoul(arg, &ep, 16);
    if (ep == arg || *ep != '\0')
        return -1;

    if (round_up_len && flash->sector_size > 0)
        *len = ROUND(len_arg, flash->sector_size);
    else
        *len = len_arg;

    return 1;
}

So even you are passing 4KB in the flash params, the 'sf erase'
command WILL erase 64KB.

>         /* Compute erase sector and command */
>         if (params->flags & SECT_4K) {
>                 flash->erase_cmd = CMD_ERASE_4K;
>                 flash->erase_size = 4096 << flash->shift;
>         } else if (params->flags & SECT_32K) {
>                 flash->erase_cmd = CMD_ERASE_32K;
>                 flash->erase_size = 32768 << flash->shift;
>         } else {
>                 flash->erase_cmd = CMD_ERASE_64K;
>                 flash->erase_size = flash->sector_size;
>         }
>
> And to be honest, these flashes were tested with lowest ie 4KB so even if they
> do support 64KB, we mentioned on 4KB on 'params->flags' as we tested
> well with that
> and it works consistently.
>
>>

Regards,
Bin

  reply	other threads:[~2015-04-20  9:32 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 12:51 [U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 1/9] sf: Update SST flash params Bin Meng
2015-04-16 18:09   ` Jagan Teki
2015-04-17  1:44     ` Bin Meng
2015-04-17  8:48       ` Jagan Teki
2015-04-20  9:32         ` Bin Meng [this message]
2015-04-21 12:47           ` Jagan Teki
2015-04-22  6:44             ` Bin Meng
2015-04-22  7:03               ` Jagan Teki
2015-04-22  7:14                 ` Bin Meng
2015-04-22  8:06                   ` Jagan Teki
2015-04-22  8:43                     ` Bin Meng
2015-04-22  9:15                       ` Jagan Teki
2015-04-22  9:32                         ` Bin Meng
2015-04-22  9:52                           ` Jagan Teki
2014-12-10 12:51 ` [U-Boot] [PATCH v3 2/9] sf: Update Atmel " Bin Meng
2015-01-09  9:27   ` Bo Shen
2015-01-12  3:32     ` Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 3/9] sf: Update EON " Bin Meng
2014-12-10 18:31   ` Jagan Teki
2014-12-11  2:33     ` Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 4/9] sf: Update GigaDevice " Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 5/9] sf: Update Macronix " Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 6/9] sf: Update Spansion " Bin Meng
2014-12-10 20:09   ` Jagan Teki
2014-12-11  2:53     ` Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 7/9] sf: Update Micron " Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 8/9] sf: Update Winbond " Bin Meng
2014-12-10 12:51 ` [U-Boot] [PATCH v3 9/9] sf: Give proper spacing between flash table params Bin Meng
2014-12-10 18:41 ` [U-Boot] [PATCH v3 0/9] sf: Update flash params for supported read commands and sector size Jagan Teki
2014-12-11  3:04   ` Bin Meng
2014-12-11  7:26     ` Jagan Teki
2014-12-11  7:40       ` Bin Meng
2014-12-15 13:51         ` Bin Meng
2014-12-17  7:59           ` Jagan Teki
2014-12-17  8:02             ` Bin Meng
2014-12-17  8:39               ` Jagan Teki
2015-01-12  3:42                 ` Bin Meng
2015-01-12  6:52                   ` Jagan Teki
2015-01-24 10:34                     ` Bin Meng
2015-01-27 13:50                       ` Bin Meng
2015-03-03  8:31                         ` Bin Meng
2015-03-03 22:52                           ` Tom Rini
2015-03-04  3:32                             ` Bin Meng
2015-03-05 17:43                               ` Jagan Teki
2015-03-06  1:00                                 ` Bin Meng
2015-03-06 10:21                                   ` Jagan Teki
2015-04-15  1:06                                     ` Bin Meng

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=CAEUhbmWBfpg_c5oQ7NziCOK0U0YTSjb16mKj2+HQq_TjuxC6gQ@mail.gmail.com \
    --to=bmeng.cn@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.