public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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.

  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