public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] SPI flash writing
Date: Tue, 13 Mar 2012 16:11:29 -0400	[thread overview]
Message-ID: <201203131611.31287.vapier@gentoo.org> (raw)
In-Reply-To: <4F5F9103.1030807@keymile.com>

On Tuesday 13 March 2012 14:25:07 Gerlando Falauto wrote:
> As it turned out, our update procedure:
> 
> sf probe 0;sf erase 0 50000;sf write ${load_addr_r} 0 ${filesize}
> 
> mistakenly expects a maximum size of 0x50000 (327680) bytes for
> u-boot.kwb. Sadly, the latest u-boot trunk results in a binary size for
> that board which is dangerously close to that limit. Hence, after adding
> some innocent lines of code, the update procedure could brick the board
> (for no evident reason and with no error message whatsoever) if the
> binary size crosses that boundary.

sounds like you should define CONFIG_BOARD_SIZE_LIMIT.  this will turn it from 
a runtime failure into a build time failure as u-boot will do size checking on 
the image for you.

>  From what I can understand, writing into a sector which has not been
> erased first is an acceptable behaviour of the flash interface, it will
> just set to zero whatever bits are not zero already, without reporting
> any error whatsoever.

correct

> 1) a "+" syntax to the "sf update" command so it can be used with
> ${filesize} as a parameter, and/or some "read,replace,erase,overwrite"
> block mechanism for the last (incomplete) block

"+len" is already in there for erase, so it'd be trivial to add to the update 
command.  feel free to post a patch and i'd be happy to review/merge.

> 2) an out-of-boundary-check againts the flash size so at least a warning
> is issued when you use too big a size value

i'm not sure about this.  if you want to do size checking, then enable the 
hush shell and do it in a script.

> 3) a command line option ("sf write -v" and/or to "sf update -v"), or an
> entirely new command (like "sf writeverify", "sf updateverify") to read
> back after writing so to double-check what really ended up being written
> to the flash before it's too late.

i don't think our other flash interfaces have a verify command, so this would 
be a general question -- the spi flash interface shouldn't diverge if we don't 
want this in general.  then again, this too would be a fairly simple thing to 
write in a hush script.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120313/6afe44c4/attachment.pgp>

  reply	other threads:[~2012-03-13 20:11 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 [this message]
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
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=201203131611.31287.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --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