From: Simon Guinot <simon@sequanux.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] SPI flash protection
Date: Sun, 30 Jan 2011 14:56:10 +0000 [thread overview]
Message-ID: <20110130145610.GA20073@kw.sim.vm.gnt> (raw)
In-Reply-To: <4D453111.50107@free.fr>
Hi Albert,
On Sun, Jan 30, 2011 at 10:36:17AM +0100, Albert ARIBAUD wrote:
> Hi Simon :)
>
> Le 29/01/2011 18:00, Simon Guinot a ?crit :
> > Hi,
> >
> > I am looking to add U-Boot support for the LaCie Network Space v2 board.
> >
> > The SoC is a Kirkwood 88F6281_A0 and the boot device is a Macronix SPI
> > flash (MX25L4005A). My problem is that the embedded stock U-Boot (1.1.4
> > version patched by Marvell and LaCie) enable write protection for the
> > SPI flash. Then, after an U-Boot update, turn off this protection is
> > needed to allow saving U-Boot environment.
> >
> > It is not clear for me how to proceed. Disable the write protection from
> > the board setup code could be an idea but a problem is that the SPI flash
> > API don't export any helpful method...
> > Maybe I should add one ?
> >
> > An another idea is disabling the write protection anyway while
> > initializing the flash (from the low level macronix driver). It is quite
> > straightforward but I don't know if a flash driver is allowed to do
> > that. After all, a flash could be protected for some good reasons.
> >
> > My last idea is doing nothing and let an another piece of software
> > handle the problem...
> >
> > Thanks in advance for advices.
>
> My personal take: let users of the board do their own mistakes and thus,
> do not protect the Flash, *except* for U-Boot itself.
>
> So, if SPI Flash protection is possible on block or sector levels,
> protect the blocks/sectors where U-Boot is located, including the
> environment.
For a Macronix SPI flash, the status register export 3 bits (or 4
depending the model and size) to configure the block protection.
Here is the protect area map for a MX25L4005A 4Mb flash:
bit 2 1 0 | protect level
____________|_______________
0 0 0 | none
0 0 1 | block 7
0 1 0 | block 6-7
0 1 1 | block 4-7
1 * * | all
As you can figure, deal with a per block protection in a generic way is
not easy..
>
> Saveenv should unprotect and re-protect the environment sector/block.
If I understand well, macronix_{erase,write}() are called from either
"saveenv" or "spi erase/write" commands and the low level macronix
functions don't have any flash map knowledge. Then, leave protect or not
a flash sector after a write/erase operation is not an easy decision.
Maybe the status register protection can be configured during the board
initialization ? after all, the required flash informations (as device
size, u-boot and environment localization) are available within the
board setup code.
>
> As for the kernel and rootfs... You can either leave them unprotected or
> protected.
As a side note, the Macronix Linux driver (m25p80) don't deal either
with the block protect bits.
>
> > Simon
> >
> > PS: some pointers about this project:
> >
> > git : http://git.lacie-nas.org/u-boot-lacie.git (branch netspace_v2)
>
> You should keep this branch based on u-boot/master generally, and on
> u-boot-arm/master right now because it has the most recent ARM commits.
OK, done :)
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110130/0e034156/attachment.pgp
next prev parent reply other threads:[~2011-01-30 14:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-29 17:00 [U-Boot] SPI flash protection Simon Guinot
2011-01-30 9:36 ` Albert ARIBAUD
2011-01-30 14:56 ` Simon Guinot [this message]
2011-01-30 17:19 ` Albert ARIBAUD
2011-01-31 0:31 ` Simon Guinot
2011-01-31 6:52 ` Albert ARIBAUD
2011-01-31 7:17 ` Reinhard Meyer
2011-02-01 9:09 ` Simon Guinot
2011-02-01 12:26 ` Albert ARIBAUD
2011-02-15 8:42 ` Mike Frysinger
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=20110130145610.GA20073@kw.sim.vm.gnt \
--to=simon@sequanux.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