[PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

Adding the ability to unlocking all Intel flash that is locked on power up. 
Currently only Intel P30 flash is unlocked.  All Intel flash is locked on power up.

Signed-off-by: Justin Treon <justin_treon@yahoo.com>
----
diff -r c105f44cf785 drivers/mtd/chips/cfi_cmdset_0001.c
--- a/drivers/mtd/chips/cfi_cmdset_0001.c	Thu Nov 08 15:36:57 2007 -0800
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c	Thu Nov 08 15:42:01 2007 -0800
@@ -244,7 +244,7 @@ static struct cfi_fixup cfi_fixup_table[
 #endif
 	{ CFI_MFR_ST, 0x00ba, /* M28W320CT */ fixup_st_m28w320ct, NULL },
 	{ CFI_MFR_ST, 0x00bb, /* M28W320CB */ fixup_st_m28w320cb, NULL },
-	{ MANUFACTURER_INTEL, 0x891c,	      fixup_use_powerup_lock, NULL, },
+	{ MANUFACTURER_INTEL, CFI_ID_ANY,     fixup_use_powerup_lock, NULL, },
 	{ 0, 0, NULL, NULL }
 };
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Thu, 8 Nov 2007, Justin Treon wrote:

> Adding the ability to unlocking all Intel flash that is locked on power up. 
> Currently only Intel P30 flash is unlocked.  All Intel flash is locked on power up.

What if you wanted for some of your flash partitions to remain locked?


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Josh Boyer]

On Thu, 8 Nov 2007 16:03:40 -0800 (PST)
Justin Treon <justin_treon@yahoo.com> wrote:

> Adding the ability to unlocking all Intel flash that is locked on power up. 
> Currently only Intel P30 flash is unlocked.  All Intel flash is locked on power up.

Um, it most certainly is not.

josh

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> > Adding the ability to unlocking all Intel flash that is locked on power up. 
> > Currently only Intel P30 flash is unlocked.  All Intel flash is locked on power
> up.
> 
> What if you wanted for some of your flash partitions to remain locked?
> 

It will not unlock any partitions that are listed are read only in your map.  

I prefer to use the command line partitioning so if I have
"mtdparts=M18:0x80000(blob)ro,0x280000(kernel)," mtd0, the boot loader, will remain
locked and mtd1, the kernel, will be unlocked.  

Justin  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Fri, 9 Nov 2007, Justin Treon wrote:

> 
> > > Adding the ability to unlocking all Intel flash that is locked on power up. 
> > > Currently only Intel P30 flash is unlocked.  All Intel flash is locked on power
> > up.
> > 
> > What if you wanted for some of your flash partitions to remain locked?
> > 
> 
> It will not unlock any partitions that are listed are read only in your map.  
> 
> I prefer to use the command line partitioning so if I have
> "mtdparts=M18:0x80000(blob)ro,0x280000(kernel)," mtd0, the boot loader, will remain
> locked and mtd1, the kernel, will be unlocked.  

That might be your preference.  But locked flash blocks are more likely 
to be immune against software bugs for example.  Unconditionally 
unlocking all blocks without regards for the wish of the user is a bad 
idea.  This is policy that is better decided elsewhere.

I think that adding a mount flag to jffs2 to unlock the concerned 
partition when it is about to be mounted read-write would be a much 
better solution.  This has been discussed on the list long ago IIRC, but 
no one came forward with a patch.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> > Adding the ability to unlocking all Intel flash that is locked on power up. 
> > Currently only Intel P30 flash is unlocked.  All Intel flash is locked on power
> up.
> 
> Um, it most certainly is not.
> 

Josh can you clarify this? 

To my understanding Intel W3 and J3 flash will ignore any additional unlock
commands. I will try to look into this further.

Many request have been sent to the mailing list regarding how to unlock a part.  I
have never seen a request asking how to lock a part.  As the patch is written
currently only mtd partitions that are mapped in as r/w rahter than read only will
be unlocked. 

I will write another patch to enable/disable unlocking by default.

Justin 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> > > > Adding the ability to unlocking all Intel flash that is locked on power up. 
> > > > Currently only Intel P30 flash is unlocked.  All Intel flash is locked on
> power
> > > up.
> > > 
> > > What if you wanted for some of your flash partitions to remain locked?
> > > 
> > 
> > It will not unlock any partitions that are listed are read only in your map.  
> > 
> > I prefer to use the command line partitioning so if I have
> > "mtdparts=M18:0x80000(blob)ro,0x280000(kernel)," mtd0, the boot loader, will
> remain
> > locked and mtd1, the kernel, will be unlocked.  
> 
> That might be your preference.  But locked flash blocks are more likely 
> to be immune against software bugs for example.  Unconditionally 
> unlocking all blocks without regards for the wish of the user is a bad 
> idea.  This is policy that is better decided elsewhere.

Setting an MTD partition to read only can be done in the maps files as will as in
the command line.  Those wishing to protect a partition should always set it to read
only for the very same reasons you mentioned.

> 
> I think that adding a mount flag to jffs2 to unlock the concerned 
> partition when it is about to be mounted read-write would be a much 
> better solution.  This has been discussed on the list long ago IIRC, but 
> no one came forward with a patch.
> 

Adding the ability to unlock a partition on mount is not a bad idea, but it should
not be the only way.  I often write to an mtd block device without mounting it and I
do not always use jffs2 as my writable filing system.

Justin

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Fri, 9 Nov 2007, Justin Treon wrote:

> > > > > Adding the ability to unlocking all Intel flash that is locked on power up. 
> > > > > Currently only Intel P30 flash is unlocked.  All Intel flash is locked on
> > power
> > > > up.
> > > > 
> > > > What if you wanted for some of your flash partitions to remain locked?
> > > > 
> > > 
> > > It will not unlock any partitions that are listed are read only in your map.  
> > > 
> > > I prefer to use the command line partitioning so if I have
> > > "mtdparts=M18:0x80000(blob)ro,0x280000(kernel)," mtd0, the boot loader, will
> > remain
> > > locked and mtd1, the kernel, will be unlocked.  
> > 
> > That might be your preference.  But locked flash blocks are more likely 
> > to be immune against software bugs for example.  Unconditionally 
> > unlocking all blocks without regards for the wish of the user is a bad 
> > idea.  This is policy that is better decided elsewhere.
> 
> Setting an MTD partition to read only can be done in the maps files as 
> will as in the command line.  Those wishing to protect a partition 
> should always set it to read only for the very same reasons you 
> mentioned.

I know.  I happen to be the original flash partition code author.
But for really sensitive data I'd prefer for that partition to remain 
locked at the hardware level too.

> > I think that adding a mount flag to jffs2 to unlock the concerned 
> > partition when it is about to be mounted read-write would be a much 
> > better solution.  This has been discussed on the list long ago IIRC, but 
> > no one came forward with a patch.
> > 
> 
> Adding the ability to unlock a partition on mount is not a bad idea, but it should
> not be the only way.  I often write to an mtd block device without mounting it and I
> do not always use jffs2 as my writable filing system.

Never heard of the MTD flash-unlock user space utility?


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> > Adding the ability to unlock a partition on mount is not a bad idea, but it
> should
> > not be the only way.  I often write to an mtd block device without mounting it
> and I
> > do not always use jffs2 as my writable filing system.
> 
> Never heard of the MTD flash-unlock user space utility?
> 

That does not help me on boot up.  I already have filing sytems that run that
through scripts on startup for some of my test images.

Justin

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Fri, 9 Nov 2007, Justin Treon wrote:

> 
> > > Adding the ability to unlock a partition on mount is not a bad idea, but it
> > should
> > > not be the only way.  I often write to an mtd block device without mounting it
> > and I
> > > do not always use jffs2 as my writable filing system.
> > 
> > Never heard of the MTD flash-unlock user space utility?
> > 
> 
> That does not help me on boot up.  I already have filing sytems that run that
> through scripts on startup for some of my test images.

What about a new partition flag then?  When set the unlock method would 
be called on the corresponding partition if the partition is not already 
marked read-only.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> > > > Adding the ability to unlock a partition on mount is not a bad idea, but it
> > > should
> > > > not be the only way.  I often write to an mtd block device without mounting
> it
> > > and I
> > > > do not always use jffs2 as my writable filing system.
> > > 
> > > Never heard of the MTD flash-unlock user space utility?
> > > 
> > 
> > That does not help me on boot up.  I already have filing sytems that run that
> > through scripts on startup for some of my test images.
> 
> What about a new partition flag then?  When set the unlock method would 
> be called on the corresponding partition if the partition is not already 
> marked read-only.
> 

Then what is the point of the read only flag?



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Fri, 9 Nov 2007, Justin Treon wrote:

> > > > > Adding the ability to unlock a partition on mount is not a bad idea, but it
> > > > should
> > > > > not be the only way.  I often write to an mtd block device without mounting
> > it
> > > > and I
> > > > > do not always use jffs2 as my writable filing system.
> > > > 
> > > > Never heard of the MTD flash-unlock user space utility?
> > > > 
> > > 
> > > That does not help me on boot up.  I already have filing sytems that run that
> > > through scripts on startup for some of my test images.
> > 
> > What about a new partition flag then?  When set the unlock method would 
> > be called on the corresponding partition if the partition is not already 
> > marked read-only.
> > 
> 
> Then what is the point of the read only flag?

It is a _software_ mechanism.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Jörn Engel]

On Fri, 9 November 2007 15:42:39 -0500, Nicolas Pitre wrote:
> 
> It is a _software_ mechanism.

Even the hardware mechanism is controlled by software, so I don't really
see a big difference.  Imo only two questions matter:
1. How hard is it to do what you want?
2. How hard is it to do what you don't want?

Ideally it should be dead easy to do the right thing and nigh'on
impossible to do the wrong.  Making both easy is a bad thing.  Making
both hard is equally bad - users would do anything to disable protection
mechanisms.

So the question is how to use the hardware mechanism in a way that
prevents damage but doesn't become a complete nuisance.  Completely
disabling it is an act of desperation, sure.  If we don't find a better
way, we'd at least want a config option to control this.

Jörn

-- 
You cannot suppose that Moliere ever troubled himself to be original in the
matter of ideas. You cannot suppose that the stories he tells in his plays
have never been told before. They were culled, as you very well know.
-- Andre-Louis Moreau in Scarabouche

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> What about a new partition flag then?  When set the unlock method would 
> be called on the corresponding partition if the partition is not already 
> marked read-only.
> 

I think that a partition flag is a good idea, but the mtd partition should be
unlocked by defualt if it is not read only and adding the flag will keep it locked.

How do you think it could be done that others would be accepting of it?  I do not
think everyone would like to see another flag that is so close to a read only flag.

Justin


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Mon, 12 Nov 2007, Justin Treon wrote:

> > What about a new partition flag then?  When set the unlock method would 
> > be called on the corresponding partition if the partition is not already 
> > marked read-only.
> > 
> 
> I think that a partition flag is a good idea, but the mtd partition should be
> unlocked by defualt if it is not read only and adding the flag will keep it locked.
> 
> How do you think it could be done that others would be accepting of 
> it?  I do not think everyone would like to see another flag that is so 
> close to a read only flag.

Don't make the unlocking the default.  The flag has simply to be set 
explicitly for the unlock to occur.  Few reasons for this:

1) you don't know if a particular flash requires unlocking after boot, 
   (most flash models don't) so doing it unconditionally is wasteful;

2) the partition might as well be meant to remain locked, except for 
   rare occasions when its content is updated (think bootloader) meaning
   it cannot be marked read-only;

3) this is a security feature and should not be bypassed "by
   default", and therefore the auto-unlock should be dependent on an 
   explicit flag so people needing it will have the opportunity to think 
   about it.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Jared Hulbert]

> Don't make the unlocking the default.  The flag has simply to be set
> explicitly for the unlock to occur.  Few reasons for this:
>
> 1) you don't know if a particular flash requires unlocking after boot,
>    (most flash models don't) so doing it unconditionally is wasteful;
>
> 2) the partition might as well be meant to remain locked, except for
>    rare occasions when its content is updated (think bootloader) meaning
>    it cannot be marked read-only;
>
> 3) this is a security feature and should not be bypassed "by
>    default", and therefore the auto-unlock should be dependent on an
>    explicit flag so people needing it will have the opportunity to think
>    about it.

Why is it a security feature to have a partition marked as r/w come up
as locked?  That's nutty.  If someone want's to implement some complex
scheme to prevent errant programs, they can use the userspace tools
and readonly flag for that.  The mailinglist gets an awful lot of
questions that have pointlessly locked partitions as the core.  Most
users don't use or view this as a security feature but just as an
annoyance.

So the semantics for the partition flags are to allow reads unless a
partition has been explictly marked readonly, right?   If you have
signaled intent to write to it, by creating a non-readonly partition,
you expect to be able to write to.  I argue it makes sense then to
unlock a partition that isn't marked readonly, granted we _only_
unlock such partitions.

I suggest we make this behavior (a) selective based on a config option
(b) make sure it only unlocks chips that actually unlock.

NFTL for using FAT file system on NAND data partition

[Gangadhar Kodishala]

Hi All,

I am working on I.MX21 based application which has Linux kernel 2.4.20 from
Freescale. 

I created a data partition on the NAND device and planning to use this
partition with FAT 
file system.  

How do I use the NAND data partition with FAT file system ?
Did anyone use the NFTL drivers provided in Kernel for FAT filesystem ?

Best Regards,
Gangadhar 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.30/1126 - Release Date: 11/12/2007
12:56 PM
 


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.

Re: NFTL for using FAT file system on NAND data partition

[falls huang]

Hello!

   Don't use NFTL on bare nand chip .

1.
   You can use yaffs  for your nand flash ,then create a loop file in
yaffs for fat filesystem.
2.
   upgrade to 2.6.x and try UBI .

2007/11/13, Gangadhar Kodishala <gangadhark@tataelxsi.co.in>:
> Hi All,
>
> I am working on I.MX21 based application which has Linux kernel 2.4.20 from
> Freescale.
>
> I created a data partition on the NAND device and planning to use this
> partition with FAT
> file system.
>
> How do I use the NAND data partition with FAT file system ?
> Did anyone use the NFTL drivers provided in Kernel for FAT filesystem ?
>
> Best Regards,
> Gangadhar
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.30/1126 - Release Date: 11/12/2007
> 12:56 PM
>
>
>
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
>
> Contact your Administrator for further information.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


-- 
Regards
Falls Huang

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Mon, 12 Nov 2007, Jared Hulbert wrote:

> > Don't make the unlocking the default.  The flag has simply to be set
> > explicitly for the unlock to occur.  Few reasons for this:
> >
> > 1) you don't know if a particular flash requires unlocking after boot,
> >    (most flash models don't) so doing it unconditionally is wasteful;
> >
> > 2) the partition might as well be meant to remain locked, except for
> >    rare occasions when its content is updated (think bootloader) meaning
> >    it cannot be marked read-only;
> >
> > 3) this is a security feature and should not be bypassed "by
> >    default", and therefore the auto-unlock should be dependent on an
> >    explicit flag so people needing it will have the opportunity to think
> >    about it.
> 
> Why is it a security feature to have a partition marked as r/w come up
> as locked?  That's nutty.

How do you update your bootloader from Linux but protect it from 
possible corruptions otherwise?  By recompiling your kernel?  _That_ is 
nutty.

> If someone want's to implement some complex
> scheme to prevent errant programs, they can use the userspace tools
> and readonly flag for that.

Well, actually I just looked and the core already has the code to 
auto-unlock flash when they have the MTD_STUPID_LOCK bit set.

So... if one partition should _not_ be automatically unlocked, it just 
has to put MTD_STUPID_LOCK in its flag_mask.  I'd have prefered if the 
auto-unlock was explicitly enabled instead of its prevention, but 
whatever.

> The mailinglist gets an awful lot of
> questions that have pointlessly locked partitions as the core.

I guess it's only a matter of properly flagging flash models that do 
power up locked then.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Mon, 12 Nov 2007, Justin Treon wrote:

> > What about a new partition flag then?  When set the unlock method would 
> > be called on the corresponding partition if the partition is not already 
> > marked read-only.
> > 
> 
> I think that a partition flag is a good idea, but the mtd partition should be
> unlocked by defualt if it is not read only and adding the flag will keep it locked.

And in fact this is already implemented, and the partition flag (which 
is actually a negative flag) is already called MTD_STUPID_LOCK.

So let's go back to finding your flash model requiring a 
fixup_use_powerup_lock() call.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Jared Hulbert]

> How do you update your bootloader from Linux but protect it from
> possible corruptions otherwise?  By recompiling your kernel?  _That_ is
> nutty.

Okay, okay I get your point.  Yep that is a problem.  But one that the
MTD_STUPID_LOCK can be unset to deal will if the
fixup_use_powerup_lock() is changed to be more intelligent.  Oh that
and the name should be MTD_AUTO_UNLOCK or something like that.

> > If someone want's to implement some complex
> > scheme to prevent errant programs, they can use the userspace tools
> > and readonly flag for that.
>
> Well, actually I just looked and the core already has the code to
> auto-unlock flash when they have the MTD_STUPID_LOCK bit set.
>
> So... if one partition should _not_ be automatically unlocked, it just
> has to put MTD_STUPID_LOCK in its flag_mask.  I'd have prefered if the
> auto-unlock was explicitly enabled instead of its prevention, but
> whatever.

Right, Justin is just extending that functionality which today only
kicks in for one size of one chip family.

So to clarify the disagreement you feel the default behavior should be
to have your writeable partitions default to locked, we feel the
default behavior should be to have your writeable partitions default
to unlocked.  Does that sum it up the core philshopical disagreement
here?

> > The mailinglist gets an awful lot of
> > questions that have pointlessly locked partitions as the core.
>
> I guess it's only a matter of properly flagging flash models that do
> power up locked then.

Actually there is a bit in struct cfi_pri_intelext.FeatureSupport&32
that I _think_ tells us this is one of the flex lock parts that does
the nonvolatile locking.  I'll have to confirm that.  That could be
used in the function fixup_use_powerup_lock() in cfi_cmdset_0001.c to
be more intelligent than just unlocking everything.  Would that be
better?

RE: NFTL for using FAT file system on NAND data partition

[Gangadhar Kodishala]

Hi Falls,

We may not move to 2.6.x for this application since all our other drivers
are 
based on the current version.

Why NFTL cannot be used on a bare nand chip ?

Please give me some more details on how I can use the yaffs and a loop file
for the
FAT file system ? We are already using the JFFS2 for the root file system
partition.
Can we use the JFFS2 with a loop file for FAT file system ?

Thanks.

Best Regards,
Gangadhar

-----Original Message-----
From: falls huang [mailto:falls.huang@gmail.com] 
Sent: Monday, November 12, 2007 7:39 PM
To: gangadhark@tataelxsi.co.in
Cc: linux-mtd@lists.infradead.org
Subject: Re: NFTL for using FAT file system on NAND data partition

Hello!

   Don't use NFTL on bare nand chip .

1.
   You can use yaffs  for your nand flash ,then create a loop file in
yaffs for fat filesystem.
2.
   upgrade to 2.6.x and try UBI .

2007/11/13, Gangadhar Kodishala <gangadhark@tataelxsi.co.in>:
> Hi All,
>
> I am working on I.MX21 based application which has Linux kernel 2.4.20
from
> Freescale.
>
> I created a data partition on the NAND device and planning to use this
> partition with FAT
> file system.
>
> How do I use the NAND data partition with FAT file system ?
> Did anyone use the NFTL drivers provided in Kernel for FAT filesystem ?
>
> Best Regards,
> Gangadhar
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.15.30/1126 - Release Date:
11/12/2007
> 12:56 PM
>
>
>
> The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s) and
may contain proprietary, confidential or privileged information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately and destroy all copies of
this message and any attachments contained in it.
>
> Contact your Administrator for further information.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>


-- 
Regards
Falls Huang

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.30/1126 - Release Date: 11/12/2007
12:56 PM
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.31/1128 - Release Date: 11/13/2007
11:09 AM
 


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Tue, 13 Nov 2007, Jared Hulbert wrote:

> > Well, actually I just looked and the core already has the code to
> > auto-unlock flash when they have the MTD_STUPID_LOCK bit set.
> >
> > So... if one partition should _not_ be automatically unlocked, it just
> > has to put MTD_STUPID_LOCK in its flag_mask.  I'd have prefered if the
> > auto-unlock was explicitly enabled instead of its prevention, but
> > whatever.
> 
> Right, Justin is just extending that functionality which today only
> kicks in for one size of one chip family.

It probably should be enabled for all flash models which always power up 
locked.

> So to clarify the disagreement you feel the default behavior should be
> to have your writeable partitions default to locked, we feel the
> default behavior should be to have your writeable partitions default
> to unlocked.  Does that sum it up the core philshopical disagreement
> here?

Yes, although I don't feel so strongly about that remaining point.  I 
initially thought there was no way to prevent the auto-unlock besides 
marking the partition read-only as well.

> Actually there is a bit in struct cfi_pri_intelext.FeatureSupport&32
> that I _think_ tells us this is one of the flex lock parts that does
> the nonvolatile locking.  I'll have to confirm that.  That could be
> used in the function fixup_use_powerup_lock() in cfi_cmdset_0001.c to
> be more intelligent than just unlocking everything.  Would that be
> better?

Probably.  At least limiting the fixup only to the affected flash models 
(adding entries as necessary) is way better than the unconditional 
unlock for everything.


Nicolas

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> > 
> > Right, Justin is just extending that functionality which today only
> > kicks in for one size of one chip family.
> 
> It probably should be enabled for all flash models which always power up 
> locked.
> 
> > So to clarify the disagreement you feel the default behavior should be
> > to have your writeable partitions default to locked, we feel the
> > default behavior should be to have your writeable partitions default
> > to unlocked.  Does that sum it up the core philshopical disagreement
> > here?
> 
> Yes, although I don't feel so strongly about that remaining point.  I 
> initially thought there was no way to prevent the auto-unlock besides 
> marking the partition read-only as well.
> 
> > Actually there is a bit in struct cfi_pri_intelext.FeatureSupport&32
> > that I _think_ tells us this is one of the flex lock parts that does
> > the nonvolatile locking.  I'll have to confirm that.  That could be
> > used in the function fixup_use_powerup_lock() in cfi_cmdset_0001.c to
> > be more intelligent than just unlocking everything.  Would that be
> > better?
> 
> Probably.  At least limiting the fixup only to the affected flash models 
> (adding entries as necessary) is way better than the unconditional 
> unlock for everything.
> 

I think the following patch should satisfy everyones concerns.  It has not been
tested.  

1. I have added a kernel config option to enable/disable automatic unlocking.  
2. The automatic unlocking can be disabled for a particular partition in the map or
the command line.
For the bit mask in the map it should look like:
.mask_flags	= MTD_POWERUP_LOCK,
   b. mtd_parts=0x80000(bootloader)lk
3. This will only unlock parts with instant individual block locking.


diff -r c105f44cf785 drivers/mtd/chips/Kconfig
--- a/drivers/mtd/chips/Kconfig	Thu Nov 08 15:36:57 2007 -0800
+++ b/drivers/mtd/chips/Kconfig	Tue Nov 13 14:11:41 2007 -0800
@@ -186,6 +186,15 @@ config MTD_CFI_INTELEXT
 	  provides support for one of those command sets, used on Intel
 	  StrataFlash and other parts.
 
+config MTD_CFI_UNLOCK_POWERUP_LOCK
+	bool "Automatically unlock partitions that are locked on power-up"
+	depends on MTD_CFI_INTELEXT
+	default y if MTD_CFI_INTELEXT
+	help
+	  Automatically unlock blocks on Intel Strata Flash parts that are
+	  mapped in MTD as writable.  This will not unlock J3 Strata Flash
+	  parts.
+
 config MTD_CFI_AMDSTD
 	tristate "Support for AMD/Fujitsu flash chips"
 	depends on MTD_GEN_PROBE
diff -r c105f44cf785 drivers/mtd/chips/cfi_cmdset_0001.c
--- a/drivers/mtd/chips/cfi_cmdset_0001.c	Thu Nov 08 15:36:57 2007 -0800
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c	Tue Nov 13 14:06:09 2007 -0800
@@ -228,8 +228,14 @@ static void fixup_use_write_buffers(stru
  */
 static void fixup_use_powerup_lock(struct mtd_info *mtd, void *param)
 {
-	printk(KERN_INFO "Using auto-unlock on power-up/resume\n" );
-	mtd->flags |= MTD_STUPID_LOCK;
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+	struct cfi_pri_intelext *cfip = cfi->cmdset_priv;
+
+	if (cfip->FeatureSupport&32) {
+ 		printk(KERN_INFO "Using auto-unlock on power-up/resume\n" );
+		mtd->flags |= MTD_POWERUP_LOCK;
+	}
 }
 
 static struct cfi_fixup cfi_fixup_table[] = {
@@ -244,7 +250,9 @@ static struct cfi_fixup cfi_fixup_table[
 #endif
 	{ CFI_MFR_ST, 0x00ba, /* M28W320CT */ fixup_st_m28w320ct, NULL },
 	{ CFI_MFR_ST, 0x00bb, /* M28W320CB */ fixup_st_m28w320cb, NULL },
-	{ MANUFACTURER_INTEL, 0x891c,	      fixup_use_powerup_lock, NULL, },
+#ifdef CONFIG_MTD_CFI_UNLOCK_POWERUP_LOCK
+	{ MANUFACTURER_INTEL, CFI_ID_ANY,     fixup_use_powerup_lock, NULL, },
+#endif /* CONFIG_MTD_CFI_UNLOCK_POWERUP_LOCK */
 	{ 0, 0, NULL, NULL }
 };
 
@@ -2273,7 +2281,7 @@ static int cfi_intelext_suspend(struct m
 	struct flchip *chip;
 	int ret = 0;
 
-	if ((mtd->flags & MTD_STUPID_LOCK)
+	if ((mtd->flags & MTD_POWERUP_LOCK)
 	    && extp && (extp->FeatureSupport & (1 << 5)))
 		cfi_intelext_save_locks(mtd);
 
@@ -2384,7 +2392,7 @@ static void cfi_intelext_resume(struct m
 		spin_unlock(chip->mutex);
 	}
 
-	if ((mtd->flags & MTD_STUPID_LOCK)
+	if ((mtd->flags & MTD_POWERUP_LOCK)
 	    && extp && (extp->FeatureSupport & (1 << 5)))
 		cfi_intelext_restore_locks(mtd);
 }
diff -r c105f44cf785 drivers/mtd/cmdlinepart.c
--- a/drivers/mtd/cmdlinepart.c	Thu Nov 08 15:36:57 2007 -0800
+++ b/drivers/mtd/cmdlinepart.c	Tue Nov 13 15:17:26 2007 -0800
@@ -140,6 +140,13 @@ static struct mtd_partition * newpart(ch
         if (strncmp(s, "ro", 2) == 0)
 	{
 		mask_flags |= MTD_WRITEABLE;
+		s += 2;
+        }
+
+        /* if lk is found do NOT unlock the MTD partition*/
+        if (strncmp(s, "lk", 2) == 0)
+	{
+		mask_flags |= MTD_POWERUP_LOCK;
 		s += 2;
         }
 
diff -r c105f44cf785 drivers/mtd/mtdcore.c
--- a/drivers/mtd/mtdcore.c	Thu Nov 08 15:36:57 2007 -0800
+++ b/drivers/mtd/mtdcore.c	Tue Nov 13 13:47:31 2007 -0800
@@ -59,7 +59,7 @@ int add_mtd_device(struct mtd_info *mtd)
 
 			/* Some chips always power up locked. Unlock them now */
 			if ((mtd->flags & MTD_WRITEABLE)
-			    && (mtd->flags & MTD_STUPID_LOCK) && mtd->unlock) {
+			    && (mtd->flags & MTD_POWERUP_LOCK) && mtd->unlock) {
 				if (mtd->unlock(mtd, 0, mtd->size))
 					printk(KERN_WARNING
 					       "%s: unlock failed, "
diff -r c105f44cf785 include/mtd/mtd-abi.h
--- a/include/mtd/mtd-abi.h	Thu Nov 08 15:36:57 2007 -0800
+++ b/include/mtd/mtd-abi.h	Fri Nov 09 10:43:28 2007 -0800
@@ -29,7 +29,7 @@ struct mtd_oob_buf {
 #define MTD_WRITEABLE		0x400	/* Device is writeable */
 #define MTD_BIT_WRITEABLE	0x800	/* Single bits can be flipped */
 #define MTD_NO_ERASE		0x1000	/* No erase necessary */
-#define MTD_STUPID_LOCK		0x2000	/* Always locked after reset */
+#define MTD_POWERUP_LOCK	0x2000	/* Always locked after reset */
 
 // Some common devices / combinations of capabilities
 #define MTD_CAP_ROM		0





      ____________________________________________________________________________________
Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs 

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Justin Treon]

> 
> I think the following patch should satisfy everyones concerns.  It has not been
> tested.  
> 
> 1. I have added a kernel config option to enable/disable automatic unlocking.  
> 2. The automatic unlocking can be disabled for a particular partition in the map
> or
> the command line.
> For the bit mask in the map it should look like:
> .mask_flags	= MTD_POWERUP_LOCK,
>    b. mtd_parts=0x80000(bootloader)lk
Minor correction to item 2.

For the bit mask in the map it should look like:
   .mask_flags	= MTD_POWERUP_LOCK,
For the command line parsing it should look like:
   mtdparts=0x80000(bootloader)lk


> 3. This will only unlock parts with instant individual block locking.
> 



      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/

Re: [PATCH 1/1] MTD: Unlocking all Intel flash that is locked on power up

[Nicolas Pitre]

On Tue, 13 Nov 2007, Justin Treon wrote:

> I think the following patch should satisfy everyones concerns.  It has 
> not been tested.
> 
> 1. I have added a kernel config option to enable/disable automatic 
> unlocking.

Please get rid of it.  This risk creating more confusion for little 
gain.  Just always do the fixup.

Everything looks fine otherwise, but make sure it is tested please.


Nicolas