ARM: OMAP: unlock flash device during boot

The bootloader may lock the flash device upon booting. This requires the use of 'flash_unlock' on each partition before using them.

However, when booting from flash the MTD driver is unable to "mark space as dirty" since the device is locked. This results lots of boot warnings from the MTD layer.

The MTD driver for OMAP needs to unlock the device during init so booting from flash can work without errors.

Signed-off-by Kevin Hilman <[email protected]>

---
 drivers/mtd/maps/omap_nor.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6.21/drivers/mtd/maps/omap_nor.c
===================================================================

drivers/mtd/maps/omap_nor.c +4 -1

@@ -108,6 +108,10 @@ static int __devinit omapflash_probe(str
 	}
 	info->mtd->owner = THIS_MODULE;
 
+	/* Unlock the flash device. */
+	if (info->mtd->unlock)
+		info->mtd->unlock(info->mtd, 0, info->mtd->size);
+
 #ifdef CONFIG_MTD_PARTITIONS
 	err = parse_mtd_partitions(info->mtd, part_probes, &info->parts, 0);
 	if (err > 0)
--

Long ago when the part size changed one version of the omap-nor driver did need to unlock partitions. This was done on some internal tree version.

By partitions I mean physical ones, inside the NOR part. Not mtd_partitions(). This only needed to be done on a per-partition basis not a per-sector one.

These physical partitions, allow for simultaneous XIP and programming on the same NOR chip. One partition can be in status mode while another has code executing out of it.

It kind of looks like this patch was aiming to do this.

Quoted 31 lines

The bootloader may lock the flash device upon booting. This requires the use of 'flash_unlock' on each partition before using them.

However, when booting from flash the MTD driver is unable to "mark space as dirty" since the device is locked. This results lots of boot warnings from the MTD layer.

The MTD driver for OMAP needs to unlock the device during init so booting from flash can work without errors.

Signed-off-by Kevin Hilman <[email protected]>

---
 drivers/mtd/maps/omap_nor.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6.21/drivers/mtd/maps/omap_nor.c
===================================================================

drivers/mtd/maps/omap_nor.c +4 -1

@@ -108,6 +108,10 @@ static int __devinit omapflash_probe(str
 	}
 	info->mtd->owner = THIS_MODULE;
 
+	/* Unlock the flash device. */
+	if (info->mtd->unlock)
+		info->mtd->unlock(info->mtd, 0, info->mtd->size);
+
 #ifdef CONFIG_MTD_PARTITIONS
 	err = parse_mtd_partitions(info->mtd, part_probes, &info->parts, 0);
 	if (err > 0)
--

Quoted 7 lines · Richard

Long ago when the part size changed one version of the omap-nor driver did need to unlock partitions. This was done on some internal tree version.

By partitions I mean physical ones, inside the NOR part. Not mtd_partitions(). This only needed to be done on a per-partition basis not a per-sector one.

These physical partitions, allow for simultaneous XIP and programming on the same NOR chip. One partition can be in status mode while another has code executing out of it.

It kind of looks like this patch was aiming to do this.

FWIW, this patch was taken from the TI kernels on linux.omap.com which have the same call to unlock in the probe hook.

The bootloader may lock the flash device upon booting. This requires the use of 'flash_unlock' on each partition before using them.

However, when booting from flash the MTD driver is unable to "mark space as dirty" since the device is locked. This results lots of boot warnings from the MTD layer.

The MTD driver for OMAP needs to unlock the device during init so booting from flash can work without errors.

Quoted 9 lines · Kevin Hilman

The bootloader may lock the flash device upon booting. This requires the use of 'flash_unlock' on each partition before using them.

However, when booting from flash the MTD driver is unable to "mark space as dirty" since the device is locked. This results lots of boot warnings from the MTD layer.

The MTD driver for OMAP needs to unlock the device during init so booting from flash can work without errors.

This patch does fix the copious amounts of the following messages that I get when I put a jffs2 filesystem on the NOR flash.

"Erase at 0x012e0000 failed immediately: -EROFS. Is the sector locked?

Dec 31 18:00:13 12 user.info ker<5>Write of 68 bytes at 0x0026111c

failed. returned -30, retlen 0
Write of 68 bytes at 0x0026111c failed. returned -30, retlen 0
nel: serial8250.0: ttyS0 at MMIO<5>Not marking the space at 0x0026111c as dirty because the flash driver returned retlen zero
Not marking the space at 0x0026111c as dirty because the flash driver returned retlen zero
0x4806a000 (irq = 72) is a ST16<5>Write of 68 bytes at 0x0026111c
failed. returned -30, retlen 0
Write of 68 bytes at 0x0026111c failed. returned -30, retlen 0 654

<5>Not marking the space at 0x0026111c as dirty because the flash driver returned retlen zero
Not marking the space at 0x0026111c as dirty because the flash driver returned retlen zero
<4>Erase at 0x012c0000 failed immediately: -EROFS. Is the sector locked? Erase at 0x012c0000 failed immediately: -EROFS. Is the sector locked? <4>Erase at 0x012a0000 failed immediately: -EROFS. Is the sector locked? Erase at 0x012a0000 failed immediately: -EROFS. Is the sector locked?"