From: Gerlando Falauto <gerlando.falauto@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 2/2] cmd_sf: let "sf update" preserve the final part of the last sector
Date: Fri, 05 Jul 2013 09:31:06 +0200 [thread overview]
Message-ID: <51D6763A.9000800@keymile.com> (raw)
In-Reply-To: <CAD6G_RSx9_nXetL=TLapeNv2co9KBi+7TUv9QXxpmgASDKXOcg@mail.gmail.com>
Hi Jagan,
On 07/04/2013 06:26 PM, Jagan Teki wrote:
> On Thu, Jul 4, 2013 at 12:03 AM, Gerlando Falauto
> <gerlando.falauto@keymile.com> wrote:
>> Since "sf update" erases the last block as a whole, but only rewrites
>> the meaningful initial part of it, the rest would be left erased,
>> potentially erasing meaningful information.
>> So, as a safety measure, have it rewrite the original content.
>>
>> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
>> Cc: Valentin Longchamp <valentin.longchamp@keymile.com>
>> Cc: Holger Brunck <holger.brunck@keymile.com>
>> Acked-by: Simon Glass <sjg@chromium.org>
>> ---
>> common/cmd_sf.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/common/cmd_sf.c b/common/cmd_sf.c
>> index ab35a94..1141dc1 100644
>> --- a/common/cmd_sf.c
>> +++ b/common/cmd_sf.c
>> @@ -152,8 +152,10 @@ static const char *spi_flash_update_block(struct spi_flash *flash, u32 offset,
>> {
>> debug("offset=%#x, sector_size=%#x, len=%#zx\n",
>> offset, flash->sector_size, len);
>> - if (spi_flash_read(flash, offset, len, cmp_buf))
>> + /* Read the entire sector so to allow for rewriting */
>> + if (spi_flash_read(flash, offset, flash->sector_size, cmp_buf))
>> return "read";
>> + /* Compare only what is meaningful (len) */
>> if (memcmp(cmp_buf, buf, len) == 0) {
>> debug("Skip region %x size %zx: no change\n",
>> offset, len);
>> @@ -163,8 +165,16 @@ static const char *spi_flash_update_block(struct spi_flash *flash, u32 offset,
>> /* Erase the entire sector */
>> if (spi_flash_erase(flash, offset, flash->sector_size))
>> return "erase";
>> + /* Write the initial part of the block from the source */
>> if (spi_flash_write(flash, offset, len, buf))
>> return "write";
>
> I din't understand why the below write is required again-
> As erase ops requires only sector operation and read + write will do
> the operations on partial sizes
>
> Can you send the failure case w/o this.
I'm not sure I understand your question.
I thought the commit message above was clear enough.
In any case, the idea is to have "sf update" be as agnostic as possible
wrt to sector size, so it virtually only erases the same amount of data
as it is going to overwrite. The rest will be preserved.
This way you could, for instance, store some binary proprietary firmware
towards the end of the space reserved for u-boot, without having to
reserve a whole flash sector for it. The reason for doing such a thing
(as opposed to just embedding it within u-boot itself) is licensing
issues, so you might want to keep the firmware as close as possible to
the u-boot binary yet not link it.
Then when you update u-boot (GPL), your firmware is preserved.
Another extreme use case that comes to my mind would be where you have
the u-boot environment within the same sector where u-boot lies, though
a) I'm not sure it's even possible
b) is of course a BAD, BAD idea
c) See b)
d) See c) and then b), plus is a BAD idea and therefore discouraged
e) it would only make sense if the u-boot environment is never meant to
be altered except during production
To be honest with you, I don't remember if there was a real use case
leading me to write this or if it was just all hypothetical or I just
thought it was nicer that way.
As for changes of v3 wrt v2, the two should be functionally equivalent:
- In v2 I used a memcpy() to write the whole sector at once
- In v3 I avoided the memcpy() but this requires writing the two
portions separately.
Hope this answers your question.
Thank you,
Gerlando
>
> --
> Thanks,
> Jagan.
>> + /* If it's a partial sector, rewrite the existing part */
>> + if (len != flash->sector_size) {
>> + /* Rewrite the original data to the end of the sector */
>> + if (spi_flash_write(flash, offset + len,
>> + flash->sector_size - len, &cmp_buf[len]))
>> + return "write";
>> + }
>> return NULL;
>> }
>>
>> --
>> 1.8.0.1
>>
next prev parent reply other threads:[~2013-07-05 7:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 18:33 [U-Boot] [PATCH v3 0/2] SPI flash update command Gerlando Falauto
2013-07-03 18:33 ` [U-Boot] [PATCH v3 1/2] cmd_sf: let "sf update" erase last sector as a whole Gerlando Falauto
2013-08-06 18:57 ` Jagan Teki
2013-08-06 19:02 ` Jagan Teki
2013-07-03 18:33 ` [U-Boot] [PATCH v3 2/2] cmd_sf: let "sf update" preserve the final part of the last sector Gerlando Falauto
2013-07-04 16:26 ` Jagan Teki
2013-07-05 7:31 ` Gerlando Falauto [this message]
2013-08-06 18:25 ` Jagan Teki
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=51D6763A.9000800@keymile.com \
--to=gerlando.falauto@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox