All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: latest mtd changes broke collie
Date: Sat, 12 Nov 2005 22:33:55 +0100	[thread overview]
Message-ID: <20051112213355.GA4676@elf.ucw.cz> (raw)
In-Reply-To: <1131692514.3525.41.camel@localhost.localdomain>

Hi!

> > > I see the old sharp driver has a normally-not-defined AUTOUNLOCK symbol 
> > > that would enable some code to unlock blocks before writing/erasing 
> > > (which isn't recommended since the code doesn't know the policy on 
> > > whether the block is supposed to be locked).  The tree previously in use 
> > > may have had something similar setup.  It seems these flashes have all 
> > > blocks locked by default at power up.
> > 
> > Is there some quick hack I can do in kernel to unlock it?
> 
> I use the following on my device:
> 
>         mtd = do_map_probe(...);
>         
>         if (!mtd) { ...err... }
>         
>         mtd->owner = THIS_MODULE;
>         
>         mtd->unlock(mtd,0,mtd->size);
>         
> > Is it possible to accidentally unlock "BIOS" area and brick the device?
> 
> Yep, but you could modify the parameters to unlock to no do so.
> Depending on you partitioning scheme you might be able to use that to
> figure out what to unlock...

I tried this one. Size 0xc0000 is reported as a "bootloader" during
boot. 

[Plus I get a warning from jffs2 that flashsize is not aligned to
erasesize. Then I get lot of messages that empty flash at XXX ends at
XXX.]

Any more ideas?
								Pavel

diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -208,8 +208,8 @@ static void collie_set_vpp(int vpp)
 }
 
 static struct flash_platform_data collie_flash_data = {
-//	.map_name	= "jedec_probe",
-	.map_name	= "sharp",
+	.map_name	= "jedec_probe",
+//	.map_name	= "sharp",
 	.set_vpp	= collie_set_vpp,
 	.parts		= collie_partitions,
 	.nr_parts	= ARRAY_SIZE(collie_partitions),
diff --git a/drivers/mtd/maps/sa1100-flash.c b/drivers/mtd/maps/sa1100-flash.c
--- a/drivers/mtd/maps/sa1100-flash.c
+++ b/drivers/mtd/maps/sa1100-flash.c
@@ -211,6 +211,7 @@ static int sa1100_probe_subdev(struct sa
 		goto err;
 	}
 	subdev->mtd->owner = THIS_MODULE;
+	subdev->mtd->unlock(subdev->mtd, 0xc0000, subdev->mtd->size);
 
 	printk(KERN_INFO "SA1100 flash: CFI device at 0x%08lx, %dMiB, "
 		"%d-bit\n", phys, subdev->mtd->size >> 20,




-- 
Thanks, Sharp!

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: Todd Poynor <tpoynor@mvista.com>,
	linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: latest mtd changes broke collie
Date: Sat, 12 Nov 2005 22:33:55 +0100	[thread overview]
Message-ID: <20051112213355.GA4676@elf.ucw.cz> (raw)
In-Reply-To: <1131692514.3525.41.camel@localhost.localdomain>

Hi!

> > > I see the old sharp driver has a normally-not-defined AUTOUNLOCK symbol 
> > > that would enable some code to unlock blocks before writing/erasing 
> > > (which isn't recommended since the code doesn't know the policy on 
> > > whether the block is supposed to be locked).  The tree previously in use 
> > > may have had something similar setup.  It seems these flashes have all 
> > > blocks locked by default at power up.
> > 
> > Is there some quick hack I can do in kernel to unlock it?
> 
> I use the following on my device:
> 
>         mtd = do_map_probe(...);
>         
>         if (!mtd) { ...err... }
>         
>         mtd->owner = THIS_MODULE;
>         
>         mtd->unlock(mtd,0,mtd->size);
>         
> > Is it possible to accidentally unlock "BIOS" area and brick the device?
> 
> Yep, but you could modify the parameters to unlock to no do so.
> Depending on you partitioning scheme you might be able to use that to
> figure out what to unlock...

I tried this one. Size 0xc0000 is reported as a "bootloader" during
boot. 

[Plus I get a warning from jffs2 that flashsize is not aligned to
erasesize. Then I get lot of messages that empty flash at XXX ends at
XXX.]

Any more ideas?
								Pavel

diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -208,8 +208,8 @@ static void collie_set_vpp(int vpp)
 }
 
 static struct flash_platform_data collie_flash_data = {
-//	.map_name	= "jedec_probe",
-	.map_name	= "sharp",
+	.map_name	= "jedec_probe",
+//	.map_name	= "sharp",
 	.set_vpp	= collie_set_vpp,
 	.parts		= collie_partitions,
 	.nr_parts	= ARRAY_SIZE(collie_partitions),
diff --git a/drivers/mtd/maps/sa1100-flash.c b/drivers/mtd/maps/sa1100-flash.c
--- a/drivers/mtd/maps/sa1100-flash.c
+++ b/drivers/mtd/maps/sa1100-flash.c
@@ -211,6 +211,7 @@ static int sa1100_probe_subdev(struct sa
 		goto err;
 	}
 	subdev->mtd->owner = THIS_MODULE;
+	subdev->mtd->unlock(subdev->mtd, 0xc0000, subdev->mtd->size);
 
 	printk(KERN_INFO "SA1100 flash: CFI device at 0x%08lx, %dMiB, "
 		"%d-bit\n", phys, subdev->mtd->size >> 20,




-- 
Thanks, Sharp!

  reply	other threads:[~2005-11-12 23:48 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-09 22:17 latest mtd changes broke collie Pavel Machek
2005-11-10  0:19 ` Josh Boyer
2005-11-10  9:48   ` Pavel Machek
2005-11-10  2:59 ` Todd Poynor
2005-11-10  9:50   ` Pavel Machek
2005-11-10 10:02     ` David Woodhouse
2005-11-10 10:38       ` Pavel Machek
2005-11-10 10:51         ` David Woodhouse
2005-11-10 10:59           ` Pavel Machek
2005-11-10 11:11             ` David Woodhouse
2005-11-10 11:44               ` Pavel Machek
2005-11-10 12:07               ` Pavel Machek
2005-11-10 13:02                 ` David Vrabel
2005-11-10 13:02                   ` David Vrabel
2005-11-10 13:09                   ` Pavel Machek
2005-11-10 13:09                     ` Pavel Machek
2005-11-10 17:41                     ` Richard Purdie
2005-11-10 17:41                       ` Richard Purdie
2005-11-10 18:09                       ` Richard Purdie
2005-11-10 18:09                         ` Richard Purdie
2005-11-10 22:06                         ` Pavel Machek
2005-11-10 22:06                           ` Pavel Machek
2005-11-10 22:41               ` Pavel Machek
2005-11-10 23:58                 ` Todd Poynor
2005-11-10 23:58                   ` Todd Poynor
2005-11-11  0:16                   ` Pavel Machek
2005-11-11  0:16                     ` Pavel Machek
2005-11-11  7:01                     ` Ian Campbell
2005-11-12 21:33                       ` Pavel Machek [this message]
2005-11-12 21:33                         ` Pavel Machek
2005-11-13 10:35                         ` Ian Campbell
2005-11-13 10:35                           ` Ian Campbell
2005-11-14 12:10                           ` Pavel Machek
2005-11-14 12:10                             ` Pavel Machek
2005-11-13 19:40                         ` Todd Poynor
2005-11-13 19:40                           ` Todd Poynor
2005-11-14 12:08                           ` Pavel Machek
2005-11-14 12:08                             ` Pavel Machek

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=20051112213355.GA4676@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=dwmw2@infradead.org \
    --cc=ijc@hellion.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.