[PATCH/RFC] ARM: OMAP: unlock flash device during boot

[PATCH/RFC] ARM: OMAP: unlock flash device during boot

[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.

Signed-off-by: Kevin Hilman <khilman@mvista.com>
---
 drivers/mtd/maps/omap_nor.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6.21/drivers/mtd/maps/omap_nor.c
===================================================================
--- linux-2.6.21.orig/drivers/mtd/maps/omap_nor.c
+++ linux-2.6.21/drivers/mtd/maps/omap_nor.c
@@ -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)
--

RE: [PATCH/RFC] ARM: OMAP: unlock flash device during boot

[Woodruff, 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.

Regards,
Richard W.

> 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 <khilman@mvista.com>
> ---
>  drivers/mtd/maps/omap_nor.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> Index: linux-2.6.21/drivers/mtd/maps/omap_nor.c
> ===================================================================
> --- linux-2.6.21.orig/drivers/mtd/maps/omap_nor.c
> +++ linux-2.6.21/drivers/mtd/maps/omap_nor.c
> @@ -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)
> --

Re: [PATCH/RFC] ARM: OMAP: unlock flash device during boot

[Kevin Hilman]

Woodruff, Richard wrote:
> 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.

Kevin

>> 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 <khilman@mvista.com>
>> ---
>>  drivers/mtd/maps/omap_nor.c |    4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> Index: linux-2.6.21/drivers/mtd/maps/omap_nor.c
>> ===================================================================
>> --- linux-2.6.21.orig/drivers/mtd/maps/omap_nor.c
>> +++ linux-2.6.21/drivers/mtd/maps/omap_nor.c
>> @@ -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)
>> --

Re: [PATCH/RFC] ARM: OMAP: unlock flash device during boot

[Nishanth Menon]

Kevin Hilman stated on 10/18/2007 9:30 AM:
> Woodruff, Richard wrote:
>> 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.
> 
I recollect some time back we had a similar discussion on a possibility of:
a) partition 1 (boot readonly partition) having a basic filesystem which
would unlock partition 2
b) partition 2: read/write which would contain all the stuff that
filesystem would like to move around.

This would allow for map drivers to do nothing special on bootup.

Regards,
Nishanth Menon

Re: [PATCH/RFC] ARM: OMAP: unlock flash device during boot

[Amit Kucheria]

On 10/18/07, Kevin Hilman <khilman@mvista.com> wrote:
> 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?"

--
Amit Kucheria, Linux developer

Re: [PATCH/RFC] ARM: OMAP: unlock flash device during boot

[Tony Lindgren]

* Amit Kucheria <kucheria.amit@gmail.com> [071019 07:09]:
> On 10/18/07, Kevin Hilman <khilman@mvista.com> wrote:
> > 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?"

I'll push this today. If somebody comes up with a better solution, then
let's consider that.

Tony