All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Longchamp <valentin.longchamp@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/2] SPI flash update command
Date: Wed, 04 Apr 2012 08:40:57 +0200	[thread overview]
Message-ID: <4F7BECF9.9040705@keymile.com> (raw)
In-Reply-To: <1333466098-31783-1-git-send-email-gerlando.falauto@keymile.com>

Hi,

We had discussed this internally with Gerlando, but I will repeat my position
here on the ML for the sake of the discussion.

On 04/03/2012 05:14 PM, Gerlando Falauto wrote:
> Hi,
> 
> this patchset allows "sf update" to erase+write a number of bytes which is not a
> multiple of the sector size.  Start address must still be sector-aligned though.

First I think this feature is really nice: the u-boot update command then
becomes really simple. But I have some remarks on how we should implement it.

That's my first remark here: some arguments have to be sector aligned and some
not. That's not really consistent.

> 
> The first patch trivially makes it such it will always erase an entire sector
> before writing, regardless of the amount of data to write (i.e. the last sector
> is erased completely before writing it only partially).
> 
> The second patch just makes sure that the original data at the end of the sector
> is written back so to apparently remain unchanged.
> 
> I anticipate two potential objections already:
> 
> - whether it is really worth writing back the portion of the sector which was
>   erased but shouldn't have been overwritten (whole purpose of the second patch)
> 
> - these changes make the semantics of "sf update" and "sf erase" somewhat
>   different, in that "sf erase" needs a "+" to deal with odd lengths, whereas
>   "sf update" does not.  I think this is only partially true.  After all, "sf
>   update" is already somehow special.  It's not a standard operation for a flash
>   (erase, read, write).  It combines two of those operations, and takes care of
>   optimizing the process by removing unneeded erase/write operations.  So it
>   might as well deserve to be "special", in my opinion.  Plus, it makes the
>   command for updating u-boot as easy as

The sector aligned arguments are mandatory for the erase command, and update is
as explained above erase + write commands (some erase/writes may be spared, but
that's transparent to the users). So why have a different nomenclature for
update and erase, when update is only putting erase and write commands together ?

With the "+" approach for the update command, we would achieve exactly the same
as proposed by these 2 patches, plus we are consistent with the "+" nomenclature
of the erase.

> 
>      sf update ${load_addr_r} 0 ${filesize}

It would then only be:

	sf update ${load_addr_r} 0 +${filesize}

Not a lot more complicated.

We have to think about 2 points here:

1) Do we want our sf commands to remain tied to the sectors ? If we want low
level control on the flash, that may be something desirable and then the "+"
approach makes more sense (you know that you may not be sector aligned and imply
with the "+".

2) Do we want our sf commands that are concerned by sector size (erase and
update) to have consistence in the arguments ? Why would an erase require a "+"
that an update does not require ? (This means that if we add the same
functionality than the "+" in update without the "+", why keep it for erase ?).

> 
> Feedback and criticism more than welcome, of course.
> 
> Thank you,
> Gerlando
> 
> Gerlando Falauto (2):
>   cmd_sf: let "sf update" erase last sector as a whole
>   cmd_sf: "sf update" preserve the final part of the last sector
> 
>  common/cmd_sf.c |   18 ++++++++++++++++--
>  1 files changed, 16 insertions(+), 2 deletions(-)
> 

Best Regards

Valentin

  reply	other threads:[~2012-04-04  6:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13 18:25 [U-Boot] SPI flash writing Gerlando Falauto
2012-03-13 20:11 ` Mike Frysinger
2012-03-13 20:17   ` Jason Cooper
2012-03-13 20:35     ` Mike Frysinger
2012-03-13 21:31       ` Falauto, Gerlando
2012-03-14  2:16         ` Mike Frysinger
2012-03-14  6:44           ` Gerlando Falauto
2012-03-15  0:50             ` Mike Frysinger
2012-03-15  0:02         ` Tom Rini
2012-03-15  0:51           ` Mike Frysinger
2012-03-14  2:18 ` Simon Glass
2012-03-14  6:58   ` Gerlando Falauto
2012-04-03 14:34 ` [U-Boot] [PATCH] cmd_sf: add size checking to spi flash commands Gerlando Falauto
2012-04-03 19:31   ` Mike Frysinger
2012-07-21 17:29   ` [U-Boot] [PATCH v2] " Mike Frysinger
2012-04-03 15:14 ` [U-Boot] [PATCH 0/2] SPI flash update command Gerlando Falauto
2012-04-04  6:40   ` Valentin Longchamp [this message]
2012-04-03 15:14 ` [U-Boot] [PATCH 1/2] cmd_sf: let "sf update" erase last sector as a whole Gerlando Falauto
2012-04-04  0:28   ` Simon Glass
2012-04-03 15:14 ` [U-Boot] [PATCH 2/2] cmd_sf: "sf update" preserve the final part of the last sector Gerlando Falauto
2012-04-04  0:33   ` Simon Glass

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=4F7BECF9.9040705@keymile.com \
    --to=valentin.longchamp@keymile.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.