Re: latest mtd changes broke collie

Re: latest mtd changes broke collie

[David Woodhouse]

On Thu, 2005-11-10 at 11:59 +0100, Pavel Machek wrote:
> Well, how do I found out? I tried switching to CFI, and it will not
> boot (unable to mount root...). No mtd-related messages as far as I
> can see. There's quite a lot of mtd-related config options, I set them
> like this:

If the old sharp driver had even a _chance_ of working, then you
presumably have four 8-bit flash chips laid out on a 32-bit bus, and
those chips are compatible with the Intel command set.

You can CONFIG_MTD_JEDECPROBE, and you want CONFIG_MTD_MAP_BANK_WIDTH=4,
CONFIG_MTD_CFI_I4, CONFIG_MTD_CFI_INTELEXT.

Check that your chips are listed in the table in jedec_probe.c and turn
on all the debugging in jedec_probe.c 

-- 
dwmw2

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> > Well, how do I found out? I tried switching to CFI, and it will not
> > boot (unable to mount root...). No mtd-related messages as far as I
> > can see. There's quite a lot of mtd-related config options, I set them
> > like this:
> 
> If the old sharp driver had even a _chance_ of working, then you
> presumably have four 8-bit flash chips laid out on a 32-bit bus, and
> those chips are compatible with the Intel command set.
> 
> You can CONFIG_MTD_JEDECPROBE, and you want CONFIG_MTD_MAP_BANK_WIDTH=4,
> CONFIG_MTD_CFI_I4, CONFIG_MTD_CFI_INTELEXT.
> 
> Check that your chips are listed in the table in jedec_probe.c and turn
> on all the debugging in jedec_probe.c 

As far as I can see, they are not listed :-(.

static int sharp_probe_map(struct map_info *map,struct mtd_info *mtd)
{
        map_word tmp, read0, read4;
        int width = 4;

        tmp = map_read(map, base+0);
        sharp_send_cmd(map, CMD_READ_ID, base+0);

        read0 = map_read(map, base+0);
        read4 = map_read(map, base+4);
        if (read0.x[0] == 0x00b000b0) {
                switch(read4.x[0]){
                case 0x00b000b0:
                        /* a6 - LH28F640BFHE 8 64k * 2 chip blocks*/
                        mtd->erasesize = 0x10000 * width / 2;
                        mtd->size = 0x800000 * width / 2;
                        return width;

...I've removed unneccessary code, this path is actually taken. Does
it mean that mfr == id == 0x00b0? [Notice that comment is wrong there,
probably belongs to another chip :-(]
							Pavel

-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> > Well, how do I found out? I tried switching to CFI, and it will not
> > boot (unable to mount root...). No mtd-related messages as far as I
> > can see. There's quite a lot of mtd-related config options, I set them
> > like this:
> 
> If the old sharp driver had even a _chance_ of working, then you
> presumably have four 8-bit flash chips laid out on a 32-bit bus, and
> those chips are compatible with the Intel command set.
> 
> You can CONFIG_MTD_JEDECPROBE, and you want CONFIG_MTD_MAP_BANK_WIDTH=4,
> CONFIG_MTD_CFI_I4, CONFIG_MTD_CFI_INTELEXT.
> 
> Check that your chips are listed in the table in jedec_probe.c and turn
> on all the debugging in jedec_probe.c 

Ok, I got a little bit more forward.

I created entry like this:
        {
                .mfr_id         = 0x00b0,
                .dev_id         = 0x00b0,
                .name           = "Collie hack",
                .uaddr          = {
                        [0] = MTD_UADDR_UNNECESSARY,    /* x8 */
                },
                .DevSize        = SIZE_4MiB,
                .CmdSet         = P_ID_INTEL_EXT,
                .NumEraseRegions= 1,
                .regions        = {
                        ERASEINFO(0x10000,8),
                }
}

(Which is probably wrong, I just made up the data), and set name in
collie.c to "jedec_probe". That made jedec_probe.c go alive, and it
prints...

Found: Collie hack
sa1100-0: Found 4 x8 devices at 0x0 in 32-bit bank
Sum of regions (200000) != total size of set of interleaved chips (1000000)
gen_probe: No Supported Vendor Command set found

sharp.c sets

			width = 4;
                        mtd->erasesize = 0x10000 * width / 2;
                        mtd->size = 0x800000 * width / 2;

...that is
		width = 4;
		erazesize = 0x20000;
		size      = 0x1000000;

Does it mean ERASEINFO(0x20000,7) should do the trick?

							Pavel
-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[David Vrabel]

Pavel Machek wrote:
> 
> Ok, I got a little bit more forward.
> 
> I created entry like this:
>         {
>                 .mfr_id         = 0x00b0,
>                 .dev_id         = 0x00b0,
>                 .name           = "Collie hack",
>                 .uaddr          = {
>                         [0] = MTD_UADDR_UNNECESSARY,    /* x8 */
>                 },
>                 .DevSize        = SIZE_4MiB,
>                 .CmdSet         = P_ID_INTEL_EXT,
>                 .NumEraseRegions= 1,
>                 .regions        = {
>                         ERASEINFO(0x10000,8),
>                 }
> }
> 
> (Which is probably wrong, I just made up the data)

Shouldn't you get hold of the datasheet for the flash chips and fill in
this information correctly?

David Vrabel

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> > Ok, I got a little bit more forward.
> > 
> > I created entry like this:
> >         {
> >                 .mfr_id         = 0x00b0,
> >                 .dev_id         = 0x00b0,
> >                 .name           = "Collie hack",
> >                 .uaddr          = {
> >                         [0] = MTD_UADDR_UNNECESSARY,    /* x8 */
> >                 },
> >                 .DevSize        = SIZE_4MiB,
> >                 .CmdSet         = P_ID_INTEL_EXT,
> >                 .NumEraseRegions= 1,
> >                 .regions        = {
> >                         ERASEINFO(0x10000,8),
> >                 }
> > }
> > 
> > (Which is probably wrong, I just made up the data)
> 
> Shouldn't you get hold of the datasheet for the flash chips and fill in
> this information correctly?

I already have working sharp.c driver... And I do not even know
manufacturer of the chip, just its ids.
							Pavel

-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[Richard Purdie]

On Thu, 2005-11-10 at 14:09 +0100, Pavel Machek wrote:
> > Shouldn't you get hold of the datasheet for the flash chips and fill in
> > this information correctly?
> 
> I already have working sharp.c driver... And I do not even know
> manufacturer of the chip, just its ids.

The chip number is LF28F640BX which is a 64MBit device so perhaps Intel
StrataFlash 28F640? That seems to be a fairly common chip...

Richard

Re: latest mtd changes broke collie

[Richard Purdie]

On Thu, 2005-11-10 at 17:41 +0000, Richard Purdie wrote:
> On Thu, 2005-11-10 at 14:09 +0100, Pavel Machek wrote:
> > > Shouldn't you get hold of the datasheet for the flash chips and fill in
> > > this information correctly?
> > 
> > I already have working sharp.c driver... And I do not even know
> > manufacturer of the chip, just its ids.
> 
> The chip number is LF28F640BX which is a 64MBit device so perhaps Intel
> StrataFlash 28F640? That seems to be a fairly common chip...

Some further research suggests it should perhaps be LH28F640BX which is
a 48 pin Sharp flash chip (much more likely). The nearest datasheet I
can find is:

http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=1120647

Richard

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> > > > Shouldn't you get hold of the datasheet for the flash chips and fill in
> > > > this information correctly?
> > > 
> > > I already have working sharp.c driver... And I do not even know
> > > manufacturer of the chip, just its ids.
> > 
> > The chip number is LF28F640BX which is a 64MBit device so perhaps Intel
> > StrataFlash 28F640? That seems to be a fairly common chip...
> 
> Some further research suggests it should perhaps be LH28F640BX which is
> a 48 pin Sharp flash chip (much more likely). The nearest datasheet I
> can find is:
> 
> http://www.datasheetarchive.com/semiconductors/download.php?Datasheet=1120647

That's strange; first the datasheet is pretty much useless; it does
not even give you product ID ("refer to documentation"). Then it
claims this device supports CFI. I guess it is easier to get the
values from sharp.c than from this datasheet :-(.

[It seems like the chip has many "options", and it is up to user how
it uses the chip.]
							Pavel
-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> > Well, how do I found out? I tried switching to CFI, and it will not
> > boot (unable to mount root...). No mtd-related messages as far as I
> > can see. There's quite a lot of mtd-related config options, I set them
> > like this:
> 
> If the old sharp driver had even a _chance_ of working, then you
> presumably have four 8-bit flash chips laid out on a 32-bit bus, and
> those chips are compatible with the Intel command set.
> 
> You can CONFIG_MTD_JEDECPROBE, and you want CONFIG_MTD_MAP_BANK_WIDTH=4,
> CONFIG_MTD_CFI_I4, CONFIG_MTD_CFI_INTELEXT.
> 
> Check that your chips are listed in the table in jedec_probe.c and turn
> on all the debugging in jedec_probe.c 

With these hacks, I'm able to mount flash at least read-only. On
attempt to remount read-write, I get 

"Write error in obliterating obsoleted node at 0x00bc0000: -30
...
Erase at 0x00c00000 failed immediately: -EROFS. Is the sector locked?"

Is it good news?
								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,7 +208,7 @@ static void collie_set_vpp(int vpp)
 }
 
 static struct flash_platform_data collie_flash_data = {
-	.map_name	= "sharp",
+	.map_name	= "jedec_probe",
 	.set_vpp	= collie_set_vpp,
 	.parts		= collie_partitions,
 	.nr_parts	= ARRAY_SIZE(collie_partitions),
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -25,6 +25,8 @@
 #include <linux/mtd/cfi.h>
 #include <linux/mtd/gen_probe.h>
 
+#define DEBUG(a, b...) printk(b)
+
 /* Manufacturers */
 #define MANUFACTURER_AMD	0x0001
 #define MANUFACTURER_ATMEL	0x001f
@@ -271,6 +273,19 @@ struct amd_flash_info {
  */
 static const struct amd_flash_info jedec_table[] = {
 	{
+		.mfr_id		= 0x00b0,
+		.dev_id		= 0x00b0,
+		.name		= "Collie hack",
+		.uaddr		= {
+                        [0] = MTD_UADDR_UNNECESSARY,    /* x8 */
+		},
+		.DevSize	= SIZE_4MiB,
+                .CmdSet         = P_ID_INTEL_EXT,
+                .NumEraseRegions= 1,
+                .regions        = {
+                        ERASEINFO(0x10000,64),
+                }
+	}, {
 		.mfr_id		= MANUFACTURER_AMD,
 		.dev_id		= AM29F032B,
 		.name		= "AMD AM29F032B",


-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[Todd Poynor]

Pavel Machek wrote:
> 
> With these hacks, I'm able to mount flash at least read-only. On
> attempt to remount read-write, I get 
> 
> "Write error in obliterating obsoleted node at 0x00bc0000: -30
> ...
> Erase at 0x00c00000 failed immediately: -EROFS. Is the sector locked?"
> 
> Is it good news?

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.

Try flash_unlock /dev/mtdX before remounting.  More automatic means of 
handling this are still under debate, I need to try another stab at 
resolving that soon.

Looks like you're close to obsoleting the pre-CFI Sharp flash driver, 
it's good news...

-- 
Todd

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> >With these hacks, I'm able to mount flash at least read-only. On
> >attempt to remount read-write, I get 
> >
> >"Write error in obliterating obsoleted node at 0x00bc0000: -30
> >...
> >Erase at 0x00c00000 failed immediately: -EROFS. Is the sector locked?"
> >
> >Is it good news?
> 
> 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? Is it
possible to accidentally unlock "BIOS" area and brick the device?

> Try flash_unlock /dev/mtdX before remounting.  More automatic means of 
> handling this are still under debate, I need to try another stab at 
> resolving that soon.

Good news is that I do have /dev/mtdX. Bad news is I do not have
flash_unlock. Does anyone have binary suitable for arm, preferably
statically linked?

> Looks like you're close to obsoleting the pre-CFI Sharp flash driver, 
> it's good news...

Ok, good. Read-only access is certainly better than nothing, and might
even be enough. Sharp shipped it with flash read-only originally.

								Pavel
-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[Pavel Machek]

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!

Re: latest mtd changes broke collie

[Ian Campbell]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Sat, 2005-11-12 at 22:33 +0100, Pavel Machek wrote:
> 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.]

What erase size did you end up using? Is 0xc0000 a multiple of it?

> +	subdev->mtd->unlock(subdev->mtd, 0xc0000, subdev->mtd->size);

Probably unrelated to the actual problems, but shouldn't that be
subdev->mtd->size - 0xc0000 at the end?

Ian.
-- 
Ian Campbell

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> > 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.]
> 
> What erase size did you end up using? Is 0xc0000 a multiple of it?

I ended up using ERASEINFO(0x10000,64), but I should probably be using
ERASEINFO(0x40000,16).

> > +	subdev->mtd->unlock(subdev->mtd, 0xc0000, subdev->mtd->size);
> 
> Probably unrelated to the actual problems, but shouldn't that be
> subdev->mtd->size - 0xc0000 at the end?

Fixed, thanks.
								Pavel
-- 
Thanks, Sharp!

Re: latest mtd changes broke collie

[Todd Poynor]

Pavel Machek wrote:

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

The datasheet ref'ed earlier says the chips have a 64KB erase block 
size, and the sharp driver multiplies that value by an interleave of 4 
chips to set the erase size.  What erase size is set under the new 
setup?  cat /proc/mtd or set loglevel for KERN_DEBUG at chip probe time. 
  The new code is setting it based on what was read from the CFI query 
info reported by the chip times the interleave factor (which apparently 
should be set as 4 after detecting 4 chips if CONFIG_MTD_CFI_I4=y).


-- 
Todd

Re: latest mtd changes broke collie

[Pavel Machek]

Hi!

> >[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.]
> 
> The datasheet ref'ed earlier says the chips have a 64KB erase block 
> size, and the sharp driver multiplies that value by an interleave of 4 
> chips to set the erase size.  What erase size is set under the new 

I'm currently using:

        {
                .mfr_id         = 0x00b0,
                .dev_id         = 0x00b0,
                .name           = "Collie hack",
                .uaddr          = {
                        [0] = MTD_UADDR_UNNECESSARY,    /* x8 */
                },
                .DevSize        = SIZE_4MiB,
                .CmdSet         = P_ID_INTEL_STD,
                .NumEraseRegions= 1,
                .regions        = {
                        ERASEINFO(0x10000,64),
                }
        },

...so I should use ERASEINFO(0x40000,16)?

> setup?  cat /proc/mtd or set loglevel for KERN_DEBUG at chip probe time. 
>  The new code is setting it based on what was read from the CFI query 
> info reported by the chip times the interleave factor (which apparently 
> should be set as 4 after detecting 4 chips if CONFIG_MTD_CFI_I4=y).

I do not have collie with me right now.
								Pavel
-- 
Thanks, Sharp!