From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Overwriting protected flash memory!!!
Date: Thu, 09 Dec 2004 20:22:10 +0100 [thread overview]
Message-ID: <20041209192215.CD773C146C@atlas.denx.de> (raw)
In-Reply-To: Your message of "Thu, 09 Dec 2004 14:00:09 EST." <f96d234e04120911001d14d232@mail.gmail.com>
In message <f96d234e04120911001d14d232@mail.gmail.com> you wrote:
>
> I have seen this several times over the years while working on
> embedded systems (including U-boot on PXA255 -- I did the same thing
> you did). If you write random data to flash, chances are you will hit
> a sequence that will corrupt the flash. All "protecting" flash memory
This has nothing to do with PXA255, and happens only ith certain
types of flash chips. If you use for example AMD chips, then a
special programming sequence must be written to special,
no-consequtive addresses. It is impossible to generate such a write
pattern by copying data sequentially to flash memory. Such chips are
safe.
> does is require a slightly more complicated sequence of write
> operations to unlock it.
No. Not even that. For most boards, the "protect" feature in U-Boot
is only a flag that prevents certain commands from working on such
"protected" flash areas. Only very few flash chips, and even fewer
boards using these chips, actually use some kind of hardware
protection.In most cases, just using a couple of "mm" or "mw"
commands to enter the erase or program seqence is all what's needed
to erase / corrupt "protected" sectors.
The "protect" stuff is something that is intended to prevent
accidential data loss by a istyped command etc. It cannot protect you
from doing stupid things.
> I slightly more reliable mechanism is to gate the write strobe in
> hardware or some other hardware mechanism, but this is usually not
It is perfectly sufficient to chose a different kind of flash chips,
that cannot be brought into erase or protgram mode by writing
sequential data. If your hardware guys selected such a type of flash
you just get what you deserve. There is no protection against bad
design decisions.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human race is faced with a cruel choice: work or daytime tele-
vision.
next prev parent reply other threads:[~2004-12-09 19:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 17:51 [U-Boot-Users] Overwriting protected flash memory!!! Cabral, Kevin
2004-12-09 18:35 ` Wolfgang Denk
2004-12-09 19:00 ` Cliff Brake
2004-12-09 19:22 ` Wolfgang Denk [this message]
2004-12-09 20:27 ` Cliff Brake
2004-12-09 20:45 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2004-12-09 21:31 Cabral, Kevin
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=20041209192215.CD773C146C@atlas.denx.de \
--to=wd@denx.de \
--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