"Read-only file system" error while writing

"Read-only file system" error while writing

[Stephen Hui]

Hi,

I have a set of STMicro flash chips (M28W320CT) that use the Intel
Extended CFI command set (0001), and I'm using kernel 2.4.2.  I can
partition the chips, lock and unlock the chips, erase the chips and read
from (dd) the chips perfectly fine.

When I write to the chips using either cat, dd, stdout redirection, or
cp, the CFI driver complains of attempting to write to a "Read-only file
system", even after unlocking all blocks in the partition and erasing
the partition.  I can mount /dev/mtdblock*, but mount complains and I
still can't put anything into the mounted partition.  do_write_buffer()
in cfi_cmdset_0001.c is returning the error (EROFS).

All I want to do is put a JFFS2 image onto the partition and be able to
erase and update the image later.

I've scoured the list archive back about a year, but haven't found
anything like the problem I'm experiencing.  Would it be worth my while
to backport cfi_cmdset_0001.c from a later kernel rev (2.4.18 or
2.4.17), besides to get the bug fix in do_write_buffer() (the one posted
to this list a little while ago)?  I diff'ed the 2.4.2 cfi_cmdset_0001.c
with a 2.4.18 and didn't see any really major differences between the
two.  Or could the bug in do_write_buffer() have something to do with
this?

Thanks in advance,
Stephen.


-- 
"Find out what you've been missing while you've been
rebooting Windows NT." -- Infoworld on Linux

http://www.ao.com/~regan/penguins/tux.html

Re: "Read-only file system" error while writing

[David Woodhouse]

gromit1463@mailworks.org said:
> When I write to the chips using either cat, dd, stdout redirection, or
> cp, the CFI driver complains of attempting to write to a "Read-only
> file system", even after unlocking all blocks in the partition and
> erasing the partition.  I can mount /dev/mtdblock*, but mount
> complains and I still can't put anything into the mounted partition.
> do_write_buffer() in cfi_cmdset_0001.c is returning the error (EROFS).

The only case in which do_write_buffer() should return -EROFS is if the 
status bit is set which means that the block in question was locked. Try 
using the MEMUNLOCK ioctl to unlock it?



--
dwmw2

Re: "Read-only file system" error while writing

[Jörn Engel]

On Tue, 30 July 2002 23:25:26 +0100, David Woodhouse wrote:
> gromit1463@mailworks.org said:
> > When I write to the chips using either cat, dd, stdout redirection, or
> > cp, the CFI driver complains of attempting to write to a "Read-only
> > file system", even after unlocking all blocks in the partition and
> > erasing the partition.  I can mount /dev/mtdblock*, but mount
> > complains and I still can't put anything into the mounted partition.
> > do_write_buffer() in cfi_cmdset_0001.c is returning the error (EROFS).
> 
> The only case in which do_write_buffer() should return -EROFS is if the 
> status bit is set which means that the block in question was locked. Try 
> using the MEMUNLOCK ioctl to unlock it?

We have had a similar problem with the ECC chips. When doing two
writes to the same page, the second write causes an error, leaving the
status word with 0x90. The word is not cleared until an explicit clear
status register command (0x50) is given.
The command set 0001 doesn't know about all this and behaves quite
strange. From user space, the _third_ write to flash causes an error
condition. The second already failed, but this is unnoticed.

At first glance, your chips doesn't appear to have ecc though. Can you
please verify, Stephen?

Jörn

-- 
You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the bottleneck is.
-- Rob Pike

Re: "Read-only file system" error while writing

[Stuart Menefy]

Stephen

On Tue, 30 Jul 2002 16:27:23 -0500
gromit1463@mailworks.org wrote:
> I have a set of STMicro flash chips (M28W320CT) that use the Intel
> Extended CFI command set (0001), and I'm using kernel 2.4.2.  I can
> partition the chips, lock and unlock the chips, erase the chips and read
> from (dd) the chips perfectly fine.

I had problems getting these devices to work as well, and ended up deciding
there were a couple of bugs which had to be worked around. One is a problem
in the state machine which handles unlocking returns to read mode when
it should stay in command mode, and the other is a simple error in the CFI
data, which gets the size of the device wrong!

The attached changes work for me. Unfortuntaly my cfi_cmdset_0001.c is
pretty heavily modified, so the patch may not apply cleanly. The two
changes are for do_lock_onblock() and do_unlock_oneblock().

Note that I was using the bottom bank version, so if you find you also
need the work around for the CFI data being wrong, you will probably have
to adjust the device ID being checked for.

Hope this helps

Stuart



diff -ru --exclude=CVS mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c mtd/drivers/mtd/chips/cfi_cmdset_0001.c
--- mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c	Tue Nov 27 14:55:12 2001
+++ mtd/drivers/mtd/chips/cfi_cmdset_0001.c	Mon Dec 10 17:46:05 2001
@@ -1400,6 +1479,10 @@
 	ENABLE_VPP(map);
 	cfi_write(map, CMD(0x60), adr);
 	cfi_write(map, CMD(0x01), adr);
+
+// SIM: I've added this for the ST chip which reverts to read mode. Ahhh
+cfi_write(map, CMD(0x70), adr);
+
 	chip->state = FL_LOCKING;
 	
 	spin_unlock_bh(chip->mutex);
@@ -1550,7 +1621,10 @@
 	cfi_write(map, CMD(0x60), adr);
 	cfi_write(map, CMD(0xD0), adr);
 	chip->state = FL_UNLOCKING;
-	
+
+// SIM: I've added this for the ST chip which reverts to read mode. Ahhh
+cfi_write(map, CMD(0x70), adr);
+
 	spin_unlock_bh(chip->mutex);
 	schedule_timeout(HZ);
 	spin_lock_bh(chip->mutex);
diff -ru --exclude=CVS mtd.orig/drivers/mtd/chips/cfi_probe.c mtd/drivers/mtd/chips/cfi_probe.c
--- mtd.orig/drivers/mtd/chips/cfi_probe.c	Tue Oct  2 16:05:12 2001
+++ mtd/drivers/mtd/chips/cfi_probe.c	Mon Dec 10 17:51:24 2001
@@ -147,6 +145,22 @@
 		((unsigned char *)cfi->cfiq)[i] = cfi_read_query(map,base + (0x10 + i)*ofs_factor);
 	}
 	
+	/* The STMicroelectronics M28W320CB device reports incorrect CFI data.
+	 * Check here and fix up if necessary.
+	 */
+#define VENDOR_STMICROELECTRONICS 0x0020
+#define DEVICE_M28W320CB 0xbb
+	{
+		unsigned int vendor, id;
+		vendor = cfi_read_query(map,base + 0*ofs_factor);
+		id     = cfi_read_query(map,base + 1*ofs_factor);
+printk("Vendor %08x id %08x\n", vendor, id);
+		if ((vendor == VENDOR_STMICROELECTRONICS) && (id == DEVICE_M28W320CB)) {
+			printk("Detected STM M28W320CB, applying CFI fixups\n");
+			((unsigned char*)cfi->cfiq)[0x31 - 0x10] = 0x3e;
+		}
+	}
+
 	/* Do any necessary byteswapping */
 	cfi->cfiq->P_ID = le16_to_cpu(cfi->cfiq->P_ID);
 	
-- 
Stuart Menefy                                        stuart.menefy@st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

Re: "Read-only file system" error while writing

[Stephen Hui]

Thanks, Stuart.

I applied the patches, but still no go.  I did notice that after
applying the patches, a slightly new behaviour appears: when I

    echo "1" > /dev/mtd0

and then

    dd if=/dev/mtd0 of=partition.dat bs=1k count=1

I see that the partition contains a "1\n", then the rest of the bits are
erased as they should be.  I know that in this case the do_write_word()
function is called based on the mess of printk()s I've sprinkled into
the source.


When I do these:

    cp rootimg.jffs2 /dev/mtd0
    cat rootimg.jffs2 > /dev/mtd0
    dd if=rootimg.jffs2 of=/dev/mtd0 bs=4k

they all call do_write_buffer().  I was looking at the specsheet for my
STMicro chips, and I didn't see any mention of Write-to-Buffer (command
0xE0) which is in the Intel command set, and issued by
do_write_buffer().  Is this command supported on the STMicro chips? 
Could non-support contribute to my problem?


Thanks again,
Stephen.  :o)




On Wed, 2002-07-31 at 10:35, Stuart Menefy wrote:
> Stephen
> 
> On Tue, 30 Jul 2002 16:27:23 -0500
> gromit1463@mailworks.org wrote:
> > I have a set of STMicro flash chips (M28W320CT) that use the Intel
> > Extended CFI command set (0001), and I'm using kernel 2.4.2.  I can
> > partition the chips, lock and unlock the chips, erase the chips and read
> > from (dd) the chips perfectly fine.
> 
> I had problems getting these devices to work as well, and ended up deciding
> there were a couple of bugs which had to be worked around. One is a problem
> in the state machine which handles unlocking returns to read mode when
> it should stay in command mode, and the other is a simple error in the CFI
> data, which gets the size of the device wrong!
> 
> The attached changes work for me. Unfortuntaly my cfi_cmdset_0001.c is
> pretty heavily modified, so the patch may not apply cleanly. The two
> changes are for do_lock_onblock() and do_unlock_oneblock().
> 
> Note that I was using the bottom bank version, so if you find you also
> need the work around for the CFI data being wrong, you will probably have
> to adjust the device ID being checked for.
> 
> Hope this helps
> 
> Stuart
> 

-- 
"Find out what you've been missing while you've been
rebooting Windows NT." -- Infoworld on Linux

http://www.ao.com/~regan/penguins/tux.html

Re: "Read-only file system" error while writing

[David Woodhouse]

gromit1463@mailworks.org said:
>  they all call do_write_buffer().  I was looking at the specsheet for
> my STMicro chips, and I didn't see any mention of Write-to-Buffer
> (command 0xE0) which is in the Intel command set, and issued by
> do_write_buffer().  Is this command supported on the STMicro chips?
> Could non-support contribute to my problem? 

We should be checking the CFI table for buffer-write support and not trying 
to use it if it's not present. Can you check the datasheet for the chip 
agrees with the built-in CFI table?

--
dwmw2

Re: "Read-only file system" error while writing

[David Woodhouse]

stuart.menefy@st.com said:
> +// SIM: I've added this for the ST chip which reverts to read mode. Ahhh 
> +cfi_write(map, CMD(0x70), adr); 

I think that one's relatively harmless -- we can just stick that in 
unconditionally.

> +	/* The STMicroelectronics M28W320CB device reports incorrect CFI data.
> +	 * Check here and fix up if necessary.

Ug. I think we need to add a generic way to do this kind of thing -- look up
mfr and device ID in a table with certain fixups, and we can do the
AMD_BOOTLOC_BUG this way too.

--
dwmw2

Re: "Read-only file system" error while writing

[Stuart Menefy]

On Thu, 1 Aug 2002 11:31:40 +0100
dwmw2@infradead.org wrote:
> gromit1463@mailworks.org said:
> >  they all call do_write_buffer().  I was looking at the specsheet for
> > my STMicro chips, and I didn't see any mention of Write-to-Buffer
> > (command 0xE0) which is in the Intel command set, and issued by
> > do_write_buffer().  Is this command supported on the STMicro chips?
> > Could non-support contribute to my problem? 
> 
> We should be checking the CFI table for buffer-write support and not trying 
> to use it if it's not present. Can you check the datasheet for the chip 
> agrees with the built-in CFI table?

Yes, the CFI data for this field is right (ie the device does not support
Block writes). So I don't think this should be the problem.

Stuart

-- 
Stuart Menefy                                        stuart.menefy@st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

Re: "Read-only file system" error while writing

[Stuart Menefy]

On Thu, 1 Aug 2002 19:05:00 +0100
stuart.menefy@st.com wrote:
> On Thu, 1 Aug 2002 11:31:40 +0100
> dwmw2@infradead.org wrote:
> > gromit1463@mailworks.org said:
> > >  they all call do_write_buffer().  I was looking at the specsheet for
> > > my STMicro chips, and I didn't see any mention of Write-to-Buffer
> > > (command 0xE0) which is in the Intel command set, and issued by
> > > do_write_buffer().  Is this command supported on the STMicro chips?
> > > Could non-support contribute to my problem? 
> > 
> > We should be checking the CFI table for buffer-write support and not trying 
> > to use it if it's not present. Can you check the datasheet for the chip 
> > agrees with the built-in CFI table?
> 
> Yes, the CFI data for this field is right (ie the device does not support
> Block writes). So I don't think this should be the problem.

Sorry, I should have read the email more closely before replying.

For the M28W320CB which I'm using, the CFI data is correct, in that it
reports that the device does not support Block writes. Stephen is using the
M28W320CT, which will have different CFI data, so maybe it is reporting that
it is supported?

The datasheet is no use in this respect, in its listing of the CFI data it
gives times for buffer-writes, which the device does not support!

Try building cfi_probe.c with DEBUG_CFI set, and post what it reports.

Stuart

-- 
Stuart Menefy                                        stuart.menefy@st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

Re: "Read-only file system" error while writing

[Stephen Hui]

Number of erase regions: 2 
Vendor 00000020 id 000000ba 
Primary Vendor Command Set: 0003 (Intel/Sharp Standard) 
Primary Algorithm Table at 0035 
Alternative Vendor Command Set: 0000 (None) 
No Alternate Algorithm Table 
Vcc Minimum: 2.7 V 
Vcc Maximum: 3.6 V 
Vpp Minimum: b.4 V 
Vpp Maximum: c.6 V 
Typical byte/word write timeout: 16 s 
Maximum byte/word write timeout: 512 s 
Typical full buffer write timeout: 16 s 
Maximum full buffer write timeout: 512 s 
Typical block erase timeout: 1024 s 
Maximum block erase timeout: 8192 s 
Chip erase not supported 
Device size: 0x400000 bytes (4 Mb) 
Flash Device Interface description: 0x0001 
x16-only asynchronous interface 
Max. bytes in buffer write: 0x4 
Number of Erase Block Regions: 2 
Erase Region #0: BlockSize 0x10000 bytes, 63 blocks 
Erase Region #1: BlockSize 0x2000 bytes, 8 blocks 



I have 8 chips total, 4MB each.


On Thu, 2002-08-01 at 13:26, Stuart Menefy wrote:
> Try building cfi_probe.c with DEBUG_CFI set, and post what it reports.


-- 
"Find out what you've been missing while you've been
rebooting Windows NT." -- Infoworld on Linux

http://www.ao.com/~regan/penguins/tux.html

Re: "Read-only file system" error while writing

[Stuart Menefy]

Stephen

This is slightly different from what I see with the bottom version of the device:

Number of erase regions: 2
Vendor 00000020 id 000000bb
Detected STM M28W320CB, applying CFI fixups
Primary Vendor Command Set: 0003 (Intel/Sharp Standard)
Primary Algorithm Table at 0035
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum:  2.7 V
Vcc Maximum:  3.6 V
Vpp Minimum: 11.4 V
Vpp Maximum: 12.6 V
Typical byte/word write timeout: 16 µs
Maximum byte/word write timeout: 256 µs
Full buffer write not supported
Typical block erase timeout: 1024 µs
Maximum block erase timeout: 8192 µs
Chip erase not supported
Device size: 0x400000 bytes (4 MiB)
Flash Device Interface description: 0x0001
  - x16-only asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 2
  Erase Region #0: BlockSize 0x2000 bytes, 8 blocks
  Erase Region #1: BlockSize 0x10000 bytes, 63 blocks

In particular the buffer write is detected as not supported.

Try this variant of the patch I'm using:

diff -u -r1.66 cfi_probe.c
--- cfi_probe.c	2 Oct 2001 15:05:12 -0000	1.66
+++ cfi_probe.c	1 Aug 2002 22:31:11 -0000
@@ -147,6 +145,28 @@
 		((unsigned char *)cfi->cfiq)[i] = cfi_read_query(map,base + (0x10 + i)*ofs_factor);
 	}
 	
+	/* The STMicroelectronics M28W320C[BT] devices report incorrect CFI data.
+	 * Check here and fix up if necessary.
+	 */
+#define VENDOR_STMICROELECTRONICS 0x0020
+#define DEVICE_M28W320CT 0xba
+#define DEVICE_M28W320CB 0xbb
+	{
+		unsigned int vendor, id;
+		vendor = cfi_read_query(map,base + 0*ofs_factor);
+		id     = cfi_read_query(map,base + 1*ofs_factor);
+printk("Vendor %08x id %08x\n", vendor, id);
+		if ((vendor == VENDOR_STMICROELECTRONICS) && (id == DEVICE_M28W320CT)) {
+			printk("Detected STM M28W320CT, applying CFI fixups\n");
+			((unsigned char*)cfi->cfiq)[0x20 - 0x10] = 0x0;
+			((unsigned char*)cfi->cfiq)[0x24 - 0x10] = 0x0;
+		}
+		if ((vendor == VENDOR_STMICROELECTRONICS) && (id == DEVICE_M28W320CB)) {
+			printk("Detected STM M28W320CB, applying CFI fixups\n");
+			((unsigned char*)cfi->cfiq)[0x31 - 0x10] = 0x3e;
+		}
+	}
+
 	/* Do any necessary byteswapping */
 	cfi->cfiq->P_ID = le16_to_cpu(cfi->cfiq->P_ID);
 	

This is not intended as a permanent fix, just to see if it fixes the problem.

Stuart


On Thu, 1 Aug 2002 14:45:45 -0500
gromit1463@mailworks.org wrote:

> Number of erase regions: 2 
> Vendor 00000020 id 000000ba 
> Primary Vendor Command Set: 0003 (Intel/Sharp Standard) 
> Primary Algorithm Table at 0035 
> Alternative Vendor Command Set: 0000 (None) 
> No Alternate Algorithm Table 
> Vcc Minimum: 2.7 V 
> Vcc Maximum: 3.6 V 
> Vpp Minimum: b.4 V 
> Vpp Maximum: c.6 V 
> Typical byte/word write timeout: 16 s 
> Maximum byte/word write timeout: 512 s 
> Typical full buffer write timeout: 16 s 
> Maximum full buffer write timeout: 512 s 
> Typical block erase timeout: 1024 s 
> Maximum block erase timeout: 8192 s 
> Chip erase not supported 
> Device size: 0x400000 bytes (4 Mb) 
> Flash Device Interface description: 0x0001 
> x16-only asynchronous interface 
> Max. bytes in buffer write: 0x4 
> Number of Erase Block Regions: 2 
> Erase Region #0: BlockSize 0x10000 bytes, 63 blocks 
> Erase Region #1: BlockSize 0x2000 bytes, 8 blocks 
> 
> 
> 
> I have 8 chips total, 4MB each.
> 
> 
> On Thu, 2002-08-01 at 13:26, Stuart Menefy wrote:
> > Try building cfi_probe.c with DEBUG_CFI set, and post what it reports.
> 
> 
> -- 
> "Find out what you've been missing while you've been
> rebooting Windows NT." -- Infoworld on Linux
> 
> http://www.ao.com/~regan/penguins/tux.html
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


-- 
Stuart Menefy                                        stuart.menefy@st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

Re: "Read-only file system" error while writing

[Stephen Hui]

Looks like it worked, Stuart.  It's calling do_write_word() instead of
do_write_buffer().

Stephen.



On Thu, 2002-08-01 at 17:37, Stuart Menefy wrote:
> 
> This is not intended as a permanent fix, just to see if it fixes the problem.
> 
> Stuart
> 

-- 
"Find out what you've been missing while you've been
rebooting Windows NT." -- Infoworld on Linux

http://www.ao.com/~regan/penguins/tux.html

Re: "Read-only file system" error while writing

[Gordon J Milne]

Hi

David Woodhouse wrote:
 > gromit1463@mailworks.org said:
 >
 >>When I write to the chips using either cat, dd, stdout redirection, or
 >>cp, the CFI driver complains of attempting to write to a "Read-only
 >>file system", even after unlocking all blocks in the partition and
 >>erasing the partition.  I can mount /dev/mtdblock*, but mount
 >>complains and I still can't put anything into the mounted partition.
 >>do_write_buffer() in cfi_cmdset_0001.c is returning the error (EROFS).
 >
 > The only case in which do_write_buffer() should return -EROFS is if the
 > status bit is set which means that the block in question was locked. Try
 > using the MEMUNLOCK ioctl to unlock it?

I am having exactly the same problem with the same ST part (M28W320CB). I am 
running uClinux (based on Linux 2.4.20). I modified the do_write_buffer() 
code to print out the status value that was read back. The value is 0xffff. 
It seems a bit strange to me that ALL the bist should be 1s.

I have tried using "unlock" to unlock the device (/dev/mtd3) but I get the 
same result.

The device (1f:03) is the root device and it has been remounted rw. I 
verified this by checking /proc/mounts - everything was rw, as expected. My 
system successfully boots and I can execute commands. It is just the 
filesystem writes that are not working for me.

Any further ideas?

Gordon

Re: "Read-only file system" error while writing

[Thayne Harbaugh]

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

On Wed, 2003-05-21 at 05:33, Gordon J Milne wrote:

> The device (1f:03) is the root device and it has been remounted rw. I 
> verified this by checking /proc/mounts - everything was rw, as expected. My 
> system successfully boots and I can execute commands. It is just the 
> filesystem writes that are not working for me.

This is the symptom if you have the incorrect unlock addresses for an
LPC flash chip: everything is readable, but nothing can be erased or
written.

The ST M28W320CB is a CFI part and so I can't guarantee that it's the
same thing, but it may be a similar problem.


-- 
Thayne Harbaugh
Linux Networx

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

Re: "Read-only file system" error while writing

[Gordon J Milne]

 > I am having exactly the same problem with the same ST part (M28W320CB).
 > I am running uClinux (based on Linux 2.4.20). I modified the
 > do_write_buffer() code to print out the status value that was read back.
 > The value is 0xffff. It seems a bit strange to me that ALL the bist
 > should be 1s.
 >
 > I have tried using "unlock" to unlock the device (/dev/mtd3) but I get
 > the same result.
 >
 > The device (1f:03) is the root device and it has been remounted rw. I
 > verified this by checking /proc/mounts - everything was rw, as expected.
 > My system successfully boots and I can execute commands. It is just the
 > filesystem writes that are not working for me.

I received an e-mail from Guillaume Gourat who pointed out to me that this 
problem has already been discussed in August 2002 and a patch was listed in 
the e-mail message.

See http://lists.infradead.org/pipermail/linux-mtd/2002-August/005579.html

I grabbed the CVS head code for MTD around January 2003 so this patch has 
clearly not made it into the mainstream source yet.

The patch works but is slightly unsightly. Basically it over-rides some of 
the information coming back from the CFI query. Is this sort of patching of 
cfp_chip_setup() common? If so, we need a standardised way of implementing 
these patches - probably a table-driven one. If not, then point patches like 
this are probably the best way to proceed on a case by case basis.

Thanks for listening.

Gordon