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>
next prev parent 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