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: Wed, 22 Apr 2015 14:44:36 +0800	[thread overview]
Message-ID: <CAEUhbmWR+7jhGED3NZDLS5Uzopb-C-vEEOvHd7pFb9zLuHvvHg@mail.gmail.com> (raw)
In-Reply-To: <CAD6G_RQJYWH9kvojSwcTS0jU2p_4L710YO=v493-_fi=Ny=uow@mail.gmail.com>

Hi Jagan,

On Tue, Apr 21, 2015 at 8:47 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> Hi Bin,
>
> On 20 April 2015 at 15:02, Bin Meng <bmeng.cn@gmail.com> wrote:
>> 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:
>
> I'm not getting your point- how could it erase use 64K sector size
> instead of 4K.

It indeed erases 64K sector size. You need check the logic in
spi_flash_validate_params().

> Suppose the sector size is 4K
>
> flash->sector_size = 0x1000
> 1.  erase 4K  len flash (it's total erase length)
>
> # sf erase 0x0 0x1000
>
>   len_arg = simple_strtoul(arg, &ep, 16);
>  gives - 0x1000
>
>    *len becomes 0x1000
>
> 2.  erase 4K+1 len flash
>
> # sf erase 0x0 +0x1001
>
>   len_arg = simple_strtoul(arg, &ep, 16);
>  gives - 0x1001
>
>  *len becomes 0x2000
>
> All the way when it goes to sf_ops.c erase will take by means of
> erase_size which is assigned in sf_probe.c based on flags like 4K
> 32K or 64K.

Regards,
Bin

  reply	other threads:[~2015-04-22  6:44 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
2015-04-21 12:47           ` Jagan Teki
2015-04-22  6:44             ` Bin Meng [this message]
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=CAEUhbmWR+7jhGED3NZDLS5Uzopb-C-vEEOvHd7pFb9zLuHvvHg@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.