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!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]