From tglx at linutronix.de  Thu Aug  1 05:28:24 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 01 Aug 2002 11:28:24 +0200
Subject: do i have to "eraseall" first?
In-Reply-To: <00f801c2390a$d956dd40$1b0448c0@gv.com.tw>
References: <013d01c2388f$94c655a0$1b0448c0@gv.com.tw>
 <0H04006C5M7GUI@smtp-out.bhp.t-online.de>
 <00f801c2390a$d956dd40$1b0448c0@gv.com.tw>
Message-ID: <0H05001Y6RM950@smtp-out.bhp.t-online.de>

On Thursday, 1. August 2002 05:23, ?? wrote:
> dear all,
>
> the only different config settings is CONFIG_JFFS2_FS_NAND
> but there is no "CONFIG_JFFS2_FS_NAND" in source of jffs2/mtd here!!
> (i'm using lastest jffs2/mtd source from cvs)
> please help
Sorry, CONFIG_JFFS2_FS_NAND is not patched in. Please add it manually. 

See updated information at http://www.linux-mtd.infradead.org/tech/nand.html

-- 
Thomas
___________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de



From dwmw2 at infradead.org  Thu Aug  1 06:31:40 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 01 Aug 2002 11:31:40 +0100
Subject: "Read-only file system" error while writing 
In-Reply-To: <1028147069.12139.81.camel@mahi190.austin.ibm.com> 
References: <1028147069.12139.81.camel@mahi190.austin.ibm.com>  <1028064443.23642.52.camel@mahi190.austin.ibm.com> <20020731163530.70c45960.stuart.menefy@st.com> 
Message-ID: <28851.1028197900@redhat.com>

gromit1463 at 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





From dwmw2 at infradead.org  Thu Aug  1 06:35:38 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 01 Aug 2002 11:35:38 +0100
Subject: "Read-only file system" error while writing 
In-Reply-To: <20020731163530.70c45960.stuart.menefy@st.com> 
References: <20020731163530.70c45960.stuart.menefy@st.com>  <1028064443.23642.52.camel@mahi190.austin.ibm.com> 
Message-ID: <29441.1028198138@redhat.com>

stuart.menefy at 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





From dwmw2 at infradead.org  Thu Aug  1 06:44:54 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 01 Aug 2002 11:44:54 +0100
Subject: jffs2_scan_eraseblock() - errors 
In-Reply-To: <FA06AA2C99BCD511951200005A99441001E3ECD8@irvexch1.sextantifs.com> 
References: <FA06AA2C99BCD511951200005A99441001E3ECD8@irvexch1.sextantifs.com> 
Message-ID: <30325.1028198694@redhat.com>

(Moved to JFFS list).

Allen.Curtis at Thales-IFS.com said:
> > real	47.258s

>  With the CRC patch:
>  real	36.7s

OK, that's respectable. I just need to finish the other part of the change 
-- to actually check the CRCs later on, rather than just leaving them 
unchecked. Make sure you take the patch back out of your tree now :)

We may get a little bit more of a speedup when we do that too, as we'll also
stop building up the fragment lists for every inode on mount, but in fact
that code wasn't showing up very high on the profile last time I looked.

> PS: The version of scan.c we are using is 1.57. The patch note was for
> 1.51.2.3.

Doesn't matter; it's basically the same in both branches. 

I suspect that if you profile it now you'll find the most time is taken in 
your flash map driver's copy_from routine or memcpy. 

I need to implement the XIP scheme which will also allow JFFS2 to directly
access the flash through a kind of pageable ioremap (which handles the times
when the flash is in a mode other than read mode correctly) instead of 
having to read into a buffer and work from that. We get to use caches and 
burst reads from flash at that point too.

--
dwmw2





From kevin at gv.com.tw  Thu Aug  1 08:30:31 2002
From: kevin at gv.com.tw (??)
Date: Thu, 1 Aug 2002 20:30:31 +0800
Subject: thanks , after this patch , i mount jffs2 successfully
References: <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de>
Message-ID: <001001c23957$3a290520$1b0448c0@gv.com.tw>

dear all,

thanks , after this patch , i mount jffs2 successfully
(i also patched to make zlib_deflate/zlib_inflate inside kernel's lib
instead of module)

best regards,
kevin

----- Original Message -----
From: "Thomas Gleixner" <tglx at linutronix.de>
To: "??" <kevin at gv.com.tw>; "David Woodhouse" <dwmw2 at infradead.org>
Cc: <linux-mtd at lists.infradead.org>
Sent: Thursday, August 01, 2002 5:28 PM
Subject: Re: do i have to "eraseall" first?


> On Thursday, 1. August 2002 05:23, ?? wrote:
> > dear all,
> >
> > the only different config settings is CONFIG_JFFS2_FS_NAND
> > but there is no "CONFIG_JFFS2_FS_NAND" in source of jffs2/mtd here!!
> > (i'm using lastest jffs2/mtd source from cvs)
> > please help
> Sorry, CONFIG_JFFS2_FS_NAND is not patched in. Please add it manually.
>
> See updated information at
http://www.linux-mtd.infradead.org/tech/nand.html
>
> --
> Thomas
> ___________________________________________
> linutronix - competence in embedded & realtime linux
> http://www.linutronix.de
> mail: tglx at linutronix.de
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From vadim.khmelnitsky at m-sys.com  Thu Aug  1 10:47:06 2002
From: vadim.khmelnitsky at m-sys.com (Vadim Khmelnitsky)
Date: Thu, 1 Aug 2002 07:47:06 -0700 
Subject: [patch] doc_stage1.S : GRUB on DoC
Message-ID: <AEA9DCA73595D411A6D4009027DE9C5E019BFE61@MSI-EX6>

Hi,

DOC_Millennium 8MB has small SRAM of 512bytes in size to accomodate IPL code
.
two copies of IPL code should be placed at offset 0 and offset 0x200 ( first
and second page ) of erasable unit 0 .

Vadim

-----Original Message-----
From: Ilguiz Latypov [mailto:ilatypov at superbt.com]
Sent: Wed, July 17, 2002 11:35 AM
To: Mark Meade
Cc: linux-mtd at lists.infradead.org
Subject: Re: [patch] doc_stage1.S : GRUB on DoC



On Tue, 16 Jul 2002, Mark Meade wrote:

> Ilguiz -- is the DOC_MIL_KEEP_IPL option still used?

I never used this conditional piece of code because I don't have DoC
Millennium.  I added that code before I could better understand the
mechanism of initial loading with DoC Millennium.  I don't know if the
Millennium's own IPL can perform extra download from flash offset 1024.  
If it can't, the DOC_MIL_KEEP_IPL piece can be removed.

I am behind my schedule at work at this moment.  I will be able to test 
the improved code on DoC 2000 around next week.

Ilguiz


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



From stuart.menefy at st.com  Thu Aug  1 14:05:00 2002
From: stuart.menefy at st.com (Stuart Menefy)
Date: Thu, 1 Aug 2002 19:05:00 +0100
Subject: "Read-only file system" error while writing
In-Reply-To: <28851.1028197900@redhat.com>
References: <1028147069.12139.81.camel@mahi190.austin.ibm.com>
	<1028064443.23642.52.camel@mahi190.austin.ibm.com>
	<20020731163530.70c45960.stuart.menefy@st.com>
	<28851.1028197900@redhat.com>
Message-ID: <20020801190500.7e73cf60.stuart.menefy@st.com>

On Thu, 1 Aug 2002 11:31:40 +0100
dwmw2 at infradead.org wrote:
> gromit1463 at 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 at st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com



From Joakim.Tjernlund at lumentis.se  Thu Aug  1 14:26:48 2002
From: Joakim.Tjernlund at lumentis.se (Joakim Tjernlund)
Date: Thu, 1 Aug 2002 20:26:48 +0200
Subject: Oops when unlinking stale file
References: <20020731121648.GA18892@wohnheim.fh-wedel.de>  <20020731115703.GB28984@wohnheim.fh-wedel.de> <20020731103419.GA23749@wohnheim.fh-wedel.de> <FA06AA2C99BCD511951200005A99441001E3ECBE@irvexch1.sextantifs.com> <14572.1028067711@redhat.com> <2881.1028115952@redhat.com> <4164.1028116749@redhat.com>  <6102.1028117866@redhat.com>
Message-ID: <000701c23988$ff62dd80$0200a8c0@telia.com>

When unlinking(in the stable branch) a stale file I got this:

JFFS2: Total scan time: 20.19 sec
Eep. Child "lumentis~" (ino #242) of dir ino #11 doesn't exist!
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 52k init 4k openfirmware

.....


jffs2_read_inode() on nonexistent ino 242
Oops: kernel access of bad area, sig: 11
NIP: C007FB54 XER: E000997F LR: C007FA98 SP: C516DDD0 REGS: c516dd20 TRAP: 0300
Using defaults from ksymoops -t elf32-little -a unknown
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c516c000[211] 'unlink' Last syscall: 10
last math 00000000 last altivec 00000000
GPR00: 00000000 C516DDD0 C516C000 00009032 00001032 0000000C C516DCF4 00000000
GPR08: C7DFA000 C5197DD0 C7C5D000 00000000 03E40000 100206E0 00000000 100AEED0
GPR16: 100BA9D0 10010000 10010000 00000000 00009032 0516DE80 00000000 C0002838
GPR24: C0002560 00000000 C7F3B2A0 C52E2BA0 C7A96070 C7A96180 C5197EE0 C7C5D290
Call backtrace:
C007FA98 C007FBC0 C0040FE8 C004113C C0002670 100004F4 0FED9DBC
00000000
Warning (Oops_read): Code line not seen, dumping what data is available

>>???; c007fb54 <jffs2_do_unlink+2e0/338>   <=====
Trace; c007fa98 <jffs2_do_unlink+224/338>
Trace; c007fbc0 <jffs2_unlink+14/24>
Trace; c0040fe8 <vfs_unlink+17c/1e8>
Trace; c004113c <sys_unlink+e8/194>
Trace; c0002670 <ret_from_syscall_2+0/44>
Trace; 100004f4 Before first symbol
Trace; 0fed9dbc Before first symbol
Trace; 00000000 Before first symbol




From stuart.menefy at st.com  Thu Aug  1 14:26:24 2002
From: stuart.menefy at st.com (Stuart Menefy)
Date: Thu, 1 Aug 2002 19:26:24 +0100
Subject: "Read-only file system" error while writing
In-Reply-To: <20020801190500.7e73cf60.stuart.menefy@st.com>
References: <1028147069.12139.81.camel@mahi190.austin.ibm.com>
	<1028064443.23642.52.camel@mahi190.austin.ibm.com>
	<20020731163530.70c45960.stuart.menefy@st.com>
	<28851.1028197900@redhat.com>
	<20020801190500.7e73cf60.stuart.menefy@st.com>
Message-ID: <20020801192624.28fe7b7e.stuart.menefy@st.com>

On Thu, 1 Aug 2002 19:05:00 +0100
stuart.menefy at st.com wrote:
> On Thu, 1 Aug 2002 11:31:40 +0100
> dwmw2 at infradead.org wrote:
> > gromit1463 at 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 at st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com



From mark at lakeshoremicro.com  Thu Aug  1 14:43:00 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Thu, 1 Aug 2002 14:43:00 -0400
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0207300002170.7104-100000@server.superbt.com>
References: <Pine.LNX.4.44.0207300002170.7104-100000@server.superbt.com>
Message-ID: <20020801144115.SM02488@there>

Ilguiz,

I tested the 07-29 patch on a DoC Millennium, and everything seemed to be 
working great.  I was able to build it against cvs grub with no errors, and 
the resulting grub_firmware booted fine on a 1.3Ghz Athlon.

However, I have also been experimenting with booting a variant of the Linux 
Router Project (LRP) from my DoC, and this latest Grub patch locks up on two 
different Pentium-133 PC's.  

Additionally, the M-Sys firmware also locked up on both machines.  The 
earlier Grub patch (the one with the -256 and -512 options) works fine.  I'm 
not sure what's going on here, but I'll continue to try to figure out what is 
wrong.  

Mark

Ilguiz Latypov wrote:
> I added floppy disk BIOS number (0) as a last resort when looking for boot
> configuration file.  Would you mind testing the aggregate patch I stored
> under
>
>     patches/grub-2002-07-29-doc.patch




From gromit1463 at mailworks.org  Thu Aug  1 15:45:45 2002
From: gromit1463 at mailworks.org (Stephen Hui)
Date: 01 Aug 2002 14:45:45 -0500
Subject: "Read-only file system" error while writing
In-Reply-To: <20020801192624.28fe7b7e.stuart.menefy@st.com>
References: <1028147069.12139.81.camel@mahi190.austin.ibm.com>
	<1028064443.23642.52.camel@mahi190.austin.ibm.com>
	<20020731163530.70c45960.stuart.menefy@st.com>
	<28851.1028197900@redhat.com>
	<20020801190500.7e73cf60.stuart.menefy@st.com> 
	<20020801192624.28fe7b7e.stuart.menefy@st.com>
Message-ID: <1028231145.22264.9.camel@mahi190.austin.ibm.com>

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




From Joakim.Tjernlund at lumentis.se  Thu Aug  1 16:33:34 2002
From: Joakim.Tjernlund at lumentis.se (Joakim Tjernlund)
Date: Thu, 1 Aug 2002 22:33:34 +0200
Subject: write suspend and/or erase suspend
References: <FA06AA2C99BCD511951200005A99441001E3ECD8@irvexch1.sextantifs.com>
Message-ID: <003d01c2399a$b519a9e0$0200a8c0@telia.com>

When a erase or write is suspened to allow some other part of the FS to read, is that read
garanted to read from another sector than the one that has been suspended?

I am asking since I think it's not allowed to access the sector that has a 
suspended operation. I am using Intel Strata Flash.

   Jocke



From ilatypov at superbt.com  Thu Aug  1 16:53:03 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Thu, 1 Aug 2002 16:53:03 -0400 (EDT)
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <20020801144115.SM02488@there>
Message-ID: <Pine.LNX.4.44.0208011649190.21990-100000@server.superbt.com>

On Thu, 1 Aug 2002, Mark Meade wrote:

> Additionally, the M-Sys firmware also locked up on both machines.  The 
> earlier Grub patch (the one with the -256 and -512 options) works fine.  I'm 
> not sure what's going on here, but I'll continue to try to figure out what is 
> wrong.  

Could that be due to change in MTD patch I made?  I added the
informational message output "DoC found" at the time of ROM BIOS extension
scan.  I wonder if the video card's BIOS extension can render INT 10h
unstable at that time.

Ilguiz




From mark at lakeshoremicro.com  Thu Aug  1 17:21:11 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Thu, 1 Aug 2002 17:21:11 -0400
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0208011649190.21990-100000@server.superbt.com>
References: <Pine.LNX.4.44.0208011649190.21990-100000@server.superbt.com>
Message-ID: <200208011718437.SM02488@there>

Ilguiz Latypov wrote:

> Could that be due to change in MTD patch I made?  I added the
> informational message output "DoC found" at the time of ROM BIOS extension
> scan.  I wonder if the video card's BIOS extension can render INT 10h
> unstable at that time.

I don't think so -- I temporarily removed that message, and made sure that 
the initial code (what used to be in doc_stage1.S) matched the previous 
version that worked.  It didn't make any difference - it still locked up on 
the P-133's, but not on the Athlon.

For what it's worth, on one of the PC's, the lockup occurs at line 363, in 
the readbyte loop.  We copy a few pages OK (%di = 0x400, 0x500, 0x600), but 
lock up when %di is between 0x700 and 0x800, specifically with ES:DI equal to 
0x07E0:0x0719.

The other board makes it to the "Jumping to Grub" message, but then 
immediately reboots.

Mark




From stuart.menefy at st.com  Thu Aug  1 18:37:10 2002
From: stuart.menefy at st.com (Stuart Menefy)
Date: Thu, 1 Aug 2002 23:37:10 +0100
Subject: "Read-only file system" error while writing
In-Reply-To: <1028231145.22264.9.camel@mahi190.austin.ibm.com>
References: <1028147069.12139.81.camel@mahi190.austin.ibm.com>
	<1028064443.23642.52.camel@mahi190.austin.ibm.com>
	<20020731163530.70c45960.stuart.menefy@st.com>
	<28851.1028197900@redhat.com>
	<20020801190500.7e73cf60.stuart.menefy@st.com>
	<20020801192624.28fe7b7e.stuart.menefy@st.com>
	<1028231145.22264.9.camel@mahi190.austin.ibm.com>
Message-ID: <20020801233710.6be124a0.stuart.menefy@st.com>

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 at 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 at st.com
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com



From dwmw2 at infradead.org  Thu Aug  1 19:31:00 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 02 Aug 2002 00:31:00 +0100
Subject: write suspend and/or erase suspend 
In-Reply-To: <003d01c2399a$b519a9e0$0200a8c0@telia.com> 
References: <003d01c2399a$b519a9e0$0200a8c0@telia.com>  <FA06AA2C99BCD511951200005A99441001E3ECD8@irvexch1.sextantifs.com> 
Message-ID: <12285.1028244660@redhat.com>

Joakim.Tjernlund at lumentis.se said:
> When a erase or write is suspened to allow some other part of the FS
> to read, is that read garanted to read from another sector than the
> one that has been suspended?

> I am asking since I think it's not allowed to access the sector that
> has a  suspended operation. I am using Intel Strata Flash. 

Correct. Currently we don't suspend writes, but when we do we need to make 
sure we get that right. Reading from a block on which an erase is in 
progress is a silly idea anyway, so I don't care that we don't check for 
that and make the reader wait.

--
dwmw2





From ilatypov at superbt.com  Thu Aug  1 19:44:52 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Thu, 1 Aug 2002 19:44:52 -0400 (EDT)
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <200208011718437.SM02488@there>
Message-ID: <Pine.LNX.4.44.0208011941330.25251-100000@server.superbt.com>

Would this modification make a difference?  It seems we read the first 
flash block into a different address when identifying the chip.

Ilguiz

--- doc_stage1.S	30 Jul 2002 01:09:35 -0000	1.12
+++ doc_stage1.S	1 Aug 2002 23:22:05 -0000
@@ -192,13 +192,13 @@
        /* Use existing block read routine to get Manufacturer &
        ** Chip ID.  Overkill, but saves code space.  */  
 
-       movw    $1, %cx         /* read just one page */
-       movw    $GRUBSTART, %ax
+       movw    $1, %cx			/* read just one block */
+       movw    $GRUBLOADSEG, %ax
        movw    %ax, %es
-       movw    $0, %di
+       movw    $GRUBLOADOFS, %di
        call    read_block
 
-       movw    %es:0,%ax               /* id/mfr in first 2 bytes */
+       movw    %es:(GRUBLOADOFS), %ax	/* id/mfr in first 2 bytes */
 
 #ifdef SHOW_INFO
 

On Thu, 1 Aug 2002, Mark Meade wrote:

> We copy a few pages OK (%di = 0x400, 0x500, 0x600), but lock up when %di
> is between 0x700 and 0x800, specifically with ES:DI equal to
> 0x07E0:0x0719.





From kevin at gv.com.tw  Thu Aug  1 22:50:05 2002
From: kevin at gv.com.tw (??)
Date: Fri, 2 Aug 2002 10:50:05 +0800
Subject: error when writing to jffs2
References: <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw>
Message-ID: <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw>

dear all,

error when writing to jffs2
any idea?

thanks in advanced!:)

--------- following message log -----------------------------
# cp -a bin bin2
ARGH. About to write node to 0x0004c020 on flash, but there's data already
there
:
0x0004c020: 85 19 01 e0 2d 00 00 00 3a 31 4d 58 04 00 00 00
argh. node added in wrong place
ARGH. About to write node to 0x0004c064 on flash, but there's data already
there
:
0x0004c064: 80 21 00 00 00 00 00 00 00 00 00 00 7d 7c 76 3a
argh. node added in wrong place
nand_read_ecc: Failed ECC read, page 0x00001260
ARGH. About to write node to 0x0004c020 on flash, but there's data already
there
:
0x0004c020: 85 19 00 e0 04 00 00 00 18 31 45 18 00 00 00 00
argh. node added in wrong place
Calculated used size 00003fc8 != stored used size 00003f84
kernel BUG at nodemgmt.c:320!
Unable to handle kernel paging request at virtual address 00000000, epc ==
80086
154, ra == 80086154
Oops in fault.c:do_page_fault, line 204:
$0 : 00000000 1000fc00 0000001e 00000001 8019d7d0 00000001 00000001 0005540e
$8 : 809f8af8 801a172c 0000001e fffffee0 0000000d 809f8af8 0000000a 809f8af8
$16: 81e302f8 81e450e8 00000013 00000000 81e4c3b0 00000000 00000044 81e73ec0
$24: 00001028 81e73c92                   81e72000 81e73de0 81e450e8 80086154
Hi : 00000020
Lo : 00000013
epc  : 80086154    Not tainted
Status: 1000fc04
Cause : 3000000c
Process cp (pid: 83, stackpage=81e72000)
Stack: 8015d7f0 8015d9fc 00000140 000553ed 81e73e08 81e45128 81e2c100
00000044
       00000000 00000000 00000044 00000044 00000046 81e2c100 81c6b740
81e2c100
       81d31640 81d31770 81c6b750 00000000 00000044 8008323c 00406a18
00000000
       00000000 80051e58 0004c020 00000000 81c05084 0004c020 ffffffe0
81d31640
       3b28008d 81d31640 81e73ec0 00000046 81d2fac0 00000000 00406a18
00000000
       00000000 ...
Call Trace: [<8015d7f0>] [<8015d9fc>] [<8008323c>] [<80051e58>] [<80062c6c>]
[<8
0041df8>]
 [<800543ed>] [<80041ec0>] [<80010a8c>]

Code: 24a5d9fc  0c006415  24060140 <ac000000> 8e220084  00000000  12020014
0000
0000  8e220088
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing





From jens.nixdorf at embesso.com  Fri Aug  2 04:20:47 2002
From: jens.nixdorf at embesso.com (Jens Nixdorf)
Date: Fri, 2 Aug 2002 10:20:47 +0200
Subject: DOC will formatted again and again 
Message-ID: <200208021020.47923.jens.nixdorf@embesso.com>

Hi,

i've send this posting some days before, but didn't get an answer and 
also didn't found a solution somewhere else. Therefore i send my 
question again:

--snip--

now, with your help, my DoC is acknowledged by the system. But the next
problem is underway ;)
Every time the system is booting, it try to format the DoC. It has two
bad blocks, and therefore i think it starts over and over again. How can
i get rid of it? nftl_format from the mtd-utils still doesnt work, it
brings  still the message:

ioctl(MEMGETINFO): Inappropriate ioctl for device

Here is a part of my dmesg-output after a fresh boot:

NFTL driver: nftlcore.c $Revision: 1.82 $, nftlmount.c $Revision: 1.25 $
NFTL_notify_add for DiskOnChip 2000
NFTL_setup
Formatting block 1964
Error erasing at 0x1eb0000
Error while formatting block 1964
Formatting block 6028
Error erasing at 0x5e30000
Error while formatting block 6028
Cannot calculate an NFTL geometry to match size of 0x853c0.
Using C:1003 H:16 S:34 (== 0x85360 sects)
  nftla:<6>NFTL_request
NFTL read request of 0x2 sectors @ 0 (req->nr_sectors == 8)
NFTL read request completed OK
NFTL_request
NFTL read request of 0x2 sectors @ 2 (req->nr_sectors == 6)
NFTL read request completed OK
NFTL_request
NFTL read request of 0x2 sectors @ 4 (req->nr_sectors == 4)
NFTL read request completed OK
NFTL_request
NFTL read request of 0x2 sectors @ 6 (req->nr_sectors == 2)
NFTL read request completed OK
  nftla1

--snip--

Thanks in Advance, Jens




From dwmw2 at infradead.org  Fri Aug  2 04:41:07 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 02 Aug 2002 09:41:07 +0100
Subject: DOC will formatted again and again 
In-Reply-To: <200208021020.47923.jens.nixdorf@embesso.com> 
References: <200208021020.47923.jens.nixdorf@embesso.com> 
Message-ID: <25819.1028277667@redhat.com>

jens.nixdorf at embesso.com said:
>  i've send this posting some days before, but didn't get an answer and
>  also didn't found a solution somewhere else. Therefore i send my
> question again: 

You need to ensure the offending blocks are _marked_ as bad so we don't try 
to format them again. Not sure why we don't do that anyway when the format 
fails.

Where did you get nftl_format and how are you trying to run it?

--
dwmw2





From Joakim.Tjernlund at lumentis.se  Fri Aug  2 05:27:12 2002
From: Joakim.Tjernlund at lumentis.se (Joakim Tjernlund)
Date: Fri, 2 Aug 2002 11:27:12 +0200
Subject: write suspend and/or erase suspend 
References: <003d01c2399a$b519a9e0$0200a8c0@telia.com>  <FA06AA2C99BCD511951200005A99441001E3ECD8@irvexch1.sextantifs.com>  <12285.1028244660@redhat.com>
Message-ID: <003b01c23a06$c83c3940$0200a8c0@telia.com>

From: "David Woodhouse" <dwmw2 at infradead.org>
> 
> Joakim.Tjernlund at lumentis.se said:
> > When a erase or write is suspened to allow some other part of the FS
> > to read, is that read garanted to read from another sector than the
> > one that has been suspended?
> 
> > I am asking since I think it's not allowed to access the sector that
> > has a  suspended operation. I am using Intel Strata Flash. 
> 
> Correct. Currently we don't suspend writes, but when we do we need to make 
> sure we get that right. Reading from a block on which an erase is in 
> progress is a silly idea anyway, so I don't care that we don't check for 
> that and make the reader wait.

Yes, it's silly but can it happen by mistake? The flash state machine may be 
confused if an access is made during suspend. 

hmm, my modified driver also supports "suspend erase to do a write". Could that be a problem? 

> 
> --
> dwmw2
> 
> 



From dwmw2 at infradead.org  Fri Aug  2 05:42:43 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 02 Aug 2002 10:42:43 +0100
Subject: write suspend and/or erase suspend 
In-Reply-To: <003b01c23a06$c83c3940$0200a8c0@telia.com> 
References: <003b01c23a06$c83c3940$0200a8c0@telia.com>  <003d01c2399a$b519a9e0$0200a8c0@telia.com> <FA06AA2C99BCD511951200005A99441001E3ECD8@irvexch1.sextantifs.com> <12285.1028244660@redhat.com> 
Message-ID: <1236.1028281363@redhat.com>

Joakim.Tjernlund at lumentis.se said:
>  Yes, it's silly but can it happen by mistake? The flash state machine
> may be  confused if an access is made during suspend. 

You'll get a buffer full of status bits, I expect. Doesn't matter -- the 
contents of the block at that time are undefined because they're in the 
middle of an erase.

> hmm, my modified driver also supports "suspend erase to do a write".
> Could that be a problem? 

Again, only if someone's trying to write to a block they're currently 
trying to erase -- which they shouldn't be doing.

We _should_ be checking for these things in the driver, and we _definitely_ 
have to do so before start suspending writes to perform reads. But at the 
moment, the only way a user could trigger wrong behaviour is if they're 
doing something bloody stupid anyway.


--
dwmw2





From mark at lakeshoremicro.com  Fri Aug  2 09:37:08 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Fri, 2 Aug 2002 09:37:08 -0400
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0208011941330.25251-100000@server.superbt.com>
References: <Pine.LNX.4.44.0208011941330.25251-100000@server.superbt.com>
Message-ID: <200208020933750.SM02488@there>

Ilguiz Latypov wrote:
> Would this modification make a difference?  It seems we read the first
> flash block into a different address when identifying the chip.

This didn't make any difference.  It still works find on the faster machine; 
reboots on the P133.

Using GRUBSTART:0 is probably the better way to do this: GRUBSTART:0 is 
equivalent to GRUBLOADSEG:GRUBLOADOFS (8200:0, 07E0:400), and using zero as 
the offset causes the "read block" command to send an address of 0 after 
sending the READID command, similar to the way it's done in bdev_diskonchip.c.

Either way, the result (mfg/id code) temporarily ends up at 8200:0, prior to 
be replaced by the Grub code.

Mark

> -       movw    $1, %cx         /* read just one page */
> -       movw    $GRUBSTART, %ax
> +       movw    $1, %cx			/* read just one block */
> +       movw    $GRUBLOADSEG, %ax
>         movw    %ax, %es
> -       movw    $0, %di
> +       movw    $GRUBLOADOFS, %di
>         call    read_block



From ilatypov at superbt.com  Fri Aug  2 10:02:33 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Fri, 2 Aug 2002 10:02:33 -0400 (EDT)
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <200208020933750.SM02488@there>
Message-ID: <Pine.LNX.4.44.0208020949420.26999-100000@server.superbt.com>

Mark,

On Fri, 2 Aug 2002, Mark Meade wrote:

> Using GRUBSTART:0 is probably the better way to do this: GRUBSTART:0 is 
> equivalent to GRUBLOADSEG:GRUBLOADOFS (8200:0, 07E0:400), and using zero as 
                                         ^^^^    ^^^^
I believe GRUBSTART is the offset value while GRUBLOADSEG is the segment 
value, i.e. GRUBSTART == (GRUBLOADSEG << 4) + GRUBLOADOFS.  The original 
code was reading a 256 byte flash block into 0x8200:0 which is 532480, and 
this could be either GRUB's playground or interrupt handlers set up by 
BIOS.

> the offset causes the "read block" command to send an address of 0 after
> sending the READID command, similar to the way it's done in
> bdev_diskonchip.c.

I understand that the same register %di serves as the offset to the
destination in RAM and as the offset in flash.  And stage2 or doc2000.c 
code will read chip ID from offset 0.  I think the offset may not be 
important because the READID command tells the chip to report the ID.  

I'd better assign (GRUBLOADSEG << 4) to %es and 0 to %di to stay safe 
though.

Ilguiz




From gromit1463 at mailworks.org  Fri Aug  2 10:46:23 2002
From: gromit1463 at mailworks.org (Stephen Hui)
Date: 02 Aug 2002 09:46:23 -0500
Subject: "Read-only file system" error while writing
In-Reply-To: <20020801233710.6be124a0.stuart.menefy@st.com>
References: <1028147069.12139.81.camel@mahi190.austin.ibm.com>
	<1028064443.23642.52.camel@mahi190.austin.ibm.com>
	<20020731163530.70c45960.stuart.menefy@st.com>
	<28851.1028197900@redhat.com>
	<20020801190500.7e73cf60.stuart.menefy@st.com>
	<20020801192624.28fe7b7e.stuart.menefy@st.com>
	<1028231145.22264.9.camel@mahi190.austin.ibm.com> 
	<20020801233710.6be124a0.stuart.menefy@st.com>
Message-ID: <1028299583.23314.1.camel@mahi190.austin.ibm.com>

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




From ilatypov at superbt.com  Fri Aug  2 15:18:30 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Fri, 2 Aug 2002 15:18:30 -0400 (EDT)
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0208020949420.26999-100000@server.superbt.com>
Message-ID: <Pine.LNX.4.44.0208021518030.27706-100000@server.superbt.com>

On Fri, 2 Aug 2002, Ilguiz Latypov wrote:

> I'd better assign (GRUBLOADSEG << 4) to %es and 0 to %di to stay safe 
> though.

I meant GRUBSTART >> 4.  Sorry.






From mark at lakeshoremicro.com  Fri Aug  2 15:49:39 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Fri, 2 Aug 2002 15:49:39 -0400
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0208020949420.26999-100000@server.superbt.com>
References: <Pine.LNX.4.44.0208020949420.26999-100000@server.superbt.com>
Message-ID: <200208021549578.SM02488@there>

Ilguiz,

Indeed, the READID command doesn't seem to care what address is sent -- the 
answer came back correctly either way.

Here's what I've learned so far:

1)  The Grub CVS code (from 7/30), with the 2002-06-21 patch applied also 
causes the P133 machine to reboot.  This code has none of the combined 
doc_stage1/1b additions made in the 07-29 patch.

2)  The 0.92 Grub, with an earlier doc patch (I think it was 05-30) boots 
fine.

3)  Using the combined doc_stage1/1b with 0.92 Grub does not work.

Again, all three combinations above work just fine on the faster PC.

Item #1 seems to suggest that cvs grub may have introduced the problem, but 
in that case #3 should work.  Item #3 was patched manually (just doc_stage1.S 
and the Makefile), so it's possible I missed something else in your 07-29 
patch.

Anyway, is it possible to take an unmodified 0.92 Grub, and cleanly apply the 
latest (07-29) patch?  I was not able to do this, mainly because of automake 
version differences.  

Thanks,

Mark

Ilguiz Latypov wrote:
> I understand that the same register %di serves as the offset to the
> destination in RAM and as the offset in flash.  And stage2 or doc2000.c
> code will read chip ID from offset 0.  I think the offset may not be
> important because the READID command tells the chip to report the ID.




From ilatypov at superbt.com  Fri Aug  2 17:27:11 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Fri, 2 Aug 2002 17:27:11 -0400 (EDT)
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <200208021549578.SM02488@there>
Message-ID: <Pine.LNX.4.44.0208021720020.1426-100000@server.superbt.com>

On Fri, 2 Aug 2002, Mark Meade wrote:

> Anyway, is it possible to take an unmodified 0.92 Grub, and cleanly apply the 
> latest (07-29) patch?  I was not able to do this, mainly because of automake 
> version differences.  

I once moved to post-0.92 snapshot by adjusting the MTD DOC patch to the
new terminal emulation.  It's not a big deal to downgrade the terminal
emultaion changes, but I have some other issues at work till the middle of
August.

I updated the 07-29 patch in the folowing areas:
 
  a) correct the READID memory block and flash addresses
  b) restore the accidentally dropped builtins.c modifications

The correction (b) came up after a routine check of the new patch against
the old patch.  Could be another reason for GRUB malfunction on P133...

Ilguiz




From ilatypov at superbt.com  Fri Aug  2 17:57:41 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Fri, 2 Aug 2002 17:57:41 -0400 (EDT)
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0208021720020.1426-100000@server.superbt.com>
Message-ID: <Pine.LNX.4.44.0208021755070.3723-100000@server.superbt.com>

On Fri, 2 Aug 2002, Ilguiz Latypov wrote:

> It's not a big deal to downgrade the terminal emultaion changes, but I
> have some other issues at work till the middle of August.

I produce more noise than I code :)  I attempted to downgrade to 0.92 and 
added the grub-0.92-doc.patch to the CVS mtd/patches area.

Both 07-29 and 0.92 patches work with 32M DoC 2000 on the Advantech PCA 
6753 F board.

Ilguiz




From Vipin.Malik at EmersonProcess.com  Fri Aug  2 17:59:07 2002
From: Vipin.Malik at EmersonProcess.com (Malik, Vipin [FRCO/HOU])
Date: Fri, 2 Aug 2002 16:59:07 -0500 
Subject: MTD Partition problems
Message-ID: <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>

Hi Folks,

I'm just getting back into playing with this.

Is there something broken with the mtd partitioning code?

I defined 3 mtd partitions on one 8MB flash. The partitions look fine on the
debug log and a "cat /proc/mtd" shows three devices with the proper sizes
and names as defined in my "mtd_partition" map structure in my map file.

However, it seems that 6 mtd partitions have been added (even though just 3
show up in /proc/mtd)!

Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3
respectively. Each of the pairs point to the same partitions (have the same
stuff in them).

However mtdblock0,1,2 point to the correct partitions!

And I've checked that my /dev/mtd0,1,2,3,4,5 devices are pointing to char
devices 30,1...5

Any clues?

Vipin
 



From joern at wohnheim.fh-wedel.de  Sat Aug  3 05:46:16 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Sat, 3 Aug 2002 11:46:16 +0200
Subject: MTD Partition problems
In-Reply-To: <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
References: <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
Message-ID: <20020803094616.GA13044@wohnheim.fh-wedel.de>

On Fri, 2 August 2002 16:59:07 -0500, Malik, Vipin [FRCO/HOU] wrote:
> I'm just getting back into playing with this.
> 
> Is there something broken with the mtd partitioning code?

Not really broken, but maybe useless.

> I defined 3 mtd partitions on one 8MB flash. The partitions look fine on the
> debug log and a "cat /proc/mtd" shows three devices with the proper sizes
> and names as defined in my "mtd_partition" map structure in my map file.
> 
> However, it seems that 6 mtd partitions have been added (even though just 3
> show up in /proc/mtd)!
> 
> Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3
> respectively. Each of the pairs point to the same partitions (have the same
> stuff in them).

One device of each pair is read-only. This is by design and scheduled
to be ripped out sometime.

David, 2.4.19 is released, but I am right in my exam period. Does end
of August and/or beginning of September sound ok for the merge?

J?rn

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth



From vipin at embeddedlinuxworks.com  Sat Aug  3 08:09:34 2002
From: vipin at embeddedlinuxworks.com (Vipin Malik)
Date: Sat, 03 Aug 2002 07:09:34 -0500
Subject: MTD partitioning code broken?
Message-ID: <5.1.0.14.0.20020803070206.03f02008@64.170.22.132>

Hi Folks,

I'm just getting back into playing with this again after successfully 
setting up partitioning up last year..

Is there something broken with the mtd partitioning code?

I defined 3 mtd partitions on one 8MB flash in my map file (based off the 
maps/netsc520.c). The partitions look fine on the printk debug log and a 
"cat /proc/mtd" shows three devices with the proper sizes and names as 
defined in my "mtd_partition" map structure in my map file.

However, it seems that 6 mtd partitions have been added (even though just 3 
show up in /proc/mtd)!
All 6 mtd devices from /dev/mtd0...5 allow a "less -f on them".

Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3 
respectively. Each of the *pairs* above point to the same partitions (have 
the same stuff in them, pair 1 points to partition 1 etc.).

However mtdblock0,1,2 each points to the correct partition! In fact I'm 
booting root fs from /dev/mtdblock1 which does contain the correct 
compressed root fs.

And I've checked that my /dev/mtd0,1,2,3,4,5 devices are pointing to char 
devices 30,1...5

Any clues?

Vipin

P.S. This is a resend of my mail yesterday from my work address that 
apparently did not make it even though the MX-verify script did not have a 
problem with my work address(?). In case that one shows up too- apologies!




From vipin at embeddedlinuxworks.com  Sat Aug  3 08:47:11 2002
From: vipin at embeddedlinuxworks.com (Vipin Malik)
Date: Sat, 03 Aug 2002 07:47:11 -0500
Subject: MTD Partition problems
In-Reply-To: <20020803094616.GA13044@wohnheim.fh-wedel.de>
References: <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
Message-ID: <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>

At 11:46 AM 8/3/2002 +0200, J?rn Engel wrote:
>On Fri, 2 August 2002 16:59:07 -0500, Malik, Vipin [FRCO/HOU] wrote:
> > I'm just getting back into playing with this.
> >
> > Is there something broken with the mtd partitioning code?
>
>Not really broken, but maybe useless.


Hmm, useless as in "that functionality has been depricated- a better way is 
available- use <state better way here>" or useless as in "it's good stuff 
but currently not working".

I am (almost) sure that it was working and allowed me to setup different 
read/write partitions on the same flash chip (about 9-12 months ago).



> > I defined 3 mtd partitions on one 8MB flash. The partitions look fine 
> on the
> > debug log and a "cat /proc/mtd" shows three devices with the proper sizes
> > and names as defined in my "mtd_partition" map structure in my map file.
> >
> > However, it seems that 6 mtd partitions have been added (even though just 3
> > show up in /proc/mtd)!
> >
> > Each of mtd[0,1], mtd[2,3] and mtd[4,5] pairs point to partitions 1,2&3
> > respectively. Each of the pairs point to the same partitions (have the same
> > stuff in them).
>
>One device of each pair is read-only. This is by design and scheduled
>to be ripped out sometime.


Sorry for the stupid question: If it's by design, why is it going to be 
ripped out sometime soon?


>David, 2.4.19 is released, but I am right in my exam period. Does end
>of August and/or beginning of September sound ok for the merge?


Should I be using the main CVS code or some branch. The above was with 
2.4.19-rc3.

Thanks

Vipin
P.S. I noticed that my original mail did show up, but not at work. Hmmm. 
Sorry for the duplicate post.



>J?rn
>
>--
>Beware of bugs in the above code; I have only proved it correct, but
>not tried it.
>-- Donald Knuth
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/




From joern at wohnheim.fh-wedel.de  Sat Aug  3 10:10:13 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Sat, 3 Aug 2002 16:10:13 +0200
Subject: MTD Partition problems
In-Reply-To: <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
References: <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
Message-ID: <20020803141013.GA14370@wohnheim.fh-wedel.de>

On Sat, 3 August 2002 07:47:11 -0500, Vipin Malik wrote:
> >> Is there something broken with the mtd partitioning code?
> >
> >Not really broken, but maybe useless.
> 
> Hmm, useless as in "that functionality has been depricated- a better way is 
> available- use <state better way here>" or useless as in "it's good stuff 
> but currently not working".

Useless as in useless, really. Functionality is added, that is
available anyway.

> >One device of each pair is read-only. This is by design and scheduled
> >to be ripped out sometime.
> 
> Sorry for the stupid question: If it's by design, why is it going to be 
> ripped out sometime soon?

It might have made sense, when it was designed. It might just have
been a relatively new developer making the usual mistakes. Whatever.

Fact is that it is useless, the superuser can create a read only
device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
those extra devices do, except for causing confusion and eating up
minor numbers.

People would get even more confused when suddenly the device nodes
have different behaviour, which will definitely happen as soon as the
ro-devices are gone. But I have some patches in my queue that will
create confusion anyway. You do the math.

> >David, 2.4.19 is released, but I am right in my exam period. Does end
> >of August and/or beginning of September sound ok for the merge?
> 
> Should I be using the main CVS code or some branch. The above was with 
> 2.4.19-rc3.

Currently, there is no branch that tackles this problem. There was
one, but David never took a look, was busy, and rescheduled to 'when
2.4.19 is out'. Now I am busy,...

J?rn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."



From mtd-linux at embeddedlinuxworks.com  Sat Aug  3 15:24:32 2002
From: mtd-linux at embeddedlinuxworks.com (Vipin Malik)
Date: Sat, 03 Aug 2002 14:24:32 -0500
Subject: MTD Partition problems
In-Reply-To: <20020803141013.GA14370@wohnheim.fh-wedel.de>
References: <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
Message-ID: <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>

> >
> > Sorry for the stupid question: If it's by design, why is it going to be
> > ripped out sometime soon?
>
>It might have made sense, when it was designed. It might just have
>been a relatively new developer making the usual mistakes. Whatever.
>
>Fact is that it is useless, the superuser can create a read only
>device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
>those extra devices do, except for causing confusion and eating up
>minor numbers.

So if I read you correctly, you are saying that the partitioning code 
really works but in a quirky way: the presence of duplicate read only 
paired devices, which really provide no useful functionality.

However, if one ignores the duplicated devices, one can still use 
partitioning and mount a JFFS2 fs on one of the partitions while having 
something completely different on another and device access locking will be 
taken care of by the mtd driver (which is essentially what partitioning 
provides vs. just calling add_mtd() NUM_PARTITION times in your map file on 
the same flash chip).

Additionally, (say) /dev/mtdblock2 will really provide a handle to 
/dev/mtd4 the writable third partition on the partitioned flash chip, thus 
mounting the JFFS2 fs on the partition originally intended (the third 
partition).

Unfortunately, my tests indicate that this is not happening. I know that 
/dev/mtdblock2 (the intended third partition) is formatted. However JFFS2 
finds data here and refuses to mount on it. I think it is really being 
passes a handle to and accesses /dev/mtd2, which is the wrong partition.

/dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and /dev/mtd4 
is the correct partition that I want!

Argh! I'll try your patches if you like.

Thanks for your answers.

Vipin




>People would get even more confused when suddenly the device nodes
>have different behaviour, which will definitely happen as soon as the
>ro-devices are gone. But I have some patches in my queue that will
>create confusion anyway. You do the math.
>
> > >David, 2.4.19 is released, but I am right in my exam period. Does end
> > >of August and/or beginning of September sound ok for the merge?
> >
> > Should I be using the main CVS code or some branch. The above was with
> > 2.4.19-rc3.
>
>Currently, there is no branch that tackles this problem. There was
>one, but David never took a look, was busy, and rescheduled to 'when
>2.4.19 is out'. Now I am busy,...
>
>J?rn
>
>--
>Public Domain  - Free as in Beer
>General Public - Free as in Speech
>BSD License    - Free as in Enterprise
>Shared Source  - Free as in "Work will make you..."
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/




From joern at wohnheim.fh-wedel.de  Sat Aug  3 19:50:32 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Sun, 4 Aug 2002 01:50:32 +0200
Subject: MTD Partition problems
In-Reply-To: <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>
References: <5.1.0.14.0.20020803074026.02927a48@64.170.22.132> <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <5.1.0.14.0.20020803074026.02927a48@64.170.22.132> <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>
Message-ID: <20020803235032.GA8021@wohnheim.fh-wedel.de>

On Sat, 3 August 2002 14:24:32 -0500, Vipin Malik wrote:
> >Fact is that it is useless, the superuser can create a read only
> >device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
> >those extra devices do, except for causing confusion and eating up
> >minor numbers.
> 
> So if I read you correctly, you are saying that the partitioning code 
> really works but in a quirky way: the presence of duplicate read only 
> paired devices, which really provide no useful functionality.

Yes.

> However, if one ignores the duplicated devices, one can still use 
> partitioning and mount a JFFS2 fs on one of the partitions while having 
> something completely different on another and device access locking will be 
> taken care of by the mtd driver (which is essentially what partitioning 
> provides vs. just calling add_mtd() NUM_PARTITION times in your map file on 
> the same flash chip).

Yes. The partitioning code basically checks the limits and hands the
work to the base device with adjusted offset.

> Additionally, (say) /dev/mtdblock2 will really provide a handle to 
> /dev/mtd4 the writable third partition on the partitioned flash chip, thus 
> mounting the JFFS2 fs on the partition originally intended (the third 
> partition).

Almost. /dev/mtd4 should be minor number 8. If you check
/usr/src/linux/Documentation/devices.txt, you will read the following:
                  0 = /dev/mtd0         First MTD (rw)
                  1 = /dev/mtdr0        First MTD (ro)
Thus mtd0 has minor 0, mtd1 has minor 2, ...

Also, the third partition is /dev/mtd3, as /dev/mtd0 is the real
device. Look at the minor numbers for /dev/hda*, just the same.

But what you *meant* is correct.

> Unfortunately, my tests indicate that this is not happening. I know that 
> /dev/mtdblock2 (the intended third partition) is formatted. However JFFS2 
> finds data here and refuses to mount on it. I think it is really being 
> passes a handle to and accesses /dev/mtd2, which is the wrong partition.

See above.

> /dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and /dev/mtd4 
> is the correct partition that I want!

See above.

> Argh! I'll try your patches if you like.

I would be happy if you did. But you don't need my patches, unless you
have more than one device that you want to partition. With the two
thinkos out of the way, you should be doing fine. :)

J?rn

-- 
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens



From gamble at wamis0.cse.nsysu.edu.tw  Sun Aug  4 15:51:59 2002
From: gamble at wamis0.cse.nsysu.edu.tw (=?big5?B?qkyt171u?=)
Date: Mon, 5 Aug 2002 03:51:59 +0800
Subject: problem about detecting FlashROM
Message-ID: <NGBBJOODKLONIAOACJDBKEJACAAA.gamble@wamis0.cse.nsysu.edu.tw>

Dear Sir
	I am trying to boot Linux kernel 2.4.16 on FlashROM
	My environment is 
	board : TOSHIBA TX4927 with FlashROM
 	kernel : linux kernel 2.4.16 with NFSroot ( I wonder whether this root filesystem will affect somethings )
	
	I have builded the Linux kernel with MTD/JIFFS/CFI supported , according to mtd-jffs-HOWTO.txt
	But when I type the "modprobe -a physmap" command , it displays that 
	" modprobe: Can't locate module physmap "

	Any help would be appreciated.
	Thank you
	

From gamble at wamis0.cse.nsysu.edu.tw  Sun Aug  4 15:54:02 2002
From: gamble at wamis0.cse.nsysu.edu.tw (=?X-UNKNOWN?Q?=AAL=AD=D7=BDn?=)
Date: Mon, 5 Aug 2002 03:54:02 +0800 (CST)
Subject: problem about detecting FlashROM
Message-ID: <Pine.BSF.4.21.0208050351180.34590-100000@wamis0.cse.nsysu.edu.tw>

Dear Sir
	I am trying to boot Linux kernel 2.4.16 on FlashROM
	My environment is 
	board : TOSHIBA TX4927 with FlashROM
 	kernel : linux kernel 2.4.16 with NFSroot ( I wonder whether this
                 root filesystem will affect somethings )
	
	I have builded the Linux kernel with MTD/JIFFS/CFI supported ,
        according to mtd-jffs-HOWTO.txt
	
        But when I type the "modprobe -a physmap" command , it displays
        that " modprobe: Can't locate module physmap "

	Any help would be appreciated.
	Thank you





From 1234 at 1234.com  Sun Aug  4 21:32:58 2002
From: 1234 at 1234.com (中关村耗材城)
Date: Mon, 5 Aug 2002 09:32:58 +0800
Subject: 中关村耗材城(订购热线：62567625、62526139)
Message-ID: <4121-2200281513257917@smtp.vip.sina.com>

?????????????????????????????????100??????????????????????????????????????????????????????????????????????100??????????
??????(?????62567625?62526139)
  ?????????????????????????????????????????????????????????????????
  ???????????????????????????????
  ???????????????????
? ? ? ? ? ?	
?   ?	?   ????	?   ?	?   ????	?   ?	?   ????	
BC-01	150	BC-10	235	BCI-61	214	
BC-02	160	BC-11E	268	BCI-10BK	95	
BC-03	150	BC-21E	283	BCI-11BK	84	
BC-05	165	BC-22E	192	BCI-11C	115	
BC-06	165	BC-23	195	BCI-11BK?C	162	
BC-20	175	BC-60	214	BCI-21BK?C	132	
BC-30	212	BC-31	     265	BCI-21BK	65	
BC-32	265	BCI-3B?C?M?Y	238	BCI-21C	95	
BX-2	135	BX-3	166	BJI-201B?C?M?Y	205	
BJI-642	103	BCI-3BK	91	BCI-24BK?C	145	
? ? ? ? ? ?	
FX-1	580	FX-3	480	EP-A	465	
FX-2	530	FX-4	595	EP-22	460	
E-16	495	EP-BII	1310			
EPSON ? ? ? ?	
SO20039	168	SO20093	94	T001091	165	
SO20062	240	SO20110	90	T007091	115	
SO20034	122	SO20108	125	T008091	110	
SO20066	230	SO20089	155	T009091	165	
SO20047	114	SO20187	106	T003091	95	
SO20049	184	SO20191	153	T003092	168	
SO20097	184	SO20193	110	T004091	125	
T017091	148	T017092	285	T018091	158	
SO20138	110	SO20189	155	T003092	360	
EPSON ? ? ? ?	
S051035	1480	S050005	440	S050010	650	
S051029	680	S051055	540	S051069	1050	
HP  ? ? ? ?	
51626A	215	51640A	214	C1843A	155	
51629A	210	51645A	214	C1823D	232	
51625A	210	C6614A	210	C6578D	240	
61649A	215	C6615A	214	C6625A	250	
50604A	145	51641A	275	C6577A	185	
51644CMY	270	C4844A	265	C4841/42/43	270	
HP ? ? ? ?	
92274A	720	C3977A	380	C4127A	750	
92298A	730	C3906F	430	C4127X	960	
C3900A	1210	C3903F	580	C4129X	1210	
C3909A	1370	C4092A	465	C4096A	760	
C4191A	740	C4195A	750	C4196A	2110	
C4149A	1050	C4153A	1350	C4154A	2115	
C7115A	450	C8061A	840	C8061X	1020	
C41/92/93/94A	1100	C4150/51/52A	1480			
? ? ? ? ? ?	
12A1145	195	12A1970	220	17G0050	220	
12A1140	225	12A1980	250	17G0060	2351	
12A1190	295	15M0120	270	10N0217	230	
? ? ? ? ?? ? ? ?	
LJ2312?	580	LJ6P/6P+?	750	LJ6012?	580	
LJ2312?	350	LJ6P/6P+?	280	LJ6012?	220	
???????????	
SF5100	580	SF5800	820	ML4500	520	
P8710	1350	P8595	1350	P8585	1270	

? ? ? ? ? ??? ? ?	
?   ?	?   ????	?   ?	?   ????	?   ?	?   ????	
1215?	280	4050?	310	3825?	2100	
3020?	360	6030?	250	6016?	1370	
3100?	200	6350?	580	6030?	960	
3050?	310	7163?	245	6330?	1150	
2120?	250	4050?	740	3020?	1160	
3050??	470	1215??	610	7163?	1440	
? ? ? ? ? ? ?? ? ?	
Z-20?	85	226?	165	730?	145	
125?	175	230?	370	780?	135	
126?	150	234?	185	880?	175	
214?	180	235?	195	AL100??	150	
216?	175	240?	375	AR200??	680	
222?	175	214??	740	235??	1260	
? ? ? ? ? ? ?? ? ?	
4000?	105	410?	185	200?	190	
4015?	165	420?	235	310?	350	
5010?	120	610?	560	4000?	275	
4501?	285	810?	830	4015?	230	
4000?	330	4015?	420	5035?	370	
? ? ? ? ? ? ?? ? ? 	
1310?	510	2060?	510	1350?	195	
1710?	440	1310?	175	1550?	165	
1710?	165	2060?	165	3560?	295	
1550??	250	1710??	250	2060??	270	
? ? ? ? ? ??? ? ?	
1027?	110	V330?	220	5317?	260	
811?	220	1027??	295	1027??	480	
? ? ? ? ? ? ??? ? ?	
101A?	140	102A?	145	104A?	175	
201A?	215	204A?	235	101??	875	
? ? ? ? ? ? ??? ? ?	
1015?	165	1020?	145	1515?	150	
2028?	275	1015??	270	1515??	270	
? ? ? ? ? ? ?? ? ?	
7113?	210	7718? 	230	7728?	510	
7113??	490	7113??	350	8710??	1370	
? ? ? ? ? ? ?	
??134	110	??136	95	??15CR	120	
??780	65	??1270	80	??1350	80	
?????	95	? ? ? ? ? ? ? ?	
?    ?    ?    ?	
MAXELL????	50	SONY????	55	TDK????	43	
MAXELL????	38	SONY????	40	TDK????	32	
IBM????	55	??????	48	DYSAN????	48	
IBM????	38	??????	36	DYSAN????	36	
?   ?   ?   ?	
??CD-R	5.5	SONY CD-R	5.5	HP  CD-R	6.5	
??CD-W	16	SONY CD-RW	21	HP  CD-RW	32	
??????????	
?  ?  ?  ?  ?	
???210*30	11.8	???210*50	22.5	???210*100	40	
???210*30	11	???210*50	19	???210*100	36	
???210*30	11	???210*50	19	???210*100	36	
??210*30	9	??210*50	17	??210*100	36	
??????
??	??	??/?	??/?	??	??	??/?	??/?	
? ? ? ? ? ?	70GA4	10?	230	? ? ? ? ?	70GA4	10?	175	
	70GA3	5?	230		70GA3	5?	175	
	70GB5	10?	178		70GB5	10?	135	
	70GB4	5?	178		70GB4	5?	135	
	80GA4	8?	210		80GA4	10?	208	
	80GA3	4?	210		80GA3	5?	208	
	80GB5	10?	205		80GB5	10?	185	
	80GB4	5?	205		80GB4	5?	185	
? ? ? 	70GA4	10?	190	? ? ?	70GA4	10?	215	
	70GA3	5?	190		70GA3	5?	215	
	70GB5	10?	155		70GB5	10?	165	
	70GB4	5?	155		70GB4	5?	165	
	82GA4	8?	190		82GA4	8?	200	
	80GA3	4?	190		80GA3	5?	200	
? ?	70GA4	8?	145	? ?	70GA4	10?	190	
	70GA3	4?	145		70GA3	5?	190	
	70GB5	8?	120		70GB5	10?	150	
	70GB4	4?	120		70GB4	5?	150	
? ? ?	70GA4	10?	175	? ? ?	70GA4	10?	170	
	70GA3	5?	175		70GA3	5?	170	
	70GB5	10?	135		70GB5	10?	130	
	70GB4	5?	135		70GB4	5?	130	
? ? 	70GA4	10?	175	? ?	70GA4	10?	170	
	70GA3	5?	175		70GA3	5?	170	
	70GB5	10?	135		70GB5	10?	130	
	70GB4	5?	135		70GB4	5?	130	
?????	?  ?	?  ?	73G???	?  ?	?  ?	
A0	2?/?	230	A0	1?/?	220	
A1	2?/?	170	A2	1?/?	160	
A2	2?/?	130	A1	1?/?	175	
A1	500?	170	A3	500?	210	
A2	500?	130	A4	500?	110	
???	?  ?	?  ?	???	?  ?	?  ?	
230GA4	100?	40	120GA3	500?	380	
230GA3	100?	65	120GA4	500?	195	
180GA3	100?	30	100GA3	500?	295	
180GA4	100?	60	100GA4	500?	150	
EPSON???	?/?	?  ?	?????	?/?	?  ?	
A3	100?	75	A3	100?	65	
A4	100?	45	A4	100?	40	
EPSON??	?/?	?  ?	????	?/?	?  ?	
A3	10/?	160	A3	10?	70	
A4	20/?	75	A4	20?	40	
????	?/?	?  ?	????	?/?	?  ?	
17.5CA4	100?	40	6MM	100?	18	
17.5CA3	100?	75	8MM	100?	20	
20CA4	100?	45	10MM	100?	25	
??????
???	?   ?	????	?   ?(?)	
???	HA007(2)P/T	??????	145	
???	HA007(3)P/TSDL	????????	160	
???	HA007(32)P/TSDL	????????	218	
???	HA007(41)P/TSDL	???????????	165	
???	HA007(45)P/TSDL	???????????	160	
???	HA1968P/TD	????????	75	
???	HA2968(1)P/TSDL	???IP, ????	138	
???	HA2968(2)P/TSDL	???IP, ????	138	
???	HA2968(3)P/TSDL	???IP?????	138	
???	HA2968(2)CP/T	???IP?????????	180	
???	HA2968(1)DP/T	???IP??????????	185	
???	HA2968(2)AP/T	???IP?????????	180	
???	HA8838(4A)P/TSDL	????????	118	
???	HA8838(2)P/TSDL	????????	110	
???	HA8838(9)P/TSDL	????????	115	
???	HCD8838(2)P/TS	???????????	140	
???	HA8838(7)P/TSDL	????????	120	
?  ?	HA1168(3)P/TSL	?????????	78	
?  ?	HA389(16)P/TSLCD	????????	116	
?  ?	HA8828(2)P/TSDL	????????	78	
?  ?	HA8828(27)P/T	?????????	40	
???	HCD9000(2C)P/TSDL	???IP??????	180	
???	HCD9000(8E)P/TSDL	???IP?????????	188	
???	HCD9000(6E)P/TSDL	?????????????	185	
???	HCD9000(47)P/TSDL	??????????	155	
???	HCD9000(8C)P/TSDL	???????????R?	175	
???	HCD9000(46C)P/TSDL	???IP?68??????LCD	150	
???	HCD9000(3E)P/TSDL	????????????	198	
???	HCD9000(3D)P/TSDL	???IP?????12?????	148	
???	HA8000(1)P/T	??????	138	
???	HA8000(2)P/T	?????	220	
???	HA8000(4)P/T	??????	145	
?????	?   ?	????	?  ?	
???HW	HWCD586(8)P/TSDL	20???????????	1180	
???HW	HWCD586(9)P/TSL	20???????????	780	
???HW	HWCD586(10)P/TSDL	20???????????	1050	
???HW	HWCD586(7)P/TSD	10?????????	950	
???HW	HWCD007(6)OP/TSDL	????	450	
???HW	HWCD007(7)P/TSDL	????	460	
???HW	HA007(9)P/TSDL	????	395	
???HW	HA007(12)P/TSDL	????????	550	
???HW	HWCD007(15)P/TS	????	260	
???HW	HWCD007(17)P/TSDL	????	468	
???HW	HA007(19)P/TSDL	?????????	550	
???HW	HA007(20)P/TSDL	????	580	
????	HWC8688(9)P/TSDL	????	400	
????	HWC8688(13)P/TSDL	????	380	
??????????
?????2D??	30	MF-30R?	180	
?????2D??	30	???C2000	280	
?????4D?www-9?	85	3MCX15L	280	
?????4D(www-21)	90	CX25L	320	
?????4D(www-25)	95	?????	60	
????????IRW-5?	150	???3M??	30	
????2253	30	???5M??	45	
????02251	45	??????	50	
????2232	50	??????	35	
2194???	100	3?????	10	
DC-25???	45	5?????	10	
??????	45	TCL????	50	
???????	50	??????	25	
3M???	20	2M???	15	
1.5M???	10	???????	80	
Maxell????5#	3	Maxell????5#	3	
Maxell MP-B6??	210	Maxell MP-B4??	260	
???Maxell?	90	MF-20?	95	
MF-20R?	105	MF-30?	140	
?  ?  ?  ?	
?????	45	?????	40	
??110????	160	???????	65	
??????	90/?	??????	75/?	
???	85/?	???	85/?	
RJ-45????	55/?	RJ-12?RJ-11????	55/?	
??????	120/?	???????	380/?	
??????	660/?	??????	680/?	
????	120/?	????	180/?	
?????	880/?	??????	720/?	
?????	30/?	????	380/?	
???	0?8/?	??	15/?	
?????	30/?	?????	140/?	








From nurpinar at basari.net.tr  Mon Aug  5 04:55:00 2002
From: nurpinar at basari.net.tr (nur)
Date: Mon, 5 Aug 2002 11:55:00 +0300
Subject: couldn't initialize doc2000
Message-ID: <009301c23c5d$c8a3d380$3064000a@nurpinar>

I compiled kernel 2.2.18-rtl3.0 with m-systems mtd support
I followed all instructions in doc-linux README
./mkinitrd_doc is ok
doc-lilo -v -C /etc/lilo.conf-initrd is ok
shutdown -r now
no message related to diskonchip is displayed during boot
i tried "insmod doc"
then i receive this message
Using /lib/modules/2.2.18-rtl3.0-doc2000/block/doc.o
Cannot initialize M-Systems DOC 2000 OSAK
/lib/modules/2.2.18-rtl3.0-doc2000/block/doc.o: init_module: Device or
resource busy

I have 8 mb DOC 2000. What might be my problem? Thanks






From meunier at enst.fr  Mon Aug  5 04:56:28 2002
From: meunier at enst.fr (Sylvain Meunier)
Date: Mon, 05 Aug 2002 10:56:28 +0200
Subject: Mix flash sector size and JFFS2
Message-ID: <3D4E3DBC.4F73955D@enst.fr>

Hello,

Does a single filesystem JFFS2 need that all sectors of flash partition
are same size or
could we use different sector size (as for some flash that mix small and
big sector). ?

Thanks

Sylvain



From dwmw2 at infradead.org  Mon Aug  5 05:54:56 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 10:54:56 +0100
Subject: error when writing to jffs2 
In-Reply-To: <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> 
References: <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw>  <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> 
Message-ID: <28541.1028541296@redhat.com>

kevin at gv.com.tw said:
>  error when writing to jffs2 any idea?

What version of fs/jffs2/scan.c do you have?

--
dwmw2





From kevin at gv.com.tw  Mon Aug  5 06:18:42 2002
From: kevin at gv.com.tw (??)
Date: Mon, 5 Aug 2002 18:18:42 +0800
Subject: error when writing to jffs2 (scan.c v1.79 20020725)
References: <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw>  <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw>  <28541.1028541296@redhat.com>
Message-ID: <01c201c23c69$7995faa0$1b0448c0@gv.com.tw>

scan.c v 1.79 20020725

/*
 * JFFS2 -- Journalling Flash File System, Version 2.
 *
 * Copyright (C) 2001, 2002 Red Hat, Inc.
 *
 * Created by David Woodhouse <dwmw2 at cambridge.redhat.com>
 *
 * For licensing information, see the file 'LICENCE' in this directory.
 *
 * $Id: scan.c,v 1.79 2002/07/25 20:48:51 dwmw2 Exp $
 *
 */

----- Original Message -----
From: "David Woodhouse" <dwmw2 at infradead.org>
To: "??" <kevin at gv.com.tw>
Cc: <tglx at linutronix.de>; <linux-mtd at lists.infradead.org>; "? ??"
<djh at gv.com.tw>; <cms at gv.com.tw>
Sent: Monday, August 05, 2002 5:54 PM
Subject: Re: error when writing to jffs2


>
> kevin at gv.com.tw said:
> >  error when writing to jffs2 any idea?
>
> What version of fs/jffs2/scan.c do you have?
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From dwmw2 at infradead.org  Mon Aug  5 06:25:13 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 11:25:13 +0100
Subject: error when writing to jffs2 (scan.c v1.79 20020725) 
In-Reply-To: <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> 
References: <01c201c23c69$7995faa0$1b0448c0@gv.com.tw>  <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> 
Message-ID: <31970.1028543113@redhat.com>

kevin at gv.com.tw said:
> scan.c v 1.79 20020725

OK, then I don't know -- could you get full logs with 
CONFIG_JFFS2_FS_DEBUG=1 from mounting the file system to the oops? Make 
sure you are logging over a serial console so you catch _all_ the messages, 
and remember they're at level KERN_DEBUG so echo 9 > /proc/sys/kernel/printk



--
dwmw2





From dwmw2 at infradead.org  Mon Aug  5 06:35:11 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 11:35:11 +0100
Subject: MTD Partition problems 
In-Reply-To: <20020803141013.GA14370@wohnheim.fh-wedel.de> 
References: <20020803141013.GA14370@wohnheim.fh-wedel.de>  <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <5.1.0.14.0.20020803074026.02927a48@64.170.22.132> 
Message-ID: <461.1028543711@redhat.com>

joern at wohnheim.fh-wedel.de said:
> > Sorry for the stupid question: If it's by design, why is it going to
> > be ripped out sometime soon?

> It might have made sense, when it was designed. It might just have
> been a relatively new developer making the usual mistakes. Whatever.

> Fact is that it is useless, the superuser can create a read only
> device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
> those extra devices do, except for causing confusion and eating up
> minor numbers. 

I inherited the major number from elsewhere, and it was already set up like 
that. I haven't changed it because people have only just started to read 
the bloody documentation and set it up right -- with the occasional 
exception :)

>  Currently, there is no branch that tackles this problem. There was
> one, but David never took a look, was busy, and rescheduled to 'when
> 2.4.19 is out'. Now I am busy,...

I want to get the remaining changes in the tree into 2.4.20-pre, then 
update the code for 2.5 and start doing new exciting stuff. 

--
dwmw2





From dwmw2 at infradead.org  Mon Aug  5 06:40:45 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 11:40:45 +0100
Subject: couldn't initialize doc2000 
In-Reply-To: <009301c23c5d$c8a3d380$3064000a@nurpinar> 
References: <009301c23c5d$c8a3d380$3064000a@nurpinar> 
Message-ID: <941.1028544045@redhat.com>

nurpinar at basari.net.tr said:
> Using /lib/modules/2.2.18-rtl3.0-doc2000/block/doc.o 
> Cannot initialize M-Systems DOC 2000 OSAK

You are trying to use a binary module. In doing so, I believe you are 
violating the GPL. You will not get any help here.

On the other hand, if you want help trying to use the legal drivers which
are part of the Linux kernel, we will try to help you.

--
dwmw2





From joakim.tjernlund at lumentis.se  Mon Aug  5 09:35:56 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Mon, 5 Aug 2002 15:35:56 +0200
Subject: Disk blocks for long periods
In-Reply-To: <461.1028543711@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLMEHIFFAA.joakim.tjernlund@lumentis.se>

Hi 

I have noticed that if i copy a "big" file(580K) it sometimes take up to 42 seconds before
it's finished. Normally it takes about 3-4 seconds. When this long copy happen, top reports
that kupdate and the copy(cp) process is in D state, the rest is sleeping.
The FS is a 45% usage. FS is about 63MB in size. Using the stable branch.

Why does it block for so long time?

Also, if I fill the FS up to 100% and later reboots, it kan take 10-15 minutes before
init starts to run. The root fs mount takes about 20 seconds and the system just
stops between the last message from the kernel and when init prints its version.

It is just the first reboot after I fill the FS, once I have gotten past the first reboot and
reboots again, things are back to normal.

Any ideas?

   Jocke




From dwmw2 at infradead.org  Mon Aug  5 09:44:00 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 14:44:00 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLMEHIFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLMEHIFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <22091.1028555040@redhat.com>

joakim.tjernlund at lumentis.se said:
>  I have noticed that if i copy a "big" file(580K) it sometimes take up
> to 42 seconds before it's finished. Normally it takes about 3-4
> seconds. When this long copy happen, top reports that kupdate and the
> copy(cp) process is in D state, the rest is sleeping. The FS is a 45%
> usage. FS is about 63MB in size. Using the stable branch.

> Why does it block for so long time?

Dunno. What's it doing? Where are cp and kupdate sleeping? (SysRq-T).

>  Also, if I fill the FS up to 100% and later reboots, it kan take
> 10-15 minutes before init starts to run. The root fs mount takes about
> 20 seconds and the system just stops between the last message from the
> kernel and when init prints its version.

> It is just the first reboot after I fill the FS, once I have gotten
> past the first reboot and reboots again, things are back to normal. 

More logs and SysRq-T required. Sounds like it's erasing blocks and for 
some reason not allowing anything else to happen while it's doing it.

--
dwmw2





From joakim.tjernlund at lumentis.se  Mon Aug  5 09:59:39 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Mon, 5 Aug 2002 15:59:39 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <22091.1028555040@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLEEHJFFAA.joakim.tjernlund@lumentis.se>

> joakim.tjernlund at lumentis.se said:
> >  I have noticed that if i copy a "big" file(580K) it sometimes take up
> > to 42 seconds before it's finished. Normally it takes about 3-4
> > seconds. When this long copy happen, top reports that kupdate and the
> > copy(cp) process is in D state, the rest is sleeping. The FS is a 45%
> > usage. FS is about 63MB in size. Using the stable branch.
> 
> > Why does it block for so long time?
> 
> Dunno. What's it doing? Where are cp and kupdate sleeping? (SysRq-T).

I am on PPC and SysRq-T does not display anything useful :-(
Perhaps readprofile?

> 
> >  Also, if I fill the FS up to 100% and later reboots, it kan take
> > 10-15 minutes before init starts to run. The root fs mount takes about
> > 20 seconds and the system just stops between the last message from the
> > kernel and when init prints its version.
> 
> > It is just the first reboot after I fill the FS, once I have gotten
> > past the first reboot and reboots again, things are back to normal. 
> 
> More logs and SysRq-T required. Sounds like it's erasing blocks and for 
> some reason not allowing anything else to happen while it's doing it.

Perhaps kupdate is holding some VFS specific block? I am on a MV 2.4.2 kernel 

> 
> --
> dwmw2
> 
> 
> 




From dwmw2 at infradead.org  Mon Aug  5 10:01:04 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 15:01:04 +0100
Subject: Mix flash sector size and JFFS2 
In-Reply-To: <3D4E3DBC.4F73955D@enst.fr> 
References: <3D4E3DBC.4F73955D@enst.fr> 
Message-ID: <24149.1028556064@redhat.com>


meunier at enst.fr said:
>  Does a single filesystem JFFS2 need that all sectors of flash
> partition are same size or could we use different sector size (as for
> some flash that mix small and big sector). ?

JFFS2 only operates with a single sector size. However, when you have 
smaller erase blocks you will generally find that they add up to a single 
block's worth of the normal erase size. For example, 8*8KiB + 15*64KiB. 

JFFS2 will work OK on that, and just treat the 8*8KiB blocks as a single 
64KiB block.


--
dwmw2





From dwmw2 at infradead.org  Mon Aug  5 10:12:06 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 15:12:06 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLEEHJFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLEEHJFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <25084.1028556726@redhat.com>

joakim.tjernlund at lumentis.se said:
>  I am on PPC and SysRq-T does not display anything useful :-( Perhaps
> readprofile?

SysRq-T should work on PPC. It's mostly generic code. What's wrong with it?

The profile _may_ help but it's most likely to tell us that the CPU spend
most time sleeping, without actually telling us _where_ each process was
sleeping.

>  Perhaps kupdate is holding some VFS specific block? I am on a MV
> 2.4.2 kernel 

I'd care more if you could reproduce it with something a little more 
recent. I'm assuming you're using v1.100 of cfi_cmdset_0001.c, since you 
committed that change.


--
dwmw2





From joakim.tjernlund at lumentis.se  Mon Aug  5 10:32:46 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Mon, 5 Aug 2002 16:32:46 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <25084.1028556726@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLMEHKFFAA.joakim.tjernlund@lumentis.se>

> 
> joakim.tjernlund at lumentis.se said:
> >  I am on PPC and SysRq-T does not display anything useful :-( Perhaps
> > readprofile?
> 
> SysRq-T should work on PPC. It's mostly generic code. What's wrong with it?
Maybe I spoke too soon, but I can not make sense of it:
SysRq: Show State                                                               
                                                                                
                         free                        sibling                    
  task             PC    stack   pid father child younger older                 
init      S 0FF86418     0     1      0   159  (NOTLB)                          
keventd   S 00000000     0     2      1        (L-TLB)       3                  
kswapd    S 00000000     0     3      1        (L-TLB)       4     2            
kreclaimd  S 00000000     0     4      1        (L-TLB)       5     3           
bdflush   S 00000000     0     5      1        (L-TLB)       6     4            
kupdate   D 00000000     0     6      1        (L-TLB)       7     5            
mtdblockd  S 00000000     0     7      1        (L-TLB)       8     6           
jffs2_gcd_mtd4  S 00000000     0     8      1        (L-TLB)      51     7      
syslogd   S 0FF86418    28    51      1        (NOTLB)      53     8            
klogd     R 0FF7EB04   144    53      1        (NOTLB)      58    51            
inetd     S 0FF86418     0    58      1   163  (NOTLB)      72    53            
te_server  S 0FF42A84     0    72      1        (NOTLB)      75    58           
te_log    S 0FF3C418    28    75      1        (NOTLB)      77    72            
te        S 0FF3C418     0    77      1        (NOTLB)      79    75            
ntpd      S 0FDE4418     0    79      1        (NOTLB)      81    77
alib_psupd  S 0FED6418     0    81      1        (NOTLB)      83    79          
icn_server  S 0FF18418     0    83      1        (NOTLB)      85    81          
cp_cm     S 0FED6418     0    85      1        (NOTLB)      87    83            
cp_cop    S 0FED6418     0    87      1        (NOTLB)      89    85            
cp_pbh    S 0FED6418     0    89      1        (NOTLB)      91    87            
alib_swusd  S 0FED6418     0    91      1        (NOTLB)      93    89          
mgmt_named  S 0FEAC418     0    93      1        (NOTLB)      95    91          
mgmt_invd  S 0FD6A418  3520    95      1        (NOTLB)      97    93           
eq_rh     S 0FD6A418     0    97      1        (NOTLB)      99    95            
mgmt_pmd  S 0FC45418     0    99      1        (NOTLB)     101    97            
eq_bh_superviso  S 0FE3E418  3520   101      1        (NOTLB)     103    99     
eq_bh     S 0FE3E418     0   103      1        (NOTLB)     105   101            
mgmt_backupd  S 0FC45418  3520   105      1        (NOTLB)     107   103        
mgmt_alarmd  S 0FD6A418   124   107      1        (NOTLB)     109   105         
tosv_server  S 0FED6418     0   109      1        (NOTLB)     111   107         
tosv_supervisor  S 0FED6418     0   111      1        (NOTLB)     113   109     
snmpd     S 0FB4B418     8   113      1   161  (NOTLB)     115   111            
sys_sysconfd  S 0FD6A418  3168   115      1        (NOTLB)     117   113        
sys_ipconfd  S 0FD6A418     0   117      1        (NOTLB)     120   115         
umi_sim   S 0FED6418    76   120      1        (NOTLB)     122   117            
uxi_sim   S 0FED6418     0   122      1        (NOTLB)     124   120            
upi_sim   S 0FED6418     0   124      1        (NOTLB)     126   122            
cp_sim    S 0FED6418   260   126      1        (NOTLB)     128   124            
eq_tm_mgr  S 0FD6A418     0   128      1        (NOTLB)     130   126
eq_mxm_mgr  S 0FD6A418     0   130      1        (NOTLB)     132   128          
eq_gbem_mgr  S 0FD6A418    24   132      1        (NOTLB)     134   130         
eq_xm_mgr  S 0FD6A418     0   134      1        (NOTLB)     136   132           
eq_cpm_mgr  S 0FD6A418     4   136      1   160  (NOTLB)     138   134          
eq_pbm_mgr  S 0FD6A418     4   138      1        (NOTLB)     140   136          
eq_bm_mgr  S 0FD6A418     0   140      1        (NOTLB)     142   138           
eq_topm_mgr  S 0FD6A418     0   142      1        (NOTLB)     144   140         
eq_spfm_mgr  S 0FD6A418  3136   144      1        (NOTLB)     146   142         
eq_pm_mgr  S 0FD6A418     0   146      1        (NOTLB)     148   144           
ne_swumd  S 0FED6418     0   148      1        (NOTLB)     150   146            
ne_rc     S 0FED6418   428   150      1        (NOTLB)     152   148            
ne_rc_superviso  S 0FF3C418     0   152      1        (NOTLB)     154   150     
pppd      S 0FF86418   152   154      1        (NOTLB)     156   152            
zebra     S 0FD29418   128   156      1        (NOTLB)     158   154            
ospfd     S 0FD97418  3520   158      1        (NOTLB)     159   156            
bash      S 0FEC35AC   416   159      1   181  (NOTLB)           158            
eq_cpm_child  S 0FD6A418    68   160    136        (NOTLB)                      
snmpd     S 0FB51B84     0   161    113   162  (NOTLB)                          
snmpd     S 0FAB3370     0   162    161        (NOTLB)                          
in.telnetd  S 0FF64418     0   163     58   164  (NOTLB)                        
bash      S 0FEE0B04     0   164    163        (NOTLB)                          
bash      S 0FEC35AC  3156   180    159   182  (NOTLB)     181                  
cp        D 0FF7EB14  2868   181    159        (NOTLB)           180            
cp        D 0FF7EB14  1996   182    180        (NOTLB)



> 
> The profile _may_ help but it's most likely to tell us that the CPU spend
> most time sleeping, without actually telling us _where_ each process was
> sleeping.
> 
> >  Perhaps kupdate is holding some VFS specific block? I am on a MV
> > 2.4.2 kernel 
> 
> I'd care more if you could reproduce it with something a little more 
> recent. I'm assuming you're using v1.100 of cfi_cmdset_0001.c, since you 
> committed that change.
> 

Sorry, but It's a major job to upgrade our kernel, so that will have to wait.
No, I am not running the v1.100 of cfi_cmdset_0001.c but I have made sure that
the relevant fixes are in.

When I last looked(many months ago) there was no 2.4 branch of the MTD layer and there
was much NAND activity so I kept the one I had. Is the latest CVS of drivers/mtd the stable one?
Is it in 2.4.19?

   Jocke 





From dwmw2 at infradead.org  Mon Aug  5 10:42:53 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 05 Aug 2002 15:42:53 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLMEHKFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLMEHKFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <28973.1028558573@redhat.com>

joakim.tjernlund at lumentis.se said:
> > SysRq-T should work on PPC. It's mostly generic code. What's wrong
> > with it? 

> Maybe I spoke too soon, but I can not make sense of it:

That's because you're using 2.4.2. A newer kernel would print the relevant 
call trace from the kernel stack too, and we'd be able to see what kernel 
function(s) it's sleeping in.

--
dwmw2





From rjb at ayrnetworks.com  Mon Aug  5 11:19:40 2002
From: rjb at ayrnetworks.com (Richard J. Broberg)
Date: Mon, 5 Aug 2002 08:19:40 -0700
Subject: Is there any interest in providing a query lock to go with lock and unlock?
Message-ID: <200208050819.40628.rjb@ayrnetworks.com>

We have a parochial need which I have met in a heavy
handed way by adding a mtd vector and an ioctl.

The files changed in our 2.4.16 kernel are

drivers/mtd/mtdchar.c
drivers/mtd/chips/amd_flash.c
drivers/mtd/chips/cfi_cmdset_0001.c
include/linux/mtd/mtd.h

If somebody has a less invasive way, I would love to hear
about it.

If some others find this approach useful, I will try to get an
acceptable patch.

Thanks,
	Dick Broberg

===================================================================
RCS file: /cvs/public/linux/drivers/mtd/mtdchar.c,v
retrieving revision 1.3
diff -c -b -B -r1.3 mtdchar.c
*** drivers/mtd/mtdchar.c       2002/04/16 20:01:07     1.3
--- drivers/mtd/mtdchar.c       2002/08/01 21:08:33
***************
*** 282,287 ****
--- 282,323 ----
                break;
        }
  

+       case MEMGETREGIONLOCKS:
+       {
+               int                     blocks,i,es;
+               char                   *stati;
+               struct region_info_lock ul;
+ 
+               if (copy_from_user(     &ul, 
+                                       (struct region_info_lock *)arg, 
+                                       sizeof(struct region_info_lock))) {
+                       ret = -EFAULT;
+               } else if (ul.regionindex >= mtd->numeraseregions) {
+                       ret = -EINVAL;
+               } else {
+                       blocks = mtd->eraseregions[ul.regionindex].numblocks;
+                       es = mtd->eraseregions[ul.regionindex].erasesize;
+                       stati = kmalloc(blocks,GFP_KERNEL);
+                       if (!stati) {
+                               ret = -ENOMEM;
+                       } else {
+                               memset(stati,0,blocks);
+                               if (mtd->is_it_locked) {
+                                       for (i = 0; i < blocks; i++) {
+                                               stati[i] = mtd->is_it_locked(mtd,
+                                                                            i * es,
+                                                                            es);
+                                       }
+                               }
+                               if (copy_to_user(ul.block_stati,stati,blocks)) {
+                                       ret = -EFAULT;
+                               }
+                               kfree(stati);
+                       }
+               }
+               break;
+       }
+ 
        case MEMGETINFO:
                if (copy_to_user((struct mtd_info *)arg, mtd,
                                 sizeof(struct mtd_info_user)))
Index: drivers/mtd/chips/amd_flash.c
===================================================================
RCS file: /cvs/public/linux/drivers/mtd/chips/amd_flash.c,v
retrieving revision 1.2
diff -c -b -B -r1.2 amd_flash.c
*** drivers/mtd/chips/amd_flash.c       2002/03/15 00:29:21     1.2
--- drivers/mtd/chips/amd_flash.c       2002/08/01 21:08:33
***************
*** 295,300 ****
--- 295,332 ----
        return amd_flash_do_unlock(mtd, ofs, len, 1);
  }
  

+ static int amd_flash_is_it_locked(struct mtd_info *mtd, loff_t ofs, size_t len)
+ {
+       struct map_info *map = mtd->priv;
+       struct mtd_erase_region_info *merip;
+       int eraseoffset, erasesize, eraseblocks;
+       int i;
+       int lock_status = 0;
+ 
+       /* Pass the whole chip through sector by sector and check for each
+          sector if the sector and the given interval overlap */
+       for(i = 0; i < mtd->numeraseregions; i++) {
+               merip = &mtd->eraseregions[i];
+ 
+               eraseoffset = merip->offset;
+               erasesize = merip->erasesize;
+               eraseblocks = merip->numblocks;
+ 
+               if (ofs > eraseoffset + erasesize)
+                       continue;
+               while (eraseblocks > 0) {
+                       if (ofs < eraseoffset + erasesize && ofs + len > eraseoffset) {
+                               lock_status = is_sector_locked(map, eraseoffset);
+                               goto have_lock_status;
+                       }
+                       eraseoffset += erasesize;
+                       eraseblocks --;
+               }
+       }
+  have_lock_status:
+       return lock_status;
+ }
+ 
  static int amd_flash_lock(struct mtd_info *mtd, loff_t ofs, size_t len)
  {
        return amd_flash_do_unlock(mtd, ofs, len, 0);
***************
*** 748,753 ****
--- 780,786 ----
        mtd->resume = amd_flash_resume; 
        mtd->lock = amd_flash_lock;
        mtd->unlock = amd_flash_unlock;
+       mtd->is_it_locked = amd_flash_is_it_locked;
  

        private = kmalloc(sizeof(*private) + (sizeof(struct flchip) *
                                              temp.numchips), GFP_KERNEL);
Index: drivers/mtd/chips/cfi_cmdset_0001.c
===================================================================
RCS file: /cvs/public/linux/drivers/mtd/chips/cfi_cmdset_0001.c,v
retrieving revision 1.3
diff -c -b -B -r1.3 cfi_cmdset_0001.c
*** drivers/mtd/chips/cfi_cmdset_0001.c 2002/03/27 23:35:42     1.3
--- drivers/mtd/chips/cfi_cmdset_0001.c 2002/08/01 21:08:33
***************
*** 51,56 ****
--- 51,57 ----
  struct mtd_info *cfi_cmdset_0001(struct map_info *, int);
  

  static struct mtd_info *cfi_intelext_setup (struct map_info *);
+ static int cfi_is_it_locked(struct mtd_info *mtd, loff_t ofs, size_t len);
  

  static struct mtd_chip_driver cfi_intelext_chipdrv = {
        probe: NULL, /* Not usable directly */
***************
*** 264,269 ****
--- 265,271 ----
      mtd->sync = cfi_intelext_sync;
      mtd->lock = cfi_intelext_lock;
      mtd->unlock = cfi_intelext_unlock;
+     mtd->is_it_locked = cfi_is_it_locked;
      mtd->suspend = cfi_intelext_suspend;
      mtd->resume = cfi_intelext_resume;
      mtd->flags = MTD_CAP_NORFLASH;
***************
*** 1067,1084 ****
  

        return 0;
  }
- 
- typedef int (*varsize_frob_t)(struct map_info *map, struct flchip *chip,
-                             unsigned long adr, void *thunk);
  

! static int cfi_intelext_varsize_frob(struct mtd_info *mtd, varsize_frob_t frob,
!                                    loff_t ofs, size_t len, void *thunk)
  {
!       struct map_info *map = mtd->priv;
!       struct cfi_private *cfi = map->fldrv_priv;
!       unsigned long adr;
!       int chipnum, ret = 0;
!       int i, first;
        struct mtd_erase_region_info *regions = mtd->eraseregions;
  

        if (ofs > mtd->size)
--- 1068,1077 ----
  

        return 0;
  }
  

! static int get_region_index(struct mtd_info *mtd, loff_t ofs, size_t len, int *first)
  {
!         int i;
        struct mtd_erase_region_info *regions = mtd->eraseregions;
  

        if (ofs > mtd->size)
***************
*** 1087,1101 ****
        if ((len + ofs) > mtd->size)
                return -EINVAL;
  

!       /* Check that both start and end of the requested erase are
         * aligned with the erasesize at the appropriate addresses.
         */
  

        i = 0;
  

!       /* Skip all erase regions which are ended before the start of 
!          the requested erase. Actually, to save on the calculations,
!          we skip to the first erase region which starts after the
           start of the requested erase, and then go back one.
        */
        

--- 1079,1093 ----
        if ((len + ofs) > mtd->size)
                return -EINVAL;
  

!       /* Check that both start and end of the requested region are
         * aligned with the erasesize at the appropriate addresses.
         */
  

        i = 0;
  

!       /* Skip all regions which are ended before the start of 
!          the requested region. Actually, to save on the calculations,
!          we skip to the first region which starts after the
           start of the requested erase, and then go back one.
        */
        

***************
*** 1104,1111 ****
        i--;
  

        /* OK, now i is pointing at the erase region in which this 
!          erase request starts. Check the start of the requested
!          erase range is aligned with the erase size which is in
           effect here.
        */
  

--- 1096,1103 ----
        i--;
  

        /* OK, now i is pointing at the erase region in which this 
!          request starts. Check the start of the requested
!          range is aligned with the erase size which is in
           effect here.
        */
  

***************
*** 1113,1121 ****
                return -EINVAL;
  

        /* Remember the erase region we start on */
!       first = i;
  

!       /* Next, check that the end of the requested erase is aligned
         * with the erase region at that address.
         */
  

--- 1105,1115 ----
                return -EINVAL;
  

        /* Remember the erase region we start on */
! 
!       if (first)
!           *first = i;
  

!       /* Next, check that the end of the request is aligned
         * with the erase region at that address.
         */
  

***************
*** 1129,1135 ****
--- 1123,1147 ----
  

        if ((ofs + len) & (regions[i].erasesize-1))
                return -EINVAL;
+       return i;
+ }
+ 
+ typedef int (*varsize_frob_t)(struct map_info *map, struct flchip *chip,
+                             unsigned long adr, void *thunk);
+ 
+ static int cfi_intelext_varsize_frob(struct mtd_info *mtd, varsize_frob_t frob,
+                                    loff_t ofs, size_t len, void *thunk)
+ {
+       struct map_info *map = mtd->priv;
+       struct cfi_private *cfi = map->fldrv_priv;
+       unsigned long adr;
+       int chipnum, ret = 0;
+       int i, first;
+       struct mtd_erase_region_info *regions = mtd->eraseregions;
  

+       if (0 > (i = get_region_index(mtd,ofs,len,&first))) 
+           return i;
+ 
        chipnum = ofs >> cfi->chipshift;
        adr = ofs - (chipnum << cfi->chipshift);
  

***************
*** 1401,1406 ****
--- 1413,1441 ----
        }
  }
  

+ static int cfi_is_it_locked(struct mtd_info *mtd, loff_t ofs, size_t len)
+ {
+       struct map_info              *map = mtd->priv;
+       struct cfi_private           *cfi = map->fldrv_priv;
+       int                           ofs_factor = cfi->interleave *
+                                                  cfi->device_type;
+       unsigned long                 adr;
+       int                           chipnum;
+       int                           i;
+       int                           flags = 0;
+ 
+       if (0 > (i = get_region_index(mtd,ofs,len,0))) 
+           return i;
+       
+       chipnum = ofs >> cfi->chipshift;
+       adr = ofs - (chipnum << cfi->chipshift);
+ 
+       cfi_send_gen_cmd(0x90, 0x55, 0, map, cfi, cfi->device_type, NULL);
+       flags = cfi_read_query(map, adr+(2*ofs_factor));
+       cfi_send_gen_cmd(0xff, 0x55, 0, map, cfi, cfi->device_type, NULL);
+       return flags;
+ }
+ 
  #ifdef DEBUG_LOCK_BITS
  static int do_printlockstatus_oneblock(struct map_info *map, struct flchip *chip, unsigned long adr, void *thunk)
  {
***************
*** 1451,1457 ****
                /* Urgh. Chip not yet ready to talk to us. */
                if (time_after(jiffies, timeo)) {
                        spin_unlock_bh(chip->mutex);
!                       printk(KERN_ERR __FUNCTION__ ": waiting for chip to be ready timed out\n");
                        return -EIO;
                }
  

--- 1486,1494 ----
                /* Urgh. Chip not yet ready to talk to us. */
                if (time_after(jiffies, timeo)) {
                        spin_unlock_bh(chip->mutex);
!                       printk(KERN_ERR 
!                              "%s: waiting for chip to be ready timed out\n",
!                              __FUNCTION__);
                        return -EIO;
                }
  

Index: include/linux/mtd/mtd.h
===================================================================
RCS file: /cvs/public/linux/include/linux/mtd/mtd.h,v
retrieving revision 1.4
diff -c -b -B -r1.4 mtd.h
*** include/linux/mtd/mtd.h     2002/04/16 20:00:29     1.4
--- include/linux/mtd/mtd.h     2002/08/01 21:08:33
***************
*** 85,90 ****
--- 85,95 ----
        u_int32_t regionindex;
  };
  

+ struct region_info_lock {
+       u_int32_t  regionindex;
+       u_char     *block_stati;
+ };
+ 
  #define MEMGETINFO              _IOR('M', 1, struct mtd_info_user)
  #define MEMERASE                _IOW('M', 2, struct erase_info_user)
  #define MEMWRITEOOB             _IOWR('M', 3, struct mtd_oob_buf)
***************
*** 93,98 ****
--- 98,104 ----
  #define MEMUNLOCK               _IOW('M', 6, struct erase_info_user)
  #define MEMGETREGIONCOUNT     _IOR('M', 7, int)
  #define MEMGETREGIONINFO      _IOWR('M', 8, struct region_info_user)
+ #define MEMGETREGIONLOCKS     _IOWR('M', 9, struct region_info_lock)
  

  #ifndef __KERNEL__
  

***************
*** 207,212 ****
--- 213,219 ----
        /* Chip-supported device locking */
        int (*lock) (struct mtd_info *mtd, loff_t ofs, size_t len);
        int (*unlock) (struct mtd_info *mtd, loff_t ofs, size_t len);
+       int (*is_it_locked) (struct mtd_info *mtd, loff_t ofs, size_t len);
  

        /* Power Management functions */
        int (*suspend) (struct mtd_info *mtd);





From mtd at empireenterprises.com  Mon Aug  5 12:48:05 2002
From: mtd at empireenterprises.com (Glen)
Date: 05 Aug 2002 12:48:05 -0400
Subject: boot from diskonchip millenium
Message-ID: <1028566085.12920.11.camel@glen>

I'm having trouble finding a solution to boot from the diskonchip
millenium. 
The available grub patches seem to do absolutely nothing useful, and the
only lilo references I can find assume you are using msys's software.  


If someone can point me in the right direction, I would appreciate it.  

-g






From ilatypov at superbt.com  Mon Aug  5 13:26:14 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Mon, 5 Aug 2002 13:26:14 -0400 (EDT)
Subject: boot from diskonchip millenium
In-Reply-To: <1028566085.12920.11.camel@glen>
Message-ID: <Pine.LNX.4.44.0208051313320.6631-100000@server.superbt.com>

On 5 Aug 2002, Glen wrote:

> The available grub patches seem to do absolutely nothing useful,

Interesting.  Are there any messages on screen during the system boot?  

Are there any errors in compiling and setting up the bootloader as
explained in README_DiskOnChip?  The latter file can be seen only after
applying the patch, sorry.

Have you tried the --enable-diskonchip-biosnetboot configuration parameter
and toggled the BIOS network boot option?

> the only lilo references I can find assume you are using msys's
> software.

One has to implement a simple BIOS INT 13h interface. I guess you can
re-use the GRUB MTD firmware open source code including its
bdev_diskonchip.c NFTL driver.

Once this is done, you would erase all /dev/mtd0 blocks preceding the NFTL
layer and run lilo against /dev/mtd0 so that it can install itself and the
list of filesystem block numbers relative to device /dev/nftla.  These
numbers are persistent.  This is unlike to locations of flash erase blocks
abstracted by the NFTL layer.

Ilguiz




From DGE at sixnetio.com  Mon Aug  5 14:50:59 2002
From: DGE at sixnetio.com (Dave Ellis)
Date: Mon, 5 Aug 2002 14:50:59 -0400 
Subject: Disk blocks for long periods
Message-ID: <00512BA4F9D3D311912A009027E9B8F407E473@NT>

joakim.tjernlund at lumentis.se said:

> I have noticed that if i copy a "big" file(580K) it sometimes 
> take up to 42 seconds before it's finished. Normally it takes 
> about 3-4 seconds. When this long copy happen, top reports 
> that kupdate and the copy(cp) process is in D state, the rest 
> is sleeping. The FS is a 45% usage. FS is about 63MB in size. 
> Using the stable branch.
> 
> Why does it block for so long time?

I've been working on what may be the same problem and I think I 
finally understand it. I've seen it with 2.4.4, 2.4.18 and
with 2.4.18 with the 2.4.19 jffs2 and mtd code. I am using an 
AM29LV641, which uses cfi_cmdset_0002.c, but the code in 
cfi_cmdset_0001.c is similar. I have a possible solution
but I'd like some feedback on it.

The problem occurs when do_erase_oneblock() tries to lock the 
flash while cfi_amdstd_write() is writing a lot of data. The 
erasing thread locks the chip mutex when do_write_oneword() does the
    cfi_spin_unlock(chip->mutex);
    cfi_udelay(chip->word_write_time);
    cfi_spinlock(chip->mutex);
sequence. It sees the state is FL_WRITING, so it puts itself 
back on the wait queue. do_write_oneword() continues and eventually
sets the state back to FL_READY and wakes up the queue, but the
erasing thread doesn't actually run until the cfi_udelay() in 
do_write_oneword() calls schedule() while writing the next word
to the flash. The state is FL_WRITING, so the erasing thread goes
back on the wait queue. This continues until the entire write is
finished, then the erasing thread finally starts the erase.

The effect of all this sheduling is to write exactly one word
to flash for each jiffie! My flash is 16 bits wide, so a single
write of 2400 bytes was sometimes taking 1200 jiffies, or
12 seconds.

This patch to cfi_cmdset_0002.c 1.56 seems solve the problem, but
I am not sure if this is right way to do it. Comments?

Dave Ellis
dge at sixnetio.com

BTW - If I make similar changes to 1.55 or before it solves this
problem, but the write fails occasionally. I am guessing that
with my change it gets to the write completion check faster and the
old check fails, but the new write completion polling works better.

--- cfi_cmdset_0002.c	Mon Jul 15 11:13:25 2002
+++ cfi_cmdset_0002.fixed.c	Mon Aug  5 14:28:40 2002
@@ -386,9 +384,7 @@
 
 	cfi_write(map, datum, adr);
 
-	cfi_spin_unlock(chip->mutex);
-	cfi_udelay(chip->word_write_time);
-	cfi_spin_lock(chip->mutex);
+	udelay(chip->word_write_time);
 
 
 	/* Polling toggle bits instead of reading back many times
@@ -447,6 +444,7 @@
 	chip->state = FL_READY;
 	wake_up(&chip->wq);
 	cfi_spin_unlock(chip->mutex);
+	cfi_udelay(1);	/* just a chance to schedule() */
 	
 	return ret;
 }




From vipin at embeddedlinuxworks.com  Mon Aug  5 15:10:24 2002
From: vipin at embeddedlinuxworks.com (Vipin Malik)
Date: Mon, 05 Aug 2002 14:10:24 -0500
Subject: MTD Partition problems
In-Reply-To: <20020803235032.GA8021@wohnheim.fh-wedel.de>
References: <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>
 <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
 <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>
Message-ID: <5.1.0.14.0.20020805140501.00af1850@ns.webzsite.com>

> > Additionally, (say) /dev/mtdblock2 will really provide a handle to
> > /dev/mtd4 the writable third partition on the partitioned flash chip, thus
> > mounting the JFFS2 fs on the partition originally intended (the third
> > partition).
>
>Almost. /dev/mtd4 should be minor number 8. If you check
>/usr/src/linux/Documentation/devices.txt, you will read the following:
>                   0 = /dev/mtd0         First MTD (rw)
>                   1 = /dev/mtdr0        First MTD (ro)
>Thus mtd0 has minor 0, mtd1 has minor 2, ...
>
>Also, the third partition is /dev/mtd3, as /dev/mtd0 is the real
>device. Look at the minor numbers for /dev/hda*, just the same.
>
>But what you *meant* is correct.
>
> > Unfortunately, my tests indicate that this is not happening. I know that
> > /dev/mtdblock2 (the intended third partition) is formatted. However JFFS2
> > finds data here and refuses to mount on it. I think it is really being
> > passes a handle to and accesses /dev/mtd2, which is the wrong partition.
>
>See above.


Well, I think there is still a problem somewhere. Regardless of which 
/dev/mtd<n> device is the actual physical partition (that was a good 
academic discussion), JFFS2 never gets passed the /dev/mtd<n> device by me- 
only the /dev/mtdblock<n> device.

I can do a 'less -f /dev/mtdblock2' and see that's the partition that I 
want to mount JFFS2 on (it's all formatted correctly). However, a 'mount -t 
jffs2 /dev/mtdblock2 /mnt/flash' fails as JFFS2 sees a bunch of data to 
whichever mtd device handle its been passed (by mtdblock2) and refuses to 
mount as it cannot find any valid JFFS2 nodes there.

Vipin



> > /dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and 
> /dev/mtd4
> > is the correct partition that I want!
>
>See above.
>
> > Argh! I'll try your patches if you like.
>
>I would be happy if you did. But you don't need my patches, unless you
>have more than one device that you want to partition. With the two
>thinkos out of the way, you should be doing fine. :)
>
>J?rn
>
>--
>Mundie uses a textbook tactic of manipulation: start with some
>reasonable talk, and lead the audience to an unreasonable conclusion.
>-- Bruce Perens
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/




From clark at esteem.com  Mon Aug  5 16:03:36 2002
From: clark at esteem.com (Conn Clark)
Date: Mon, 05 Aug 2002 13:03:36 -0700
Subject: Need help getting JFFS2 working with kernel 2.4.19
Message-ID: <3D4EDA18.C77AEDA@esteem.com>

Hello all,

	I am new here and I am having trouble getting the JFFS2 code
working/compiling with the 2.4.19 kernel . I get multiple definition
errors when the kernel is linking.

Many thanks in advance,

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From jasmine at regolith.co.uk  Mon Aug  5 17:45:33 2002
From: jasmine at regolith.co.uk (Jasmine Strong)
Date: Mon, 5 Aug 2002 22:45:33 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <28973.1028558573@redhat.com>
Message-ID: <AB0AE002-A8BC-11D6-9E39-000502893FA1@regolith.co.uk>

On Monday, August 5, 2002, at 03:42 PM, David Woodhouse wrote:

>
> joakim.tjernlund at lumentis.se said:
>>> SysRq-T should work on PPC. It's mostly generic code. What's wrong
>>> with it?
>
>> Maybe I spoke too soon, but I can not make sense of it:
>
> That's because you're using 2.4.2.

...2.4.2 was the last-but-one Redwood PPC kernel release from Montavista;
they have a 2.4.17 out now which is much more stable and faster.

On the 2.4.2 kernel we had lots of odd little problems with stuff like
this that Just Went Away with 2.4.17.

(in ppc405gp land) Jas.




From mtd at empireenterprises.com  Mon Aug  5 19:20:36 2002
From: mtd at empireenterprises.com (Glen)
Date: 05 Aug 2002 19:20:36 -0400
Subject: boot from diskonchip millenium
In-Reply-To: <Pine.LNX.4.44.0208051313320.6631-100000@server.superbt.com>
References: <Pine.LNX.4.44.0208051313320.6631-100000@server.superbt.com>
Message-ID: <1028589640.12920.177.camel@glen>

Well, I've gotten a bit farther.  
Since I would prefer grub, we'll go that route.  

For description, we'll say I have the mtd-source in /mtd and grub in
/grub-0.92.


First, I compiled grub with --enable-diskonchip-mil, --enable-ext2fs,
and --enable-vfat

# cp /grub-0.92/stage2/pre_stage2 /mtd/grub
# /mtd/util/doc_loadbios /dev/mtd/0 /mtd/grub/grub_firmware  

This didn't seem to present any results, as the bios didn't recognize a
bootloader at all.  

Then I tried running doc_loadbios with the grub_firmware generated from
within /grub-0.92/stage1.  

Now the bios recognizes and runs the boot loader, but it can't seem to
read my diskonchip filesystem.  

I've been loosely following the directions at:
http://lists.infradead.org/pipermail/linux-mtd/2001-October/003475.html


I'm a bit confused.  
What's the difference between the grub_firmware generated by grub and
grub_firmware generated by mtd?  

-g




First, I tried loading the grub_firmware that was generated from <mtd
source>/grub.  
On Mon, 2002-08-05 at 13:26, Ilguiz Latypov wrote:
> 
> On 5 Aug 2002, Glen wrote:
> 
> > The available grub patches seem to do absolutely nothing useful,
> 
> Interesting.  Are there any messages on screen during the system boot?  
> 
> Are there any errors in compiling and setting up the bootloader as
> explained in README_DiskOnChip?  The latter file can be seen only after
> applying the patch, sorry.
> 
> Have you tried the --enable-diskonchip-biosnetboot configuration parameter
> and toggled the BIOS network boot option?
> 
> > the only lilo references I can find assume you are using msys's
> > software.
> 
> One has to implement a simple BIOS INT 13h interface. I guess you can
> re-use the GRUB MTD firmware open source code including its
> bdev_diskonchip.c NFTL driver.
> 
> Once this is done, you would erase all /dev/mtd0 blocks preceding the NFTL
> layer and run lilo against /dev/mtd0 so that it can install itself and the
> list of filesystem block numbers relative to device /dev/nftla.  These
> numbers are persistent.  This is unlike to locations of flash erase blocks
> abstracted by the NFTL layer.
> 
> Ilguiz
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 





From kevin at gv.com.tw  Tue Aug  6 00:06:23 2002
From: kevin at gv.com.tw (??)
Date: Tue, 6 Aug 2002 12:06:23 +0800
Subject: error when writing to jffs2 (success in another evb)
References: <01c201c23c69$7995faa0$1b0448c0@gv.com.tw>  <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com>  <31970.1028543113@redhat.com>
Message-ID: <000701c23cfe$a1542040$1b0448c0@gv.com.tw>

by enabling CONFIG_JFFS2_FS_DEBUG=1
i discover a typo buggy in fs/jffs2/gc.c:
fs/fs.o: In function `jffs2_garbage_collect_hole':
gc.c(.text+0x45c9c): undefined reference to `unlikely'
gc.c(.text+0x45c9c): relocation truncated to fit: R_MIPS_26 unlikely
fixed it by add:
#include <linux/compiler.h>
to fs/jffs2/gc.c for macro<"unlikely">
---success
story----------------------------------------------------------------------
success story: in our evb241x, jffs2 is ported ok

# mount
/dev/root on / type jffs2 (rw)
none on /proc type proc (rw)
/dev/ram1 on /var type minix (rw)
# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock1            6.7M      2.3M      4.4M  34% /
/dev/ram1              1009.0k     23.0k    986.0k   2% /var
#
--- faulting
log---------------------------------------------------------------------
the faulting kernel in our evb13x can't boot today, so log can't send :<
log show: "kernel BUG at traps.c:623!"
(probably hw problem or buggy mips 2.4.17 kernel)

POSIX conformance testing by UNIFIX
kernel BUG at traps.c:623!
Unable to handle kernel paging request at virtual address 00000000, epc ==
8000e
d0c, ra == 8000ed0c
Oops in fault.c:do_page_fault, line 204:
$0 : 00000000 1000fc00 0000001b 00000001 801a77d0 00000001 00000001 000003ec
$8 : 80a04478 801ab45c 0000001b fffffee0 0000000d 80a04478 0000000a 80a04478
$16: 00000000 810bbea0 00000000 8000a2bc 0000000a 00000017 00000000 00000200
$24: 00000000 810bbd32                   810ba000 810bbe80 81f0dc10 8000ed0c
Hi : 00000000
Lo : 00000080
epc  : 8000ed0c    Not tainted
Status: 1000fc04
Cause : 3000000c
Process swapper (pid: 1, stackpage=810ba000)
Stack: 80157870 80157c24 0000026f 00000cff 00010f00 00000040 00000000
8000db6c
       8015b3a0 00000000 8006d164 00000005 801fb284 801fb298 00000000
ffff0000
       18000000 fc000000 ffff0000 00000000 0001869e 00000cff 00000cfc
8014c9d4
       00000004 80018e40 1000fc01 00000001 0000000a 810b7f30 00010f00
00000040
       00000000 8000a2bc 0000000a 00000017 00000000 00000200 00000001
80009e14
       8001fd50 ...
Call Trace: [<80157870>] [<80157c24>] [<8000db6c>] [<8015b3a0>] [<8006d164>]
[<8
014c9d4>]
 [<80018e40>] [<8000a2bc>] [<80009e14>] [<8001fd50>] [<8000a2bc>]
[<8000a2bc>]
 [<80018e40>] [<8000a2bc>] [<8000a2cc>] [<80019518>] [<80009e14>]
[<8000abec>]
 [<8000a020>] [<80019298>] [<8000abdc>]

Code: 24a57c24  0c006415  2406026f <ae000000> 8e2200ac  8e2400a0  04410002
0000
0000  24840004
Kernel panic: Attempted to kill init!

----- Original Message -----
From: "David Woodhouse" <dwmw2 at infradead.org>
To: "??" <kevin at gv.com.tw>
Cc: <tglx at linutronix.de>; <linux-mtd at lists.infradead.org>; "? ??"
<djh at gv.com.tw>; <cms at gv.com.tw>
Sent: Monday, August 05, 2002 6:25 PM
Subject: Re: error when writing to jffs2 (scan.c v1.79 20020725)


>
> kevin at gv.com.tw said:
> > scan.c v 1.79 20020725
>
> OK, then I don't know -- could you get full logs with
> CONFIG_JFFS2_FS_DEBUG=1 from mounting the file system to the oops? Make
> sure you are logging over a serial console so you catch _all_ the
messages,
> and remember they're at level KERN_DEBUG so echo 9 >
/proc/sys/kernel/printk
>
>
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From ilatypov at superbt.com  Tue Aug  6 00:15:06 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Tue, 6 Aug 2002 00:15:06 -0400 (EDT)
Subject: boot from diskonchip millenium
In-Reply-To: <1028589640.12920.177.camel@glen>
Message-ID: <Pine.LNX.4.44.0208060003210.7633-100000@server.superbt.com>

On 5 Aug 2002, Glen wrote:

> Now the bios recognizes and runs the boot loader, but it can't seem to
> read my diskonchip filesystem.  

Great, now on to the next step: what are the informational and error
messages?  Have you set up an NFTL layer on the chip?  Perhaps, you are
trying to install JFFS2 not NFTL?  Can you mount a flash filesystem when
booted from hard disk?  What is the content of your menu.lst file?

> I've been loosely following the directions at:
> http://lists.infradead.org/pipermail/linux-mtd/2001-October/003475.html

There is a newer instruction at

   http://lists.infradead.org/pipermail/linux-mtd/2002-June/005240.html

> What's the difference between the grub_firmware generated by grub and
> grub_firmware generated by mtd?  

I believe the original patch to GRUB worked only with DoC 2000.

Ilguiz




From cain.yuan at intel.com  Tue Aug  6 01:04:50 2002
From: cain.yuan at intel.com (Yuan, Cain)
Date: Tue, 6 Aug 2002 13:04:50 +0800 
Subject: JFFS2 peoblems  with K3  strata flash on  Dalhart
Message-ID: <957BD1C2BF3CD411B6C500A0C944CA2601499C35@pdsmsx32.pd.intel.com>

Hi all,
	I am now test JFFS2 file system on Dalhart with Redboot as
boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for dalhart.

	When I first burned JFFS2 and linux image into k3 flash and load &
run linux it will report some  warnings but can boot successful.
later  I can   create/del files  on JFFS2 filesystem.  But when I reset the
board,   load linux na drun again, it will report  thousands of warnings.
after linux bootup,  create/del file will all  fail.   Here is the msg:

Probing Lubbock flash at physical address 0x00000000
In check_cmd_set() find CFI Intel Extend command sets.
 Intel/Sharp Extended Query Table at 0x0031
  Feature/Command Support: 01E6
     - Chip Erase:         unsupported
     - Suspend Erase:      supported
     - Suspend Program:    supported
     - Legacy Lock/Unlock: unsupported
     - Queued Erase:       unsupported
     - Instant block lock: supported
     - Protection Bits:    supported
     - Page-mode read:     supported
     - Synchronous read:   supported
  Supported functions after Suspend: 01
     - Program after Erase Suspend: supported
  Block Status Register Mask: 0007
     - Lock Bit Active:      yes
     - Valid Bit Active:     yes
     - Unknown Bit 2 Active: yes
  Vcc Logic Supply Optimum Program/Erase Voltage: 0.3 V
Using word write method
cfi probe success.
Using RedBoot partition definition
Creating 7 MTD partitions on "Lubbock flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00080000 : "RedBoot[backup]"
0x00080000-0x00180000 : "unallocated space"
0x00180000-0x00980000 : "JFFS2"
0x00980000-0x00fc0000 : "unallocated space"
0x00fc0000-0x00fc1000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't end on an erase block -- force
read-only
0x00fe0000-0x01000000 : "FIS directory"
Linux Kernel Card Services 3.1.22
  options:  [pm]
...
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000:
0xad74 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004:
0xef02 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020008:
0xcf75 instead
  ......  thousands of   such " Magic bitmask ox1985 not found.. "
errors.....................
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 80K
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 68 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
INIT: version 2.74 booting
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 293 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00

 thousands of   such  " ARGH: About to write node to 0x0022039c.."   errors.


Linux login: root
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
In function do_write_oneword(), will call cain_deump_state.
Current status is FL_READY.
Current status is FL_READY.
Current status is FL_UNKNOWN.
Current status is FL_UNKNOWN.
Current status is FL_UNKNOWN.
Current status is FL_STATUS.
Write of 299 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 333 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 70 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 70 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
login[41]: root login  on `ttyS0'

[root at Linux /root]$touch jj
ARGH. About to write node to 0x0022039c on flash, but there's data already
there:
0x0022039c: 85 19 02 e0 7b 03 00 00 b3 ad f9 32 3b 01 00 00
Write of 68 bytes at 0x0022039c failed. returned 0, retlen 0
Not marking the space at 0x0022039c as dirty because the flash driver
returned retlen zero
touch: Input/output error
[root at Linux /root]$


Does somebody here counter this problem before?  Any advice?  TIA!!

Best regards.

Cain




From brendan.simon at ctam.com.au  Tue Aug  6 01:40:07 2002
From: brendan.simon at ctam.com.au (Brendan J Simon)
Date: Tue, 06 Aug 2002 15:40:07 +1000
Subject: ATA Disk Chips
Message-ID: <3D4F6137.1070103@ctam.com.au>

Anyone used the ATA Disk Chips from SST ??
These are 32pin JEDEC pacakges (similar to M-Systems DiskOnChip) but 
with an ATA controller inside them.

Are there any linux drivers for them ?  They act like ordinary hard 
disks but there must be code for memory mapping them, etc.

Cheers,
Brendan Simon.





From kevin at gv.com.tw  Tue Aug  6 02:13:24 2002
From: kevin at gv.com.tw (??)
Date: Tue, 6 Aug 2002 14:13:24 +0800
Subject: what't the max partition(single file size) jffs2/mtd can support?(64MB? or 2GB? or 8GB?)
References: <01c201c23c69$7995faa0$1b0448c0@gv.com.tw>  <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com>  <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw>
Message-ID: <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw>

what't the max partition(single file size) jffs2/mtd can support?
64MB? or 2GB? or 8GB?
thanks in advanced!:)





From startec at ms11.hinet.net  Tue Aug  6 03:25:41 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Tue, 6 Aug 2002 15:25:41 +0800
Subject: NAND Configuration
Message-ID: <001601c23d1a$7c6a4ae0$5501a8c0@synso.com.tw>

Does I have to set CONFIG_MTD_NAND_ECC_JFFS2=y and
CONFIG_JFFS2_FS_NAND=y to use NAND flash? Weh I set these settings, I
will get the following easily. If  I did not set these settings and the
condition is better, still has problem, but it will not halt the system.
If I need not set CONFIG_MTD_NAND_ECC_JFFS2=y and
CONFIG_JFFS2_FS_NAND=y, I can trace my problem easily. I use
mtd-snapshot-20020731.tar.bz2 with uClinux.


Steve Tsai


ARGH. About to write node to 0x0018de8c on flash, but there are data
already the
re:
0x0018de8c: 85 19 04 20 74 01 00 00 4d 62 52 56 ff ff ff ff
pid 24: failed 256

jffs2_flush_wbuf(): Write failed with -5
Write of 68 bytes at 0x004da000 failed. returned -5, retlen 0
Not marking the space at 0x004da000 as dirty because the flash driver
returned r
etlen zero





From dwmw2 at infradead.org  Tue Aug  6 04:22:25 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 09:22:25 +0100
Subject: Need help getting JFFS2 working with kernel 2.4.19 
In-Reply-To: <3D4EDA18.C77AEDA@esteem.com> 
References: <3D4EDA18.C77AEDA@esteem.com> 
Message-ID: <30838.1028622145@redhat.com>

clark at esteem.com said:
> 
> 	I am new here and I am having trouble getting the JFFS2 code working/
> compiling with the 2.4.19 kernel . I get multiple definition errors
> when the kernel is linking.

Might help if you showed us the errors?

--
dwmw2





From dwmw2 at infradead.org  Tue Aug  6 04:24:46 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 09:24:46 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA2601499C35@pdsmsx32.pd.intel.com> 
References: <957BD1C2BF3CD411B6C500A0C944CA2601499C35@pdsmsx32.pd.intel.com> 
Message-ID: <31204.1028622286@redhat.com>

cain.yuan at intel.com said:
> 	I am now test JFFS2 file system on Dalhart with Redboot as
> boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for
> dalhart.

What erase size did you create your JFFS2 image with?

--
dwmw2





From dwmw2 at infradead.org  Tue Aug  6 04:26:29 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 09:26:29 +0100
Subject: what't the max partition(single file size) jffs2/mtd can support?(64MB? or 2GB? or 8GB?) 
In-Reply-To: <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw> 
References: <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw>  <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw> 
Message-ID: <31481.1028622389@redhat.com>

kevin at gv.com.tw said:
> what't the max partition(single file size) jffs2/mtd can support?
> 64MB? or 2GB? or 8GB? thanks in advanced!:) 

The maximum partition size is 4GiB, as is the maximum file size for JFFS2.
Theoretically -- I suspect the performance would suck too hard _long_ 
before you got there.

--
dwmw2





From brendan.simon at ctam.com.au  Tue Aug  6 04:33:19 2002
From: brendan.simon at ctam.com.au (Brendan J Simon)
Date: Tue, 06 Aug 2002 18:33:19 +1000
Subject: kernel hangs on DOC2000 root filesystem
Message-ID: <3D4F89CF.3010809@ctam.com.au>

I'm having trouble getting a linux-2.4.18-pre8 PowerPC kernel booting 
from a DOC2000 device.  A similar kernel boots fine using an NFS root 
filesystem.  I can then do a modprobe nftl and read/write to the DOC 
fine.  The only difference between the 2 kernels is that the MTD. 
DOC2000 and NFTL drivers are built into one kernel and are modules on 
the other.

Any ideas why the kernel just hangs ?

Thanks,
Brendan Simon.

Here is a log of the console during boot with some extra printk messages.


CPM UART driver version 0.01
ttyS00 at 0x1040 is a SMC
ttyS01 at 0x8300 is a SCC
pty: 256 Unix98 ptys configured
block: 128 slots per queue, batch=32
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
NET4: Frame Diverter 0.46
rx_bd_base = c01a7208, tx_bd_base = c01a7288
fec: Phy @ 0x0, type 0x001378e1
FCC Startup....
Control register = 3100
Full Duplex mode
FCC3: eth0: FCC ENET Version 0.2, 00:d0:1f:20:69:bf
Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994
Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak.
Using configured DiskOnChip probe address 0xf02c0000
DiskOnChip 2000 found at address 0xF02C0000
Flash chip found: Manufacturer ID: 98, Chip ID: 73 (Toshiba TH58V128DC)
2 flash chips found. Total DiskOnChip size: 32 MiB
NFTL driver: nftlcore.c $Revision: 1.3 $, nftlmount.c $Revision: 1.6 $
Partition check:
 nftla: nftla1 nftla2
IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
prepare_namespace()
 >>>>>>>> BJS: mount_root()
 >>>>>>>> BJS: mount_root(): __getname()
 >>>>>>>> BJS: mount_root(): __getname()
 >>>>>>>> BJS: mount_root(): devfs_find_handle()
 >>>>>>>> BJS: mount_root(): bdget()
 >>>>>>>> BJS: mount_root(): devfs_get_ops()
 >>>>>>>> BJS: mount_root(): devfs_generate_path()
 >>>>>>>> BJS: mount_root(): blkdev_get()
 >>>>>>>> BJS: mount_root(): check_disk_change()
 >>>>>>>> BJS: mount_root(): get_super()
 >>>>>>>> BJS: get_super():
 >>>>>>>> BJS: get_super(): spin_lock()
 >>>>>>>> BJS: get_super(): find_super()
 >>>>>>>> BJS: get_super(): spin_unlock()
 >>>>>>>> BJS: get_super(): return(NULL)
 >>>>>>>> BJS: mount_root(): fs_name = ext2
 >>>>>>>> BJS: mount_root(): atomic_inc()
 >>>>>>>> BJS: mount_root(): blkdev_get()
 >>>>>>>> BJS: mount_root(): read_super()
 >>>>>>>> BJS: mount_root(): put_filesystem()
 >>>>>>>> BJS: mount_root(): blkdev_put()
 >>>>>>>> BJS: blkdev_put(): down()
 >>>>>>>> BJS: blkdev_put(): lock()
 >>>>>>>> BJS: blkdev_put(): fsync_no_super()
 >>>>>>>> BJS: blkdev_put(): release()
 >>>>>>>> BJS: nftl_release():
 >>>>>>>> BJS: nftl_release():
 >>>>>>>> BJS: nftl_release(): invalidate_device()
 >>>>>>>> BJS: invalidate_device():
 >>>>>>>> BJS: invalidate_device(): fsync_dev()
 >>>>>>>> BJS: fsync_dev(): sync_buffers()
 >>>>>>>> BJS: fsync_dev(): lock_kernel()
 >>>>>>>> BJS: fsync_dev(): sync_inodes()
 >>>>>>>> BJS: sync_inodes():
 >>>>>>>> BJS: sync_inodes(): get_super()
 >>>>>>>> BJS: get_super():
 >>>>>>>> BJS: get_super(): spin_lock()
 >>>>>>>> BJS: get_super(): find_super()
 >>>>>>>> BJS: get_super(): spin_unlock()
 >>>>>>>> BJS: get_super(): down_read()
 >>>>>>>> BJS: rwsem_down_read_failed(): rwsemtrace(enter)
 >>>>>>>> BJS: rwsem_down_read_failed(): rwsem_down_failed_common()
 >>>>>>>> BJS: rwsem_down_failed_common(): set_tast_state()
 >>>>>>>> BJS: rwsem_down_failed_common(): spin_lock()
 >>>>>>>> BJS: rwsem_down_failed_common(): list_add_tail()
 >>>>>>>> BJS: rwsem_down_failed_common(): rwsem_atomic_update()
 >>>>>>>> BJS: rwsem_down_failed_common(): spin_unlock()
 >>>>>>>> BJS: rwsem_down_failed_common(): schedule()





From dwmw2 at infradead.org  Tue Aug  6 04:57:45 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 09:57:45 +0100
Subject: kernel hangs on DOC2000 root filesystem 
In-Reply-To: <3D4F89CF.3010809@ctam.com.au> 
References: <3D4F89CF.3010809@ctam.com.au> 
Message-ID: <4518.1028624265@redhat.com>

brendan.simon at ctam.com.au said:
>  Any ideas why the kernel just hangs ? 

> >>>>>>>> BJS: nftl_release(): invalidate_device()

--
dwmw2





From tglx at linutronix.de  Tue Aug  6 05:07:37 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 11:07:37 +0200
Subject: NAND Configuration
In-Reply-To: <001601c23d1a$7c6a4ae0$5501a8c0@synso.com.tw>
References: <001601c23d1a$7c6a4ae0$5501a8c0@synso.com.tw>
Message-ID: <1028624857.19435.2.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 09:25, Steve Tsai wrote:
> Does I have to set CONFIG_MTD_NAND_ECC_JFFS2=y and
> CONFIG_JFFS2_FS_NAND=y to use NAND flash? Weh I set these settings, I
> will get the following easily. If  I did not set these settings and the
> condition is better, still has problem, but it will not halt the system.
> If I need not set CONFIG_MTD_NAND_ECC_JFFS2=y and
> CONFIG_JFFS2_FS_NAND=y, I can trace my problem easily. I use
> mtd-snapshot-20020731.tar.bz2 with uClinux.
You have to set it. Read http://linux-mtd.infradead.org/tech/nand.html
> 
> ARGH. About to write node to 0x0018de8c on flash, but there are data
> already the
> re:
> 0x0018de8c: 85 19 04 20 74 01 00 00 4d 62 52 56 ff ff ff ff
> pid 24: failed 256
> 
> jffs2_flush_wbuf(): Write failed with -5
> Write of 68 bytes at 0x004da000 failed. returned -5, retlen 0
> Not marking the space at 0x004da000 as dirty because the flash driver
> returned r
> etlen zero
We need more info from mount onwards.
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

nix.de





From joern at wohnheim.fh-wedel.de  Tue Aug  6 05:35:54 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 6 Aug 2002 11:35:54 +0200
Subject: MTD Partition problems
In-Reply-To: <5.1.0.14.0.20020805140501.00af1850@ns.webzsite.com>
References: <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132> <5.1.0.14.0.20020803074026.02927a48@64.170.22.132> <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01> <5.1.0.14.0.20020803074026.02927a48@64.170.22.132> <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132> <5.1.0.14.0.20020805140501.00af1850@ns.webzsite.com>
Message-ID: <20020806093554.GA7162@wohnheim.fh-wedel.de>

On Mon, 5 August 2002 14:10:24 -0500, Vipin Malik wrote:
> Well, I think there is still a problem somewhere. Regardless of which 
> /dev/mtd<n> device is the actual physical partition (that was a good 
> academic discussion), JFFS2 never gets passed the /dev/mtd<n> device by me- 
> only the /dev/mtdblock<n> device.

I fail to see what was academic about that discussion. Is it academic,
if you pass /dev/hda1 (empty partition) or /dev/hda (whole disk with
root partition) to mke2fs? Try it and tell me again. :-)

> I can do a 'less -f /dev/mtdblock2' and see that's the partition that I 
> want to mount JFFS2 on (it's all formatted correctly). However, a 'mount -t 
> jffs2 /dev/mtdblock2 /mnt/flash' fails as JFFS2 sees a bunch of data to 
> whichever mtd device handle its been passed (by mtdblock2) and refuses to 
> mount as it cannot find any valid JFFS2 nodes there.

If it was formatted correctly, it should get mounted. But I have no
idea, what "it's all formatted correctly" or "JFFS2 sees a bunch of
data" means. Try doing a trivial format (eraseall /dev/mtd<n>) and
mount that. If that fails, show me that the partition has all 0xff and
the jffs2 messages and I will have a look. Until then, I consider this
to be pebkac.

J?rn

-- 
There's nothing better for promoting creativity in a medium than
making an audience feel "Hmm ? I could do better than that!"
-- Douglas Adams in a slashdot interview



From tglx at linutronix.de  Tue Aug  6 05:45:40 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 11:45:40 +0200
Subject: NAND Configuration
In-Reply-To: <001601c23d1a$7c6a4ae0$5501a8c0@synso.com.tw>
References: <001601c23d1a$7c6a4ae0$5501a8c0@synso.com.tw>
Message-ID: <1028627141.19592.5.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 09:25, Steve Tsai wrote:
Could you send me your hardware driver ? 

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

nix.de





From tglx at linutronix.de  Tue Aug  6 05:46:18 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 11:46:18 +0200
Subject: error when writing to jffs2 (success in another evb)
In-Reply-To: <000701c23cfe$a1542040$1b0448c0@gv.com.tw>
References: <01c201c23c69$7995faa0$1b0448c0@gv.com.tw>
 <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw>
 <013d01c2388f$94c655a0$1b0448c0@gv.com.tw>
 <0H04006C5M7GUI@smtp-out.bhp.t-online.de>
 <00f801c2390a$d956dd40$1b0448c0@gv.com.tw>
 <0H05001Y6RM950@smtp-out.bhp.t-online.de>
 <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com>
 <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw>
Message-ID: <1028627179.19447.7.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 06:06, ?? wrote:
> the faulting kernel in our evb13x can't boot today, so log can't send :<
could you send me your hardware driver ? 
-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

nix.de





From joakim.tjernlund at lumentis.se  Tue Aug  6 06:06:34 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Tue, 6 Aug 2002 12:06:34 +0200
Subject: Disk blocks for long periods
In-Reply-To: <00512BA4F9D3D311912A009027E9B8F407E473@NT>
Message-ID: <IGEFJKJNHJDCBKALBJLLAEIBFFAA.joakim.tjernlund@lumentis.se>

Hi Dave

This is interesting ...

> I've been working on what may be the same problem and I think I 
> finally understand it. I've seen it with 2.4.4, 2.4.18 and
> with 2.4.18 with the 2.4.19 jffs2 and mtd code. I am using an 
> AM29LV641, which uses cfi_cmdset_0002.c, but the code in 
> cfi_cmdset_0001.c is similar. I have a possible solution
> but I'd like some feedback on it.

Yes, cfi_cmdset_0001.c has the same problem and I think do_write_buffer() is
even more sensitive since is has an extra unlock,udelay,lock pair in it.

> 
> The problem occurs when do_erase_oneblock() tries to lock the 
> flash while cfi_amdstd_write() is writing a lot of data. The 
> erasing thread locks the chip mutex when do_write_oneword() does the
>     cfi_spin_unlock(chip->mutex);
>     cfi_udelay(chip->word_write_time);
>     cfi_spinlock(chip->mutex);
> sequence. It sees the state is FL_WRITING, so it puts itself 
> back on the wait queue. do_write_oneword() continues and eventually
> sets the state back to FL_READY and wakes up the queue, but the
> erasing thread doesn't actually run until the cfi_udelay() in 
> do_write_oneword() calls schedule() while writing the next word
> to the flash. The state is FL_WRITING, so the erasing thread goes
> back on the wait queue. This continues until the entire write is
> finished, then the erasing thread finally starts the erase.
> 
> The effect of all this sheduling is to write exactly one word
> to flash for each jiffie! My flash is 16 bits wide, so a single
> write of 2400 bytes was sometimes taking 1200 jiffies, or
> 12 seconds.
> 
> This patch to cfi_cmdset_0002.c 1.56 seems solve the problem, but
> I am not sure if this is right way to do it. Comments?

I am not sure this is the the rigth way either, but I will test and see what happens.

BTW, is it neccesary to use spin_lock_bh()? Can we not get away with just spin_lock()?
I am not very good at locking, but I think xxx_bh is only needed when interrupts can
can execute the locked code and currently there are no interrupts in this code path(I think).

Is it not true that xxx_bh() also disables interrupts? If so, there must be rather long
periods with interrupts turned off in cfi_cmdset_xxxx.c?

Have you tried to use cfi_udelay(chip->word_write_time) instead of udelay(chip->word_write_time)?
That will at least let other processes run, won't it? 

Perhaps David can comment?

> 
> Dave Ellis
> dge at sixnetio.com
> 
> BTW - If I make similar changes to 1.55 or before it solves this
> problem, but the write fails occasionally. I am guessing that
> with my change it gets to the write completion check faster and the
> old check fails, but the new write completion polling works better.
> 
> --- cfi_cmdset_0002.c	Mon Jul 15 11:13:25 2002
> +++ cfi_cmdset_0002.fixed.c	Mon Aug  5 14:28:40 2002
> @@ -386,9 +384,7 @@
>  
>  	cfi_write(map, datum, adr);
>  
> -	cfi_spin_unlock(chip->mutex);
> -	cfi_udelay(chip->word_write_time);
> -	cfi_spin_lock(chip->mutex);
> +	udelay(chip->word_write_time);
>  
>  
>  	/* Polling toggle bits instead of reading back many times
> @@ -447,6 +444,7 @@
>  	chip->state = FL_READY;
>  	wake_up(&chip->wq);
>  	cfi_spin_unlock(chip->mutex);
> +	cfi_udelay(1);	/* just a chance to schedule() */
>  	
>  	return ret;
>  }
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 




From dwmw2 at infradead.org  Tue Aug  6 06:09:09 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 11:09:09 +0100
Subject: Is there any interest in providing a query lock to go with lock and unlock? 
In-Reply-To: <200208050819.40628.rjb@ayrnetworks.com> 
References: <200208050819.40628.rjb@ayrnetworks.com> 
Message-ID: <14180.1028628549@redhat.com>

rjb at ayrnetworks.com said:
> We have a parochial need which I have met in a heavy handed way by
> adding a mtd vector and an ioctl.

That makes sense. Change the name to something like test_lock() or 
is_locked(), and perhaps declare that it shall only take an 'offset' 
argument which must be the start of a block, rather than doing all the 
range stuff -- the users can do that themselves if they need it, can't they?

--
dwmw2





From startec at ms11.hinet.net  Tue Aug  6 06:25:47 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Tue, 6 Aug 2002 18:25:47 +0800
Subject: NAND Configuration
In-Reply-To: <1028627141.19592.5.camel@thomas.tec.linutronix.de>
Message-ID: <001b01c23d33$a254d450$5501a8c0@synso.com.tw>

I use GPIO to control NCE, ALE and CLE. RE and WE are connected to CS of
ROM bank 1 and ROM bank 2.
The test program are work fine to do read/write and it seems work fine
also when I did not use CONFIG_JFFS2_FS_NAND. Thanks.


Steve Tsai



================================================================
Change in nand.c for our board.
=================================================================

#undef readb
#undef writeb

#define readb(a)  (*(volatile unsigned char *)(a))

/* Use function call for more delay in write cycle */
void writeb(unsigned char v, unsigned int a)
{
	*(volatile unsigned char *)(a) = v;
}


================================================================
Netpower.c for our board - board-specific glue layer.
=================================================================


#include <linux/slab.h>
#include <linux/module.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/partitions.h>
#include <asm/io.h>

/*
 * MTD structure for .NETpower board
 */
static struct mtd_info *dnp_mtd = NULL;

/*
 * Values specific to the .NETpower board (used with S3C4510 processor)
 */
#define DNP_FIO_BASE	0x2000000


#define   NCE   0x100
#define   ALE   0x400
#define   CLE   0x200 


/*
 * Module stuff
 */

static int dnp_fio_base = DNP_FIO_BASE;

#if 0
MODULE_PARM(dnp_fio_base, "i");

__setup("dnp_fio_base=",dnp_fio_base);
#endif

/*
 * Define partitions for flash device
 */
const static struct mtd_partition partition_info[] = {
	{ name: "DNP flash partition 1",
	  offset: 0,
	  size: 2*1024*1024 },
	{ name: "DNP flash partition 2",
	  offset: 2*1024*1024,
	  size: 6*1024*1024 }
};
#define NUM_PARTITIONS 2

/* 
 *	hardware specific access to control-lines
*/
void dnp_hwcontrol(int cmd){
    switch(cmd){

	case NAND_CTL_SETCLE: (*(volatile unsigned int *) (IOPDATA)) |=
CLE; break;
	case NAND_CTL_CLRCLE: (*(volatile unsigned int *) (IOPDATA)) &=
~CLE; break;

	case NAND_CTL_SETALE: (*(volatile unsigned int *) (IOPDATA)) |=
ALE; break;
	case NAND_CTL_CLRALE: (*(volatile unsigned int *) (IOPDATA)) &=
~ALE; break;

	case NAND_CTL_SETNCE: (*(volatile unsigned int *) (IOPDATA)) &=
~NCE; break;
	case NAND_CTL_CLRNCE: (*(volatile unsigned int *) (IOPDATA)) |=
NCE; break;
    }
}

/*
 * Main initialization routine
 */
int __init dnp_init (void)
{
	struct nand_chip *this;

	/* Allocate memory for MTD device structure and private data */
	dnp_mtd = kmalloc (sizeof(struct mtd_info) + sizeof (struct
nand_chip),
				GFP_KERNEL);
	if (!dnp_mtd) {
		printk ("Unable to allocate DNP NAND MTD device
structure.\n");
		return -ENOMEM;
	}

	/* Get pointer to private data */
	this = (struct nand_chip *) (&dnp_mtd[1]);

	/* Initialize structures */
	memset((char *) dnp_mtd, 0, sizeof(struct mtd_info));
	memset((char *) this, 0, sizeof(struct nand_chip));

	/* Link the private data with the MTD structure */
	dnp_mtd->priv = this;

	/*
	 * Set GPIO Port register so that the pins are configured
	 * to be outputs for controlling the NAND flash.
	 */
	*(volatile unsigned int *)(IOPMOD)  |= (CLE|ALE|NCE);
	*(volatile unsigned int *)(IOPDATA) |= (NCE);

	/* Set address of NAND IO lines */
	/* 0x2000000 for ROM bank 1, 0x2200000 form ROM bank 2 */
	/* Above 0x4000000 is noncachable area
*/
	this->IO_ADDR_W = (dnp_fio_base | 0x4000000);
	this->IO_ADDR_R = ((dnp_fio_base+0x200000) | 0x4000000);
	/* Set address of hardware control function */
	this->hwcontrol = dnp_hwcontrol;
	this->dev_ready = NULL;
	/* 15 us command delay time */
	this->chip_delay = 15;		
	

	/* Scan to find existance of the device */
	if (nand_scan (dnp_mtd)) {
		kfree (dnp_mtd);
		return -ENXIO;
	}

	/* Allocate memory for internal data buffer */
	this->data_buf = kmalloc (sizeof(u_char) * (dnp_mtd->oobblock +
dnp_mtd->oobsize), GFP_KERNEL);
	if (!this->data_buf) {
		printk ("Unable to allocate NAND data buffer for
DNP.\n");
		kfree (dnp_mtd);
		return -ENOMEM;
	}

	/* Register the partitions */
	add_mtd_partitions(dnp_mtd, partition_info, NUM_PARTITIONS);

	/* Return happy */
	return 0;
}
module_init(dnp_init);

/*
 * Clean up routine
 */
#ifdef MODULE
static void __exit dnp_cleanup (void)
{
	struct nand_chip *this = (struct nand_chip *) &dnp_mtd[1];

	/* Unregister the device */
	del_mtd_device (dnp_mtd);

	/* Free internal data buffer */
	kfree (this->data_buf);

	/* Free the MTD device structure */
	kfree (dnp_mtd);
}
module_exit(dnp_cleanup);
#endif

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Steve Tsai <steve at synso.com");
MODULE_DESCRIPTION("Board-specific glue layer for NAND flash on DNP
board");








-----Original Message-----
From: linux-mtd-admin at lists.infradead.org
[mailto:linux-mtd-admin at lists.infradead.org] On Behalf Of Thomas
Gleixner
Sent: Tuesday, August 06, 2002 5:46 PM
To: Steve Tsai
Cc: Linux MTD mailing list
Subject: Re: NAND Configuration


On Tue, 2002-08-06 at 09:25, Steve Tsai wrote:
Could you send me your hardware driver ? 

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

nix.de



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/




From startec at ms11.hinet.net  Tue Aug  6 06:40:32 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Tue, 6 Aug 2002 18:40:32 +0800
Subject: NAND Configuration
In-Reply-To: <1028624857.19435.2.camel@thomas.tec.linutronix.de>
Message-ID: <001c01c23d35$b0e899f0$5501a8c0@synso.com.tw>


-----Original Message-----
From: linux-mtd-admin at lists.infradead.org
[mailto:linux-mtd-admin at lists.infradead.org] On Behalf Of Thomas
Gleixner
Sent: Tuesday, August 06, 2002 5:08 PM
To: Steve Tsai
Cc: Linux MTD mailing list
Subject: Re: NAND Configuration


On Tue, 2002-08-06 at 09:25, Steve Tsai wrote:
> Does I have to set CONFIG_MTD_NAND_ECC_JFFS2=y and 
> CONFIG_JFFS2_FS_NAND=y to use NAND flash? Weh I set these settings, I 
> will get the following easily. If  I did not set these settings and 
> the condition is better, still has problem, but it will not halt the 
> system. If I need not set CONFIG_MTD_NAND_ECC_JFFS2=y and 
> CONFIG_JFFS2_FS_NAND=y, I can trace my problem easily. I use 
> mtd-snapshot-20020731.tar.bz2 with uClinux.
You have to set it. Read http://linux-mtd.infradead.org/tech/nand.html

I read it many time, but CONFIG_JFFS2_FS_NAND use to take care buffering
and OOB . Does I have to use it absolutely? If I do not use it, what's
the result of the driver?

> 
> ARGH. About to write node to 0x0018de8c on flash, but there are data 
> already the
> re:
> 0x0018de8c: 85 19 04 20 74 01 00 00 4d 62 52 56 ff ff ff ff pid 24: 
> failed 256
> 
> jffs2_flush_wbuf(): Write failed with -5
> Write of 68 bytes at 0x004da000 failed. returned -5, retlen 0 Not 
> marking the space at 0x004da000 as dirty because the flash driver 
> returned r etlen zero
We need more info from mount onwards.

Maybe I do not provide repeatable messages and steps. The following are
the steps I use.
1. eraseall /dev/mtd1            
2. mount -t jffs2 /dev/mtdblock1 /mnt
3. Make directory to /mnt
4. Use ftp to copy files to /mnt
5. Change the kernel to to mount /dev/mtdblock1 as root FS.
6. Copy or delete files and sometime the message display
	ARGH. About to write node to 0x003f9e2c on flash, but there are
data already the re:...
    After that, the patition will display more error messages, ECC error
and others.

Regards,
Steve tsai

 




From kevin at gv.com.tw  Tue Aug  6 07:43:31 2002
From: kevin at gv.com.tw (??)
Date: Tue, 6 Aug 2002 19:43:31 +0800
Subject: fail to rm files when jffs2 is full
References: <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw>  <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw>  <31481.1028622389@redhat.com>
Message-ID: <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw>

dear all,

when we test disk-full with jffs2/mtd,
we fail to rm files when jffs2 is full
it keeps showing the following messages repeatly:
----fail to rm files when jffs2 is
full------------------------------------------------
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (e
rasableempty: yes, erasingempty: yes, erasependingempty: yes)
.....repeat ........
----------------------------------------------------------------------------
------
any idea?
thanks in advanced!:)





From kevin at gv.com.tw  Tue Aug  6 07:47:44 2002
From: kevin at gv.com.tw (??)
Date: Tue, 6 Aug 2002 19:47:44 +0800
Subject: fail to rm files when jffs2 is full
Message-ID: <011e01c23d3f$145f0240$1b0448c0@gv.com.tw>

jffs2 ?????,

? disk full ?,?????
jffs2 ? garbage collection ??????......

??mailing list ???........

----- Original Message -----
From: "??" <kevin at gv.com.tw>
To: "David Woodhouse" <dwmw2 at infradead.org>
Cc: <linux-mtd at lists.infradead.org>; "? ??" <djh at gv.com.tw>;
<cms at gv.com.tw>; "jiunrong" <jiunrong at gv.com.tw>
Sent: Tuesday, August 06, 2002 7:43 PM
Subject: fail to rm files when jffs2 is full


> dear all,
>
> when we test disk-full with jffs2/mtd,
> we fail to rm files when jffs2 is full
> it keeps showing the following messages repeatly:
> ----fail to rm files when jffs2 is
> full------------------------------------------------
> jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
> Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
> 0. (e
> rasableempty: yes, erasingempty: yes, erasependingempty: yes)
> .....repeat ........
> --------------------------------------------------------------------------
--
> ------
> any idea?
> thanks in advanced!:)
>
>




From dwmw2 at infradead.org  Tue Aug  6 08:14:47 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 13:14:47 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLAEIBFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLAEIBFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <30768.1028636087@redhat.com>

joakim.tjernlund at lumentis.se said:
>  BTW, is it neccesary to use spin_lock_bh()? Can we not get away with
> just spin_lock()? I am not very good at locking, but I think xxx_bh is
> only needed when interrupts can can execute the locked code and
> currently there are no interrupts in this code path(I think).

> Is it not true that xxx_bh() also disables interrupts? If so, there
> must be rather long periods with interrupts turned off in
> cfi_cmdset_xxxx.c?

spin_lock_bh() should not disable interrupts, only bottom-halves. It was 
used to protect against timers, because we intend(ed) to have the erase 
completion done from a timer. At the moment there's no real need to use 
anything but spin_lock().


--
dwmw2





From tglx at linutronix.de  Tue Aug  6 08:16:15 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 14:16:15 +0200
Subject: NAND Configuration
In-Reply-To: <001c01c23d35$b0e899f0$5501a8c0@synso.com.tw>
References: <001c01c23d35$b0e899f0$5501a8c0@synso.com.tw>
Message-ID: <1028636176.19435.47.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 12:40, Steve Tsai wrote:
> I read it many time, but CONFIG_JFFS2_FS_NAND use to take care buffering
> and OOB . Does I have to use it absolutely? If I do not use it, what's
> the result of the driver?
Yes, you _HAVE_ _ABSOLUTELY_ to use it !  
IF not, no buffering and OOB check, no bad block management ..--> no
JFFS2 on NAND.

> We need more info from mount onwards.
> 
> Maybe I do not provide repeatable messages and steps. The following are
> the steps I use.
> 1. eraseall /dev/mtd1            
> 2. mount -t jffs2 /dev/mtdblock1 /mnt
> 3. Make directory to /mnt
> 4. Use ftp to copy files to /mnt
> 5. Change the kernel to to mount /dev/mtdblock1 as root FS.
> 6. Copy or delete files and sometime the message display
> 	ARGH. About to write node to 0x003f9e2c on flash, but there are
> data already the re:...
>     After that, the patition will display more error messages, ECC error
> and others.

I meant, could you get full logs with CONFIG_JFFS2_FS_DEBUG=1 from
mounting the file system to the ARGH? Make sure you are logging over a
serial console so you catch _ALL_ the messages, and remember they're at
level KERN_DEBUG so echo 9 > /proc/sys/kernel/printk before mount.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

nix.de





From dwmw2 at infradead.org  Tue Aug  6 08:26:55 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 13:26:55 +0100
Subject: fail to rm files when jffs2 is full 
In-Reply-To: <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw> 
References: <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw>  <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw> <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw> <31481.1028622389@redhat.com> 
Message-ID: <31830.1028636815@redhat.com>

kevin at gv.com.tw said:
> when we test disk-full with jffs2/mtd, we fail to rm files when jffs2
> is full

Were there any other errors leading up to this? The flash should never get 
so full that it doesn't allow you to remove things.

--
dwmw2





From tglx at linutronix.de  Tue Aug  6 08:28:55 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 14:28:55 +0200
Subject: NAND Configuration
In-Reply-To: <001b01c23d33$a254d450$5501a8c0@synso.com.tw>
References: <001b01c23d33$a254d450$5501a8c0@synso.com.tw>
Message-ID: <1028636935.19435.73.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 12:25, Steve Tsai wrote:
> I use GPIO to control NCE, ALE and CLE. RE and WE are connected to CS of
> ROM bank 1 and ROM bank 2.
> The test program are work fine to do read/write and it seems work fine
> also when I did not use CONFIG_JFFS2_FS_NAND. Thanks.
> 
> ================================================================
> Change in nand.c for our board.
> =================================================================
> 
> #undef readb
> #undef writeb
> 
> #define readb(a)  (*(volatile unsigned char *)(a))
It's really innovative to reinvent the wheel.
 
> /* Use function call for more delay in write cycle */
> void writeb(unsigned char v, unsigned int a)
> {
> 	*(volatile unsigned char *)(a) = v;
> }
For what do you need more delay ??? NAND is fast enough.
> 
> 
> 	/* Set address of NAND IO lines */
> 	/* 0x2000000 for ROM bank 1, 0x2200000 form ROM bank 2 */
> 	/* Above 0x4000000 is noncachable area
> */
> 	this->IO_ADDR_W = (dnp_fio_base | 0x4000000);
> 	this->IO_ADDR_R = ((dnp_fio_base+0x200000) | 0x4000000);
Is your read address really different to your write address ???
If yes, get a baseball bat and trim the hardware guy. :)
If no, you read and write from/to different address ranges.

> 	/* Set address of hardware control function */
> 	this->hwcontrol = dnp_hwcontrol;
> 	this->dev_ready = NULL;
> 	/* 15 us command delay time */
> 	this->chip_delay = 15;		
Could you try to set chipdelay to a longer value ? 	
-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de





From dwmw2 at infradead.org  Tue Aug  6 08:32:40 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 13:32:40 +0100
Subject: NAND Configuration 
In-Reply-To: <1028636935.19435.73.camel@thomas.tec.linutronix.de> 
References: <1028636935.19435.73.camel@thomas.tec.linutronix.de>  <001b01c23d33$a254d450$5501a8c0@synso.com.tw> 
Message-ID: <32287.1028637160@redhat.com>

tglx at linutronix.de said:
> > RE and WE are connected to CS of ROM bank 1 and ROM bank 2.

> Is your read address really different to your write address ???

That's what he said.

> If yes, get a baseball bat and trim the hardware guy. :)

Nah -- that's not so bad. There are hardware guys _far_ more deserving of a 
batting than this one.

--
dwmw2





From tglx at linutronix.de  Tue Aug  6 08:40:30 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 14:40:30 +0200
Subject: NAND Configuration
In-Reply-To: <32287.1028637160@redhat.com>
References: <1028636935.19435.73.camel@thomas.tec.linutronix.de>
 <001b01c23d33$a254d450$5501a8c0@synso.com.tw> <32287.1028637160@redhat.com>
Message-ID: <1028637631.19435.86.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 14:32, David Woodhouse wrote:
> 
> tglx at linutronix.de said:
> > > RE and WE are connected to CS of ROM bank 1 and ROM bank 2.
Sorry, I must have missed this line.
> 
> 
-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

nix.de





From kevin at gv.com.tw  Tue Aug  6 09:03:39 2002
From: kevin at gv.com.tw (??)
Date: Tue, 6 Aug 2002 21:03:39 +0800
Subject: No free space left for GC(test2 with log)
References: <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw>  <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw> <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw> <31481.1028622389@redhat.com>  <31830.1028636815@redhat.com>
Message-ID: <000701c23d49$aefcb860$1b0448c0@gv.com.tw>

(console log of evb241x:)

# mkdir aaa

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock1            6904      1612      5292  23% /
/dev/ram1                 1009        17       992   2% /var
192.72.4.43:/home/test/mips   4134900    328600   3596252   8% /mnt

(/mnt is a mounted nfs directory on pc)

# cp /mnt/* /aaa/
jffs2_g_c_deletion_dirent(): Short read (40 not 12) reading from obsolete
node at 00633ae0
jffs2_g_c_deletion_dirent(): Short read (40 not 12) reading from obsolete
node at 00665b68

(after about 10 minutes, we do a ctrl-c here to interrupt the files copy)

#

(it begin to show "No free space left for GC" repeatly after ctrl-c)

Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
mjffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is
0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_bloc
----- Original Message -----
From: "David Woodhouse" <dwmw2 at infradead.org>
To: "??" <kevin at gv.com.tw>
Cc: <linux-mtd at lists.infradead.org>; "? ??" <djh at gv.com.tw>;
<cms at gv.com.tw>; "jiunrong" <jiunrong at gv.com.tw>
Sent: Tuesday, August 06, 2002 8:26 PM
Subject: Re: fail to rm files when jffs2 is full


>
> kevin at gv.com.tw said:
> > when we test disk-full with jffs2/mtd, we fail to rm files when jffs2
> > is full
>
> Were there any other errors leading up to this? The flash should never get
> so full that it doesn't allow you to remove things.
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From dwmw2 at infradead.org  Tue Aug  6 09:07:37 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 14:07:37 +0100
Subject: No free space left for GC(test2 with log) 
In-Reply-To: <000701c23d49$aefcb860$1b0448c0@gv.com.tw> 
References: <000701c23d49$aefcb860$1b0448c0@gv.com.tw>  <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw> <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw> <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw> <31481.1028622389@redhat.com> <31830.1028636815@redhat.com> 
Message-ID: <2884.1028639257@redhat.com>

kevin at gv.com.tw said:
> jffs2_g_c_deletion_dirent(): Short read (40 not 12) reading from
> obsolete node at 00665b68 

Er, that's broken. Thomas?


--
dwmw2





From olivier.eribon at acterna.com  Tue Aug  6 09:46:23 2002
From: olivier.eribon at acterna.com (olivier.eribon at acterna.com)
Date: Tue, 6 Aug 2002 15:46:23 +0200
Subject: JFFS2 problem with MTD & 2.4.17
Message-ID: <C1256C0D.004BE77A.00@magnus.eni.wago.de>


Hello,

I am using JFFS2 (from CVS july 01 2002) and 2.4.17 linux kernel on a
specific board (ppc405gp with a nand flash : Toshiba TC58256FT/DC)
Before using my nand flash partition :

[root at serdmq7111 /root]# eraseall /dev/mtd1
[root at serdmq7111 /root]# mount -t jffs2 /dev/mtdblock1 /mnt/jffsp2 where
/mnt/jffsp2 is the NAND flash partition
[root at serdmq7111 /root]# cd /mnt/jffsp2
[root at serdmq7111 /mnt/jffsp2]# tar xvf /files.tar
[root at serdmq7111 /mnt/jffsp2]# cd
[root at serdmq7111 /root]# umount /mnt/jffsp2
reboot

*-1-* When I mounted my JFFS2 flash partition, I got the following on the
console.

Linux version 2.4.17_mvl21 (oeribon at ensun14) (gcc version 2.95.3 20010315
(release/MontaVista))
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
Communications AB.
NAND device: Manufacture ID: 0x98, Chip ID: 0x75 (Toshiba TC58256FT/DC)
Creating 2 MTD partitions on "Toshiba TC58256FT/DC":
0x00000000-0x00100000 : "boot"
0x00100000-0x02000000 : "partition 31Mo" <= I using only this partition
serdmq7111 login: root

[root at serdmq7111 /root]# mount -t jffs2 /dev/mtdblock1 /mnt/jffsp2
jffs2_scan_empty(): Empty block at 0x0179b588 ends at 0x0179b5f4 (with
0x1985e002)! Marking dirty

Time after time (after writting on flash) more and more blocks are indicated
as Empty block and Marking dirty.
Why ?
How can I solve this problem ? (because this message induce long time to
mount partition.)


*-2-* I have another problem with files :
for example when I do :
[root at serdmq7111 /root]# mkdir /mnt/jffsp2/dir where /mnt/jffsp2 is the NAND
flash partition
[root at serdmq7111 /root]# cp /MAKEDEV /mnt/jffsp2/dir/f0
[root at serdmq7111 /root]# cp /MAKEDEV /mnt/jffsp2/dir/f1
[root at serdmq7111 /root]# cp /MAKEDEV /mnt/jffsp2/dir/f2

[root at serdmq7111 /root]# umount /mnt/jffsp2
reboot
[root at serdmq7111 /root]# mount -t jffs2 /dev/mtdblock1 /mnt/jffsp2
no problem

but when I erase files, and for each mount I have the same message
[root at serdmq7111 /root]#rm -rf /mnt/jffsp2/dir
[root at serdmq7111 /root]# umount /mnt/jffsp2
reboot
[root at serdmq7111 /root]# mount -t jffs2 /dev/mtdblock1 /mnt/jffsp2
I got the following on the console.

Inode #???? was a directory with children - removing those too...
Cannot remove child "f0", ino #0, because it doesn't exist
Cannot remove child "f1", ino #0, because it doesn't exist
Cannot remove child "f2", ino #0, because it doesn't exist
Why ?
How can I solve this problem ? (because this message induce long time to
mount partition.)


*-3-* And after erasing files, the system periodically does not respond for
multiple "seconds" to
CR's on the bash prompt.
What's going on?

Thanks in advance for your time and your help !

Best regards,

Olivier





From joern at wohnheim.fh-wedel.de  Tue Aug  6 09:52:17 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 6 Aug 2002 15:52:17 +0200
Subject: Disk blocks for long periods
In-Reply-To: <30768.1028636087@redhat.com>
References: <IGEFJKJNHJDCBKALBJLLAEIBFFAA.joakim.tjernlund@lumentis.se> <30768.1028636087@redhat.com>
Message-ID: <20020806135217.GA17427@wohnheim.fh-wedel.de>

Hi!

Just a wild thought:
With three command sets already implemented (0020 is not in the tree
yet), wouldn't it make sense to go through them and try to collect as
much common code, as possible? I really dislike code multiplication,
especially bug multiplication.

J?rn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu



From dwmw2 at infradead.org  Tue Aug  6 09:53:32 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 14:53:32 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <20020806135217.GA17427@wohnheim.fh-wedel.de> 
References: <20020806135217.GA17427@wohnheim.fh-wedel.de>  <IGEFJKJNHJDCBKALBJLLAEIBFFAA.joakim.tjernlund@lumentis.se> <30768.1028636087@redhat.com> 
Message-ID: <7034.1028642012@redhat.com>

joern at wohnheim.fh-wedel.de said:
> Just a wild thought: With three command sets already implemented (0020
> is not in the tree yet), wouldn't it make sense to go through them and
> try to collect as much common code, as possible? I really dislike code
> multiplication, especially bug multiplication.

Yes, it would. We've done some of it already -- the cfi_cmd() bits, etc. 
Some helpful stuff for handling the state machine and scheduling 
appropriately would also be good.

--
dwmw2





From tglx at linutronix.de  Tue Aug  6 10:08:19 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 06 Aug 2002 16:08:19 +0200
Subject: No free space left for GC(test2 with log)
In-Reply-To: <000701c23d49$aefcb860$1b0448c0@gv.com.tw>
References: <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw>
 <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw>
 <01c201c23c69$7995faa0$1b0448c0@gv.com.tw>
 <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw>
 <013d01c2388f$94c655a0$1b0448c0@gv.com.tw>
 <0H04006C5M7GUI@smtp-out.bhp.t-online.de>
 <00f801c2390a$d956dd40$1b0448c0@gv.com.tw>
 <0H05001Y6RM950@smtp-out.bhp.t-online.de>
 <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com>
 <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw>
 <31481.1028622389@redhat.com> <31830.1028636815@redhat.com>
 <000701c23d49$aefcb860$1b0448c0@gv.com.tw>
Message-ID: <1028642900.19448.117.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-06 at 15:03, ?? wrote:
> (console log of evb241x:)
> 
> # mkdir aaa
> 
> # df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/mtdblock1            6904      1612      5292  23% /
> /dev/ram1                 1009        17       992   2% /var
> 192.72.4.43:/home/test/mips   4134900    328600   3596252   8% /mnt
> 
> (/mnt is a mounted nfs directory on pc)
> 
> # cp /mnt/* /aaa/
> jffs2_g_c_deletion_dirent(): Short read (40 not 12) reading from obsolete
> node at 00633ae0
> jffs2_g_c_deletion_dirent(): Short read (40 not 12) reading from obsolete
> node at 00665b68
We really need a complete log from mount to this point. Could you please
provide one ?

compile kernel with CONFIG_JFFS2_DEBUG = 1 and serial console

boot
# echo 9 >/proc/sys/kernel/printk
Switch on logging on your terminal program
# mount /dev/mtdblockx
# mkdir
# cp
Save logfile and compress it 
Put it anywhere for ftp access, if possible, else send it to me and
David, not to the list

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de





From DGE at sixnetio.com  Tue Aug  6 10:53:00 2002
From: DGE at sixnetio.com (Dave Ellis)
Date: Tue, 6 Aug 2002 10:53:00 -0400 
Subject: Disk blocks for long periods
Message-ID: <00512BA4F9D3D311912A009027E9B8F407E474@NT>

joakim.tjernlund at lumentis.se said:

> Have you tried to use cfi_udelay(chip->word_write_time) 
> instead of udelay(chip->word_write_time)? That will at least 
> let other processes run, won't it? 

The cfi_udelay() call is part of the problem, since it lets other
processes run, and the one that runs is the erasing process, but
it can't do anything except slow things down since the flash 
is busy writing. What the erasing process does seem to do (and 
I don't understand why) is cause current->need_resched to be set
for every call to cfi_udelay(), so it calls schedule_timeout(1) 
and sleeps for a whole jiffie.

By calling cfi_udelay() at the _end_ of the write of each word,
it still allows the call to schedule_timeout() to happen, but
at a time when the chip state allows other mtd processes operations,
such as erase, to use it, so the one jiffie doesn't happen
for every word written. The word writes are short (10 us typical,
360 us worst case for my chip), so not scheduling during the write
is not so bad.

My change seems to solve the problem for me, but I don't 
understand the scheduling well enough to understand why 
current->need_resched gets set each time.

Maybe cfi_udelay() should be changed so for short delays it
does schedule(); udelay(delay); instead of schedule_timeout(1).
If I get some time later I will try it.
 
Dave Ellis
dge at sixnetio.com

> > --- cfi_cmdset_0002.c	Mon Jul 15 11:13:25 2002
> > +++ cfi_cmdset_0002.fixed.c	Mon Aug  5 14:28:40 2002
> > @@ -386,9 +384,7 @@
> >  
> >  	cfi_write(map, datum, adr);
> >  
> > -	cfi_spin_unlock(chip->mutex);
> > -	cfi_udelay(chip->word_write_time);
> > -	cfi_spin_lock(chip->mutex);
> > +	udelay(chip->word_write_time);
> >  
> >  
> >  	/* Polling toggle bits instead of reading back many 
> times @@ -447,6 
> > +444,7 @@
> >  	chip->state = FL_READY;
> >  	wake_up(&chip->wq);
> >  	cfi_spin_unlock(chip->mutex);
> > +	cfi_udelay(1);	/* just a chance to schedule() */
> >  	
> >  	return ret;
> >  }



From joakim.tjernlund at lumentis.se  Tue Aug  6 11:09:12 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Tue, 6 Aug 2002 17:09:12 +0200
Subject: Disk blocks for long periods
In-Reply-To: <00512BA4F9D3D311912A009027E9B8F407E474@NT>
Message-ID: <IGEFJKJNHJDCBKALBJLLKEIGFFAA.joakim.tjernlund@lumentis.se>

> 
> joakim.tjernlund at lumentis.se said:
> 
> > Have you tried to use cfi_udelay(chip->word_write_time) 
> > instead of udelay(chip->word_write_time)? That will at least 
> > let other processes run, won't it? 
> 
> The cfi_udelay() call is part of the problem, since it lets other
> processes run, and the one that runs is the erasing process, but
> it can't do anything except slow things down since the flash 
> is busy writing. What the erasing process does seem to do (and 
> I don't understand why) is cause current->need_resched to be set
> for every call to cfi_udelay(), so it calls schedule_timeout(1) 
> and sleeps for a whole jiffie.

hmm, I just noticed that the BIG kernel lock is held while the
erasing thread executes, since kupdate takes it in sync_old_buffers()
(if I understand this code correctly). Maybe that is causing
current->need_resched to be set?

Also, is it not a bad idea to hold the kernel lock for, possibly, seconds while
erasing sectors?

> 
> By calling cfi_udelay() at the _end_ of the write of each word,
> it still allows the call to schedule_timeout() to happen, but
> at a time when the chip state allows other mtd processes operations,
> such as erase, to use it, so the one jiffie doesn't happen
> for every word written. The word writes are short (10 us typical,
> 360 us worst case for my chip), so not scheduling during the write
> is not so bad.

I assume your chip does not support buffered writes? or is it just do_write_one_word()
that is causing the log delays?

 Jocke




From gromit1463 at mailworks.org  Tue Aug  6 12:21:28 2002
From: gromit1463 at mailworks.org (Stephen Hui)
Date: 06 Aug 2002 11:21:28 -0500
Subject: Latest JFFS2 Patch for Kernel 2.4.2?
Message-ID: <1028650893.28423.2.camel@mahi190.austin.ibm.com>

Hi again.

Is there a patch for the latest JFFS2 support against the 2.4.2 kernel? 
I'd hate to re-invent the wheel just for this, and I don't have the
option of using a newer kernel.

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




From mark at lakeshoremicro.com  Tue Aug  6 12:26:45 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Tue, 6 Aug 2002 12:26:45 -0400
Subject: [patch] doc_stage1.S : GRUB on DoC
In-Reply-To: <Pine.LNX.4.44.0208021755070.3723-100000@server.superbt.com>
References: <Pine.LNX.4.44.0208021755070.3723-100000@server.superbt.com>
Message-ID: <20020806162717.SAGG23732.sccrmhc01.attbi.com@there>

Ilguiz Latypov wrote:
> Both 07-29 and 0.92 patches work with 32M DoC 2000 on the Advantech PCA
> 6753 F board.

Ilguiz,

Both patches are now working great on both the faster PC and the P133 system.

I finally figured out what is going on with Grub not working on a P133 
system:  The grub_firmware produced on a Debian system (gcc 2.95.4) works 
fine on both machines; grub_firmware from a Gentoo system (gcc 2.95.3) works 
on the faster PC, but not on the P133.

> I believe GRUBSTART is the offset value while GRUBLOADSEG is the segment 
> value, i.e. GRUBSTART == (GRUBLOADSEG << 4) + GRUBLOADOFS.

My apologies for misunderstanding your earlier post.  Your latest change puts 
the manufacturer/id code where I had intended it to be; I goofed on the 
offset value in the original patch.

It's my understanding that these DoC 2000/Millennium patches will soon be 
incorporated into the official Grub sources.   Until then, if anyone else is 
interested in trying the latest patches, here's a summary:

GRUB CVS: http://savannah.gnu.org/cvs/?group=grub
Patch: grub-2002-07-29-doc.patch (MTD cvs)
On a Debian system, use: 
aclocal-1.6 && automake-1.6 --add-missing && autoconf2.50

GRUB 0.92: http://www.gnu.org/software/grub/grub-0.92.tar.gz
Patch: grub-0.92-doc.patch (MTD cvs)

Instructions:
http://lists.infradead.org/pipermail/linux-mtd/2002-June/005240.html
(With these patches, use "--enable-diskonchip-mil" for all DoC Millenniums)

Mark






From clark at esteem.com  Tue Aug  6 12:34:35 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 06 Aug 2002 09:34:35 -0700
Subject: Need help getting JFFS2 working with kernel 2.4.19
References: <3D4EDA18.C77AEDA@esteem.com>
Message-ID: <3D4FFA9B.2C693A02@esteem.com>

Conn Clark wrote:
> 
> Hello all,
> 
>         I am new here and I am having trouble getting the JFFS2 code
> working/compiling with the 2.4.19 kernel . I get multiple definition
> errors when the kernel is linking.
> 
> Many thanks in advance,
> 
>         Conn

	I figured it out. The jffs2 zlib was conflicting with the zlib
used bye ppp compresion. I just had to remove zlib.o from the COMPR_OBJS
definition in the Makefile.

	Sorry for the lack of details. I figured it out yesterday but
mailed this post to myself instead of the list. Sorry again.


Thanks anyways

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From joakim.tjernlund at lumentis.se  Tue Aug  6 12:45:59 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Tue, 6 Aug 2002 18:45:59 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <30768.1028636087@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLAEIIFFAA.joakim.tjernlund@lumentis.se>

> 
> spin_lock_bh() should not disable interrupts, only bottom-halves. It was 
> used to protect against timers, because we intend(ed) to have the erase 
> completion done from a timer. At the moment there's no real need to use 
> anything but spin_lock().

Can the JFFS2 layer also use spin_lock() instead of spin_lock_bh()?
Shold we try not to disable bottom-halves or does it not matter?

BTW,
     I just did a test, ran this some 20 times:
     #> time cp tstfile tmp1 & time cp file tmp2 & time cp file tmp3 &
     sometimes I removed the tmp1,tmp2 and tmp3 files before running it.

     if I rm the files first it takes 10 seconds to complete and if I don't
     it takes 20 seconds. It's a bit much I think.

I have set kupdate to run every .5 second   
tstfile is 581K

 Jocke



> 
> 
> --
> dwmw2
> 
> 
> 




From dwmw2 at infradead.org  Tue Aug  6 13:06:56 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Aug 2002 18:06:56 +0100
Subject: Need help getting JFFS2 working with kernel 2.4.19 
In-Reply-To: <3D4FFA9B.2C693A02@esteem.com> 
References: <3D4FFA9B.2C693A02@esteem.com>  <3D4EDA18.C77AEDA@esteem.com> 
Message-ID: <25573.1028653616@redhat.com>

clark at esteem.com said:
> 
> 	I figured it out. The jffs2 zlib was conflicting with the zlib used
> bye ppp compresion. I just had to remove zlib.o from the COMPR_OBJS
> definition in the Makefile.

There's a better fix in 2.4.20-pre2 and at 
ftp.kernel.org:/pub/linux/kernel/people/dwmw2/shared-zlib/

Get the latest patch (2.4.19-pre10) and it should apply to most 2.4 kernels.

--
dwmw2





From mtd at empireenterprises.com  Tue Aug  6 13:54:40 2002
From: mtd at empireenterprises.com (Glen)
Date: 06 Aug 2002 13:54:40 -0400
Subject: boot from diskonchip millenium
In-Reply-To: <Pine.LNX.4.44.0208060003210.7633-100000@server.superbt.com>
References: <Pine.LNX.4.44.0208060003210.7633-100000@server.superbt.com>
Message-ID: <1028656482.16600.20.camel@glen>

Ok.  
When the machine boots up, several lines scroll by...unfortunately too
fast for me to see.  

Then, about 50 lines scroll that say: 
Attempting to open /boot/grub/menu.lst 0x0 0x0
Attempting to open /boot/grub/menu.lst 0x0 0x1
Attempting to open /boot/grub/menu.lst 0x0 0x2
...and so on...

I then get a grub> prompt

"grub> geometry" reports: 
Error 11: Unrecognized device string

"grub> root" reports:
(dc0): Filesystem type unknown, using whole disk


I am using nftl_format to prepare the DOC (I don't even know what jffs2
is at this point).
The command used was nftl_format /dev/mtd/0 98304
After the nftl_format, I fdisk, format the partition, mount it, and copy
the kernel and grub conf.  

I've tried using both ext2 and vfat filesystems, with the same results. 


/boot/grub/menu.lst (on the DOC) is as follows:

default 0
timeout 5
title DOC Linux
	kernel (dc0,0)/boot/vmlinuz-2.4.18 root=/dev/nftl/disc0/part1

I've also tried: 

default 0
timeout 5
title DOC Linux
	kernel (dc0,0)/boot/vmlinuz-2.4.18 root=/dev/nftla1

and: 

default 0
timeout 5
title DOC Linux
	kernel (dc0)/boot/vmlinuz-2.4.18 root=/dev/nftl/disc0/part1


Ideas??

-g


On Tue, 2002-08-06 at 00:15, Ilguiz Latypov wrote:
> 
> On 5 Aug 2002, Glen wrote:
> 
> > Now the bios recognizes and runs the boot loader, but it can't seem to
> > read my diskonchip filesystem.  
> 
> Great, now on to the next step: what are the informational and error
> messages?  Have you set up an NFTL layer on the chip?  Perhaps, you are
> trying to install JFFS2 not NFTL?  Can you mount a flash filesystem when
> booted from hard disk?  What is the content of your menu.lst file?
> 
> > I've been loosely following the directions at:
> > http://lists.infradead.org/pipermail/linux-mtd/2001-October/003475.html
> 
> There is a newer instruction at
> 
>    http://lists.infradead.org/pipermail/linux-mtd/2002-June/005240.html
> 
> > What's the difference between the grub_firmware generated by grub and
> > grub_firmware generated by mtd?  
> 
> I believe the original patch to GRUB worked only with DoC 2000.
> 
> Ilguiz
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 





From ilatypov at superbt.com  Tue Aug  6 14:04:44 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Tue, 6 Aug 2002 14:04:44 -0400 (EDT)
Subject: boot from diskonchip millenium
In-Reply-To: <1028656482.16600.20.camel@glen>
Message-ID: <Pine.LNX.4.44.0208061356340.9804-100000@server.superbt.com>

On 6 Aug 2002, Glen wrote:

> Attempting to open /boot/grub/menu.lst 0x0 0x0
> Attempting to open /boot/grub/menu.lst 0x0 0x1

I believe there were attempts to open configuration file on disk 0xe0
(DiskOnChip fake BIOS drive number just for the GRUB's internal BIOS disk
access API).  This always happens when the grub_firmware was compiled by
running aclocal/autoconf/automake commands from README_DiskOnChip and
specifying the --enable-diskonchip-mil option.  [The latest patches are
0.92 and 2002-07-29].
 
> Ideas??

If you created a partition within NFTL layer, the "root (dc0,0)" command 
would be worth trying.

Ilguiz





From vipin at embeddedlinuxworks.com  Tue Aug  6 15:08:54 2002
From: vipin at embeddedlinuxworks.com (Vipin Malik)
Date: Tue, 06 Aug 2002 14:08:54 -0500
Subject: MTD Partition problems
In-Reply-To: <20020803235032.GA8021@wohnheim.fh-wedel.de>
References: <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>
 <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <AB8D0DF31D9BD511BE94000347959DC901996389@MXSFRCOHOU01>
 <5.1.0.14.0.20020803074026.02927a48@64.170.22.132>
 <5.1.0.14.0.20020803112646.00ace9d8@64.170.22.132>
Message-ID: <5.1.0.14.0.20020806140518.02d03890@ns.webzsite.com>

>
> > However, if one ignores the duplicated devices, one can still use
> > partitioning and mount a JFFS2 fs on one of the partitions while having
> > something completely different on another and device access locking 
> will be
> > taken care of by the mtd driver (which is essentially what partitioning
> > provides vs. just calling add_mtd() NUM_PARTITION times in your map 
> file on
> > the same flash chip).
>
>Yes. The partitioning code basically checks the limits and hands the
>work to the base device with adjusted offset.
>
> > Additionally, (say) /dev/mtdblock2 will really provide a handle to
> > /dev/mtd4 the writable third partition on the partitioned flash chip, thus
> > mounting the JFFS2 fs on the partition originally intended (the third
> > partition).
>
>Almost. /dev/mtd4 should be minor number 8. If you check
>/usr/src/linux/Documentation/devices.txt, you will read the following:
>                   0 = /dev/mtd0         First MTD (rw)
>                   1 = /dev/mtdr0        First MTD (ro)
>Thus mtd0 has minor 0, mtd1 has minor 2, ...
>
>Also, the third partition is /dev/mtd3, as /dev/mtd0 is the real
>device. Look at the minor numbers for /dev/hda*, just the same.


I got the JFFS2 to mount on /dev/mtdblock2 (most of the partition was 
erased. I must have passed the wrong size to the mtd_debug erase. There was 
some garbage at the end).

Anyway, thanks for the explanations.

Vipin


>But what you *meant* is correct.
>
> > Unfortunately, my tests indicate that this is not happening. I know that
> > /dev/mtdblock2 (the intended third partition) is formatted. However JFFS2
> > finds data here and refuses to mount on it. I think it is really being
> > passes a handle to and accesses /dev/mtd2, which is the wrong partition.
>
>See above.
>
> > /dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and 
> /dev/mtd4
> > is the correct partition that I want!
>
>See above.
>
> > Argh! I'll try your patches if you like.
>
>I would be happy if you did. But you don't need my patches, unless you
>have more than one device that you want to partition. With the two
>thinkos out of the way, you should be doing fine. :)
>
>J?rn
>
>--
>Mundie uses a textbook tactic of manipulation: start with some
>reasonable talk, and lead the audience to an unreasonable conclusion.
>-- Bruce Perens
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/




From clark at esteem.com  Tue Aug  6 15:51:19 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 06 Aug 2002 12:51:19 -0700
Subject: Need help getting JFFS2 working with kernel 2.4.19
References: <3D4FFA9B.2C693A02@esteem.com>  <3D4EDA18.C77AEDA@esteem.com> <25573.1028653616@redhat.com>
Message-ID: <3D5028B7.22893B6E@esteem.com>

David Woodhouse wrote:
> 
> clark at esteem.com said:
> >
> >       I figured it out. The jffs2 zlib was conflicting with the zlib used
> > bye ppp compresion. I just had to remove zlib.o from the COMPR_OBJS
> > definition in the Makefile.
> 
> There's a better fix in 2.4.20-pre2 and at
> ftp.kernel.org:/pub/linux/kernel/people/dwmw2/shared-zlib/
> 
> Get the latest patch (2.4.19-pre10) and it should apply to most 2.4 kernels.
> 
> --
> dwmw2


I take it that this patch wasn't submitted to Marcelo or Marcelo didn't get
it integrated the final 2.4.19 then?

Is there anything else I need to do or will the patch fix everything?


Thanks

	Conn	


-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From DGE at sixnetio.com  Tue Aug  6 16:16:10 2002
From: DGE at sixnetio.com (Dave Ellis)
Date: Tue, 6 Aug 2002 16:16:10 -0400 
Subject: Disk blocks for long periods
Message-ID: <00512BA4F9D3D311912A009027E9B8F407E475@NT>

joakim.tjernlund at lumentis.se said:

> hmm, I just noticed that the BIG kernel lock is held while 
> the erasing thread executes, since kupdate takes it in 
> sync_old_buffers() (if I understand this code correctly). 
> Maybe that is causing current->need_resched to be set?
> 
> Also, is it not a bad idea to hold the kernel lock for, 
> possibly, seconds while erasing sectors?

If it is doing that, it doesn't seem right to me. But I 
thought jffs2/mtd bypassed the kernel buffers, so maybe 
kupdate and sync_old_buffers() are not involved here? I don't
know much about this.
 
> I assume your chip does not support buffered writes? or is it 
> just do_write_one_word() that is causing the log delays?

No, it doesn't support buffered writes. The long delay I saw
comes from sleeping for a jiffie during each call to
do_write_oneword().

Dave Ellis
dge at sixnetio.com



From Joakim.Tjernlund at lumentis.se  Tue Aug  6 17:06:01 2002
From: Joakim.Tjernlund at lumentis.se (Joakim Tjernlund)
Date: Tue, 6 Aug 2002 23:06:01 +0200
Subject: Disk blocks for long periods
References: <00512BA4F9D3D311912A009027E9B8F407E475@NT>
Message-ID: <001f01c23d8d$11bbd240$0200a8c0@telia.com>


> joakim.tjernlund at lumentis.se said:
> 
> > hmm, I just noticed that the BIG kernel lock is held while 
> > the erasing thread executes, since kupdate takes it in 
> > sync_old_buffers() (if I understand this code correctly). 
> > Maybe that is causing current->need_resched to be set?
> > 
> > Also, is it not a bad idea to hold the kernel lock for, 
> > possibly, seconds while erasing sectors?
> 
> If it is doing that, it doesn't seem right to me. But I 
> thought jffs2/mtd bypassed the kernel buffers, so maybe 
> kupdate and sync_old_buffers() are not involved here? I don't
> know much about this.

hmm, just remembered that a spin_lock() is NOP on Uni Processor computers.

Kupdate does the erasing and puts a CLEANMARKER on it when its 
done.  Just follow sync_old_buffers()  until it ends up in jffs2_write_super()

BTW
          jffs2_mark_erased_blocks() also checks the newly erased block for
         0xffffffff by reading the EB back. Removing this test improves my litte test case 
         I wrote about in my previous post to the mtd list. The max copy time is reduced
         from 20 seconds to 15 seconds.

        Jocke 

>  
> > I assume your chip does not support buffered writes? or is it 
> > just do_write_one_word() that is causing the log delays?
> 
> No, it doesn't support buffered writes. The long delay I saw
> comes from sleeping for a jiffie during each call to
> do_write_oneword().

I tried your patch and it improved my write times as well. Thanks

> 
> Dave Ellis
> dge at sixnetio.com



From mtd at empireenterprises.com  Tue Aug  6 17:26:53 2002
From: mtd at empireenterprises.com (Glen)
Date: 06 Aug 2002 17:26:53 -0400
Subject: [Fwd: Re: boot from diskonchip millenium]
Message-ID: <1028669214.1719.1.camel@glen>

Thank you for your help thus far.  


> This always happens when the grub_firmware was compiled by
> running aclocal/autoconf/automake commands from README_DiskOnChip and
> specifying the --enable-diskonchip-mil option.  [The latest patches are
> 0.92 and 2002-07-29].

This is what I did, with the 0.92 patch; are you saying I should have
done otherwise?  

I started from scratch, and recompiled everything, reformatted, and the
like.  Now I get the following message:  


DoC Mil D000
E698
Jumping to Grub
Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0xff
Unknown ChipID a0 at c8000
DiskOnChip Millennium found at d0000
floor 0, chip 0; manufacturer: Toshiba
Chip: Toshiba TC58V64AFT/DC, total size: 8MiB
	erase unit: 8192 bytes, page: 512 byes
unknown manufacturer code: 0x43
Total of 1 chips found - total capacity 8 MiB
Scanning for NFTL Media Header
NFTL Media Header found in flash sector 208
nftl_rawread(): error 16 in memcpy() or earlier, press any key


Interestingly enough, after I boot the machine to the HDD by entering
the commands in grub manually, I no longer have a nftl partition.  

Does grub write to the DOC upon booting? 


-g


On Tue, 2002-08-06 at 14:04, Ilguiz Latypov wrote:
> 
> On 6 Aug 2002, Glen wrote:
> 
> > Attempting to open /boot/grub/menu.lst 0x0 0x0
> > Attempting to open /boot/grub/menu.lst 0x0 0x1
> 
> I believe there were attempts to open configuration file on disk 0xe0
> (DiskOnChip fake BIOS drive number just for the GRUB's internal BIOS disk
> access API).  This always happens when the grub_firmware was compiled by
> running aclocal/autoconf/automake commands from README_DiskOnChip and
> specifying the --enable-diskonchip-mil option.  [The latest patches are
> 0.92 and 2002-07-29].
>  
> > Ideas??
> 
> If you created a partition within NFTL layer, the "root (dc0,0)" command 
> would be worth trying.
> 
> Ilguiz
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 







From mark at lakeshoremicro.com  Tue Aug  6 18:15:01 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Tue, 6 Aug 2002 18:15:01 -0400
Subject: [Fwd: Re: boot from diskonchip millenium]
In-Reply-To: <1028669214.1719.1.camel@glen>
References: <1028669214.1719.1.camel@glen>
Message-ID: <20020806221545.NGDX19356.rwcrmhc51.attbi.com@there>

Glen wrote:
> This is what I did, with the 0.92 patch; are you saying I should have
> done otherwise? ?

Glen,

The 0.92 patch is for released Grub; 2002-07-29 is for the latest Grub CVS 
code.  The 0.92 w/patch should work fine.

> Interestingly enough, after I boot the machine to the HDD by entering
> the commands in grub manually, I no longer have a nftl partition.

It's been my experience that after burning the grub_firmware, you may need to 
do the format and fdisk again.   This could be caused by running doc_loadbios 
when the NFTL module is loaded (and a valid NFTL signature is detected):

http://lists.infradead.org/pipermail/linux-mtd/2002-June/005129.html
http://lists.infradead.org/pipermail/linux-mtd/2002-June/005123.html

> Does grub write to the DOC upon booting?

Grub doesn't have the capability to write to a DoC, as far as I know.

Mark




From clark at esteem.com  Tue Aug  6 18:44:04 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 06 Aug 2002 15:44:04 -0700
Subject: Need help getting JFFS2 working with kernel 2.4.19
References: <3D4FFA9B.2C693A02@esteem.com>  <3D4EDA18.C77AEDA@esteem.com> <25573.1028653616@redhat.com> <3D5028B7.22893B6E@esteem.com>
Message-ID: <3D505134.47477658@esteem.com>

Conn Clark wrote:
> 
> David Woodhouse wrote:
> >
> > clark at esteem.com said:
> > >
> > >       I figured it out. The jffs2 zlib was conflicting with the zlib used
> > > bye ppp compresion. I just had to remove zlib.o from the COMPR_OBJS
> > > definition in the Makefile.
> >
> > There's a better fix in 2.4.20-pre2 and at
> > ftp.kernel.org:/pub/linux/kernel/people/dwmw2/shared-zlib/
> >
> > Get the latest patch (2.4.19-pre10) and it should apply to most 2.4 kernels.
> >
> > --
> > dwmw2
> 
> I take it that this patch wasn't submitted to Marcelo or Marcelo didn't get
> it integrated the final 2.4.19 then?
> 
> Is there anything else I need to do or will the patch fix everything?
> 
> Thanks
> 
>         Conn
> 

I applied the patch and now it won't compile again.


here is what the compiler pukes out.

ppc_8xx-ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic
arch/ppc/kernel/head_8xx.o init/main.o init/version.o init/do_mounts.o \
	--start-group \
	arch/ppc/kernel/kernel.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o arch/ppc/math-emu/math-emu.o \
	 drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o
drivers/media/media.o drivers/mtd/mtdlink.o drivers/pcmcia/pcmcia.o
drivers/macintosh/macintosh.o arch/ppc/8xx_io/8xx_io.o \
	net/network.o \
	/192esrc/area51/linux-2.4.19/lib/lib.a \
	--end-group \
	-o vmlinux
fs/fs.o: In function `zlib_compress':
fs/fs.o(.text+0x42c30): undefined reference to `zlib_deflateInit_'
fs/fs.o(.text+0x42c30): relocation truncated to fit: R_PPC_REL24 zlib_deflateInit_
fs/fs.o(.text+0x42cd4): undefined reference to `zlib_deflate'
fs/fs.o(.text+0x42cd4): relocation truncated to fit: R_PPC_REL24 zlib_deflate
fs/fs.o(.text+0x42ce4): undefined reference to `zlib_deflateEnd'
fs/fs.o(.text+0x42ce4): relocation truncated to fit: R_PPC_REL24
zlib_deflateEndfs/fs.o(.text+0x42d4c): undefined reference to `zlib_deflate'
fs/fs.o(.text+0x42d4c): relocation truncated to fit: R_PPC_REL24 zlib_deflate
fs/fs.o(.text+0x42d58): undefined reference to `zlib_deflateEnd'
fs/fs.o(.text+0x42d58): relocation truncated to fit: R_PPC_REL24
zlib_deflateEndfs/fs.o: In function `zlib_decompress':
fs/fs.o(.text+0x42e24): undefined reference to `zlib_inflateInit_'
fs/fs.o(.text+0x42e24): relocation truncated to fit: R_PPC_REL24 zlib_inflateInit_
fs/fs.o(.text+0x42e80): undefined reference to `zlib_inflate'
fs/fs.o(.text+0x42e80): relocation truncated to fit: R_PPC_REL24 zlib_inflate
fs/fs.o(.text+0x42ea4): undefined reference to `zlib_inflateEnd'
fs/fs.o(.text+0x42ea4): relocation truncated to fit: R_PPC_REL24
zlib_inflateEndfs/fs.o: In function `jffs2_zlib_init':
fs/fs.o(.text.init+0x1868): undefined reference to `zlib_deflate_workspacesize'
fs/fs.o(.text.init+0x1868): relocation truncated to fit: R_PPC_REL24
zlib_deflate_workspacesize
fs/fs.o(.text.init+0x1890): undefined reference to `zlib_deflate_workspacesize'
fs/fs.o(.text.init+0x1890): relocation truncated to fit: R_PPC_REL24
zlib_deflate_workspacesize
fs/fs.o(.text.init+0x18a8): undefined reference to `zlib_inflate_workspacesize'
fs/fs.o

Blah Blah Blah.

I take it there are still a few more things I must do?

here is some additional info on my system.
My processor is a PPC MPC850.
My flash chip 1 intel 28F320C3B 16 bit mode

Thanks

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From brendan.simon at ctam.com.au  Tue Aug  6 19:32:21 2002
From: brendan.simon at ctam.com.au (Brendan J Simon)
Date: Wed, 07 Aug 2002 09:32:21 +1000
Subject: kernel hangs on DOC2000 root filesystem
References: <3D4F89CF.3010809@ctam.com.au> <4518.1028624265@redhat.com>
Message-ID: <3D505C85.80705@ctam.com.au>


David Woodhouse wrote:

>brendan.simon at ctam.com.au said:
>
>> Any ideas why the kernel just hangs ? 
>>
>>>>>>>>>>BJS: nftl_release(): invalidate_device()
>>>>>>>>>>

Is this because get_super() fails ???

I've done an fsck.ext2 and it passed with no problems.  This should mean 
that the super blocks are OK, should it ???

I formatted the DOC with nftl_format if that makes any difference.
I also used the latest fdisk from util-linux for format the drive with 
an MSDOS partition table and one ext2 partition.

Thanks for any help or advice.
Brendan Simon.





From brendan.simon at ctam.com.au  Tue Aug  6 19:52:23 2002
From: brendan.simon at ctam.com.au (Brendan J Simon)
Date: Wed, 07 Aug 2002 09:52:23 +1000
Subject: kernel hangs on DOC2000 root filesystem
References: <3D4F89CF.3010809@ctam.com.au> <4518.1028624265@redhat.com>
Message-ID: <3D506137.9050208@ctam.com.au>


David Woodhouse wrote:

>brendan.simon at ctam.com.au said:
>
>> Any ideas why the kernel just hangs ? 
>>
>>>>>>>>>>BJS: nftl_release(): invalidate_device()
>>>>>>>>>>

I've just tried an older 2.4.1-pre11 kernel that a coleague is using.  I 
loaded the kernel via tftp and passed it "root=/dev/nftla1 ro" 
parameters.  It booted perfectly (except for some busybox seg faults). 
 ie. the DOC was mounted so that implies that the super blocks are OK.

Maybe there is a bug in the 2.4.18-pre8 kernel related to MTD/NFTL ??
Maybe I've changed something that I've forgotten about ?  I'll have a 
closer look.

Regards,
Brendan Simon.





From karim at opersys.com  Tue Aug  6 20:03:46 2002
From: karim at opersys.com (Karim Yaghmour)
Date: Tue, 06 Aug 2002 20:03:46 -0400
Subject: Support for Intel 28F032SA
Message-ID: <3D5063E2.C93342D8@opersys.com>

I have an old board with an Intel 28F032SA which I would like to use
with Linux. The 28F032SA is actually 2 consecutively mapped 28F016SA
chips in the same packaging. They, however, cannot be modified
simultaneously, so they can't be dealt with as 2 independent devices.

The chip is non-CFI and the closest driver I've seen is the
drivers/mtd/chips/sharp.c driver which supports Sharp 28F016SCT chips.
I suppose I could hack it to create a driver for the 28F032SA. Before
I do so, nevertheless, I was wondering if someone on this list had any
experience with using this chip and/or if someone knew of another
driver I could use with this chip.

Any insight would be appreciated,

Karim

===================================================
                 Karim Yaghmour
               karim at opersys.com
      Embedded and Real-Time Linux Expert
===================================================



From cain.yuan at intel.com  Tue Aug  6 20:19:56 2002
From: cain.yuan at intel.com (Yuan, Cain)
Date: Wed, 7 Aug 2002 08:19:56 +0800 
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
Message-ID: <957BD1C2BF3CD411B6C500A0C944CA2601499C37@pdsmsx32.pd.intel.com>

Does  this concerned with the fails of JFFS2?  If is, why I can use JFFS2
system   just after burn JFFS2 fs image into  flash with the help of
redboot?


-----Original Message-----
From: David Woodhouse [mailto:dwmw2 at infradead.org]
To: Yuan, Cain
Cc: 'nico at cam.org'; linux-mtd at lists.infradead.org
Subject: Re: JFFS2 peoblems with K3 strata flash on Dalhart 



cain.yuan at intel.com said:
> 	I am now test JFFS2 file system on Dalhart with Redboot as
> boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for
> dalhart.

What erase size did you create your JFFS2 image with?

--
dwmw2



From kevin at gv.com.tw  Tue Aug  6 21:35:08 2002
From: kevin at gv.com.tw (??)
Date: Wed, 7 Aug 2002 09:35:08 +0800
Subject: kernel hangs on DOC2000 root filesystem
References: <3D4F89CF.3010809@ctam.com.au> <4518.1028624265@redhat.com> <3D505C85.80705@ctam.com.au>
Message-ID: <003001c23db2$a9fe8d20$1b0448c0@gv.com.tw>

(2.4.18)mount_root():blkdev_put():bdev->bd_op->release():invalidate_device()
: invalidate_inodes(sb)
probably caused by doing invalidate_xxx() inside mount_root()?
(some other driver also hang when doing release() operation inside
mount_root)

----- Original Message -----
From: "Brendan J Simon" <brendan.simon at ctam.com.au>
To: "linux-mtd" <linux-mtd at lists.infradead.org>
Sent: Wednesday, August 07, 2002 7:32 AM
Subject: Re: kernel hangs on DOC2000 root filesystem


>
>
> David Woodhouse wrote:
>
> >brendan.simon at ctam.com.au said:
> >
> >> Any ideas why the kernel just hangs ?
> >>
> >>>>>>>>>>BJS: nftl_release(): invalidate_device()
> >>>>>>>>>>
>
> Is this because get_super() fails ???
>
> I've done an fsck.ext2 and it passed with no problems.  This should mean
> that the super blocks are OK, should it ???
>
> I formatted the DOC with nftl_format if that makes any difference.
> I also used the latest fdisk from util-linux for format the drive with
> an MSDOS partition table and one ext2 partition.
>
> Thanks for any help or advice.
> Brendan Simon.
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From cain.yuan at intel.com  Tue Aug  6 22:11:28 2002
From: cain.yuan at intel.com (Yuan, Cain)
Date: Wed, 7 Aug 2002 10:11:28 +0800 
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
Message-ID: <957BD1C2BF3CD411B6C500A0C944CA2601499C38@pdsmsx32.pd.intel.com>

Hi  David,
	According to your email  I  rebuild a JFFS2 image with the   block
size 0x10000,  same as the datasheet saids.
but the problem still exist.  First bootup will success without any error
message. but when I reset the board and boot it again, many errors occurs.

---------------------  first  time bootup
message-----------------------------
Creating 7 MTD partitions on "Lubbock flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00080000 : "RedBoot[backup]"
0x00080000-0x00180000 : "unallocated space"
0x00180000-0x00980000 : "JFFS2"
0x00980000-0x00fc0000 : "unallocated space"
0x00fc0000-0x00fc1000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't end on an erase block -- force
read-only
0x00fe0000-0x01000000 : "FIS directory"
Linux Kernel Card Services 3.1.22
  options:  [pm]
Intel PXA250/210 PCMCIA (CS release 3.1.22)
Unable to initialize kernel PCMCIA service.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
ds: no socket drivers loaded!
FAT: bogus logical sector size 453
jffs2_scan_empty(): Empty block at 0x0000fffc ends at 0x00010000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0002ff58 ends at 0x00030000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0034fffc ends at 0x00350000 (with
0xe0021985)! Marking dirty
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 80K
INIT: version 2.74 booting
INIT: Entering runlevel: 3
Starting system logger:  syslogd
Starting INET services:  inetd
Starting pcmcia Starting PCMCIA services: module directory
/lib/modules/2.4.18-rmk6-pxa2/pcmcia not found.

Linux login:

After login.  create/del/ files are all OK.

---------------------  second   time bootup
message-----------------------------

cfi probe success.
Using RedBoot partition definition
Creating 7 MTD partitions on "Lubbock flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x00080000 : "RedBoot[backup]"
0x00080000-0x00180000 : "unallocated space"
0x00180000-0x00980000 : "JFFS2"
0x00980000-0x00fc0000 : "unallocated space"
0x00fc0000-0x00fc1000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't end on an erase block -- force
read-only
0x00fe0000-0x01000000 : "FIS directory"
Linux Kernel Card Services 3.1.22
  options:  [pm]
Intel PXA250/210 PCMCIA (CS release 3.1.22)
Unable to initialize kernel PCMCIA service.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP

jffs2_scan_empty(): Empty block at 0x0030fffc ends at 0x00310000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0032fffc ends at 0x00330000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0034fffc ends at 0x00350000 (with
0xe0021985)! Marking dirty
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 80K
Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
INIT: version 2.74 booting
Write of 257 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
Write of 185 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero

Linux login:

After login.  create/del/ files will all fail.

[root at Linux /root]$touch test
Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero
touch: Input/output error







-----Original Message-----
From: David Woodhouse [mailto:dwmw2 at infradead.org]
To: Yuan, Cain
Cc: 'nico at cam.org'; linux-mtd at lists.infradead.org
Subject: Re: JFFS2 peoblems with K3 strata flash on Dalhart 



cain.yuan at intel.com said:
> 	I am now test JFFS2 file system on Dalhart with Redboot as
> boorloader, Linux version 2.4.18-rmk6-pxa2 and some patches for
> dalhart.

What erase size did you create your JFFS2 image with?

--
dwmw2



From felix.giffuni at alliancetelecom.fr  Wed Aug  7 03:23:38 2002
From: felix.giffuni at alliancetelecom.fr (Felix GIFFFUNI (E-mail))
Date: Wed, 7 Aug 2002 09:23:38 +0200
Subject: ChipOnDisk ank uClinux kernel 2.0.38
Message-ID: <000001c23de3$5a2aa550$3201a8c0@ANALYTEL.fr>


Hello,

I would add a DiskOnChip 2000 on my HitachiDevBoard( h8:3068).
I suppose i have to use mtd and ffs with uClinux kernel 2.0.38: could you
confirm that is possible or not?







From jay.s at sohu.com  Wed Aug  7 04:48:04 2002
From: jay.s at sohu.com (jay.s at sohu.com)
Date: Wed, 7 Aug 2002 16:48:04 +0800 (CST)
Subject: problem at boot from doc2000-with grub
Message-ID: <871203.1028710084678.JavaMail.postfix@mailsrv1.mail.sohu.com>

hi
  I have managed to compile the kernel and the grub, now I can read/write the doc2000 and I also get the grub_firmware which is about 89664 bytes, but still I cannot make the doc boot itself up. Although a previous good how to tell me to doc_loadbios /dev/mtd0   grub_firmware, but I find the doc_firmware space is only about 49k bytes, this 88k one can not inserted into it. I've tried to use dformat5.1 /BDKL0:90k to change the firmware space but I met the old !=1 preblem, but dformat4.2 seems doesn't support the parameter, what shall I do then?
 I am using a doc-2000 in a pc104 SBC with phoenix bios.

thans
                                 jay





From nurpinar at basari.net.tr  Wed Aug  7 05:05:52 2002
From: nurpinar at basari.net.tr (nur)
Date: Wed, 7 Aug 2002 12:05:52 +0300
Subject: docprobe for millennium
Message-ID: <000701c23df1$a20ae1b0$3064000a@nurpinar>

is there such a parameter for docprobe related to memory address of doc?
dinfo results doc millennium at 0xe8000 while docprobe says no diskonchip
found







From startec at ms11.hinet.net  Wed Aug  7 05:08:16 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Wed, 7 Aug 2002 17:08:16 +0800
Subject: NAND Configuration
In-Reply-To: <1028636176.19435.47.camel@thomas.tec.linutronix.de>
Message-ID: <002101c23df1$f8caad00$5501a8c0@synso.com.tw>


> > I read it many time, but CONFIG_JFFS2_FS_NAND use to take care 
> > buffering and OOB . Does I have to use it absolutely? If I 
> do not use 
> > it, what's the result of the driver?
> Yes, you _HAVE_ _ABSOLUTELY_ to use it !  
> IF not, no buffering and OOB check, no bad block management 
> ..--> no JFFS2 on NAND.
> 
JFFS2 on NOR type flash does not use buffering, OOB check and bad block
management, but it can be used now. I meant that CONFIG_JFFS2_FS_NAND is
not defined, maybe the driver still can work, but it is not good as the
original one.


> > We need more info from mount onwards.
> > 
> > Maybe I do not provide repeatable messages and steps. The following 
> > are the steps I use.
> > 1. eraseall /dev/mtd1            
> > 2. mount -t jffs2 /dev/mtdblock1 /mnt
> > 3. Make directory to /mnt
> > 4. Use ftp to copy files to /mnt
> > 5. Change the kernel to to mount /dev/mtdblock1 as root FS. 
> 6. Copy or 
> > delete files and sometime the message display
> > 	ARGH. About to write node to 0x003f9e2c on flash, but 
> there are data 
> > already the re:...
> >     After that, the patition will display more error messages, ECC 
> > error and others.
> 
> I meant, could you get full logs with CONFIG_JFFS2_FS_DEBUG=1 
> from mounting the file system to the ARGH? Make sure you are 
> logging over a serial console so you catch _ALL_ the 
> messages, and remember they're at level KERN_DEBUG so echo 9 
> > /proc/sys/kernel/printk before mount.
> 
OK. I log the file. I have two files, one is logging the process to
build the file system, anothor is logging the process of file operation.
The attached file is the second file. Thanks.


Steve Tsai
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: trace2.txt
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20020807/8a8c3882/attachment.txt 

From dwmw2 at infradead.org  Wed Aug  7 05:46:49 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 10:46:49 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA2601499C38@pdsmsx32.pd.intel.com> 
References: <957BD1C2BF3CD411B6C500A0C944CA2601499C38@pdsmsx32.pd.intel.com> 
Message-ID: <30833.1028713609@redhat.com>

cain.yuan at intel.com said:
> 	According to your email  I  rebuild a JFFS2 image with the   block
> size 0x10000,  same as the datasheet saids. but the problem still
> exist.  First bootup will success without any error message. but when
> I reset the board and boot it again, many errors occurs.

Looks like you should be using 0x20000. 0x10000 is fine but triggers 
harmless messages about 'Empty block at 0x.... '. I think you were using 
0x40000 before which would have caused problems.

The other problem still remains, and isn't related, though...

> Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
> Not marking the space at 0x0035e908 as dirty because the flash driver returned retlen zero

The hardware driver seems broken -- it's returning success but not actually 
reporting that it's written any data. What driver, what version?

--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 05:50:06 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 10:50:06 +0100
Subject: Need help getting JFFS2 working with kernel 2.4.19 
In-Reply-To: <3D5028B7.22893B6E@esteem.com> 
References: <3D5028B7.22893B6E@esteem.com>  <3D4FFA9B.2C693A02@esteem.com> <3D4EDA18.C77AEDA@esteem.com> <25573.1028653616@redhat.com> 
Message-ID: <31041.1028713806@redhat.com>

clark at esteem.com said:
>  I take it that this patch wasn't submitted to Marcelo or Marcelo
> didn't get it integrated the final 2.4.19 then?

> Is there anything else I need to do or will the patch fix everything?

It's in 2.4.20-pre2. We figured it was a little too intrusive to go into 
2.4.19.


--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 05:51:44 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 10:51:44 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLAEIIFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLAEIIFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <31147.1028713904@redhat.com>

joakim.tjernlund at lumentis.se said:
>  Can the JFFS2 layer also use spin_lock() instead of spin_lock_bh()?
> Shold we try not to disable bottom-halves or does it not matter?

Well, the MTD API documentation (in my head) says that the erase completion 
callback may be called in bottom-half context (i.e. from a timer), which is 
why JFFS2 uses spin_lock_bh(). 

I suppose we could change that.

--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 05:56:13 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 10:56:13 +0100
Subject: Need help getting JFFS2 working with kernel 2.4.19 
In-Reply-To: <3D505134.47477658@esteem.com> 
References: <3D505134.47477658@esteem.com>  <3D4FFA9B.2C693A02@esteem.com> <3D4EDA18.C77AEDA@esteem.com> <25573.1028653616@redhat.com> <3D5028B7.22893B6E@esteem.com> 
Message-ID: <31413.1028714173@redhat.com>

clark at esteem.com said:
> I applied the patch and now it won't compile again.

Did you run 'make oldconfig'?

--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 06:05:35 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 11:05:35 +0100
Subject: No free space left for GC(test2 with log) 
In-Reply-To: <000701c23d49$aefcb860$1b0448c0@gv.com.tw> 
References: <000701c23d49$aefcb860$1b0448c0@gv.com.tw>  <010801c23d3e$7d0f0c00$1b0448c0@gv.com.tw> <003501c23d10$5f6c4f60$1b0448c0@gv.com.tw> <01c201c23c69$7995faa0$1b0448c0@gv.com.tw> <00bc01c239cf$4ef3a8c0$1b0448c0@gv.com.tw> <013d01c2388f$94c655a0$1b0448c0@gv.com.tw> <0H04006C5M7GUI@smtp-out.bhp.t-online.de> <00f801c2390a$d956dd40$1b0448c0@gv.com.tw> <0H05001Y6RM950@smtp-out.bhp.t-online.de> <001001c23957$3a290520$1b0448c0@gv.com.tw> <28541.1028541296@redhat.com> <31970.1028543113@redhat.com> <000701c23cfe$a1542040$1b0448c0@gv.com.tw> <31481.1028622389@redhat.com> <31830.1028636815@redhat.com> 
Message-ID: <32140.1028714735@redhat.com>

kevin at gv.com.tw said:
> jffs2_g_c_deletion_dirent(): Short read (40 not 12) reading from
> obsolete node at 00633ae0

Ok, this was a stupid error on my part which prevented GC from working. It 
may well have been causing the problem. CVS update and try again.


--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 06:05:30 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 11:05:30 +0100
Subject: NAND Configuration 
In-Reply-To: <002101c23df1$f8caad00$5501a8c0@synso.com.tw> 
References: <002101c23df1$f8caad00$5501a8c0@synso.com.tw> 
Message-ID: <32129.1028714730@redhat.com>

startec at ms11.hinet.net said:
> JFFS2 on NOR type flash does not use buffering, OOB check and bad
> block management, but it can be used now. I meant that
> CONFIG_JFFS2_FS_NAND is not defined, maybe the driver still can work,
> but it is not good as the original one.

JFFS2 cannot work on NAND flash without the extra code enabled by 
CONFIG_JFFS2_FS_NAND. You need to batch writes into page-sized chunks and 
use ECC. It looks like you have enabled CONFIG_JFFS2_FS_NAND in the log you 
show -- is that correct?

--
dwmw2





From startec at ms11.hinet.net  Wed Aug  7 06:19:08 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Wed, 7 Aug 2002 18:19:08 +0800
Subject: NAND Configuration 
In-Reply-To: <32129.1028714730@redhat.com>
Message-ID: <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw>

> > JFFS2 on NOR type flash does not use buffering, OOB check and bad 
> > block management, but it can be used now. I meant that 
> > CONFIG_JFFS2_FS_NAND is not defined, maybe the driver still 
> can work, 
> > but it is not good as the original one.
> 
> JFFS2 cannot work on NAND flash without the extra code enabled by 
> CONFIG_JFFS2_FS_NAND. You need to batch writes into 
> page-sized chunks and 
> use ECC. It looks like you have enabled CONFIG_JFFS2_FS_NAND 
> in the log you 
> show -- is that correct?
> 

Yes, I enable CONFIG_JFFS2_FS_NAND. I follow
http://www.linux-mtd.infradead.org/tech/nand.html to config the
settings. Can I do not care ECC on NAND flash?

Steve Tsai




From startec at ms11.hinet.net  Wed Aug  7 06:45:14 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Wed, 7 Aug 2002 18:45:14 +0800
Subject: NAND Configuration
In-Reply-To: <1028636935.19435.73.camel@thomas.tec.linutronix.de>
Message-ID: <003401c23dff$84796be0$5501a8c0@synso.com.tw>

> Could you try to set chipdelay to a longer value ? 	
> -- 


I try to set chip_delay to a longer value, but I got the same result.


Steve tsai




From tglx at linutronix.de  Wed Aug  7 06:49:05 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 07 Aug 2002 12:49:05 +0200
Subject: NAND Configuration
In-Reply-To: <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw>
References: <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw>
Message-ID: <1028717345.19447.249.camel@thomas.tec.linutronix.de>

On Wed, 2002-08-07 at 12:19, Steve Tsai wrote:
> > > JFFS2 on NOR type flash does not use buffering, OOB check and bad 
> > > block management, but it can be used now. I meant that 
> > > CONFIG_JFFS2_FS_NAND is not defined, maybe the driver still 
> > can work, 
> > > but it is not good as the original one.
> > 
> > JFFS2 cannot work on NAND flash without the extra code enabled by 
> > CONFIG_JFFS2_FS_NAND. You need to batch writes into 
> > page-sized chunks and 
> > use ECC. It looks like you have enabled CONFIG_JFFS2_FS_NAND 
> > in the log you 
> > show -- is that correct?
> > 
> 
> Yes, I enable CONFIG_JFFS2_FS_NAND. I follow
> http://www.linux-mtd.infradead.org/tech/nand.html to config the
> settings. Can I do not care ECC on NAND flash?
> 
ECC _HAS_ to be enabled !

Have you ever erased your flash with erase /dev/mtdX ?
This may have caused the problem, because erase is not aware of bad
block handling and may have erased a block, which was marked as bad
already and erased the bad block marker too. So if you write to this
block, you get a write failure and therefor a read failure afterwards. 
I will change nand.c, so that bad blocks cannot be erased anymore.

Another problem could be your command delay time. You have set it to
15?sec. Is that correct for your chip ? Which chip are you using ?
Have you tried to set it to a higher value ? 

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Wed Aug  7 07:11:06 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 12:11:06 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <00512BA4F9D3D311912A009027E9B8F407E474@NT> 
References: <00512BA4F9D3D311912A009027E9B8F407E474@NT> 
Message-ID: <7780.1028718666@redhat.com>

DGE at sixnetio.com said:
> The cfi_udelay() call is part of the problem, since it lets other
> processes run, and the one that runs is the erasing process, but it
> can't do anything except slow things down since the flash  is busy
> writing.

The erasing process should be sitting in TASK_UNINTERRUPTIBLE and on the 
chip's wait queue, waiting to be woken when the chip becomes available. Why 
is it running?

> What the erasing process does seem to do (and  I don't understand why)
> is cause current->need_resched to be set for every call to
> cfi_udelay(), so it calls schedule_timeout(1)  and sleeps for a whole
> jiffie. 

Sleeping for a whole jiffie is bad. We should udelay() and yield() as you 
point out; there's no reason to use schedule_timeout() and hence stop 
ourself from being woken immediately if there's not really anything else to 
run. I've committed that change to CVS.

I don't understand why need_resched is being set either, though. 

Adding cfi_udelay() to do_write_oneword() is dangerous. You may trigger a
bug that's actually already there. ISTR there's a time limit on the 'unlock
bypass' mode, and if you schedule() you may find that the chip is no longer 
in that mode when you return.

Another thing you might want to do if you really care about write 
performance is copy the logic for calculating word_write_time from the 
cfi_cmdset_0001 driver.

--
dwmw2





From cain.yuan at intel.com  Wed Aug  7 08:59:23 2002
From: cain.yuan at intel.com (Yuan, Cain)
Date: Wed, 7 Aug 2002 20:59:23 +0800 
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
Message-ID: <957BD1C2BF3CD411B6C500A0C944CA2601499C3B@pdsmsx32.pd.intel.com>

cain.yuan at intel.com said:
> 	According to your email  I  rebuild a JFFS2 image with the   block
> size 0x10000,  same as the datasheet saids. but the problem still
> exist.  First bootup will success without any error message. but when
> I reset the board and boot it again, many errors occurs.

Looks like you should be using 0x20000. 0x10000 is fine but triggers 
harmless messages about 'Empty block at 0x.... '. I think you were using 
0x40000 before which would have caused problems.
~~~~~~~~~~  yes, I am using 0x40000 before.


The other problem still remains, and isn't related, though...

> Write of 68 bytes at 0x0035e908 failed. returned 0, retlen 0
> Not marking the space at 0x0035e908 as dirty because the flash driver
returned retlen zero

The hardware driver seems broken -- it's returning success but not actually 
reporting that it's written any data. What driver, what version?

---  Since using CFI  with Ks flash, I think  it is CFI driver and
cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
      Should I download  newest   code from CVS server and merge them into
the   kernel src tree?


Thanks!!



--
dwmw2



From ssh at sgi.com  Wed Aug  7 09:06:29 2002
From: ssh at sgi.com (Steven Hein)
Date: Wed, 07 Aug 2002 08:06:29 -0500
Subject: Hardware ECC in NAND flash driver
Message-ID: <3D511B55.6ADABE4D@sgi.com>

Hello,

I'm working on the Linux port to the Samsung S3C2410 PDA controller
(ARM 920T core with many interfaces, including a NAND flash controller,
built-in).  The 2410's NAND flash controller generates ECC codes
(3 bytes ECC per each 512 bytes data).  Are there any plans to
incorporate hardware ECC support into this driver?  Specifically,
I guess that would mean adding "hooks" so the hardware-specific
driver could handle the ECC parts   (I only had to make
a few small changes to nand.c to get this working for the 2410.)
If there's an effort underway in this area, I'd be happy to
participate in the development.

Thanks,
Steve


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh at sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From tglx at linutronix.de  Wed Aug  7 09:15:38 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 07 Aug 2002 15:15:38 +0200
Subject: Hardware ECC in NAND flash driver
In-Reply-To: <3D511B55.6ADABE4D@sgi.com>
References: <3D511B55.6ADABE4D@sgi.com>
Message-ID: <1028726139.19447.255.camel@thomas.tec.linutronix.de>

On Wed, 2002-08-07 at 15:06, Steven Hein wrote:
> Hello,
> 
> I'm working on the Linux port to the Samsung S3C2410 PDA controller
> (ARM 920T core with many interfaces, including a NAND flash controller,
> built-in).  The 2410's NAND flash controller generates ECC codes
> (3 bytes ECC per each 512 bytes data).  Are there any plans to
> incorporate hardware ECC support into this driver?  Specifically,
> I guess that would mean adding "hooks" so the hardware-specific
> driver could handle the ECC parts   (I only had to make
> a few small changes to nand.c to get this working for the 2410.)
> If there's an effort underway in this area, I'd be happy to
> participate in the development.
> 
We thougt about that already, but nobody made an attempt to do so,
because we had no hardware supporting this.
I was thinking about a similar hook as it is used for command function
and dev_ready function. So the hardware ecc support would be located in
the corresponding hardware driver.
If you send me a diff against current CVS, we can find a clean way
together to incorporate it into nand.c

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Wed Aug  7 09:28:05 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 14:28:05 +0100
Subject: Hardware ECC in NAND flash driver 
In-Reply-To: <1028726139.19447.255.camel@thomas.tec.linutronix.de> 
References: <1028726139.19447.255.camel@thomas.tec.linutronix.de>  <3D511B55.6ADABE4D@sgi.com> 
Message-ID: <20434.1028726885@redhat.com>

tglx at linutronix.de said:
> We thougt about that already, but nobody made an attempt to do so,
> because we had no hardware supporting this.

Except the DiskOnChip, which probably ought to be using the generic NAND 
driver too.

--
dwmw2





From tglx at linutronix.de  Wed Aug  7 09:39:18 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 07 Aug 2002 15:39:18 +0200
Subject: Hardware ECC in NAND flash driver
In-Reply-To: <20434.1028726885@redhat.com>
References: <1028726139.19447.255.camel@thomas.tec.linutronix.de>
 <3D511B55.6ADABE4D@sgi.com> <20434.1028726885@redhat.com>
Message-ID: <1028727565.19592.257.camel@thomas.tec.linutronix.de>

On Wed, 2002-08-07 at 15:28, David Woodhouse wrote:
> 
> tglx at linutronix.de said:
> > We thougt about that already, but nobody made an attempt to do so,
> > because we had no hardware supporting this.
> 
> Except the DiskOnChip, which probably ought to be using the generic NAND 
> driver too.
Yep, it could be handled the same way.
-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Wed Aug  7 10:20:10 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 15:20:10 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA2601499C3B@pdsmsx32.pd.intel.com> 
References: <957BD1C2BF3CD411B6C500A0C944CA2601499C3B@pdsmsx32.pd.intel.com> 
Message-ID: <24862.1028730010@redhat.com>

cain.yuan at intel.com said:
>  ---  Since using CFI  with Ks flash, I think  it is CFI driver and
> cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
>       Should I download  newest   code from CVS server and merge them
> into the   kernel src tree? 

Er, I don't think there have been significant changes since then. Updating 
to the latest code certainly can't hurt though.

The problem is that the chip write() call is returning zero (i.e. no error) 
but is setting the number of written bytes to zero. That doesn't make sense 
-- if it didn't write all the bytes we asked it to, then there must have 
been an error.

This chip supports buffer writes, doesn't it? Can you add some extra 
'printk' calls in cfi_intelext_write_buffers() to try to show what's 
happening to 'retlen' and when it returns.

--
dwmw2





From w15879 at motorola.com  Wed Aug  7 10:28:08 2002
From: w15879 at motorola.com (Gu Susan-w15879)
Date: Wed, 7 Aug 2002 22:28:08 +0800 
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
Message-ID: <89DEFCC5DB33D411A27F00508BCF8A8205EE3C7D@ZCH07EXM05.corp.mot.com>

Does K3 (and Dalhart) be configured as "burst" read mode when system is reset?

-----Original Message-----
From: David Woodhouse [mailto:dwmw2 at infradead.org]
Sent: Wednesday, August 07, 2002 10:20 PM
To: Yuan, Cain
Cc: linux-mtd at lists.infradead.org
Subject: Re: JFFS2 peoblems with K3 strata flash on Dalhart 



cain.yuan at intel.com said:
>  ---  Since using CFI  with Ks flash, I think  it is CFI driver and
> cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
>       Should I download  newest   code from CVS server and merge them
> into the   kernel src tree? 

Er, I don't think there have been significant changes since then. Updating 
to the latest code certainly can't hurt though.

The problem is that the chip write() call is returning zero (i.e. no error) 
but is setting the number of written bytes to zero. That doesn't make sense 
-- if it didn't write all the bytes we asked it to, then there must have 
been an error.

This chip supports buffer writes, doesn't it? Can you add some extra 
'printk' calls in cfi_intelext_write_buffers() to try to show what's 
happening to 'retlen' and when it returns.

--
dwmw2



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



From cain.yuan at intel.com  Wed Aug  7 11:18:53 2002
From: cain.yuan at intel.com (Yuan, Cain)
Date: Wed, 7 Aug 2002 23:18:53 +0800 
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
Message-ID: <957BD1C2BF3CD411B6C500A0C944CA2601499C3D@pdsmsx32.pd.intel.com>

Dear David,
Please notice the fact:  
   at the first,  I burn JFFS2  into K3  flash, then load zImage It boot up
all ok, and   JFFS2 file system are all OK.
But after reset   and load zImage again  I can't create/del  files on JFFS2
file system.
SO I think   there is no much concern with the cfi_xxx_write function, maybe
the status is not  correctly set.
As to buffer writes, I  see  some  lines in  cfi_cmdset_001.c:

// debugging, turns off buffer write mode  #define      FORCE_WORD_WRITE
. . . . . . 
    mtd->read = cfi_intelext_read;
#ifndef FORCE_WORD_WRITE
    if ( cfi->cfiq->BufWriteTimeoutTyp ) {
        printk("Using buffer write method\n" );
        mtd->write = cfi_intelext_write_buffers;
    } else {
#else
    {
#endif
        printk("Using word write method\n" );
        mtd->write = cfi_intelext_write_words;
    }
 . . . . 

So I added #define      FORCE_WORD_WRITE     at hte begining of the file, so
I think   there is nothing concerned with   buffer write functions.
 



cain.yuan at intel.com said:
>  ---  Since using CFI  with Ks flash, I think  it is CFI driver and
> cfi_cmdset_001.c,  the  code   reside in  linux2.4.18-rmk6-pxa2.
>       Should I download  newest   code from CVS server and merge them
> into the   kernel src tree? 

Er, I don't think there have been significant changes since then. Updating 
to the latest code certainly can't hurt though.

The problem is that the chip write() call is returning zero (i.e. no error) 
but is setting the number of written bytes to zero. That doesn't make sense 
-- if it didn't write all the bytes we asked it to, then there must have 
been an error.

This chip supports buffer writes, doesn't it? Can you add some extra 
'printk' calls in cfi_intelext_write_buffers() to try to show what's 
happening to 'retlen' and when it returns.



From cain.yuan at intel.com  Wed Aug  7 11:21:40 2002
From: cain.yuan at intel.com (Yuan, Cain)
Date: Wed, 7 Aug 2002 23:21:40 +0800 
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
Message-ID: <957BD1C2BF3CD411B6C500A0C944CA2601499C3E@pdsmsx32.pd.intel.com>

No,  but if we don't configure it as" burst" mode,  It will always fail with
write???
Thanks for your useful  information. 



-----Original Message-----
From: Gu Susan-w15879 [mailto:w15879 at motorola.com]
To: 'David Woodhouse'; Yuan, Cain
Cc: linux-mtd at lists.infradead.org
Subject: RE: JFFS2 peoblems with K3 strata flash on Dalhart 


Does K3 (and Dalhart) be configured as "burst" read mode when system is
reset?




From DGE at sixnetio.com  Wed Aug  7 12:42:09 2002
From: DGE at sixnetio.com (Dave Ellis)
Date: Wed, 7 Aug 2002 12:42:09 -0400 
Subject: Disk blocks for long periods 
Message-ID: <00512BA4F9D3D311912A009027E9B8F407E477@NT>

David Woodhouse said:
> DGE at sixnetio.com said:
> > The cfi_udelay() call is part of the problem, since it lets other 
> > processes run, and the one that runs is the erasing process, but it 
> > can't do anything except slow things down since the flash  is busy 
> > writing.
> 
> The erasing process should be sitting in TASK_UNINTERRUPTIBLE and on the 
> chip's wait queue, waiting to be woken when the chip becomes available.
Why 
> is it running?

It is running because of the
        wake_up(&chip->wq);
at the end of do_write_oneword(). So it wakes up for every word written.

With the old code (cfi_cmdset_0002.c 1.56 and before) the next chance it 
gets to run is when cfi_udelay() is called during the next 
do_write_oneword(). Unfortunately, it can't start erasing because 
chip->state is FL_WRITING, so it puts itself back on the wait queue. The
wake_up() at the end of do_write_oneword() wakes it up again, but it
doesn't run until the cfi_delay() in the _next_ call to do_write_oneword().
So it runs and puts itself back on the wait queue for every call to 
do_write_oneword(). Eventually all the words are written, it wakes up to 
find FL_READY and starts the erase. Without the one jiffie delay in 
cfi_delay() each time it wouldn't have been as bad, but erase going off 
and back on the wait queue several thousand times still doesn't seem right.

> > What the erasing process does seem to do (and  I don't understand why) 
> > is cause current->need_resched to be set for every call to 
> > cfi_udelay(), so it calls schedule_timeout(1) and sleeps for a whole 
> > jiffie.
> 
> Sleeping for a whole jiffie is bad. We should udelay() and yield() as you 
> point out; there's no reason to use schedule_timeout() and hence stop 
> ourself from being woken immediately if there's not really anything else
to 
> run. I've committed that change to CVS.

Thanks, I looked at the change and seems much better to me.

> Adding cfi_udelay() to do_write_oneword() is dangerous. You 
> may trigger a bug that's actually already there. ISTR there's 
> a time limit on the 'unlock bypass' mode, and if you 
> schedule() you may find that the chip is no longer 
> in that mode when you return.

Actually I didn't add it, I just moved it to the end, where chip->state
is FL_READY, so the erase can actually start if it wakes up. I think
both the old code and your latest change to cfi_cmdset_0002.c
would have the same problem with a time limit, since they call 
cfi_udelay() or yield() while each word is writing. I didn't
find any time limit for my chip.

I think my change (which really should be cond_resched(), not 
cfi_udelay() since I don't need the delay) would cause a 
different problem with 'unlock bypass' (which I am not using).
The chip is tagged as FL_READY when it really (I guess) 
isn't. But if I schedule() between words with the chip not 
FL_READY, I am right back to the original problem. And if I
don't schedule() until the whole write is done nothing else
can run for a long time.

Maybe if 'unlock bypass' is used the
  chip->state = FL_READY; wake_up(&chip->wq);
should only happen after leaving 'unlock bypass' mode?

I wonder if 'unlock bypass' is worth all the trouble. I think
I'll just not use it and call cond_resched() instead of 
cfi_udelay() at the end of do_write_oneword().
 
> Another thing you might want to do if you really care about write 
> performance is copy the logic for calculating word_write_time 
> from the cfi_cmdset_0001 driver.

Thanks for the suggestion, but the write performance with my
fix is fine so I may not try it for a while. The long delays
(up to 60 seconds) on single write() were the problem. They 
were making a communications protocol time out and making total
load times very long. Without them, the average performance is 
fine.

I am very impressed with jffs2 and mtd. With this one problem
fixed it is exactly what we need and works very well.

Dave Ellis
dge at sixnetio.com



From dwmw2 at infradead.org  Wed Aug  7 13:38:00 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 18:38:00 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <89DEFCC5DB33D411A27F00508BCF8A8205EE3C7D@ZCH07EXM05.corp.mot.com> 
References: <89DEFCC5DB33D411A27F00508BCF8A8205EE3C7D@ZCH07EXM05.corp.mot.com> 
Message-ID: <10839.1028741880@redhat.com>

w15879 at motorola.com said:
> Does K3 (and Dalhart) be configured as "burst" read mode when system
> is reset?

Linux doesn't currently make use of burst reads from flash. To do so you'd 
need to either operate through the caches or use the 'read buffer' if you 
have an SA1110.

To use caches sanely, the best way is probably to implement the mechanism 
I've been planning for execute-in-place.

--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 13:39:11 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 18:39:11 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA2601499C3E@pdsmsx32.pd.intel.com> 
References: <957BD1C2BF3CD411B6C500A0C944CA2601499C3E@pdsmsx32.pd.intel.com> 
Message-ID: <10931.1028741951@redhat.com>

cain.yuan at intel.com said:
> No,  but if we don't configure it as" burst" mode,  It will always
> fail with write??? Thanks for your useful  information. 

It shouldn't, no -- and if it did I don't see why the flash driver wouldn't
return an _error_ instead of returning status zero but 'written bytes zero'.

--
dwmw2





From dwmw2 at infradead.org  Wed Aug  7 13:42:21 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 07 Aug 2002 18:42:21 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA2601499C3D@pdsmsx32.pd.intel.com> 
References: <957BD1C2BF3CD411B6C500A0C944CA2601499C3D@pdsmsx32.pd.intel.com> 
Message-ID: <11201.1028742141@redhat.com>

cain.yuan at intel.com said:
> Please notice the fact:  
>    at the first,  I burn JFFS2  into K3  flash, then load zImage It
> boot up all ok, and   JFFS2 file system are all OK. 

OK... and you can write to it too? What if you reset the board between 
flashing the image and booting Linux?

> But after reset and load zImage again  I can't create/del  files on 
> JFFS2 file system.

Strange. I'm wondering if perhaps the map driver isn't correctly setting 
the Vpp line, but again you should get an _error_ for that, not a zero 
return status. So even if the underlying fault doesn't lie with the write 
routine, it seems to be doing _something_ wrong. 

--
dwmw2





From ahennessy at mvista.com  Wed Aug  7 17:11:34 2002
From: ahennessy at mvista.com (Alice Hennessy)
Date: Wed, 07 Aug 2002 14:11:34 -0700
Subject: NAND Configuration
References: <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw> <1028717345.19447.249.camel@thomas.tec.linutronix.de>
Message-ID: <3D518D06.B809B67@mvista.com>

Thomas Gleixner wrote:

> On Wed, 2002-08-07 at 12:19, Steve Tsai wrote:
> > > > JFFS2 on NOR type flash does not use buffering, OOB check and bad
> > > > block management, but it can be used now. I meant that
> > > > CONFIG_JFFS2_FS_NAND is not defined, maybe the driver still
> > > can work,
> > > > but it is not good as the original one.
> > >
> > > JFFS2 cannot work on NAND flash without the extra code enabled by
> > > CONFIG_JFFS2_FS_NAND. You need to batch writes into
> > > page-sized chunks and
> > > use ECC. It looks like you have enabled CONFIG_JFFS2_FS_NAND
> > > in the log you
> > > show -- is that correct?
> > >
> >
> > Yes, I enable CONFIG_JFFS2_FS_NAND. I follow
> > http://www.linux-mtd.infradead.org/tech/nand.html to config the
> > settings. Can I do not care ECC on NAND flash?
> >
> ECC _HAS_ to be enabled !
>
> Have you ever erased your flash with erase /dev/mtdX ?
> This may have caused the problem, because erase is not aware of bad
> block handling and may have erased a block, which was marked as bad
> already and erased the bad block marker too. So if you write to this
> block, you get a write failure and therefor a read failure afterwards.
> I will change nand.c, so that bad blocks cannot be erased anymore.
>

>From looking at nand_erase(), it appears that the attempted erase of a bad
block would
result in not performing the erase and exiting with -EIO, correct?

What is the preferred method to erase nand?

Alice

>
> Another problem could be your command delay time. You have set it to
> 15?sec. Is that correct for your chip ? Which chip are you using ?
> Have you tried to set it to a higher value ?
>
> --
> Thomas
> ____________________________________________________
> linutronix - competence in embedded & realtime linux
> http://www.linutronix.de
> mail: tglx at linutronix.de
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From startec at ms11.hinet.net  Wed Aug  7 22:47:49 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Thu, 8 Aug 2002 10:47:49 +0800
Subject: NAND Configuration
In-Reply-To: <1028717345.19447.249.camel@thomas.tec.linutronix.de>
Message-ID: <001101c23e85$fcbad3b0$5501a8c0@synso.com.tw>

> > > > JFFS2 on NOR type flash does not use buffering, OOB 
> check and bad
> > > > block management, but it can be used now. I meant that 
> > > > CONFIG_JFFS2_FS_NAND is not defined, maybe the driver still 
> > > can work,
> > > > but it is not good as the original one.
> > > 
> > > JFFS2 cannot work on NAND flash without the extra code enabled by
> > > CONFIG_JFFS2_FS_NAND. You need to batch writes into 
> > > page-sized chunks and 
> > > use ECC. It looks like you have enabled CONFIG_JFFS2_FS_NAND 
> > > in the log you 
> > > show -- is that correct?
> > > 
> > 
> > Yes, I enable CONFIG_JFFS2_FS_NAND. I follow 
> > http://www.linux-mtd.infradead.org/tech/nand.html to config the 
> > settings. Can I do not care ECC on NAND flash?
> > 
> ECC _HAS_ to be enabled !
> 
> Have you ever erased your flash with erase /dev/mtdX ?
> This may have caused the problem, because erase is not aware 
> of bad block handling and may have erased a block, which was 
> marked as bad already and erased the bad block marker too. So 
> if you write to this block, you get a write failure and 
> therefor a read failure afterwards. 
> I will change nand.c, so that bad blocks cannot be erased anymore.
> 
> Another problem could be your command delay time. You have 
> set it to 15?sec. Is that correct for your chip ? Which chip 
> are you using ? Have you tried to set it to a higher value ? 
> 

Yes, I use eraseall /dev/mtd1 to erase the partition. But I check the
page that causes the problem, it is fine to read/write all the page.

I use Samsung K9F6408 and I try to set the delay time to 20?sec and it
can not solve the problem.

Could I use the content of the page that the error occures to trace the
problem? Can it help to solve the problem? Thanks.


Steve Tsai




From kevin at gv.com.tw  Thu Aug  8 00:37:26 2002
From: kevin at gv.com.tw (??)
Date: Thu, 8 Aug 2002 12:37:26 +0800
Subject: will jffs2 write to device when doing "read-only" operation like "ls"?
Message-ID: <000d01c23e95$4c679060$1b0448c0@gv.com.tw>

dear all,

will jffs2 write to device when doing "read-only" operation like "ls"?

for example, if you do a "ls -lR" then a fs like ext2/minix will write stuff
to block device
(because of put_inode operation),thus might reduce life of nand flash.......

if the answer is yes, is it possible to impore/modify it?

thanks in advanced!:)





From acurtis at onz.com  Thu Aug  8 00:46:49 2002
From: acurtis at onz.com (Allen Curtis)
Date: Wed, 7 Aug 2002 21:46:49 -0700
Subject: will jffs2 write to device when doing "read-only" operation like "ls"?
In-Reply-To: <000d01c23e95$4c679060$1b0448c0@gv.com.tw>
Message-ID: <NCBBIINEHIPFGJPLBEIFMEIDDKAA.acurtis@onz.com>

> will jffs2 write to device when doing "read-only" operation like "ls"?

To my knowledge NO. JFFS and JFFS2 work just fine with read-only devices so
I assume that writing for no reason is not necessary.




From startec at ms11.hinet.net  Thu Aug  8 01:23:38 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Thu, 8 Aug 2002 13:23:38 +0800
Subject: NAND Configuration
In-Reply-To: <1028717345.19447.249.camel@thomas.tec.linutronix.de>
Message-ID: <001201c23e9b$c188b490$5501a8c0@synso.com.tw>

Thomas,
The following are the content of the page writing error. All the tests
have the similar data in the page and the area have the data already
always start with 0x1985  and  there are empty data next to the area.
Does it mean that the area was written before?

Steve TSai

 85  19  01  e0  2b  00  00  00  e6  6e  26  7d  02  00  00  00
 27  00  00  00  00  00  00  00  48  01  00  00  03  00  e3  01
 3f  18  e6  6c  5f  cb  19  04  61  72  70  ff  85  19  04  20
<------ start with 85 19
 d4  01  00  00  48  7b  39  1b  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff
 ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff  ff





From kevin at gv.com.tw  Thu Aug  8 01:25:26 2002
From: kevin at gv.com.tw (=?big5?B?pHCp+g==?=)
Date: Thu, 8 Aug 2002 13:25:26 +0800
Subject: [jffs2]is the free space reported by "df" a  real one or enlarged one?
Message-ID: <007b01c23e9c$0107bda0$1b0448c0@gv.com.tw>

dear all,

is the free space reported by "df" a  real one(i.e. total "free" page in
flash)
 or enlarged one?

(i'm using jffs2)

thanks in advanced!:)





From joakim.tjernlund at lumentis.se  Thu Aug  8 03:08:59 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Thu, 8 Aug 2002 09:08:59 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <00512BA4F9D3D311912A009027E9B8F407E477@NT>
Message-ID: <IGEFJKJNHJDCBKALBJLLMEJEFFAA.joakim.tjernlund@lumentis.se>

> David Woodhouse said:
> > DGE at sixnetio.com said:
> > > The cfi_udelay() call is part of the problem, since it lets other 
> > > processes run, and the one that runs is the erasing process, but it 
> > > can't do anything except slow things down since the flash  is busy 
> > > writing.
> > 
> > The erasing process should be sitting in TASK_UNINTERRUPTIBLE and on the 
> > chip's wait queue, waiting to be woken when the chip becomes available.
> Why 
> > is it running?
> 
> It is running because of the
>         wake_up(&chip->wq);
> at the end of do_write_oneword(). So it wakes up for every word written.
> 
> With the old code (cfi_cmdset_0002.c 1.56 and before) the next chance it 
> gets to run is when cfi_udelay() is called during the next 
> do_write_oneword(). Unfortunately, it can't start erasing because 
> chip->state is FL_WRITING, so it puts itself back on the wait queue. The
> wake_up() at the end of do_write_oneword() wakes it up again, but it
> doesn't run until the cfi_delay() in the _next_ call to do_write_oneword().
> So it runs and puts itself back on the wait queue for every call to 
> do_write_oneword(). Eventually all the words are written, it wakes up to 
> find FL_READY and starts the erase. Without the one jiffie delay in 
> cfi_delay() each time it wouldn't have been as bad, but erase going off 
> and back on the wait queue several thousand times still doesn't seem right.

You can move the wake_up() call up one step(xxxx_write_words()) and call it just before 
you leave that function. I tried that and it's a improvement(note, I using buffer writes, so
word writes should see an even better improvement), but that will also
hold reads back(not that I noticed anything) until xxx_write_words has completed. 
We can fix that by having separate wait queues for read and erase.

   Jocke




From dwmw2 at infradead.org  Thu Aug  8 03:17:46 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 08:17:46 +0100
Subject: will jffs2 write to device when doing "read-only" operation like "ls"? 
In-Reply-To: <000d01c23e95$4c679060$1b0448c0@gv.com.tw> 
References: <000d01c23e95$4c679060$1b0448c0@gv.com.tw> 
Message-ID: <27538.1028791066@redhat.com>


kevin at gv.com.tw said:
> will jffs2 write to device when doing "read-only" operation like "ls"?
> for example, if you do a "ls -lR" then a fs like ext2/minix will write
> stuff to block device (because of put_inode operation),thus might
> reduce life of nand flash....... 

Normal file systems write because they have to update the 'atime' (access 
time) field whenever an inode is read. Very few applications actually care 
about a correct atime, and JFFS2 does not implement atime.

--
dwmw2





From joakim.tjernlund at lumentis.se  Thu Aug  8 03:23:49 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Thu, 8 Aug 2002 09:23:49 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <31147.1028713904@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLIEJFFFAA.joakim.tjernlund@lumentis.se>

> 
> joakim.tjernlund at lumentis.se said:
> >  Can the JFFS2 layer also use spin_lock() instead of spin_lock_bh()?
> > Shold we try not to disable bottom-halves or does it not matter?
> 
> Well, the MTD API documentation (in my head) says that the erase completion 
> callback may be called in bottom-half context (i.e. from a timer), which is 
> why JFFS2 uses spin_lock_bh().

I noticed that erase_callback() in erase.c useses spin_lock(), not spin_lock_bh().
Should it?
 
> 
> I suppose we could change that.

I dont understand what using a timer would give us. I suppose that one could have
more the one erase simontainously(one per bank) but that won't give a significant
improvement and erase.c must be made "bank aware" as well. 

Unless there is some other advantage, I think you should change the spec.

 Jocke

> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 




From frank.oltmanns.ml at gmx.de  Thu Aug  8 03:38:52 2002
From: frank.oltmanns.ml at gmx.de (Frank Oltmanns)
Date: Thu, 8 Aug 2002 09:38:52 +0200 (MEST)
Subject: problem at boot from doc2000-with grub
References: <871203.1028710084678.JavaMail.postfix@mailsrv1.mail.sohu.com>
Message-ID: <15719.1028792332@www19.gmx.net>

Did you try "eraseall /dev/mtd0"? I don't know too much about DiskOnChip,
but I think this should work!? But this would also erase your
bad-block-table,
so use with care.

  Frank

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net




From dwmw2 at infradead.org  Thu Aug  8 04:02:51 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 09:02:51 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLIEJFFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLIEJFFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <28015.1028793771@redhat.com>

joakim.tjernlund at lumentis.se said:
>  I noticed that erase_callback() in erase.c useses spin_lock(), not
> spin_lock_bh(). Should it?

It expects to actually be called in bottom-half context, and if it isn't 
then nothing else will be. So it's fine to use spin_lock() there.

>  I dont understand what using a timer would give us. I suppose that
> one could have more the one erase simontainously(one per bank) but
> that won't give a significant improvement and erase.c must be made
> "bank aware" as well. 

> Unless there is some other advantage, I think you should change the
> spec.

Using a timer to check for erase completion means that the process which 
submitted the erase doesn't have to be blocked waiting for it. The callback 
can happen some time later. In the case of JFFS2, it's kupdated that ends 
up stuck in the erase routine for ages.

But using a timer to actually do the check doesn't mean we have to call the 
completion callback in timer context -- we could use schedule_task() to run 
it in process context.

--
dwmw2





From dwmw2 at infradead.org  Thu Aug  8 04:08:42 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 09:08:42 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLMEJEFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLMEJEFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <28529.1028794122@redhat.com>

joakim.tjernlund at lumentis.se said:
>  You can move the wake_up() call up one step(xxxx_write_words()) and
> call it just before  you leave that function. I tried that and it's a
> improvement(note, I using buffer writes, so word writes should see an
> even better improvement), but that will also hold reads back(not that
> I noticed anything) until xxx_write_words has completed.  We can fix
> that by having separate wait queues for read and erase. 

Aren't reads held back anyway for the same reason that erases are -- by the 
time we actually schedule after waking them, the chip is in FL_WRITING 
again?

What happens if you stick a cond_resched() immediately after the wake_up() 
(ok, after the spin_unlock).?

--
dwmw2





From joakim.tjernlund at lumentis.se  Thu Aug  8 04:32:40 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Thu, 8 Aug 2002 10:32:40 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <28015.1028793771@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLMEJGFFAA.joakim.tjernlund@lumentis.se>

> 
> joakim.tjernlund at lumentis.se said:
> >  I noticed that erase_callback() in erase.c useses spin_lock(), not
> > spin_lock_bh(). Should it?
> 
> It expects to actually be called in bottom-half context, and if it isn't 
> then nothing else will be. So it's fine to use spin_lock() there.
OK.
> 
> >  I dont understand what using a timer would give us. I suppose that
> > one could have more the one erase simontainously(one per bank) but
> > that won't give a significant improvement and erase.c must be made
> > "bank aware" as well. 
> 
> > Unless there is some other advantage, I think you should change the
> > spec.
> 
> Using a timer to check for erase completion means that the process which 
> submitted the erase doesn't have to be blocked waiting for it. The callback 
> can happen some time later. In the case of JFFS2, it's kupdated that ends 
> up stuck in the erase routine for ages.

Maybe erasing should be moved away from kupdate then, to the gc thread or a new
erase thread that does not mind beeing blocked?
> 
> But using a timer to actually do the check doesn't mean we have to call the 
> completion callback in timer context -- we could use schedule_task() to run 
> it in process context.

OK, so if schedule_task() is used instead its possible to replace spin_lock_bh
with spin_lock everywhere?

I think we should change erase.c to do atmost 3 erase & mark in one go.
That will free up space more quickly when there is a lot of pending erases.

 Jocke
> 
> --
> dwmw2
> 
> 
> 




From nurpinar at basari.net.tr  Thu Aug  8 04:33:32 2002
From: nurpinar at basari.net.tr (nur)
Date: Thu, 8 Aug 2002 11:33:32 +0300
Subject: kernel 2.2.18
Message-ID: <001301c23eb6$4a184630$3064000a@nurpinar>

I receive this error every time i compile kernel with doc2000 or doc 2001
support
I do something wrong?
Thanks


cc -D__KERNEL__ -I/usr/src/rtlinux_kernel_2.2.18-rtl/include -Wall -Wstrict-
prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength
-reduce
-m486 -DCPU=486 -DMODULE   -c -o doc2000.o doc2000.c
doc2000.c: In function `init_doc2000':
doc2000.c:1090: warning: implicit declaration of function
`inter_module_register'
doc2000.c: At top level:
doc2000.c:1094: parse error before `cleanup_doc2000'
doc2000.c:1095: warning: return-type defaults to `int'
doc2000.c: In function `cleanup_doc2000':
doc2000.c:1109: warning: implicit declaration of function
`inter_module_unregister'
doc2000.c:1110: warning: control reaches end of non-void function
doc2000.c: In function `__cleanup_module_inline':
doc2000.c:1112: warning: return from incompatible pointer type
make[2]: *** [doc2000.o] Error 1
make[2]: Leaving directory `/usr/src/rtlinux_kernel_2.2.18-rtl/drivers/mtd'
make[1]: *** [_modsubdir_mtd] Error 2
make[1]: Leaving directory `/usr/src/rtlinux_kernel_2.2.18-rtl/drivers'
make: *** [_mod_drivers] Error 2






From dwmw2 at infradead.org  Thu Aug  8 04:36:56 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 09:36:56 +0100
Subject: kernel 2.2.18 
In-Reply-To: <001301c23eb6$4a184630$3064000a@nurpinar> 
References: <001301c23eb6$4a184630$3064000a@nurpinar> 
Message-ID: <31396.1028795816@redhat.com>

nurpinar at basari.net.tr said:
> I receive this error every time i compile kernel with doc2000 or doc
> 2001 support I do something wrong?

Look for the inter_module patch in the patches/ directory of CVS.

--
dwmw2





From dwmw2 at infradead.org  Thu Aug  8 04:37:28 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 09:37:28 +0100
Subject: JFFS2 peoblems with K3 strata flash on Dalhart 
In-Reply-To: <957BD1C2BF3CD411B6C500A0C944CA2601499C38@pdsmsx32.pd.intel.com> 
References: <957BD1C2BF3CD411B6C500A0C944CA2601499C38@pdsmsx32.pd.intel.com> 
Message-ID: <31433.1028795848@redhat.com>

cain.yuan at intel.com said:
>  First bootup will success without any error message. but when I reset
> the board and boot it again, many errors occurs. 

The error is -EROFS. Your chip might need unlocking each time it's reset. At 
least one map driver does this automatically at startup.

The reason the error isn't being reported properly is because I'm 
stupid...

--- writev.c	20 May 2002 14:56:39 -0000	1.2
+++ writev.c	8 Aug 2002 08:35:21 -0000	1.3
@@ -7,7 +7,7 @@
  *
  * For licensing information, see the file 'LICENCE' in this directory.
  *
- * $Id: writev.c,v 1.2 2002/05/20 14:56:39 dwmw2 Exp $
+ * $Id: writev.c,v 1.3 2002/08/08 08:35:21 dwmw2 Exp $
  *
  */
 
@@ -28,7 +28,7 @@ static inline int mtd_fake_writev(struct
 	for (i=0; i<count; i++) {
 		if (!vecs[i].iov_len)
 			continue;
-		mtd->write(mtd, to, vecs[i].iov_len, &thislen, vecs[i].iov_base);
+		ret = mtd->write(mtd, to, vecs[i].iov_len, &thislen, vecs[i].iov_base);
 		totlen += thislen;
 		if (ret || thislen != vecs[i].iov_len)
 			break;


--
dwmw2





From dwmw2 at infradead.org  Thu Aug  8 04:40:29 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 09:40:29 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLMEJGFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLMEJGFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <31741.1028796029@redhat.com>

joakim.tjernlund at lumentis.se said:
> Maybe erasing should be moved away from kupdate then, to the gc thread
> or a new erase thread that does not mind beeing blocked?

Maybe. I want to keep the GC thread optional though. I think it's 
sufficient just to fix the chip drivers to really do asynchronous erases, 
so the thread calling ->erase() doesn't actually have to block. Then we can 
leave it in kupdate.

>  OK, so if schedule_task() is used instead its possible to replace
> spin_lock_bh with spin_lock everywhere?

Yes.

> I think we should change erase.c to do atmost 3 erase & mark in one
> go. That will free up space more quickly when there is a lot of
> pending erases. 

Seems reasonable.

--
dwmw2





From nurpinar at basari.net.tr  Thu Aug  8 04:54:20 2002
From: nurpinar at basari.net.tr (nur)
Date: Thu, 8 Aug 2002 11:54:20 +0300
Subject: kernel 2.2.18 
References: <001301c23eb6$4a184630$3064000a@nurpinar>  <31396.1028795816@redhat.com>
Message-ID: <000b01c23eb9$36058b00$3064000a@nurpinar>

Is there an inter-module patch for 2.2.18 kernel?
I found one in mtd directory but it is inter-module-2.2.17.patch


----- Original Message ----- 
From: "David Woodhouse" <dwmw2 at infradead.org>
To: "nur" <nurpinar at basari.net.tr>
Cc: <linux-mtd at lists.infradead.org>
Sent: Thursday, August 08, 2002 11:36 AM
Subject: Re: kernel 2.2.18 


> 
> nurpinar at basari.net.tr said:
> > I receive this error every time i compile kernel with doc2000 or doc
> > 2001 support I do something wrong?
> 
> Look for the inter_module patch in the patches/ directory of CVS.
> 
> --
> dwmw2
> 
> 
> 





From dwmw2 at infradead.org  Thu Aug  8 04:56:06 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 09:56:06 +0100
Subject: kernel 2.2.18 
In-Reply-To: <000b01c23eb9$36058b00$3064000a@nurpinar> 
References: <000b01c23eb9$36058b00$3064000a@nurpinar>  <001301c23eb6$4a184630$3064000a@nurpinar> <31396.1028795816@redhat.com> 
Message-ID: <927.1028796966@redhat.com>

nurpinar at basari.net.tr said:
> Is there an inter-module patch for 2.2.18 kernel? I found one in mtd
> directory but it is inter-module-2.2.17.patch

Should still work fine.

--
dwmw2





From tglx at linutronix.de  Thu Aug  8 04:59:23 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 08 Aug 2002 10:59:23 +0200
Subject: NAND Configuration
In-Reply-To: <3D518D06.B809B67@mvista.com>
References: <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw>
 <1028717345.19447.249.camel@thomas.tec.linutronix.de>
 <3D518D06.B809B67@mvista.com>
Message-ID: <1028797164.9592.2.camel@thomas.tec.linutronix.de>

On Wed, 2002-08-07 at 23:11, Alice Hennessy wrote:
> > Have you ever erased your flash with erase /dev/mtdX ?
> > This may have caused the problem, because erase is not aware of bad
> > block handling and may have erased a block, which was marked as bad
> > already and erased the bad block marker too. So if you write to this
> > block, you get a write failure and therefor a read failure afterwards.
> > I will change nand.c, so that bad blocks cannot be erased anymore.
> >
> 
> >From looking at nand_erase(), it appears that the attempted erase of a bad
> block would
> result in not performing the erase and exiting with -EIO, correct?
> 
> What is the preferred method to erase nand?
> 
> Alice

With actual code in CVS you can use erase(all) /dev/mtdX. I modified it,
that attempts to erase bad block's are rejeceted in any case. The
previous version let you erase bad blocks, if CONFIG_NAND_ECC_JFFS2 was
not set. But now it's forced by default.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From tglx at linutronix.de  Thu Aug  8 05:11:33 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 08 Aug 2002 11:11:33 +0200
Subject: NAND Configuration
In-Reply-To: <001201c23e9b$c188b490$5501a8c0@synso.com.tw>
References: <001201c23e9b$c188b490$5501a8c0@synso.com.tw>
Message-ID: <1028797894.9586.8.camel@thomas.tec.linutronix.de>

On Thu, 2002-08-08 at 07:23, Steve Tsai wrote:
> Thomas,
> The following are the content of the page writing error. All the tests
> have the similar data in the page and the area have the data already
> always start with 0x1985  and  there are empty data next to the area.
> Does it mean that the area was written before?
Yep.

Can you please do the following ?

Update to latest CVS code.
Erase the partition, you can use erase(all) /dev/mtdX
echo 9 >/proc/sys/kernel/printk
Start log
mount
do your mkdir, cp ...

if this happens again, please send a dump of the concerned page and the
logfile 

Thanks

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Thu Aug  8 05:14:02 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 10:14:02 +0100
Subject: NAND Configuration 
In-Reply-To: <3D518D06.B809B67@mvista.com> 
References: <3D518D06.B809B67@mvista.com>  <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw> <1028717345.19447.249.camel@thomas.tec.linutronix.de> 
Message-ID: <2777.1028798042@redhat.com>

ahennessy at mvista.com said:
>  From looking at nand_erase(), it appears that the attempted erase of
> a bad block would result in not performing the erase and exiting with
> -EIO, correct?

> What is the preferred method to erase nand? 

As I understand it, the preferred method to erase factory-marked bad blocks
is not at all.

--
dwmw2





From joakim.tjernlund at lumentis.se  Thu Aug  8 05:15:05 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Thu, 8 Aug 2002 11:15:05 +0200
Subject: Disk blocks for long periods 
In-Reply-To: <28529.1028794122@redhat.com>
Message-ID: <IGEFJKJNHJDCBKALBJLLKEJIFFAA.joakim.tjernlund@lumentis.se>

> 
> joakim.tjernlund at lumentis.se said:
> >  You can move the wake_up() call up one step(xxxx_write_words()) and
> > call it just before  you leave that function. I tried that and it's a
> > improvement(note, I using buffer writes, so word writes should see an
> > even better improvement), but that will also hold reads back(not that
> > I noticed anything) until xxx_write_words has completed.  We can fix
> > that by having separate wait queues for read and erase. 
> 
> Aren't reads held back anyway for the same reason that erases are -- by the 
> time we actually schedule after waking them, the chip is in FL_WRITING 
> again?

Yes, that why you need 2 queues. Then you do wake_up()&cond_resched(). 
The read queue get woken after every word/buffer write and
the erase queue after the whole read/write has completed.

> 
> What happens if you stick a cond_resched() immediately after the wake_up() 
> (ok, after the spin_unlock).?

I had that before I moved wake_up one step. My copy test was improved
with almost 1 sec(from ~10 to ~9) when the wake_up()&cond_resched() was one step up.

 Jocke
> 
> --
> dwmw2
> 
> 
> 




From dwmw2 at infradead.org  Thu Aug  8 05:18:39 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 10:18:39 +0100
Subject: Disk blocks for long periods 
In-Reply-To: <IGEFJKJNHJDCBKALBJLLKEJIFFAA.joakim.tjernlund@lumentis.se> 
References: <IGEFJKJNHJDCBKALBJLLKEJIFFAA.joakim.tjernlund@lumentis.se> 
Message-ID: <3192.1028798319@redhat.com>

joakim.tjernlund at lumentis.se said:
>  Yes, that why you need 2 queues. Then you do wake_up()&cond_resched().
>   The read queue get woken after every word/buffer write and the erase
> queue after the whole read/write has completed. 

OK, right. That makes sense.

--
dwmw2





From tglx at linutronix.de  Thu Aug  8 05:28:30 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 08 Aug 2002 11:28:30 +0200
Subject: NAND Configuration
In-Reply-To: <2777.1028798042@redhat.com>
References: <3D518D06.B809B67@mvista.com>
 <002f01c23dfb$dea583f0$5501a8c0@synso.com.tw>
 <1028717345.19447.249.camel@thomas.tec.linutronix.de>
 <2777.1028798042@redhat.com>
Message-ID: <1028798911.9592.11.camel@thomas.tec.linutronix.de>

On Thu, 2002-08-08 at 11:14, David Woodhouse wrote:
> 
> ahennessy at mvista.com said:
> >  From looking at nand_erase(), it appears that the attempted erase of
> > a bad block would result in not performing the erase and exiting with
> > -EIO, correct?
> 
> > What is the preferred method to erase nand? 
> 
> As I understand it, the preferred method to erase factory-marked bad blocks
> is not at all.
nand.c takes care of factory-marked blocks now, wether CONFIG_NAND_ECC_JFFS2 is set of not.
So you can use erase(all) and bad blockes are skipped.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From startec at ms11.hinet.net  Thu Aug  8 05:37:40 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Thu, 8 Aug 2002 17:37:40 +0800
Subject: NAND Configuration
In-Reply-To: <1028797894.9586.8.camel@thomas.tec.linutronix.de>
Message-ID: <002c01c23ebf$40a81c70$5501a8c0@synso.com.tw>

Maybe I found the problem here. I find jffs2 will write to the page that
was used. The proble is that jffs2_wbuf_process make
jffs2_do_reserve_space caculate wrong ofs.

In jffs2_wbuf_process, when free_size is smaller than (c->wbuf_pagesize
- c->wbuf_len), jffs2_flush_wbuf(c, 1) was called, but free_size will
not be assigned right value. In the case, the block can not be used
anymore because the last page in the block was used here, but
jffs2_do_reserve_space does not know. 
jffs2_do_reserve_space will use the block, if minsize > jeb->free_size
and it maybe happen here. 



jffs2_wbuf_process
==============
if(!c->nextblock || (c->nextblock->free_size < (c->wbuf_pagesize -
c->wbuf_len)))
	jffs2_flush_wbuf(c, 1); /* pad only */   <========== should take
care free_size here
else			
	jffs2_flush_wbuf(c, 2); /* pad and adjust nextblock */



static int jffs2_do_reserve_space(struct jffs2_sb_info *c,  uint32_t
minsize, uint32_t *ofs, uint32_t *len)
{
	struct jffs2_eraseblock *jeb = c->nextblock;
	
 restart:
	if (jeb && minsize > jeb->free_size) {          <====== if
minisize > free_size, the block will be used
		/* Skip the end of this block and file it as having some
dirty space */
		/* If there's a pending write to it, flush now */
		if (c->wbuf_len) {


I add the following codes and I am still testing it. 

		if(!c->nextblock || (c->nextblock->free_size <
(c->wbuf_pagesize - c->wbuf_len))){
			jffs2_flush_wbuf(c, 1); /* pad only */
			c->dirty_size += c->nextblock->free_size;
			c->free_size  -= c->nextblock->free_size;
			c->nextblock->dirty_size +=
c->nextblock->free_size;
			c->nextblock->free_size = 0;
		}	
		else			
			jffs2_flush_wbuf(c, 2); /* pad and adjust
nextblock */


Steve Tsai



> 
> Can you please do the following ?
> 
> Update to latest CVS code.
> Erase the partition, you can use erase(all) /dev/mtdX
> echo 9 >/proc/sys/kernel/printk
> Start log
> mount
> do your mkdir, cp ...
> 
> if this happens again, please send a dump of the concerned 
> page and the logfile 
> 




From dwmw2 at infradead.org  Thu Aug  8 07:05:45 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 08 Aug 2002 12:05:45 +0100
Subject: NAND Configuration 
In-Reply-To: <002c01c23ebf$40a81c70$5501a8c0@synso.com.tw> 
References: <002c01c23ebf$40a81c70$5501a8c0@synso.com.tw> 
Message-ID: <12213.1028804745@redhat.com>

startec at ms11.hinet.net said:
>  In jffs2_wbuf_process, when free_size is smaller than (c->
> wbuf_pagesize - c->wbuf_len), jffs2_flush_wbuf(c, 1) was called, but
> free_size will not be assigned right value. In the case, the block can
> not be used anymore because the last page in the block was used here,
> but jffs2_do_reserve_space does not know.  jffs2_do_reserve_space will
> use the block, if minsize > jeb->free_size and it maybe happen here.  

Try this (it's in CVS).... 

Index: wbuf.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/wbuf.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- wbuf.c	20 May 2002 14:56:39 -0000	1.12
+++ wbuf.c	8 Aug 2002 11:04:40 -0000	1.13
@@ -7,7 +7,7 @@
  *
  * For licensing information, see the file 'LICENCE' in this directory.
  *
- * $Id: wbuf.c,v 1.12 2002/05/20 14:56:39 dwmw2 Exp $
+ * $Id: wbuf.c,v 1.13 2002/08/08 11:04:40 dwmw2 Exp $
  *
  */
 
@@ -80,17 +80,33 @@ void jffs2_wbuf_process (void *data)
 	
 	D1(printk(KERN_DEBUG "jffs2_wbuf_process() entered\n"));
 
-	if (!down_trylock(&c->alloc_sem)) {
-		D1(printk (KERN_DEBUG "jffs2_wbuf_process() alloc_sem got\n"));
-	
-		if(!c->nextblock || (c->nextblock->free_size < (c->wbuf_pagesize - c->wbuf_len)))
-			jffs2_flush_wbuf(c, 1); /* pad only */
-		else			
-			jffs2_flush_wbuf(c, 2); /* pad and adjust nextblock */
-		up(&c->alloc_sem);
-	} else {
+	if (down_trylock(&c->alloc_sem)) {
+		/* If someone else has the alloc_sem, they're about to
+		   write anyway. So no need to waste space by
+		   padding */
 		D1(printk (KERN_DEBUG "jffs2_wbuf_process() alloc_sem already occupied\n"));
+		return;
 	}	
+
+	D1(printk (KERN_DEBUG "jffs2_wbuf_process() alloc_sem got\n"));
+
+	if (!c->nextblock) {
+		D1(printk(KERN_DEBUG "jffs2_wbuf_process(): nextblock NULL, nothing to do\n"));
+		if (c->wbuf_len) {
+			printk(KERN_WARNING "jffs2_wbuf_process(): c->wbuf_len is 0x%03x but nextblock is NULL!\n", c->wbuf_len);
+			up(&c->alloc_sem);
+			BUG();
+		}
+		return;
+	}
+	
+	
+	/* if !c->nextblock then the tail will have got flushed from
+	   jffs2_do_reserve_space() anyway. */
+	if(c->nextblock)
+		jffs2_flush_wbuf(c, 2); /* pad and adjust nextblock */
+
+	up(&c->alloc_sem);
 }
 
 
@@ -166,8 +182,16 @@ int jffs2_flush_wbuf(struct jffs2_sb_inf
 		spin_lock_bh(&c->erase_completion_lock);
 		if (!c->nextblock)
 			BUG();
-		if (c->nextblock->free_size < (c->wbuf_pagesize - c->wbuf_len))
+		/* wbuf_pagesize - wbuf_len is the amount of space that's to be 
+		   padded. If there is less free space in the block than that,
+		   something screwed up */
+		if (c->nextblock->free_size < (c->wbuf_pagesize - c->wbuf_len)) {
+			printk(KERN_CRIT "jffs2_flush_wbuf(): Accounting error. wbuf at 0x%08x has 0x%03x bytes, 0x%03x left.\n",
+			       c->wbuf_ofs, c->wbuf_len, c->wbuf_pagesize-c->wbuf_len);
+			printk(KERN_CRIT "jffs2_flush_wbuf(): But free_size for block at 0x%08x is only 0x%08x\n",
+			       c->nextblock->offset, c->nextblock->free_size);
 			BUG();
+		}
 		c->nextblock->free_size -= (c->wbuf_pagesize - c->wbuf_len);
 		c->nextblock->dirty_size += (c->wbuf_pagesize - c->wbuf_len);
 		spin_unlock_bh(&c->erase_completion_lock);


--
dwmw2





From ilatypov at superbt.com  Thu Aug  8 12:28:08 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Thu, 8 Aug 2002 12:28:08 -0400 (EDT)
Subject: docprobe for millennium
In-Reply-To: <000701c23df1$a20ae1b0$3064000a@nurpinar>
Message-ID: <Pine.LNX.4.44.0208081226560.18509-100000@server.superbt.com>

On Wed, 7 Aug 2002, nur wrote:

> is there such a parameter for docprobe related to memory address of doc?
> dinfo results doc millennium at 0xe8000 while docprobe says no diskonchip
> found

This configuration item can be found inside the advanced DiskOnChip option 
of the kernel configuration menu.

Quoting linux-2.4.29-rc1 Documentation/Configure.help,

Physical address of DiskOnChip
CONFIG_MTD_DOCPROBE_ADDRESS
  By default, the probe for DiskOnChip devices will look for a
  DiskOnChip at every multiple of 0x2000 between 0xC8000 and 0xEE000.
  This option allows you to specify a single address at which to probe
  for the device, which is useful if you have other devices in that
  range which get upset when they are probed.

  (Note that on PowerPC, the normal probe will only check at
  0xE4000000.)

  Normally, you should leave this set to zero, to allow the probe at
  the normal addresses.


Ilguiz





From xjin at redswitch.com  Thu Aug  8 19:43:30 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Thu, 08 Aug 2002 16:43:30 -0700
Subject: MTD/JFFS2 on Intel 28F160F3
Message-ID: <3D530222.7040303@redswitch.com>

Hi *,

I'm trying to enable MTD and JFFS2 on an Intel 28F160F3 chip but have 
some problems.

The basic problem is what the physical start address of flash mapping 
is? While on PPCBoot, I got flash information using command 'flinfo'. 
The start address is FFE00000. Is this address the one used to configure 
CFI flash device in physical memeory map? I tried using this address but 
  'physmap' couldn't find flash device.

-----------------clip-----------------------------------------
root at ib8sw:~# modprobe -a physmap
physmap flash device: 100000 at ffe00000
CFI: Found no Physically mapped flash device at location zero
-----------------clip-----------------------------------------
-----------------clip-----------------------------------------
=> flinfo

Bank # 1: INTEL 28F160F3 (16 Mbit, top boot sector)
   Size: 2 MB in 39 Sectors
   Sector Start Addresses:
     FFE00000      FFE10000      FFE20000      FFE30000      FFE40000
     FFE50000      FFE60000      FFE70000      FFE80000      FFE90000
     FFEA0000      FFEB0000      FFEC0000      FFED0000      FFEE0000
     FFEF0000      FFF00000 (RO) FFF10000 (RO) FFF20000 (RO) FFF30000 (RO)
     FFF40000      FFF50000      FFF60000      FFF70000      FFF80000
     FFF90000      FFFA0000      FFFB0000      FFFC0000      FFFD0000
     FFFE0000      FFFF0000      FFFF2000      FFFF4000      FFFF6000
     FFFF8000      FFFFA000      FFFFC000      FFFFE000
=>
-----------------clip-----------------------------------------

I haven't dived into the routine 'do_cfi_probe()' yet since I'm not sure 
if the start address I specified is correct. Any help is greatly 
appreciated.

- Shawn.




From karim at opersys.com  Thu Aug  8 20:50:47 2002
From: karim at opersys.com (Karim Yaghmour)
Date: Thu, 08 Aug 2002 20:50:47 -0400
Subject: Avoiding DOC hotplug when Grub fails
Message-ID: <3D5311E7.93A4805B@opersys.com>

As far as I can see by browsing this mailing list archive, one
has to hotplug the DOC device in order to have the HD come up
first if Grub fails in some way after having hijacked int 19h.
This is rather inconvenient, to say the least.

Why not just hijack int 16h (keyboard) while we're at it, write
a small keyboard int handler, and check if the space-bar (or
some other key) is held down while Grub is booting? If it is,
then Grub invokes the BIOS's original int 19h which then proceeds
normally. If it isn't, then Grub continues with its own load
procedure.

Comments?

Karim

===================================================
                 Karim Yaghmour
               karim at opersys.com
      Embedded and Real-Time Linux Expert
===================================================



From xjin at redswitch.com  Thu Aug  8 21:18:20 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Thu, 08 Aug 2002 18:18:20 -0700
Subject: A custom board need a specific map file?
Message-ID: <3D53185C.9060100@redswitch.com>

For a custom board, is it necessary to write a specific map file like 
'rpxlite.c' and 'mbx860.c'? I'm really new to MTD stuff. I looked into 
these two files as examples and found that they are almost similar. BTW, 
what's differece between '__raw_readb()' and 'readb()'? Thanks.

- Shawn.




From mark at lakeshoremicro.com  Thu Aug  8 22:02:07 2002
From: mark at lakeshoremicro.com (Mark Meade)
Date: Thu, 8 Aug 2002 22:02:07 -0400
Subject: Avoiding DOC hotplug when Grub fails
Message-ID: <200208082158.18411.mark@lakeshoremicro.com>

Karim Yaghmour wrote:

> As far as I can see by browsing this mailing list archive, one
> has to hotplug the DOC device in order to have the HD come up
> first if Grub fails in some way after having hijacked int 19h.
> This is rather inconvenient, to say the least.

I've recently found an easier way - with the M-Sys ISA Eval card, anyway.  I 
assume the PCI card would be similar.

On the ISA card, there is a jumper used to set the DoC Address (C800, D000, 
etc).  If this jumper is removed, the DoC is no longer recognized by the 
BIOS.

If the DoC has int 19h, simply boot without the jumper in place, and then put 
it back after the hard drive boot has finished.  If you have the MTD stuff 
compiled as modules, don't do the modprobe until after the jumper is 
replaced.   Works great, plus eliminates the risky procedure of hotplugging 
the DoC or Eval card.

> Why not just hijack int 16h (keyboard) while we're at it, write
> a small keyboard int handler, and check if the space-bar (or
> some other key) is held down while Grub is booting? If it is,
> then Grub invokes the BIOS's original int 19h which then proceeds
> normally. If it isn't, then Grub continues with its own load
> procedure.

One potential problem is that the low level Grub code that grabs int 19 is 
limited to 512 bytes.  With all the other things that code has to do, there 
might not be enough room to add another int handler.

Mark



From hansolofalcon at worldnet.att.net  Thu Aug  8 22:16:19 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Thu, 8 Aug 2002 22:16:19 -0400
Subject: Avoiding DOC hotplug when Grub fails
In-Reply-To: <200208082158.18411.mark@lakeshoremicro.com>
Message-ID: <000001c23f4a$c08ea9a0$c255580c@who>

Hello from Gregg C Levine
Our correspondent mentions the M-Sys ISA Eval card. I would assume
anyway that the gizmo exists. Can someone also tell me how much this
thing would also cost? I've been attempting to track down a relatively
easy method of evaluating such hardware, and I remembered that most
providers of such hardware also make this cards. If anyone actually has
one that they do not need, plus any blank disks I'd be glad to take it
off their hands.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linux-mtd-admin at lists.infradead.org [mailto:linux-mtd-
> admin at lists.infradead.org] On Behalf Of Mark Meade
> Sent: Thursday, August 08, 2002 10:02 PM
> To: linux-mtd at lists.infradead.org
> Cc: karim at opersys.com
> Subject: Re: Avoiding DOC hotplug when Grub fails
> 
> Karim Yaghmour wrote:
> 
> > As far as I can see by browsing this mailing list archive, one
> > has to hotplug the DOC device in order to have the HD come up
> > first if Grub fails in some way after having hijacked int 19h.
> > This is rather inconvenient, to say the least.
> 
> I've recently found an easier way - with the M-Sys ISA Eval card,
anyway.  I
> assume the PCI card would be similar.
> 
> On the ISA card, there is a jumper used to set the DoC Address (C800,
D000,
> etc).  If this jumper is removed, the DoC is no longer recognized by
the
> BIOS.
> 
> If the DoC has int 19h, simply boot without the jumper in place, and
then put
> it back after the hard drive boot has finished.  If you have the MTD
stuff
> compiled as modules, don't do the modprobe until after the jumper is
> replaced.   Works great, plus eliminates the risky procedure of
hotplugging
> the DoC or Eval card.
> 
> > Why not just hijack int 16h (keyboard) while we're at it, write
> > a small keyboard int handler, and check if the space-bar (or
> > some other key) is held down while Grub is booting? If it is,
> > then Grub invokes the BIOS's original int 19h which then proceeds
> > normally. If it isn't, then Grub continues with its own load
> > procedure.
> 
> One potential problem is that the low level Grub code that grabs int
19 is
> limited to 512 bytes.  With all the other things that code has to do,
there
> might not be enough room to add another int handler.
> 
> Mark
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From karim at opersys.com  Fri Aug  9 00:01:52 2002
From: karim at opersys.com (Karim Yaghmour)
Date: Fri, 09 Aug 2002 00:01:52 -0400
Subject: Avoiding DOC hotplug when Grub fails
References: <200208082158.18411.mark@lakeshoremicro.com>
Message-ID: <3D533EB0.23ADF2A6@opersys.com>

Mark Meade wrote:
> > As far as I can see by browsing this mailing list archive, one
> > has to hotplug the DOC device in order to have the HD come up
> > first if Grub fails in some way after having hijacked int 19h.
> > This is rather inconvenient, to say the least.
> 
> I've recently found an easier way - with the M-Sys ISA Eval card, anyway.  I
> assume the PCI card would be similar.
> 
> On the ISA card, there is a jumper used to set the DoC Address (C800, D000,
> etc).  If this jumper is removed, the DoC is no longer recognized by the
> BIOS.
> 
> If the DoC has int 19h, simply boot without the jumper in place, and then put
> it back after the hard drive boot has finished.  If you have the MTD stuff
> compiled as modules, don't do the modprobe until after the jumper is
> replaced.   Works great, plus eliminates the risky procedure of hotplugging
> the DoC or Eval card.

Interesting. I hadn't thought of this. It sure beats the hotplugging
circus, but it still involves risky runtime hardware manipulation _and_
it only works if you have a jumper to set the address of the DOC, such
as with the eval board (which I am using myself).

> > Why not just hijack int 16h (keyboard) while we're at it, write
> > a small keyboard int handler, and check if the space-bar (or
> > some other key) is held down while Grub is booting? If it is,
> > then Grub invokes the BIOS's original int 19h which then proceeds
> > normally. If it isn't, then Grub continues with its own load
> > procedure.
> 
> One potential problem is that the low level Grub code that grabs int 19 is
> limited to 512 bytes.  With all the other things that code has to do, there
> might not be enough room to add another int handler.

That's a possibility. Although I'm sure some of the folks on this list
have DOS asm wizardry in some past life. There are, nevertheless, other
ways to rely on keyboard input to influence Grub's behavior without
implementing a complete int 9 handler (I made a mistake in my previous
mail, int 16h is the BIOS's service routine for keyboard ops while
int 9 is the actual interrupt handler for the keyboard). Here are two 
I can think of:

1) The BIOS keeps all keyboard input in a buffer starting at 0040:001E
and measuring 16 words (2 bytes per word). This is a circular buffer
and appropriate head and tail pointers are located at 0040:001A and
0040:001C. We don't need those pointers, however. By keeping the
space-bar down, this buffer will fill with space-bar characters. When
Grub's int 19 handler starts executing, it would scan the content of
the keyboard buffer and check whether one of the character is the
space-bar. If it is, then continue with the default BIOS int 19h.

2) The BIOS provides keyboard services through int 16h. Function 02h
of this interrupt handler returns a bit field in AL which has a "1"
set in the appropriate position if one of these keys is active:
right shift, left shift, ctrll, alt, scroll lock, num lock, caps lock,
and insert. Grub's int 19 need only call on this function, do the
appropriate test, and jump to an alternate path in case, say, "ctrl"
is held down.

Both of these should be very short and trivial in assembly (the second
one should be 5 instructions more: 1 to store the old handler before
overwritting it with Grub's handler, 1 to fill AH with 02h, 1 to call
int 16h, 1 to test the appropriate bit, and one to jump to the old
handler according to the test result). Unfortunately, my DOS/BIOS/real-
mode asm past life is very far away. My hope is that someone on this
list has this experience a little bit closer to memory than I.
Otherwise I'll have to go looking for my old spell books in the attic ...

Karim

===================================================
                 Karim Yaghmour
               karim at opersys.com
      Embedded and Real-Time Linux Expert
===================================================



From startec at ms11.hinet.net  Fri Aug  9 02:53:17 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Fri, 9 Aug 2002 14:53:17 +0800
Subject: NAND Configuration 
In-Reply-To: <12213.1028804745@redhat.com>
Message-ID: <000901c23f71$7115bea0$5501a8c0@synso.com.tw>

The patch can work on my system. Thanks. 

I got another problem in mounting  JFFS2 file system.  When I write a
JFFS2 image into the NAND partition, I can mount it on /mnt. If I write
a JFFS2 image into the NAND partition and reboot system to use it as the
root file system, there are some CRC errors occur. When the system
mounts the root file system, it will start to access files also. Does
the kernel access file on jffs2 file system too early?

Steve Tsai


> 
> Try this (it's in CVS).... 
> 
> Index: wbuf.c 
> ===================================================================
> RCS file: /home/cvs/mtd/fs/jffs2/wbuf.c,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -p -r1.12 -r1.13




From tglx at linutronix.de  Fri Aug  9 04:09:41 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 09 Aug 2002 10:09:41 +0200
Subject: NAND Configuration
In-Reply-To: <000901c23f71$7115bea0$5501a8c0@synso.com.tw>
References: <000901c23f71$7115bea0$5501a8c0@synso.com.tw>
Message-ID: <1028880582.9673.28.camel@thomas.tec.linutronix.de>

On Fri, 2002-08-09 at 08:53, Steve Tsai wrote:
> The patch can work on my system. Thanks. 
> 
> I got another problem in mounting  JFFS2 file system.  When I write a
> JFFS2 image into the NAND partition, I can mount it on /mnt. If I write
> a JFFS2 image into the NAND partition and reboot system to use it as the
> root file system, there are some CRC errors occur. When the system
> mounts the root file system, it will start to access files also. Does
> the kernel access file on jffs2 file system too early?
No, also the kernel has to wait until the filesystem is mounted
complete. The kernel reads files, which you probably do not access, when
you mount it manually on /mnt. Try to copy all your files from /mnt to
anywhere and check, if the same errors occure. 


-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From nurpinar at e-kolay.net  Fri Aug  9 06:50:55 2002
From: nurpinar at e-kolay.net (nur)
Date: Fri, 9 Aug 2002 13:50:55 +0300
Subject: Am I subscribed to the list?
Message-ID: <00ac01c23f92$a38431c0$3064000a@nurpinar>

I didn't receive any email of mine

Is it dangerous to create 2 partitions on doc millennium as msdos and minix
for example
My diskonchip is not accessible in any way any more !






From rabeeh at galileo.co.il  Fri Aug  9 11:01:27 2002
From: rabeeh at galileo.co.il (Rabeeh Khoury)
Date: Fri, 09 Aug 2002 18:01:27 +0300
Subject: MTD/JFFS2 on Intel 28F160F3
References: <3D530222.7040303@redswitch.com>
Message-ID: <3D53D947.7040309@galileo.co.il>

>
> The basic problem is what the physical start address of flash mapping
> is? While on PPCBoot, I got flash information using command 'flinfo'.
> The start address is FFE00000. Is this address the one used to configure
> CFI flash device in physical memeory map? I tried using this address but
>  'physmap' couldn't find flash device.

It is not a must that the address mapping in PPCBoot is the same as in 
the kernel.

What board are you using ?




From startec at ms11.hinet.net  Sat Aug 10 03:54:59 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Sat, 10 Aug 2002 15:54:59 +0800
Subject: NAND Configuration
In-Reply-To: <1028880582.9673.28.camel@thomas.tec.linutronix.de>
Message-ID: <000a01c24043$3a331d10$80d1a8c0@synso.com.tw>

That's the fault of our board. We can not adujst a proper chip_delay, so
we add a circuit to check the ready bit and it does not have these
errors so far. Do you think chip_delay can be used with NAND flash? I
don't think it is good idea to use chip_delay.

Steve Tsai

> > I got another problem in mounting  JFFS2 file system.  When 
> I write a 
> > JFFS2 image into the NAND partition, I can mount it on /mnt. If I 
> > write a JFFS2 image into the NAND partition and reboot 
> system to use 
> > it as the root file system, there are some CRC errors 
> occur. When the 
> > system mounts the root file system, it will start to access files 
> > also. Does the kernel access file on jffs2 file system too early?
> No, also the kernel has to wait until the filesystem is 
> mounted complete. The kernel reads files, which you probably 
> do not access, when you mount it manually on /mnt. Try to 
> copy all your files from /mnt to anywhere and check, if the 
> same errors occure. 
> 




From tglx at linutronix.de  Sat Aug 10 04:41:14 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 10 Aug 2002 10:41:14 +0200
Subject: NAND Configuration
In-Reply-To: <000a01c24043$3a331d10$80d1a8c0@synso.com.tw>
References: <000a01c24043$3a331d10$80d1a8c0@synso.com.tw>
Message-ID: <1028968874.9586.69.camel@thomas.tec.linutronix.de>

On Sat, 2002-08-10 at 09:54, Steve Tsai wrote:
> That's the fault of our board. We can not adujst a proper chip_delay, so
> we add a circuit to check the ready bit and it does not have these
> errors so far. Do you think chip_delay can be used with NAND flash? I
> don't think it is good idea to use chip_delay.
> 
I'm pretty sure, that chip_delay is working. 

Cite from data sheet:
'..Page Read... by writing 00h to the command register along with three
address cycles. ...
The 528 bytes of data within the selected page are transferred to the
data registers in _LESS_ than 10us(tR). The system controller _CAN_
detect the completion of this data transfer(tR) by analyzing the output
of R/B pin. Once the data in a page is loaded into the registers, they
may be read out by sequential RE pulse of 70ns/50n(K9F2808Q0B:70ns,
K9F2808U0B:50ns) period cycle. High to low transitions of the RE clock
take out the data from the selected column address up to the last column
address. '

As tR is defined as a max value of x ms, it's safe to use it. I tested
this, when we started the work on JFFS2/NAND. I could verify with the
scope, that R/B high transition was always within the specified time. 

For program and erase we use a different scheme. If we have no access to
the R/B pin, we read back the Status Register. Bit 6 is a mirror of R/B
pin.


If increasing of chip_delay has no effect on your device, could you
verify all the other timing constraints ? AS you use chipselects for WE
and RE, are you sure that data hold time (tdh) is guaranteed ? Usually
tdh on a CPU is specified from the rising egde of WE, which is earlier
than the rising egde of a CS.

Have you ever tried to set chip_delay to 1 ? Then you should get a bunch
of errors.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From tglx at linutronix.de  Sat Aug 10 06:33:08 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 10 Aug 2002 12:33:08 +0200
Subject: Hardware ECC in NAND flash driver
In-Reply-To: <3D527739.5B19816C@sgi.com>
References: <3D511B55.6ADABE4D@sgi.com>
 <1028726139.19447.255.camel@thomas.tec.linutronix.de>
 <3D527739.5B19816C@sgi.com>
Message-ID: <1028975588.9592.167.camel@thomas.tec.linutronix.de>

On Thu, 2002-08-08 at 15:50, Steven Hein wrote:
> Hi Thomas,
Hi Steven,
I put this back on the list, because it might be of public interest.

> I basically added 4 fields to the struct nand_chip:
>     eccsize:  size of ECC block  (512 in my case)
>     eccbytes: # bytes ECC per ECC block (3 in my case)
>     calculate_ecc:  pointer to ECC calculation (in my case,it reads HW ECC)
>     correct_data:  pointer to ECC checking/data fix function
> If these fields aren't set, by the hardware-specific driver, they
> all default to the software ECC functions and settings.
I'm not convinced yet, because I have to solve some compability issues.
See below.

> I don't have any experience with how any other Hardware ECC generators
> for NAND flash might work (including DiskOnChip), but the one in the
> S3C2410 is pretty simple.  Before reading/writing data, you write a bit
> to an internal register to reset the ECC generator.  Then, after
> reading/writing the 512 bytes of data, you read a register that contains
> the 3 byte ECC code (this must be read *before* reading/writing OOB data).
3 byte for 512 byte data reduces the recovery probabilty by factor 2.
I'm wondering, why Samsung did it this way. They support 256 byte page
NAND chips and don't care about the ECC for these chips. Also they are
member of the SmartMedia Consortium and the spec's there use definitly 3
byte ECC per 256 Byte, which means 6 Byte per 512 Byte. So you cannot
read/write SmartMediaSpec compatible Cards, if you wan't to use the
onchip ECC generator. 
But maybe they have decided that the ugly SmartMedia DOS-FAT filesystem
is not reliable and give a sh.. on compability :). This is likely the
case as they support booting from NAND  in a way which is definitly not
compatible with SmartMediaDosFAT.

But nevertheless it breaks and influences existing code. But that should
be possible to handle.

> So, I had to make a few changes due to this implementation:
>   1) In nand_read_ecc(), I separated the read of data from read of OOB data
>      and put the calculate_ecc() call between them.  (This means that ECC
>      is calculated/read for blocks that weren't written with ECC--we can't
>      check that until we've read the OOB data).
Should be no problem.

>   2) In nand_write_page(), in order to generate a correct hardware ECC
>      for partial page writes, you need to write the actual data stored
>      in the page (rather than pre-padding with 0xff).
I see your need, but this breaks the datasheet specs. You have to pad
already written data with 0xff or in case of Samsung NAND you can write
only the bytes you want program to the chip and the chip takes care of
0xff padding itself. As far as I understand the physical insides of
NAND, it might lead to erroneous behaviour, if you reprogram contents.  
In that case, which should not happen with JFFS2 or any other
filesystem, which takes care of NAND specific issues, we should skip ECC
for this page in case we are using a 512 byte only hardware ECC
generator.

>   3) For NAND controllers like mine with 512-byte ECC, using ECC with
>      256-byte page NAND chips isn't really practical  (my changes currently
>      don't handle that case very gracefully, but I'm not using chips with
>      256-byte pages).
In this case you could use the software ECC. Your HW driver can specify
this after chipdetection. 

> In general, I don't think the implementation is *too* bad; I think the part
> that needs cleaning up yet is the handling of different ECC block sizes.
> In the cases were there are two operations due to 256 byte ECC in a
> 512 byte page, I put a (mtd->eccsize < 512) check in with the current
> (mtd->oobblock == 512) checks.  Maybe you can think of a better way
> to handle this.
It's definitly not *too* bad. I'm just thinking about a clean way to
seperate the resulting 3byte ECC/ 512 Byte and the standard of 3Byte ECC
/ 256 Byte. 

More comments later today.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From oops2k at rediffmail.com  Sat Aug 10 12:30:19 2002
From: oops2k at rediffmail.com (sriram  neelakandan)
Date: 10 Aug 2002 16:30:19 -0000
Subject: tiny JFFS2 Reader
Message-ID: <20020810163019.19590.qmail@mailFA12.rediffmail.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20020810/5f89ee67/attachment.pl 

From tglx at linutronix.de  Sat Aug 10 19:05:31 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sun, 11 Aug 2002 01:05:31 +0200
Subject: Hardware ECC in NAND flash driver
In-Reply-To: <1028975588.9592.167.camel@thomas.tec.linutronix.de>
References: <3D511B55.6ADABE4D@sgi.com>
 <1028726139.19447.255.camel@thomas.tec.linutronix.de>
 <3D527739.5B19816C@sgi.com>
 <1028975588.9592.167.camel@thomas.tec.linutronix.de>
Message-ID: <1029020732.9668.344.camel@thomas.tec.linutronix.de>

On Sat, 2002-08-10 at 12:33, Thomas Gleixner wrote:
> More comments later today.
Hi Steven,

back again. I tried several possibilities to deal with all aspects. I
picked up most of your ideas and worked them into the existing code. My
final conclusion is as follows: 

struct nand_chip got following extensions:

calculate_ecc - function for ecc calculation or readback from ecc
hardware, defaults to nand_calculate_ecc for software ecc
correct_data - function for ecc correction, matching to ecc generator
(sw/hw), defaults to nand_correct_data for software ecc
enable_hwecc - function to enable (reset) hardware ecc generator
eccmod - mode of ecc: see constants
eccsize - databytes used per ecc-calculation, set by nand.c depending on
eccmod value

following eccmodes are defined at the moment

#define NAND_ECC_NONE		0 
is forced, if CONFIG_MTD_NAND_ECC is not set
#define NAND_ECC_SOFT		1 
is forced, if CONFIG_MTD_NAND_ECC is set and no hardware ecc is selected
#define NAND_ECC_HW3_256	2 
user selectable, if your ecc hardware supports 3 byte ecc for 256 byte
of data (DOC or passive SmartMedia adaptors)
#define NAND_ECC_HW3_512	3
user selectable, if your ecc hardware supports 3 byte ecc for 512 byte
of data (Samsung S3C2410)

If you select hardware ecc in your driver, you have to take care, that
calculate_ecc, correct_data and enable_hwecc are filled with the
relevant function pointers and eccmod is set to the appropriate type,
before you call nand_scan.

I'm still not willing to write already written data to the device for a
second time. So I decided to skip hardware ecc for that case. If you use
a NAND aware filesystem e.g. JFFS2 this should not happen, otherwise you
will get in trouble anyway. 

The funtion, which does correct_data calculations for the specfic
hardware ecc should be implemented as a general function in nand_ecc.c
to make it usable for similar hardware drivers and to avoid duplicated
code in these drivers.

Please remove the ECC reset out of your command function and move it to
a seperate function, which will be called by enable_hwecc.

Get code from CVS and enjoy. Thanks for your suggestions. The standard
software ecc mode runs on my machine without complains. I tested HW3_256
mode with software ecc routines and a dummy enable_hwecc and found no
problems. Any suggestions and improvements are welcome. 
Happy testing.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From karim at opersys.com  Sat Aug 10 17:47:22 2002
From: karim at opersys.com (Karim Yaghmour)
Date: Sat, 10 Aug 2002 17:47:22 -0400
Subject: Possible fix for Grub hotplug problem [needs testing]
Message-ID: <3D5589EA.3A9B1082@opersys.com>


I've modified doc_stage1.S to do the following:
o Copy the old interrupt handler (whether it be int 18 or 19) before
  overwriting it.
o The Grub int handler calls on the BIOS's int 16 to check whether
  the user is holding down the "ctrl" key.
o If he is, then the old handler is copied back in place and invoked.
o If he isn't, then the code continues on with loading the DOC.

I had to shorten the "msgjmp" string to get the code to still fit
in 512 bytes. On a tangential note: given the 512 byte limitations
it may be simpler get rid of any printout and output single chars,
like lilo does when booting. The expensive string ops could then be
left once we're out of the 512 bytes.

I haven't tested the code. Because my real-mode programming skills
are somewhat rusty, I wanted someone else to take a look at it first
in case I made a mistake somewhere. (I would usually test stuff
before sending it off, but hotplugging my card isn't very appealing,
hence the additional caution).

I've attached a bzip2'd copy of my modified doc_stage1.S. The code
I added is surrounded by "#ifdef KEYBRD_READ" statements for easier
reading.

Any comments and suggestions are greatly appreciated.

Karim

===================================================
                 Karim Yaghmour
               karim at opersys.com
      Embedded and Real-Time Linux Expert
===================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc_stage1.S.bz2
Type: application/octet-stream
Size: 4726 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020810/79df282a/attachment.obj 

From karim at opersys.com  Sun Aug 11 04:00:25 2002
From: karim at opersys.com (Karim Yaghmour)
Date: Sun, 11 Aug 2002 04:00:25 -0400
Subject: No more DoC hotplug on Grub fail [tested & working]
Message-ID: <3D561999.593157B6@opersys.com>


I modified doc_stage1.S to check whether the user is holding
down the "ctrl" key while booting. If so, then it uses the
BIOS's original bootstrap handler instead of its own. This
avoids having to hotplug the DOC in case you misconfigure it
or if it fails to boot adequately for some other reason.

I had suggested this idea earlier on this list, but I figured
I'd dig up some of my old real-mode witchcraft and get it over
with. I sent a preliminary version of the code earlier, but
now that I tested it out, I know that that version doesn't
work. The version attached with the current e-mail, however,
does work.

The scheme works as described in my earlier emails.

Hopefully this saves some folks some cold sweat (me included).

Karim

P.S.: For some reason, gas 2.9.5 is unable to build my modified
doc_stage1.S in the prescribed 512 bytes. gas 2.12, nevertheless,
works just fine.

===================================================
                 Karim Yaghmour
               karim at opersys.com
      Embedded and Real-Time Linux Expert
===================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc_stage1.S.bz2
Type: application/octet-stream
Size: 4734 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020811/be9c33a3/attachment.obj 

From hansolofalcon at worldnet.att.net  Sun Aug 11 12:14:25 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Sun, 11 Aug 2002 12:14:25 -0400
Subject: A question if I might
Message-ID: <000001c24152$2c446a00$5157580c@who>

Hello from Gregg C Levine
Now here's my question: Just when did the MTD collection become a part
of the kernel source code? I know it is not in the 2.2.19 and related
series. But I do see it in the 2.4 series.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )







From mtd at mcmen.demon.co.uk  Sun Aug 11 14:08:06 2002
From: mtd at mcmen.demon.co.uk (adr)
Date: Sun, 11 Aug 2002 19:08:06 +0100
Subject: Help with Dreamcast flash devices
Message-ID: <200208111908.06874.mtd@mcmen.demon.co.uk>

I wonder if someone here might help me.

I am one of the (too) small team of developers on the Linux on Dreamcast 
project (http://sourceforge.net/projects/linuxdc). I am currently working on 
developing a driver for the flash memory devices available for this machine.

Someone else started work on this months ago, but nothing has been done for 
ages, so I'm hacking at it now.

The flash memory on the DC is "smart" - ie it's attached to an 8-bit 
micro-controller. The device communicates with the rest of the system via a 
high speed serial ("maple") protocol. The flash is not mapped into the sh4 
(main cpu) physical memory at all. (http://mc.pp.se/dc/vms/index.html leads 
to more information for those interested).

Well, the long and the short of it is that I am somewhat at sea here. Are 
there any similar mtd devices I can look at?

Is there an explanation anywhere of how mapping works and how to 'virtual' map 
something which isn't in the physical map at all?

Any other ideas (random or now) about how to make this work? Currently the 
driver fails on mapping.

Adrian



From hansolofalcon at worldnet.att.net  Sun Aug 11 14:24:08 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Sun, 11 Aug 2002 14:24:08 -0400
Subject: Help with Dreamcast flash devices
In-Reply-To: <200208111908.06874.mtd@mcmen.demon.co.uk>
Message-ID: <000101c24164$4e3dc040$5157580c@who>

Hello from Gregg C Levine
Funny... I bought my DC console, on, or around the beginning of December
of last year, superficially for trying out either Linux, or say another
related OS, on it. So far, I have tracked down the usual collection of
resources, including several pages on a site that I find mentioned on
the ECOS pages, at Sources Red Hat. Have you had any luck getting your
DC to startup using Linux? And can you send me a CD, to try out, if I
were to supply my hard mail address? E-mail me off list with your
details. I regret that I can not actually support your flash problems.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linux-mtd-admin at lists.infradead.org [mailto:linux-mtd-
> admin at lists.infradead.org] On Behalf Of adr
> Sent: Sunday, August 11, 2002 2:08 PM
> To: linux-mtd at lists.infradead.org
> Subject: Help with Dreamcast flash devices
> 
> I wonder if someone here might help me.
> 
> I am one of the (too) small team of developers on the Linux on
Dreamcast
> project (http://sourceforge.net/projects/linuxdc). I am currently
working on
> developing a driver for the flash memory devices available for this
machine.
> 
> Someone else started work on this months ago, but nothing has been
done for
> ages, so I'm hacking at it now.
> 
> The flash memory on the DC is "smart" - ie it's attached to an 8-bit
> micro-controller. The device communicates with the rest of the system
via a
> high speed serial ("maple") protocol. The flash is not mapped into the
sh4
> (main cpu) physical memory at all. (http://mc.pp.se/dc/vms/index.html
leads
> to more information for those interested).
> 
> Well, the long and the short of it is that I am somewhat at sea here.
Are
> there any similar mtd devices I can look at?
> 
> Is there an explanation anywhere of how mapping works and how to
'virtual' map
> something which isn't in the physical map at all?
> 
> Any other ideas (random or now) about how to make this work? Currently
the
> driver fails on mapping.
> 
> Adrian
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




From joern at wohnheim.fh-wedel.de  Sun Aug 11 15:52:38 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Sun, 11 Aug 2002 21:52:38 +0200
Subject: Help with Dreamcast flash devices
In-Reply-To: <200208111908.06874.mtd@mcmen.demon.co.uk>
References: <200208111908.06874.mtd@mcmen.demon.co.uk>
Message-ID: <20020811195238.GA1638@wohnheim.fh-wedel.de>

On Sun, 11 August 2002 19:08:06 +0100, adr wrote:
> I am one of the (too) small team of developers on the Linux on Dreamcast 
> project (http://sourceforge.net/projects/linuxdc). I am currently working on 
> developing a driver for the flash memory devices available for this machine.
> 
> Someone else started work on this months ago, but nothing has been done for 
> ages, so I'm hacking at it now.
> 
> The flash memory on the DC is "smart" - ie it's attached to an 8-bit 
> micro-controller. The device communicates with the rest of the system via a 
> high speed serial ("maple") protocol. The flash is not mapped into the sh4 
> (main cpu) physical memory at all. (http://mc.pp.se/dc/vms/index.html leads 
> to more information for those interested).
> 
> Well, the long and the short of it is that I am somewhat at sea here. Are 
> there any similar mtd devices I can look at?
> 
> Is there an explanation anywhere of how mapping works and how to 'virtual' map 
> something which isn't in the physical map at all?
> 
> Any other ideas (random or now) about how to make this work? Currently the 
> driver fails on mapping.

My best guess would be to create something similar to the slram
driver, but with different guts. Basically, you have to write some
functions for reading and writing to the flash through the controller.
Erasing, locking and so on might work directly, or it might have to be
emulated.
This should be some two weeks of work, if you trust my estimates more
than I do. :)

Just out of curiosity: Is the flash really only 128kiB? If so, will
there be anything much in it, except for the bootloader? And if even
that is true, shouldn't a userspace flasher do the job just as well?

J?rn

-- 
A surrounded army must be given a way out.
-- Sun Tzu



From mtd at mcmen.demon.co.uk  Sun Aug 11 16:16:40 2002
From: mtd at mcmen.demon.co.uk (adr)
Date: Sun, 11 Aug 2002 21:16:40 +0100
Subject: Help with Dreamcast flash devices
In-Reply-To: <20020811195238.GA1638@wohnheim.fh-wedel.de>
References: <200208111908.06874.mtd@mcmen.demon.co.uk> <20020811195238.GA1638@wohnheim.fh-wedel.de>
Message-ID: <200208112116.40813.mtd@mcmen.demon.co.uk>

On Sunday 11 Aug 2002 8:52 pm, J?rn Engel wrote:

>
> Just out of curiosity: Is the flash really only 128kiB? If so, will
> there be anything much in it, except for the bootloader? And if even
> that is true, shouldn't a userspace flasher do the job just as well?
>
> Jrn

Well, you can get bigger lumps of flash, but they can only be addressed in 
128k lumps.

It won't even have a booloader - as there is no way to get the DC to boot from 
the flash. It's just a challenge, that's all :->



From startec at ms11.hinet.net  Mon Aug 12 02:30:24 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Mon, 12 Aug 2002 14:30:24 +0800
Subject: NAND Configuration
In-Reply-To: <1028968874.9586.69.camel@thomas.tec.linutronix.de>
Message-ID: <000a01c241c9$be627270$80d1a8c0@synso.com.tw>

> 
> On Sat, 2002-08-10 at 09:54, Steve Tsai wrote:
> > That's the fault of our board. We can not adujst a proper 
> chip_delay, 
> > so we add a circuit to check the ready bit and it does not 
> have these 
> > errors so far. Do you think chip_delay can be used with 
> NAND flash? I 
> > don't think it is good idea to use chip_delay.
> > 
> I'm pretty sure, that chip_delay is working. 
> 
> Cite from data sheet:
> '..Page Read... by writing 00h to the command register along 
> with three address cycles. ... The 528 bytes of data within 
> the selected page are transferred to the data registers in 
> _LESS_ than 10us(tR). The system controller _CAN_ detect the 
> completion of this data transfer(tR) by analyzing the output 
> of R/B pin. Once the data in a page is loaded into the 
> registers, they may be read out by sequential RE pulse of 
> 70ns/50n(K9F2808Q0B:70ns,
> K9F2808U0B:50ns) period cycle. High to low transitions of the 
> RE clock take out the data from the selected column address 
> up to the last column address. '
> 
> As tR is defined as a max value of x ms, it's safe to use it. 
> I tested this, when we started the work on JFFS2/NAND. I 
> could verify with the scope, that R/B high transition was 
> always within the specified time. 
> 
> For program and erase we use a different scheme. If we have 
> no access to the R/B pin, we read back the Status Register. 
> Bit 6 is a mirror of R/B pin.
> 
> 
> If increasing of chip_delay has no effect on your device, 
> could you verify all the other timing constraints ? AS you 
> use chipselects for WE and RE, are you sure that data hold 
> time (tdh) is guaranteed ? Usually tdh on a CPU is specified 
> from the rising egde of WE, which is earlier than the rising 
> egde of a CS.
> 
> Have you ever tried to set chip_delay to 1 ? Then you should 
> get a bunch of errors.
> 

We use udelay function here, but I found that ARM uClinux can not
provide a stable delay function. I write my own delay function and I
will not get errors. I will use ready bit , because it make the JFFS2
drivers faster.

Steve Tsai




From tino.keitel at innominate.com  Mon Aug 12 02:55:33 2002
From: tino.keitel at innominate.com (Tino Keitel)
Date: Mon, 12 Aug 2002 08:55:33 +0200
Subject: tiny JFFS2 Reader
In-Reply-To: <20020810163019.19590.qmail@mailFA12.rediffmail.com>; from oops2k@rediffmail.com on Sat, Aug 10, 2002 at 04:30:19PM -0000
References: <20020810163019.19590.qmail@mailFA12.rediffmail.com>
Message-ID: <20020812085533.A24857@gateway.bln.gelonet.local>

On Sat, Aug 10, 2002 at 16:30:19 -0000, sriram  neelakandan wrote:
> Hi group,
> I am looking for a tiny jffs2 reader that can read a file from a 
> jffs2 partition..
> the code in jffs2reader.c in the MTD utils tar
> mtd-20000704.tar.gz (hope this is the latest)
> does not have the logic to read beyond the first node of the 
> file.

There was a project called load_kernel at
http://russ.dhs.org/load_kernel.html, but this web server doesn't exist
anymore. It contains all code to look for a file called "linux" on a
cramfs oder jffs2 image and read it (including zlib decompression).
Maybe you want to contact the author (try Russ.Dill at asu.edu). I could
also send you the archive.

Regards,
Tino

-- 
tino.keitel at innominate.com
dipl.-inf.                        Innominate Security Technologies AG
software engineer                                   networking people
tel: +49.30.6392-3308                      http://www.innominate.com/



From meunier at enst.fr  Mon Aug 12 03:41:14 2002
From: meunier at enst.fr (Sylvain Meunier)
Date: Mon, 12 Aug 2002 09:41:14 +0200
Subject: tiny JFFS2 Reader
References: <20020810163019.19590.qmail@mailFA12.rediffmail.com> <20020812085533.A24857@gateway.bln.gelonet.local>
Message-ID: <3D57669A.142EC6F3@enst.fr>

> > On Sat, Aug 10, 2002 at 16:30:19 -0000, sriram  neelakandan wrote:
> > Hi group,
> > I am looking for a tiny jffs2 reader that can read a file from a
> > jffs2 partition..
> > the code in jffs2reader.c in the MTD utils tar
> > mtd-20000704.tar.gz (hope this is the latest)
> > does not have the logic to read beyond the first node of the
> > file.
...

Hi

Look for ppcboot sources, this is a bootloader that know about jffs2 (it
can acces any level of
directory and load a file).

Sylvain



From Jamey.Hicks at hp.com  Mon Aug 12 08:05:45 2002
From: Jamey.Hicks at hp.com (Hicks, Jamey)
Date: Mon, 12 Aug 2002 08:05:45 -0400
Subject: tiny JFFS2 Reader
Message-ID: <D99C1FB421989A40818B6370E31870940283B428@tayexc19.americas.cpqcorp.net>


> -----Original Message-----
> From: Tino Keitel [mailto:tino.keitel at innominate.com]
> Sent: Monday, August 12, 2002 2:56 AM
> To: linux-mtd at lists.infradead.org
> Subject: Re: tiny JFFS2 Reader
> 
> 
> On Sat, Aug 10, 2002 at 16:30:19 -0000, sriram  neelakandan wrote:
> > Hi group,
> > I am looking for a tiny jffs2 reader that can read a file from a 
> > jffs2 partition..
> > the code in jffs2reader.c in the MTD utils tar
> > mtd-20000704.tar.gz (hope this is the latest)
> > does not have the logic to read beyond the first node of the 
> > file.
> 
> There was a project called load_kernel at
> http://russ.dhs.org/load_kernel.html, but this web server 
> doesn't exist
> anymore. It contains all code to look for a file called "linux" on a
> cramfs oder jffs2 image and read it (including zlib decompression).
> Maybe you want to contact the author (try Russ.Dill at asu.edu). I could
> also send you the archive.

This code has also been incorporated into our bootldr: http://www.handhelds.org/feeds/bootldr has binaries and source.

Jamey



From peter.holik at it-technology.at  Mon Aug 12 08:10:28 2002
From: peter.holik at it-technology.at (Peter Holik)
Date: Mon, 12 Aug 2002 14:10:28 +0200 (CEST)
Subject: mtdblock and preempt patch
Message-ID: <46152.62.99.145.150.1029154228.squirrel@www.it-technology.at>

Everything works as expected without the preempt patch.

I'm using cfi_cmdset_0001, jedec_probe, physmap and mtdblock with
a 512kByte Intel Flash.

But with the patch after 3 to 5 times of copy a file to /dev/mtdblock0
linux userspace stops working.

Reading from /dev/mtdblock0 produces after 3 to 5 times a reboot.

any hints?

Peter






From peter.holik at it-technology.at  Mon Aug 12 08:14:15 2002
From: peter.holik at it-technology.at (Peter Holik)
Date: Mon, 12 Aug 2002 14:14:15 +0200 (CEST)
Subject: mtdblock and preempt patch
Message-ID: <46155.62.99.145.150.1029154455.squirrel@www.it-technology.at>

Everything works as expected without the preempt patch.

I'm using cfi_cmdset_0001, jedec_probe, physmap and mtdblock with
a 512kByte Intel Flash.

But with the patch after 3 to 5 times of copy a file to /dev/mtdblock0
linux userspace stops working.

Reading from /dev/mtdblock0 produces after 3 to 5 times a reboot.

any hints?

Peter






From peter.holik at it-technology.at  Mon Aug 12 08:16:51 2002
From: peter.holik at it-technology.at (Peter Holik)
Date: Mon, 12 Aug 2002 14:16:51 +0200 (CEST)
Subject: mtdblock and preempt patch
Message-ID: <46164.62.99.145.150.1029154611.squirrel@www.it-technology.at>

Everything works as expected without the preempt patch.

I'm using cfi_cmdset_0001, jedec_probe, physmap and mtdblock with
a 512kByte Intel Flash.

But with the patch after 3 to 5 times of copy a file to /dev/mtdblock0
linux userspace stops working.

Reading from /dev/mtdblock0 produces after 3 to 5 times a reboot.

any hints?

Peter






From peter.holik at it-technology.at  Mon Aug 12 08:16:54 2002
From: peter.holik at it-technology.at (Peter Holik)
Date: Mon, 12 Aug 2002 14:16:54 +0200 (CEST)
Subject: mtdblock and preempt patch
Message-ID: <46164.62.99.145.150.1029154614.squirrel@www.it-technology.at>

Everything works as expected without the preempt patch.

I'm using cfi_cmdset_0001, jedec_probe, physmap and mtdblock with
a 512kByte Intel Flash.

But with the patch after 3 to 5 times of copy a file to /dev/mtdblock0
linux userspace stops working.

Reading from /dev/mtdblock0 produces after 3 to 5 times a reboot.

any hints?

Peter






From dwmw2 at infradead.org  Mon Aug 12 08:37:09 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 12 Aug 2002 13:37:09 +0100
Subject: mtdblock and preempt patch 
In-Reply-To: <46164.62.99.145.150.1029154614.squirrel@www.it-technology.at> 
References: <46164.62.99.145.150.1029154614.squirrel@www.it-technology.at> 
Message-ID: <28045.1029155829@redhat.com>

peter.holik at it-technology.at said:
>  Everything works as expected without the preempt patch.

I thought the preempt patches for 2.4 were known to be broken. Does it 
happen in 2.5?

--
dwmw2





From nurpinar at e-kolay.net  Mon Aug 12 09:37:32 2002
From: nurpinar at e-kolay.net (nur)
Date: Mon, 12 Aug 2002 16:37:32 +0300
Subject: DOC millenium doesnt work anymore 
Message-ID: <009601c24205$690cc730$3064000a@nurpinar>

I have created two partitions as minix and msdos. After reboot, my kernel
printed a message as follows
Using configured DiskOnChip probe address 0ex8000
Possible Diskonchop with unknown ChipID FD found at 0xe8000
No recognised Diskonchip devices found

Anyone has faced such a problem?

Under romdos dformat /win:e800 /s:doc51.exb doesn't work
It can't find any diskonchip. dinfo /win:e800 doesnt work as well

running nftl_format after insmod nftl could harm my diskonchip? I don't
suppose, because it was ok after formating and re-booting.
I would like to know what was my mistake so that I won't do it again. Cos I
have one doc millenium left
Thanks

P.S. mtd-patch-2.4.0-test12-20001218-2230GMT doesn't apply to 2.4.0 kernel.
gives many errors






From ilatypov at superbt.com  Mon Aug 12 11:12:57 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Mon, 12 Aug 2002 11:12:57 -0400 (EDT)
Subject: DOC millenium doesnt work anymore 
In-Reply-To: <009601c24205$690cc730$3064000a@nurpinar>
Message-ID: <Pine.LNX.4.44.0208121108380.31365-100000@server.superbt.com>

On Mon, 12 Aug 2002, nur wrote:

> Using configured DiskOnChip probe address 0ex8000
> Possible Diskonchop with unknown ChipID FD found at 0xe8000
> No recognised Diskonchip devices found
> 
> Anyone has faced such a problem?

The BIOS might have configurable chip selects.  You may need to associate
a certain chip select number with the DoC memory window in the BIOS
configuration screen.

I included a sample BIOS setup for the MZ104 board below.

Ilguiz

==================================================================

  Main
    Boot Drive Order:  Floppy Disk
    Boot through RFD:  No [Removable Flash Disk?  The RFD thing is
                          confusing because it doesn't apparently
                          refer to DiskOnChip]
  Advanced
    Onboard RFD:            Disabled
    Installed O/S:          Other   [are these two relevant
    Large Disk Access Mode: DOS      to DiskOnChip startup?]

    Console COM Port Address  Disabled
      Console Baud Rate            115.2K
      ...Continue C.R. after POST: Off

  IO Devices
    Serial Port A: Enabled
    Serial Port B: Enabled
    Infrared Port: Disabled
    Parallel Port: Enabled
    Floppy disk controller: Enabled
      Base I/O address: Primary
    Local Bus IDE adapter: Primary

  Memory Windows
    Memory Window - mem_cs3
      Window Size:   1h
      Window Base:  D0h
      Window Page: F30h
      Data width:  8-bits

  I/O Windows
    all disabled

==================================================================





From ssh at sgi.com  Mon Aug 12 12:00:25 2002
From: ssh at sgi.com (Steven Hein)
Date: Mon, 12 Aug 2002 11:00:25 -0500
Subject: Hardware ECC in NAND flash driver
References: <3D511B55.6ADABE4D@sgi.com>
	 <1028726139.19447.255.camel@thomas.tec.linutronix.de>
	 <3D527739.5B19816C@sgi.com> <1028975588.9592.167.camel@thomas.tec.linutronix.de>
Message-ID: <3D57DB99.A8F39B75@sgi.com>

Thomas Gleixner wrote:

> > I don't have any experience with how any other Hardware ECC generators
> > for NAND flash might work (including DiskOnChip), but the one in the
> > S3C2410 is pretty simple.  Before reading/writing data, you write a bit
> > to an internal register to reset the ECC generator.  Then, after
> > reading/writing the 512 bytes of data, you read a register that contains
> > the 3 byte ECC code (this must be read *before* reading/writing OOB data).
> 3 byte for 512 byte data reduces the recovery probabilty by factor 2.
> I'm wondering, why Samsung did it this way. They support 256 byte page
> NAND chips and don't care about the ECC for these chips. Also they are
> member of the SmartMedia Consortium and the spec's there use definitly 3
> byte ECC per 256 Byte, which means 6 Byte per 512 Byte. So you cannot
> read/write SmartMediaSpec compatible Cards, if you wan't to use the
> onchip ECC generator.
> But maybe they have decided that the ugly SmartMedia DOS-FAT filesystem
> is not reliable and give a sh.. on compability :). This is likely the
> case as they support booting from NAND  in a way which is definitly not
> compatible with SmartMediaDosFAT.
> 
Interesting...... (I didn't have any background on the SmartMedia
spec.).
I just discovered that the next rev. of the Samsung 2410 (rev. 1) no
longer supports NAND parts with 256 byte pages (there was a problem with
nWAIT holding the bus during erase operations or something, so they
redefined the the pin used for 256/512 byte pages to be a R/nB signal
for NAND flash).


> 
> >   2) In nand_write_page(), in order to generate a correct hardware ECC
> >      for partial page writes, you need to write the actual data stored
> >      in the page (rather than pre-padding with 0xff).
> I see your need, but this breaks the datasheet specs. You have to pad
> already written data with 0xff or in case of Samsung NAND you can write
> only the bytes you want program to the chip and the chip takes care of
> 0xff padding itself. As far as I understand the physical insides of
> NAND, it might lead to erroneous behaviour, if you reprogram contents.
> In that case, which should not happen with JFFS2 or any other
> filesystem, which takes care of NAND specific issues, we should skip ECC
> for this page in case we are using a 512 byte only hardware ECC
> generator.

That sounds like the best approach to me also.   (Since I just have a
JFFS2 filesystems and a couple of partitions with a kernel and a
CRAMFS ramdisk, I don't expect to see any partial page programming
happening anyway......)

....As an alternative, if you *really* wanted to do ECC on when you
finally
program to the end of the page, couldn't you....
   -- write the entire 512 bytes out exactly as it should be in Flash
   -- capture/generate the correct hardware ECC
   -- reset (via the SEQIN command) and rewrite the block padded with
0xFF
   -- then issue the PAGE_PROGRAM command
The data doesn't actually get written to the flash until the
PAGE_PROGRAM
command, correct?  This would be slower (as you are writing out the data
twice), but it would allow the correct ECC to be generated.  (This may
not work for all hardware ECC generators I guess).  Again, just a
thought
but not worth pursuing.

> 
> >   3) For NAND controllers like mine with 512-byte ECC, using ECC with
> >      256-byte page NAND chips isn't really practical  (my changes currently
> >      don't handle that case very gracefully, but I'm not using chips with
> >      256-byte pages).
> In this case you could use the software ECC. Your HW driver can specify
> this after chipdetection.

I guess I don't have to worry about this anymore   :)



Thanks,
Steve


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh at sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From ssh at sgi.com  Mon Aug 12 12:10:52 2002
From: ssh at sgi.com (Steven Hein)
Date: Mon, 12 Aug 2002 11:10:52 -0500
Subject: Hardware ECC in NAND flash driver
References: <3D511B55.6ADABE4D@sgi.com>
	 <1028726139.19447.255.camel@thomas.tec.linutronix.de>
	 <3D527739.5B19816C@sgi.com>
	 <1028975588.9592.167.camel@thomas.tec.linutronix.de> <1029020732.9668.344.camel@thomas.tec.linutronix.de>
Message-ID: <3D57DE0C.9EF20FF@sgi.com>

Thomas Gleixner wrote:
> 
> On Sat, 2002-08-10 at 12:33, Thomas Gleixner wrote:
> > More comments later today.
> Hi Steven,
> 
> back again. I tried several possibilities to deal with all aspects. I
> picked up most of your ideas and worked them into the existing code. My
> final conclusion is as follows:
> 
> struct nand_chip got following extensions:
> 
> calculate_ecc - function for ecc calculation or readback from ecc
> hardware, defaults to nand_calculate_ecc for software ecc
> correct_data - function for ecc correction, matching to ecc generator
> (sw/hw), defaults to nand_correct_data for software ecc
> enable_hwecc - function to enable (reset) hardware ecc generator
> eccmod - mode of ecc: see constants
> eccsize - databytes used per ecc-calculation, set by nand.c depending on
> eccmod value
> 
> following eccmodes are defined at the moment
> 
> #define NAND_ECC_NONE           0
> is forced, if CONFIG_MTD_NAND_ECC is not set
> #define NAND_ECC_SOFT           1
> is forced, if CONFIG_MTD_NAND_ECC is set and no hardware ecc is selected
> #define NAND_ECC_HW3_256        2
> user selectable, if your ecc hardware supports 3 byte ecc for 256 byte
> of data (DOC or passive SmartMedia adaptors)
> #define NAND_ECC_HW3_512        3
> user selectable, if your ecc hardware supports 3 byte ecc for 512 byte
> of data (Samsung S3C2410)
> 
> If you select hardware ecc in your driver, you have to take care, that
> calculate_ecc, correct_data and enable_hwecc are filled with the
> relevant function pointers and eccmod is set to the appropriate type,
> before you call nand_scan.

This all looks great!

> 
> I'm still not willing to write already written data to the device for a
> second time. So I decided to skip hardware ecc for that case. If you use
> a NAND aware filesystem e.g. JFFS2 this should not happen, otherwise you
> will get in trouble anyway.

Sounds good.

> 
> The funtion, which does correct_data calculations for the specfic
> hardware ecc should be implemented as a general function in nand_ecc.c
> to make it usable for similar hardware drivers and to avoid duplicated
> code in these drivers.

Dumb question--is ECC calculation "generic" enough to be applicable from
one hardware ECC generator to the next, even if they do the same number
of ECC bytes for the same block size?  Is it very likely that the
algorithm
is actually going to be the same between platforms?


> 
> Get code from CVS and enjoy. Thanks for your suggestions. The standard
> software ecc mode runs on my machine without complains. I tested HW3_256
> mode with software ecc routines and a dummy enable_hwecc and found no
> problems. Any suggestions and improvements are welcome.
> Happy testing.
> 
THANKS for adding this!!  I'll try it today/tomorrow.

Another question--how do you typically handle adding new HW drivers
to the NAND flash code?  I know that in my case, the HW implementation
uses access to specific S3C2410 processor registers, and those
register definitions live in include/asm-arm/arch-s3c2410 directory
in the Linux kernel tree.  I would expect that these arch-specific
files would not live in the MTD tree.  Let me know--I'd like to get
this HW driver incorporated into the standard tree as soon as I
get it working!


Thanks again,
Steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh at sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From Russ.Dill at asu.edu  Mon Aug 12 13:08:32 2002
From: Russ.Dill at asu.edu (Russ Dill)
Date: 12 Aug 2002 10:08:32 -0700
Subject: tiny JFFS2 Reader
In-Reply-To: <20020812085533.A24857@gateway.bln.gelonet.local>
References: <20020810163019.19590.qmail@mailFA12.rediffmail.com> 
	<20020812085533.A24857@gateway.bln.gelonet.local>
Message-ID: <1029172113.19462.2.camel@russ>

On Sun, 2002-08-11 at 23:55, Tino Keitel wrote:
> On Sat, Aug 10, 2002 at 16:30:19 -0000, sriram  neelakandan wrote:
> > Hi group,
> > I am looking for a tiny jffs2 reader that can read a file from a 
> > jffs2 partition..
> > the code in jffs2reader.c in the MTD utils tar
> > mtd-20000704.tar.gz (hope this is the latest)
> > does not have the logic to read beyond the first node of the 
> > file.
> 
> There was a project called load_kernel at
> http://russ.dhs.org/load_kernel.html, but this web server doesn't exist
> anymore. It contains all code to look for a file called "linux" on a
> cramfs oder jffs2 image and read it (including zlib decompression).
> Maybe you want to contact the author (try Russ.Dill at asu.edu). I could
> also send you the archive.

it exists, it just moved to port 8000, also, the code is in blob cvs




From tglx at linutronix.de  Mon Aug 12 13:26:53 2002
From: tglx at linutronix.de (tglx at linutronix.de)
Date: Mon, 12 Aug 2002 19:26:53 +0200
Subject: Aw: Re: Hardware ECC in NAND flash driver
Message-ID: <34a9835a72.35a7234a98@t-online.de>

Steven Hein <ssh at sgi.com> wrote:
> This all looks great!
:):):) 

> Sounds good.
:):):) 

> > The funtion, which does correct_data calculations for the specfic
> > hardware ecc should be implemented as a general function in 
> nand_ecc.c> to make it usable for similar hardware drivers and to 
> avoid duplicated
> > code in these drivers.
> 
> Dumb question--is ECC calculation "generic" enough to be 
> applicable from
> one hardware ECC generator to the next, even if they do the same 
> numberof ECC bytes for the same block size?  Is it very likely 
> that the
> algorithm
> is actually going to be the same between platforms?
I think so, because  Samsung and others will bring up similar chips, 
which 
incorporate the same ECC generator, but with maybe different registers 
or
opcodes. But the algorithm will be the same for interdevice compability. 
So
IMHO it's correct to put it in the generic nand_ecc code.
 
> THANKS for adding this!!  I'll try it today/tomorrow.
I'm curious, how many bugs you will detect. :)
 
> Another question--how do you typically handle adding new HW drivers
> to the NAND flash code?  I know that in my case, the HW implementation
> uses access to specific S3C2410 processor registers, and those
> register definitions live in include/asm-arm/arch-s3c2410 directory
> in the Linux kernel tree.  I would expect that these arch-specific
> files would not live in the MTD tree.  Let me know--I'd like to get
> this HW driver incorporated into the standard tree as soon as I
> get it working!

That's easy, you include <asm/hardware.h> and you should be done. When 
your
driver is ready, let me know. I will take care for incorporation.
 
Thomas





From invictus_rm at hotmail.com  Mon Aug 12 13:29:46 2002
From: invictus_rm at hotmail.com (invictus rm)
Date: Mon, 12 Aug 2002 22:59:46 +0530
Subject: flash erase on 64 bit arch
Message-ID: <F1366TwctPBjxPGsKsJ0000553f@hotmail.com>

hi,
i am facing a strange problem of flash erase/program of 2*16 intel strata 
flash.
When i configure my bootloader for 64 bit addressing scheme on 64 bit 
architecture and  try to erase the flash/program the flash , only the first 
word of the doubleword gets programmed/erased.
The same program/erase function was working when configures for 32 bit 
support .

here is the dump after flash erase at a particular block

>>dump  bc600000   <--- physical address of flash

FFFFFFFFBC600000: 3C1C8014FFFFFFFF 3C083000FFFFFFFF  <.......<.0.....
FFFFFFFFBC600010: 40886000FFFFFFFF 67BDFFE0FFFFFFFF  @.`.....g.......
FFFFFFFFBC600020: 40824800FFFFFFFF 40805800FFFFFFFF  @.H..... at .X.....
FFFFFFFFBC600030: 24040000FFFFFFFF 03E00008FFFFFFFF  $...............
FFFFFFFFBC600040: 03E00008FFFFFFFF 34880003FFFFFFFF  ........4.......
FFFFFFFFBC600050: 39080003FFFFFFFF 240A00FFFFFFFFFF  9.......$.......
FFFFFFFFBC600060: 012A5004FFFFFFFF C10B0000FFFFFFFF  .*P.............
FFFFFFFFBC600070: 15800006FFFFFFFF E10C0000FFFFFFFF  ................
FFFFFFFFBC600080: 00000000FFFFFFFF 24020001FFFFFFFF  ........$.......
FFFFFFFFBC600090: 24020000FFFFFFFF 1D000009FFFFFFFF  $...............
FFFFFFFFBC6000A0: 3C0A8000FFFFFFFF 012A5021FFFFFFFF  <........*P!....
FFFFFFFFBC6000B0: 40801000FFFFFFFF 40840000FFFFFFFF  @....... at .......
FFFFFFFFBC6000C0: 03E00008FFFFFFFF 4442F800FFFFFFFF  ........DB......
FFFFFFFFBC6000D0: 3C060003FFFFFFFF 00C23024FFFFFFFF  <.........0$....
FFFFFFFFBC6000E0: 24050F80FFFFFFFF 000529C2FFFFFFFF  $.........).....
FFFFFFFFBC6000F0: 00A72825FFFFFFFF 3C01FFFCFFFFFFFF  ..(%....<.......


It can be seen that only half the block is erased .
Can someone gimme some pointers in this regard.
Waiting for a reply

rgd
rm

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com




From mtd at empireenterprises.com  Mon Aug 12 14:02:19 2002
From: mtd at empireenterprises.com (Glen)
Date: 12 Aug 2002 14:02:19 -0400
Subject: kernel won't load root on doc millenium
Message-ID: <1029175339.2250.36.camel@glen>

I'm not sure whether my problem is a mtd issue or not, but here goes.  


I finally have grub booting off the doc millenium.  
I achieved this by compiling grub with the grub-0.92 mtd patch.  
I then loaded the grub_firmware from the grub-0.92/stage1 directory onto
the doc using the mtd supplied doc_loadbios utility.  

Then, using, the mtd supplied nftl_format command, starting at offset
106496.  
(./nftl_format /dev/mtd/0 106496)  

I had been running nftl_format at offset 98304, however grub would never
load after that.  So, after running nftl_format, I rebooted (mtd is
loaded within the kernel), and then ran fdisk to partition the doc.  

This is all working fine, and I have my teeny linux filesystem on the
doc.  Grub loads, boots the kernel off of the doc, and then reports the
same message it always does when it loads an ext3 filesystem, then
stops.  

No error messages like "cannot mount root" or "i want to scream" or
"kernel panic" or anything.  

It just stops and sits there, mocking me.  

I originally thought this may have had something to do with my using
devfs.  I was specifying /dev/nftl/disc0/part1 as root within grub, and
I also tried writing it to the kernel with rdev.  No results.  

So I created the devices (mknod /dev/nftla b 93 0 and mknod /dev/nftla1
b 93 1) on the doc filesystem and mounted the kernel without devfs.  

Still nothing.  
I'm at odds as to the cause of the problem. I though possibly that it
could have been a problem with init, so I removed init from the
filesystem and tried again -- this should have at least given me another
error message -- no change.  This prompts me to think it is an mtd
issue, specifically because I have an exact duplicate of the doc root
filesystem on a 10M ide partition; it loads perfectly.  

Ideas..??


-g


~~
It felt like the entire ship was a party, and she was the pooper
thereof.  
--Peter David




From mtd at mcmen.demon.co.uk  Mon Aug 12 16:54:19 2002
From: mtd at mcmen.demon.co.uk (adr)
Date: Mon, 12 Aug 2002 21:54:19 +0100
Subject: Help with Dreamcast flash devices
In-Reply-To: <20020811195238.GA1638@wohnheim.fh-wedel.de>
References: <200208111908.06874.mtd@mcmen.demon.co.uk> <20020811195238.GA1638@wohnheim.fh-wedel.de>
Message-ID: <200208122154.19331.mtd@mcmen.demon.co.uk>

On Sunday 11 Aug 2002 8:52 pm, J?rn Engel wrote:

>
> My best guess would be to create something similar to the slram
> driver, but with different guts. 


I've looked at slram.c - but don't really understand what it is for. What sort 
of device is it?

Adrian




From dwmw2 at infradead.org  Mon Aug 12 16:58:15 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 12 Aug 2002 21:58:15 +0100
Subject: Help with Dreamcast flash devices 
In-Reply-To: <200208111908.06874.mtd@mcmen.demon.co.uk> 
References: <200208111908.06874.mtd@mcmen.demon.co.uk> 
Message-ID: <18431.1029185895@redhat.com>

mtd at mcmen.demon.co.uk said:
>  Well, the long and the short of it is that I am somewhat at sea here.
> Are  there any similar mtd devices I can look at?

> Is there an explanation anywhere of how mapping works and how to
> 'virtual' map  something which isn't in the physical map at all? 

Your map functions must read and write words to the flash, and provide 
methods for copying chunks of data from the flash. That's about it.

They may not sleep. Is that a problem?

--
dwmw2





From joern at wohnheim.fh-wedel.de  Mon Aug 12 17:06:38 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 12 Aug 2002 23:06:38 +0200
Subject: Help with Dreamcast flash devices
In-Reply-To: <200208122154.19331.mtd@mcmen.demon.co.uk>
References: <200208111908.06874.mtd@mcmen.demon.co.uk> <20020811195238.GA1638@wohnheim.fh-wedel.de> <200208122154.19331.mtd@mcmen.demon.co.uk>
Message-ID: <20020812210638.GA23744@wohnheim.fh-wedel.de>

On Mon, 12 August 2002 21:54:19 +0100, adr wrote:
> On Sunday 11 Aug 2002 8:52 pm, J?rn Engel wrote:
> > My best guess would be to create something similar to the slram
> > driver, but with different guts. 
> 
> I've looked at slram.c - but don't really understand what it is for.
> What sort of device is it?

Physical RAM, plain and simple. Usually system memory, after passing a
"mem=a_little_less_than_availlable" command line option. Sometimes
NVRAM that is mapped into the physical memory address range.

J?rn

-- 
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001



From ssh at sgi.com  Mon Aug 12 17:49:15 2002
From: ssh at sgi.com (Steven Hein)
Date: Mon, 12 Aug 2002 16:49:15 -0500
Subject: Aw: Re: Hardware ECC in NAND flash driver
References: <34a9835a72.35a7234a98@t-online.de>
Message-ID: <3D582D5B.A18054F@sgi.com>

tglx at linutronix.de wrote:
> >
> > Dumb question--is ECC calculation "generic" enough to be
> > applicable from
> > one hardware ECC generator to the next, even if they do the same
> > numberof ECC bytes for the same block size?  Is it very likely
> > that the
> > algorithm
> > is actually going to be the same between platforms?
> I think so, because  Samsung and others will bring up similar chips,
> which
> incorporate the same ECC generator, but with maybe different registers
> or
> opcodes. But the algorithm will be the same for interdevice compability.
> So
> IMHO it's correct to put it in the generic nand_ecc code.
> 

Sounds fine with me!

Any preference on how the correct_data function should be named
(the one I should add to nand_ecc.c)?  Let me know what you'd prefer
and I'll use that name from the start.

> > THANKS for adding this!!  I'll try it today/tomorrow.
> I'm curious, how many bugs you will detect. :)
> 

The final tally is.......ZERO!!  I tried it and it worked great.
Thanks again!


> > Another question--how do you typically handle adding new HW drivers
> > to the NAND flash code?  I know that in my case, the HW implementation
> > uses access to specific S3C2410 processor registers, and those
> > register definitions live in include/asm-arm/arch-s3c2410 directory
> > in the Linux kernel tree.  I would expect that these arch-specific
> > files would not live in the MTD tree.  Let me know--I'd like to get
> > this HW driver incorporated into the standard tree as soon as I
> > get it working!
> 
> That's easy, you include <asm/hardware.h> and you should be done. When
> your
> driver is ready, let me know. I will take care for incorporation.
> 
I'll let you know when I have it done  (I'm working with a Samsung
employee on the 2410 port; when we get it cleaned up I'll
send it to you).


Steve



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh at sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From xjin at redswitch.com  Mon Aug 12 23:49:02 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Mon, 12 Aug 2002 20:49:02 -0700
Subject: how to mount a root filesystem stored on MTD device?
Message-ID: <3D5881AE.3020809@redswitch.com>

I've read the MTD/JFFS howto but still cannot get it. Right now I've 
been able to enable MTD devices and mount jffs2. I set bootargs to 
'root=/dev/mtdblock0' on PPCBoot and use tftpboot to boot the kernel via 
network. But the boot process doesn't succeed due to unability to mount 
root filesystem.

Here is the message showing that mtd devices have been found.
--------------------clip--------------------------------------
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis 
Communications AB.
loop: loaded (max 8 devices)
Search for id:(89 88f3) interleave(1) type(2)
Found: Intel 28F160F3T
IB8SW Bank 0: Found 1 x16 devices at 0x0 in 16-bit mode
Using word write method
init_ib8sw_mtd: part_num=3
IB8SW flash bank 0: Using static image partition definition
Creating 3 MTD partitions on "IB8SW Bank 0":
0x00000000-0x000f0000 : "jffs2"
mtd: Giving out device 0 to jffs2
0x000f0000-0x00100000 : "spare"
mtd: Giving out device 1 to spare
0x00100000-0x00200000 : "ppcboot"
mtd: Giving out device 2 to ppcboot
--------------------clip--------------------------------------

But here it complains that root fs hasn't been mounted.
--------------------clip-----------------------------------
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
request_module[block-major-2]: Root fs not mounted
VFS: Cannot open root device "mtdblock0" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
--------------------clip-----------------------------------

Any instructions or hints? Thanks a lot.

- Shawn.




From karim at opersys.com  Tue Aug 13 01:06:34 2002
From: karim at opersys.com (Karim Yaghmour)
Date: Tue, 13 Aug 2002 01:06:34 -0400
Subject: Latest Grub CVS results in UnitSizeFactor problems
Message-ID: <3D5893DA.F0BE2B16@opersys.com>

I've been playing around with the latest Grub code from CVS
on a 32MB DOC 2000. There was no way to get the NFTL code in
MTD to recognize the DOC once the firmware image was written
using: doc_loadbios /dev/mtd0 grub_firmware
I always got the following message when loading the nftl module:
Sorry, we don't support UnitSizeFactor 0x6e

When using Grub 0.92, however, everything works fine (except
that I had to steal the configure.in, stage1/Makefile.am and
stage2/Makefile.am from the CVS to get 0.92 to build because
I have the latest automake/autoconf versions).

I tried digging around the Grub source code to see where the
problem originates from so that I could fix it, but I don't
have the time to become a grub-internals guru. I can see that
the "ANAND" character string has something to do with the
position where the media header is being looked for, but the
only place I can find this string is in a C call to strcmp().
Beats me how this can be used as a marker.

Karim

===================================================
                 Karim Yaghmour
               karim at opersys.com
      Embedded and Real-Time Linux Expert
===================================================



From nurpinar at e-kolay.net  Tue Aug 13 06:05:24 2002
From: nurpinar at e-kolay.net (nur)
Date: Tue, 13 Aug 2002 13:05:24 +0300
Subject: 2.2.20
Message-ID: <001d01c242b0$f10ca410$3064000a@nurpinar>

Anybody has mtd patch for linux-2.2.20?
2.2.17 gives many errors
thanks






From frank.oltmanns.ml at gmx.de  Tue Aug 13 11:32:06 2002
From: frank.oltmanns.ml at gmx.de (Frank Oltmanns)
Date: Tue, 13 Aug 2002 17:32:06 +0200
Subject: kernel won't load root on doc millenium
In-Reply-To: <1029175339.2250.36.camel@glen>
References: <1029175339.2250.36.camel@glen>
Message-ID: <02081317320600.02924@franksrechner>

Hi Glen,

i had the same problem with a DoC2000 (root-fs loads from NFS
but not from DoC).

Try:
http://lists.infradead.org/pipermail/linux-mtd/2002-July/005509.html

HTH
  Frank



From kevin at gv.com.tw  Tue Aug 13 02:52:12 2002
From: kevin at gv.com.tw (??)
Date: Tue, 13 Aug 2002 14:52:12 +0800
Subject: jffs2_mark_node_obsolete() called with wbuf active but alloc_sem not locked!
Message-ID: <006501c24295$f436fd40$1b0448c0@gv.com.tw>

test program: lls.c attached
usage: "./lls /"
---------------------------
jffs2_mark_node_obsolete() called with wbuf active but alloc_sem not locked!
kernel BUG at nodemgmt.c:400!
Unable to handle kernel paging request at virtual address 00000000, epc ==
80094
dd8, ra == 80094dd8
Oops in fault.c:do_page_fault, line 204:
$0 : 00000000 10003c00 0000001e 00000001 801ce7d0 00000001 00000001 00810303
$8 : b4000090 0000001e b4000098 80000000 0000000d 0000000a 50000000 fffffff9
$16: 8018c9fc 808930e8 00000000 8018c350 80bb7620 80893120 00000001 00000004
$24: ffffffff 80dafc8a                   80dae000 80dafdd8 802ae1ec 80094dd8
Hi : 00001b1c
Lo : 00000265
epc  : 80094dd8    Not tainted
Status: 10003c04
Cause : 8000000c
Process rmdir (pid: 96, stackpage=80dae000)
Stack: 8018c350 8018c9fc 00000190 008102e2 801e74cc 801e74ce 800184a8
00000400
       808930e8 8009e1d0 8018dfea 808930e8 802c4640 00000000 802c4640
00000000
       806aef00 808a0560 0000002c 808930e8 00000001 80097f1c 8018dfb4
802c4655
       00000350 00000000 00000004 004c830c 00000000 80e4a970 004c830c
00001cf4
       806aef00 802ae190 808a04b8 808a0430 802ae190 808a04b8 00000002
00000001
       7ffffcb0 ...
Call Trace: [<8018c350>] [<8018c9fc>] [<800184a8>] [<8009e1d0>] [<8018dfea>]
[<8
0097f1c>]
 [<8018dfb4>] [<8008ed38>] [<8005e33c>] [<8008fd54>] [<8005103c>]
[<80050e70>]
 [<800544f4>] [<80052c10>] [<800547a4>] [<80054694>] [<800107ac>]

Code: 02002821  0c006099  24060190 <08025397> ae400000  3c02801d  8c42f76c
0000
0000  3042007f
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lls.c
Type: application/octet-stream
Size: 7186 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020813/fe1b4348/attachment.obj 

From clark at esteem.com  Tue Aug 13 12:50:55 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 13 Aug 2002 09:50:55 -0700
Subject: improving performance of jffs2?
Message-ID: <3D5938EF.9BB4FAB0@esteem.com>

Hi all,

	Now that I have jffs2 working in kernel 2.4.19, I was wondering
If there was any updates that improve its performance without
destablizing it? Also where and how do I get them (Note: I've never used
CVS before) ? 


Many many thanks in advance

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From Steve_Chen at kingston.com  Tue Aug 13 18:31:11 2002
From: Steve_Chen at kingston.com (Steve_Chen at kingston.com)
Date: Tue, 13 Aug 2002 15:31:11 -0700
Subject: JFFS2 Page Fault Problem Report
Message-ID: <OFC661DE72.85EF7A4C-ON88256C14.007953C1@LocalDomain>

Hi,
I need help.  I am wondering if anyone has experienced the same problem.
After mounting the JFFS2 on an empty NAND flash chip, a page fault
occurred.  The Linux kernel version is 2.4.6.  Here is the error log:

-------------------------------------------------------------------------------------------

[root at RedHat7 /root]# mount -t jffs2 /dev/mtdblock2 /mnt2
jffs2: read_super for device 1f:01
jffs2_do_fill_super:..entry point
jffs2_do_mount_fs():..entry point
jffs2_scan_medium():empty_blocks 1792, bad_blocks 0, c->nr_blocks 1792
erasing_blocks = 1792,
Scanned flash completely
Pass 1 complete
Pass 2 complete
Pass 3 complete
jffs2_do_fill_super(): Getting root inode
jffs2_do_fill_super(): d_alloc_root()
jffs2_write_super(): flush_wbuf before gc-trigger
root at RedHat7 /mnt2]# Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 10008400 00000029 8028a048
$4 : 8025c0d0 00000000 00000001 0000000a
$8 : 80272960 0000003c 00000003 00000003
$12: 8111dee8 8111e848 00000000 8111e840
$16: 81042e24 81042e08 00000031 00000001
$20: 00000000 8028a048 8028a04c 00000000
$24: 00000001 2ab93310
$28: 83fc6000 83fc7f70 00000000 8005d3bc
epc   : 8005d3c8
Status: 10008403
Cause : 1000000c
Process kswapd (pid: 3, stackpage=83fc6000)
Stack: 801c3eb4 00000001 00000004 8025d3e8 83fc6000 80266cd0 00000000
8005d830
       00000000 00000000 00000000 8005d8f8 00000000 00000000 00000700
00000010
       00010f00 80253268 80028924 83fc7fe0 00000000 80216b14 802531d4
80253268
       80028914 8002801c 10008403 00000020 ffffffbe fffffff7 ffffffbf
efffffbf
       fff5ffdf fffffbf5 f7ffffff fdbfffbf
Call Trace: [<801c3eb4>] [<8005d830>] [<8005d8f8>] [<80028924>]
[<80028914>] [<8
002801c>]
Code: 8e050004  8e030000  ac650004 <aca30000> 3c028029  8c429e68  2442ffff
3c01
8029  ac229e68

-------------------------------------------------------------------------------------------------

Thanks.

Regards,
Steve





From inox_kas at yahoo.com  Tue Aug 13 22:37:27 2002
From: inox_kas at yahoo.com (kas turi)
Date: Tue, 13 Aug 2002 19:37:27 -0700 (PDT)
Subject: Mounting JFFS2 slows console prints. 
Message-ID: <20020814023727.35575.qmail@web21002.mail.yahoo.com>

Hi
 I am running timesys linux on our custom made 8260
board. The board has a 16 bit 8M Intel flash chip. I
have defined 2 partitions. The first partition
contains ppcboot and the second partition is for
jffs2. I am using root filesystem as NFS. After the
linux boots up I mount JFFS2 filesystem onto /mnt/jffs
directory. After I do the mounting it slows down the
console output. When I type a command it takes atleast
few seconds before it appears on the console. I am
running the console at 115200. When I unmount the
JFFS2 filesystem the console output is faster. I have
configured the verbose level for JFFS2 as 0. Any idea
what is the problem?.  
  Thanks in advance

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com



From dag4004 at free.fr  Wed Aug 14 02:59:43 2002
From: dag4004 at free.fr (dag4004)
Date: Wed, 14 Aug 2002 08:59:43 +0200
Subject: It neems that CVS isnot any morel compatible with 2.2.17 kernel ?
Message-ID: <BNEJIGKFJNJLELKBCMDAIEOFCBAA.dag4004@free.fr>

Hello,

I use an ELAN-104NC PC Board.
It use JFFS/MTD with the 2.2.17 kernel.
I actually use an old CVS snap shot (15 September 2000)
It work well but it is quit slow (~ 1min to mount the
JFFS file system)

So wanted to update.
I download the last CVS today.
I download linux-2.2.17 from kernel.org

I patch the kernel with :
- inter-module-2.2.17
- mtd-patch-2.2.17-20001218-2230GMT
build zImage
All goes right

BUT at run time when i boot the kernel it got this :
(my root is 1f:02 it i a JFFS partition)

...
ELAN-104NC flash: IO:0x22-0x23 MEM:0xb0000-0xb7fff
ELAN-104NC flash: Found 1 x16 CFI device at 0x0 in 16 bit mode
...
JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
ll_rw_block: Trying to read nonexistent block-device 1f:02 (1)
EXT2-fs: unable to read superblock
Invalid session number or type of track
ll_rw_block: Trying to read nonexistent block-device 1f:02 (32)
isofs_read_super: bread failed, dev=1f:02, iso_blknum=16, block=32
VFS: Mounted root (jffs filesystem) readonly.
Freeing unused kernel memory: 48k freed
...

I try to BUT

what does mean :
ll_rw_block: Trying to read nonexistent block-device 1f:02 (32)
isofs_read_super: bread failed, dev=1f:02, iso_blknum=16, block=32

Is it dangerous ?


So i tried to put last CVS mtd : i patch with
sh patchin.sh /usr/src/linux

But when i try to compile i got this :

make zImage
...
make -C mtd
make[2]: Entering directory `/usr/src/linux/drivers/mtd'
make -C chips
make[3]: Entering directory `/usr/src/linux/drivers/mtd/chips'
make all_targets
make[4]: Entering directory `/usr/src/linux/drivers/mtd/chips'
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -DEXPORT_SYMTAB -c chipreg.c
chipreg.c:11: linux/spinlock.h: Aucun fichier ou r?pertoire de ce type
make[4]: *** [chipreg.o] Error 1
make[4]: Leaving directory `/usr/src/linux/drivers/mtd/chips'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory `/usr/src/linux/drivers/mtd/chips'
make[2]: *** [_subdir_chips] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/mtd'
make[1]: *** [_subdir_mtd] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2

I do not undesrtant but i try this
cd /usr/src/linux/include/linux
ln -s ../asm-i386/spinlock.h
cd /usr/src/linux
make zImage

Is it a good idea ?
It seams not because few secand later i stop with that :

...
make -C mtd
make[2]: Entering directory `/usr/src/linux/drivers/mtd'
make -C chips
make[3]: Entering directory `/usr/src/linux/drivers/mtd/chips'
make all_targets
make[4]: Entering directory `/usr/src/linux/drivers/mtd/chips'
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -DEXPORT_SYMTAB -c chipreg.c
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -DEXPORT_SYMTAB -c gen_probe.c
gen_probe.c: In function `genprobe_ident_chips':
gen_probe.c:100: warning: implicit declaration of function `BUG'
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -c -o cfi_probe.o cfi_probe.c
cfi_probe.c:336: warning: type defaults to `int' in declaration of
`module_init'
cfi_probe.c:336: warning: parameter names (without types) in function
declaration
cfi_probe.c:336: warning: data definition has no type or storage class
cfi_probe.c:337: warning: type defaults to `int' in declaration of
`module_exit'
cfi_probe.c:337: warning: parameter names (without types) in function
declaration
cfi_probe.c:337: warning: data definition has no type or storage class
cfi_probe.c:332: warning: `cfi_probe_exit' defined but not used
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -c -o cfi_cmdset_0001.o cfi_cmdset_0001.c
cfi_cmdset_0001.c: In function `do_xxlock_oneblock':
cfi_cmdset_0001.c:1488: warning: implicit declaration of function `BUG'
cfi_cmdset_0001.c: At top level:
cfi_cmdset_0001.c:1682: warning: type defaults to `int' in declaration of
`module_init'
cfi_cmdset_0001.c:1682: warning: parameter names (without types) in function
declaration
cfi_cmdset_0001.c:1682: warning: data definition has no type or storage
class
cfi_cmdset_0001.c:1683: warning: type defaults to `int' in declaration of
`module_exit'
cfi_cmdset_0001.c:1683: warning: parameter names (without types) in function
declaration
cfi_cmdset_0001.c:1683: warning: data definition has no type or storage
class
cfi_cmdset_0001.c:1677: warning: `cfi_intelext_exit' defined but not used
rm -f chipslink.o
ld -m elf_i386  -r -o chipslink.o chipreg.o gen_probe.o cfi_probe.o
cfi_cmdset_0001.o
make[4]: Leaving directory `/usr/src/linux/drivers/mtd/chips'
make[3]: Leaving directory `/usr/src/linux/drivers/mtd/chips'
make -C maps
make[3]: Entering directory `/usr/src/linux/drivers/mtd/maps'
make all_targets
make[4]: Entering directory `/usr/src/linux/drivers/mtd/maps'
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -c -o elan-104nc.o elan-104nc.c
elan-104nc.c:271: warning: type defaults to `int' in declaration of
`module_init'
elan-104nc.c:271: warning: parameter names (without types) in function
declaration
elan-104nc.c:271: warning: data definition has no type or storage class
elan-104nc.c:272: warning: type defaults to `int' in declaration of
`module_exit'
elan-104nc.c:272: warning: parameter names (without types) in function
declaration
elan-104nc.c:272: warning: data definition has no type or storage class
rm -f mapslink.o
ld -m elf_i386  -r -o mapslink.o  elan-104nc.o
make[4]: Leaving directory `/usr/src/linux/drivers/mtd/maps'
make[3]: Leaving directory `/usr/src/linux/drivers/mtd/maps'
make -C devices
make[3]: Entering directory `/usr/src/linux/drivers/mtd/devices'
make all_targets
make[4]: Entering directory `/usr/src/linux/drivers/mtd/devices'
rm -f devlink.o
ar rcs devlink.o
make[4]: Leaving directory `/usr/src/linux/drivers/mtd/devices'
make[3]: Leaving directory `/usr/src/linux/drivers/mtd/devices'
make -C nand
make[3]: Entering directory `/usr/src/linux/drivers/mtd/nand'
make all_targets
make[4]: Entering directory `/usr/src/linux/drivers/mtd/nand'
rm -f nandlink.o
ar rcs nandlink.o
make[4]: Leaving directory `/usr/src/linux/drivers/mtd/nand'
make[3]: Leaving directory `/usr/src/linux/drivers/mtd/nand'
make all_targets
make[3]: Entering directory `/usr/src/linux/drivers/mtd'
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -DEXPORT_SYMTAB -c mtdcore.c
mtdcore.c: In function `init_mtd':
mtdcore.c:332: warning: implicit declaration of function `init_mtd_devices'
mtdcore.c: At top level:
mtdcore.c:360: warning: type defaults to `int' in declaration of
`module_init'
mtdcore.c:360: warning: parameter names (without types) in function
declaration
mtdcore.c:360: warning: data definition has no type or storage class
mtdcore.c:361: warning: type defaults to `int' in declaration of
`module_exit'
mtdcore.c:361: warning: parameter names (without types) in function
declaration
mtdcore.c:361: warning: data definition has no type or storage class
mtdcore.c:342: warning: `cleanup_mtd' defined but not used
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -DEXPORT_SYMTAB -c mtdpart.c
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -c -o mtdchar-compat.o mtdchar-compat.c
mtdchar-compat.c:589: warning: type defaults to `int' in declaration of
`module_init'
mtdchar-compat.c:589: warning: parameter names (without types) in function
declaration
mtdchar-compat.c:589: warning: data definition has no type or storage class
mtdchar-compat.c:590: warning: type defaults to `int' in declaration of
`module_exit'
mtdchar-compat.c:590: warning: parameter names (without types) in function
declaration
mtdchar-compat.c:590: warning: data definition has no type or storage class
cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomi
t-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m386 -DCPU=
386   -c -o mtdblock.o mtdblock.c
mtdblock.c:470: warning: type defaults to `int' in declaration of
`DECLARE_MUTEX_LOCKED'
mtdblock.c:470: warning: parameter names (without types) in function
declaration
mtdblock.c: In function `mtdblock_thread':
mtdblock.c:485: warning: implicit declaration of function `daemonize'
mtdblock.c:491: `QUEUE_EMPTY' undeclared (first use in this function)
mtdblock.c:491: (Each undeclared identifier is reported only once
mtdblock.c:491: for each function it appears in.)
mtdblock.c:503: `thread_sem' undeclared (first use in this function)
mtdblock.c: In function `cleanup_mtdblock':
mtdblock.c:654: `thread_sem' undeclared (first use in this function)
mtdblock.c:662: array subscript is not an integer
mtdblock.c: At top level:
mtdblock.c:667: warning: type defaults to `int' in declaration of
`module_init'
mtdblock.c:667: warning: parameter names (without types) in function
declaration
mtdblock.c:667: warning: data definition has no type or storage class
mtdblock.c:668: warning: type defaults to `int' in declaration of
`module_exit'
mtdblock.c:668: warning: parameter names (without types) in function
declaration
mtdblock.c:668: warning: data definition has no type or storage class
mtdblock.c:51: warning: `mtdblock_lock' defined but not used
mtdblock.c:470: warning: `DECLARE_MUTEX_LOCKED' declared `static' but never
defined
mtdblock.c:651: warning: `cleanup_mtdblock' defined but not used
make[3]: *** [mtdblock.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/mtd'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/mtd'
make[1]: *** [_subdir_mtd] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2


Does some one understand what append ?
I am curous to know the truth.

Thanks

Damien









From tino.keitel at innominate.com  Wed Aug 14 03:02:04 2002
From: tino.keitel at innominate.com (Tino Keitel)
Date: Wed, 14 Aug 2002 09:02:04 +0200
Subject: Bad blocks on NOR flash
Message-ID: <20020814070204.GA16910@tkeitel001.bln.gelonet.local>

Hi folks,

if I got this right, JFFS2 has bad block handling only for NAND
flashes. I have also read that NAND flashes could be shipped with bad
blocks whereas NOR flashes don't. Does this mean that there nevver will
be something like a bad block on a NOR flash?

Regards,
Tino

-- 
tino.keitel at innominate.com
dipl.-inf.                        Innominate Security Technologies AG
software engineer                                   networking people
tel: +49.30.6392-3308                      http://www.innominate.com/



From armlinuxkernel at hotmail.com  Wed Aug 14 08:42:32 2002
From: armlinuxkernel at hotmail.com (yuan cain)
Date: Wed, 14 Aug 2002 12:42:32 +0000
Subject: Intel I28F160B3T flash support on Linux JFFS2
Message-ID: <F24C6HixqDCZx4FR0rm000001f4@hotmail.com>

Hi all,
       I am now using Intel I28F160B3 flash chip with uClinux 2.4.17 but 
currectly  JEDEC probe can't   notice the  flash chip.  I tracd  but find 
that the base addres is not the same I want it to probe, the physical 
address of the flash is 0x1400000. Below is the message when boot up:
....
Output from jedec_probe.
In function mtd_do_chip_probe,call genprobe_ident_chips next.
In function genprobe_ident_chips, call genprobe_new_chip() next.
In function genprobe_new_chip, show the parameter as below:
Cain: output from jedec_probe_chip. The base address is 0x0.
Search for id:(e1a0 e1a0) interleave(1) type(2)
Search for id:(e1a0 e1a0) interleave(1) type(2)
JEDEC: Found no S3C4510B Flash device at location 0x1400000
JEDEC  probe failed.
...

Any advices?   TIA!!





_________________________________________________________________
?????????????? MSN Messenger: 
http://messenger.microsoft.com/cn




From paul at maypaul.com  Wed Aug 14 12:02:19 2002
From: paul at maypaul.com (paul at maypaul.com)
Date: Thu, 15 Aug 2002 00:02:19 +0800
Subject: NAND + JFFS2, run in Kernel 2.4.17
Message-ID: <003c01c243ab$fb65b310$b200a8c0@paulhome>

Hi! all,
    I have some questions about the MTD -> nand flash + jffs2 using Kernel
2.4.17

1. when I configure  CONFIG_JFFS2_FS=y and then make bzImage, there have
error message to show, that mean about the zlib_inflate and zlib_deflate
missing. Otherwise, set CONFIG_JFFS2_FS=m, it is successful to compile . Is
it the problem about the jffs2 compile in kernel ????

2. I want to bootup from jffs2 for file system. the speed will reduce ??????
Or copy the compressed file system in NAND flash  and then extract in
ramdisk when boot up. which is the better one and stable?

thanks a lot.

Paul




From manningc2 at actrix.gen.nz  Wed Aug 14 13:50:58 2002
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Thu, 15 Aug 2002 05:50:58 +1200
Subject: Bad blocks on NOR flash
In-Reply-To: <20020814070204.GA16910@tkeitel001.bln.gelonet.local>
References: <20020814070204.GA16910@tkeitel001.bln.gelonet.local>
Message-ID: <20020814175805.5EFDE45D1@tiger.actrix.co.nz>

On Wed, 14 Aug 2002 19:02, Tino Keitel wrote:
> Hi folks,
>
> if I got this right, JFFS2 has bad block handling only for NAND
> flashes. I have also read that NAND flashes could be shipped with bad
> blocks whereas NOR flashes don't. Does this mean that there nevver will
> be something like a bad block on a NOR flash?

NOR is shipped with all blocks good. However, NOR does start to fail with use 
- hence the endurance limit of 100k~1M erasure cycles. Thus, with extended 
erasure NOR does start to fail. Some file systems will retire these blocks. I 
don't recall whether JFFS does or not.

The reason behind this difference is that NOR is linearly memory mapped and 
is thus not very suited to having holes. NAND is page accessed and managed on 
a per block basis. This makes it far more suited to supporting bad blocks. 
Allowing bad blocks increases yield and thus lowers cost as well as allowing 
higher densities.

-- CHarles



From jay.s at sohu.com  Thu Aug 15 23:54:20 2002
From: jay.s at sohu.com (jay.s at sohu.com)
Date: Fri, 16 Aug 2002 11:54:20 +0800 (CST)
Subject: grub loading problem, for help
Message-ID: <6753069.1029470073112.JavaMail.postfix@mailsrv1.mail.sohu.com>

thanks in advance.

I am doing as a document advice, since I havn't the choice of change boot sequence to NETWORK boot option in bios, I did ./configure without "--enable-diskonchip-biosnetboot ", now I halt the system and reboot it, it says :

DoC 2000 D800
E698
Jumping to Grub

then nothing appeared on the screen, the keyboard is not locked.

accidently, I reboot the system without the hard disk, things were changed as follows:

DoC 2000 D800
D698
Jumping to Grub
Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0xff
DiskOnChip 2000 found at d8000
floor 0, chip 0; manufacturer:Toshiba
Chip: Toshiba TC58V64AFT/DC, total size:8 MiB
erase unit: 8192 bytes, page: 512 bytes
total of 1 chip2 found - total capacity 8 MiB
Scanning for NFTL Media Header
NFTL Media Header found in flash sector 192
spare Media Header for NFTL 0 fount in flash sector 208
Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0xff
Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0x0
Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0x1
.....................
Attempting to open /boot/grub/menu.lst on drive 0xe0, partition 0xf
Attempting to open /boot/grub/menu.lst on drive 0x80, partition 0xff
Attempting to open /boot/grub/menu.lst on drive 0x80, partition 0xff
Attempting to open /boot/grub/menu.lst on drive 0x80, partition 0xf0
.....................
Attempting to open /boot/grub/menu.lst on drive 0x80, partition 0xf
Attempting to open /boot/grub/menu.lst on drive 0x0, partition 0xff
Attempting to open /boot/grub/menu.lst on drive 0x0, partition 0x0
.....................
Attempting to open /boot/grub/menu.lst on drive 0x0, partition 0xf

GRUB version 0.93 (616k lower / 31744k upper memory)

[ Minimal BASH-like line editing is supported......]
grub>


I feel lucky to see the prompt, however I cant access the doc anymore( I have tried to use "kernel ...." according to that howto), I have installed the contents in the doc and also the grub/menu.lst, but nothing help. Because I don't know grub much, I don't know what to do then.

could you have any suggestions?

regards

jays




From ilatypov at superbt.com  Fri Aug 16 14:58:52 2002
From: ilatypov at superbt.com (Ilguiz Latypov)
Date: Fri, 16 Aug 2002 14:58:52 -0400 (EDT)
Subject: grub loading problem, for help
In-Reply-To: <6753069.1029470073112.JavaMail.postfix@mailsrv1.mail.sohu.com>
Message-ID: <Pine.LNX.4.44.0208160039180.16312-100000@server.superbt.com>

Jay,

On Fri, 16 Aug 2002 jay.s at sohu.com wrote:

> grub>
> 
> 
> I feel lucky to see the prompt, however I cant access the doc anymore( I
> have tried to use "kernel ...." according to that howto), I have
> installed the contents in the doc and also the grub/menu.lst, but
> nothing help. Because I don't know grub much, I don't know what to do
> then.

Does the "root (dc0)" or the "root (dc0,0)" command work?  Can you see the 
content of the menu.lst file by typing "cat /boot/grub/menu.lst"?  I 
always create a symbolic link when preparing the boot partition:

    cd boot
    ln -s . boot

In this way the path /boot/grub/menu.lst will resolve even when /boot is a 
mount point.

Also one has to make sure that the DoC's filesystem can be mounted at all 
(that is, mount -t ext3 /dev/nftla2 /mnt/flash or similar must work).  
It's easy to do mounting probe by booting off the hard disk first.

Ilguiz




From gromit1463 at mailworks.org  Fri Aug 16 15:23:48 2002
From: gromit1463 at mailworks.org (Stephen Hui)
Date: 16 Aug 2002 14:23:48 -0500
Subject: JFFS2 Power Fail Issue
Message-ID: <1029525828.11559.47.camel@mahi190.austin.ibm.com>

Hi,

My JFFS2 filesystem doesn't like having the plug pulled on it.  I get
some bad behaviour when:

1.  I have the partition mounted under another filesystem, and I pull
the plug while writing to it, or

2.  I have the partition unlocked and mounted read-write as root, and I
pull the plug (regardless of whether I'm writing).

After booting again and mounting the partition, I get a bunch of these:

Write error in obliterating obsoleted node at 0x0007eaec: -30                                                                                                                     
Write error in obliterating obsoleted node at 0x0013d66c: -30                                                                                                                     
Write error in obliterating obsoleted node at 0x0013d7b4: -30                                                                                                                     
Write error in obliterating obsoleted node at 0x0013d884: -30                                                                                                                     
Write error in obliterating obsoleted node at 0x0013dbec: -30

and each time I pull the plug and bring it back up, more nodes are
obsoleted.  Has this been seen before?  I'm using the latest JFFS2 code.

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




From koffer at arlut.utexas.edu  Fri Aug 16 17:13:44 2002
From: koffer at arlut.utexas.edu (Ken Offer)
Date: Fri, 16 Aug 2002 16:13:44 -0500
Subject: Found ecc verify bug in nand.c
Message-ID: <0BBECB8C-B15D-11D6-BE50-000393467F1A@arlut.utexas.edu>

Hi all,

Using the cvs code from August 12th, I found a bug in nand.c 
that was causing a page write to fail ecc verify.  In nand.c in 
the function "nand_write_page" there is a line which reads:

    if ((this->data_buf[(oob_config.ecc_pos[i])] != 
ecc_code[i]) && ecc_code[i]) {

This is a compare to see if the ecc has changed.  Unfortunately, 
data_buf is UNSIGNED char and ecc_code is SIGNED char.  When 
compiling under gcc 2.95.3 on a powerpc system, the code ends up 
comparing two identical bytes and fails because one is 
sign-extended (example: comparing 0xc3 becomes "0xc3 == 
0xffffffc3").  I don't know if this makes a difference with the 
x86 compiler, but it does under powerpc.

Changing the local array "ecc_code" to type "u_char" resolves 
the problem.  Verified by running nandtest.

+-----------------------------------------------------------+
|  Ken Offer        koffer at arlut.utexas.edu         ARL:UT  |
|  Office: 512-835-3859                  Fax: 512-835-3259  |
+-----------------------------------------------------------+




From tglx at linutronix.de  Sat Aug 17 04:16:31 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sat, 17 Aug 2002 10:16:31 +0200
Subject: Found ecc verify bug in nand.c
In-Reply-To: <0BBECB8C-B15D-11D6-BE50-000393467F1A@arlut.utexas.edu>
References: <0BBECB8C-B15D-11D6-BE50-000393467F1A@arlut.utexas.edu>
Message-ID: <1029571384.2142.19.camel@thomas.tec.linutronix.de>

On Fri, 2002-08-16 at 23:13, Ken Offer wrote:
> This is a compare to see if the ecc has changed.  Unfortunately, 
> data_buf is UNSIGNED char and ecc_code is SIGNED char.  When 
> compiling under gcc 2.95.3 on a powerpc system, the code ends up 
> comparing two identical bytes and fails because one is 
> sign-extended (example: comparing 0xc3 becomes "0xc3 == 
> 0xffffffc3").  I don't know if this makes a difference with the 
> x86 compiler, but it does under powerpc.
It's a problem on other arch's too. It did not happen to me, because I
don't use the NAND_WRITE_VERIFY paranoia check :)
Thanks, fixed in CVS

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From tglx at linutronix.de  Sat Aug 17 18:35:26 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Sun, 18 Aug 2002 00:35:26 +0200
Subject: No free space left for GC
Message-ID: <1029623727.2142.495.camel@thomas.tec.linutronix.de>

Hi David ! 

You wanted to know, why free_size got that low. 

I just copied stuff to an empty partition, until it got full. 
But instead of returning with "not enough space" it keeps garbage 
collection until really no more space is left. 
One of the problems is, that we have at lot of blocks on the dirty list,
with less than 2*sizeof(struct jffs2_raw_inode) left. At scan time we
put these blocks on the clean_list. We must do this in normal operation
too. It's total crap to gc blocks with 4 byte dirty space ! 
The total sum of dirty space is 32K, when we start gc. The most dirty 
block has 1.2k dirty space. Many blocks have less than 512 bytes dirty,
which is the pagesize on my device. This is a result of padding, when we
flush wbuf. The dirty space on blocks with more than 512 byte dirty
space is 12048 Byte, which is less than 1 block. 

The real weird thing is, that we write to the device (from gc) until the
last block is used and we run into an endless loop, where no more space
is left for garbage collection. This happens, because we increase dirty
size during gc instead of decreasing it. Once we are there we cannot
mount the filesystem again, without running in that endless gc loop.

I changed nodemgmt.c so that blocks with less than 2*sizeof(struct
jffs2_raw_inode) dirty space are moved to clean_list. But the gc effect
was still the same. 

Now I noticed that we don't move blocks to the dirty list anymore,
neither on mount (pass1) nor during gc or write. The reason is that
mark_node_obsolete checks if the dirty_size == ref_totlen. Due to the
fact, that we have blocks with some dirty space in the clean list, these
blocks stay there until they are very dirty, which may never happen. I
changed this by checking used space against sector_size -
2*sizeof(struct jffs2_raw_inode). Result is better but not good.
I tried the same procedure on a larger partition (56MB, previous one was
8MB). There I was running in trouble again. I had enough dirty space in
the clean_list, that the check in jffs2_reserve_space c->dirty_size <
c->sector_size never lead to -ENOSPC. I added a check, which is done,
when dirty_size is less than blocksneeded * sector_size. It checks if
the dirty_size in the dirty_lists is > c->sector_size. If not it returns
-ENOSPC too. Same as above.

In both cases, we end up with 3 empty blocks and we can't even remove a
file from the filesystem.

The strange thing is, that the dirty_size is not always correct. When I
filled the filesystem complete, df tells me:
/dev/mtdblock1	8192	8164	28	100%	/mnt/data
The last dirty information from the log was dirty_space = 0x3e0c
After umount and mount I have suddenly dirty_space = 0xcfe8, which is
the real dirty size. The good thing on this is, that the endless gc on a
100% full filesystem stops. The bad thing is that we have only 3 blocks
left and I can't remove a file anymore. Have to add some more checks on
monday.

If we are at the point of a 100% full filesystem and the dirty space is
splitted into small pieces, we add for each gc'd block one or two blocks
to the dirty list and the block, we have written to ends up sometimes on
the dirty list too. Maybe we have to add a check, where we calc the
average dirty space per block on dirty_list. If this is less than a
defined threshold, we return ENOSPC and stop garbage collection instead
of screwing up the filesystem at least. It should always be possible to
delete a file.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From paul.wong at digitalview.com  Mon Aug 19 05:28:36 2002
From: paul.wong at digitalview.com (Paul Wong)
Date: Mon, 19 Aug 2002 17:28:36 +0800
Subject: help! more message -->jffs2_scan_eraseblock() 
Message-ID: <00bb01c24762$dbcbaa40$9000010a@paulwong>

Hi!
    i am using a NAND flash to build up the jffs2 file system in Linux
kernel 2.4.17. and get the updated version of the MTD via CVS server. I
followed the NAND doc. and success to control the nand flash component. But,
when using "mount" command to make a device driver. there are more message
to display (like below that). After that, I check the file in jffs2
partition. all files are avaliable in nand flash and good condition.  What
is the meaning about the below message?????

Thank you.

Paul


jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00143760:
0x27de in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00143764:
0x27de in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00143768:
0x3000 in
stead
Further such events for this erase block will not be printed
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144000:
0x9f2c in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144004:
0x6ba1 in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144008:
0x04d4 in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0014400c:
0x25a6 in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144010:
0xb265 in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144014:
0xefc5 in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144018:
0x12d8 in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0014401c:
0x1a8f in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144020:
0x7bfa in
stead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00144024:
0x42b7 in
stead
Further such events for this erase block will not be printed

******************************************************************
all files are avalible in nand flash
******************************************************************

bash-2.04# ls /mnt/flash -al
total 2419
drwxr-xr-x    3 root     0               0 Jan  1  1970 .
drwxrwxrwx    4 root     0            1024 Aug 13  2002 ..
-rw-r--r--    1 root     0           10818 Jul 25  2002 SiS630
-rwxr--r--    1 root     0           35321 Jul 22  2002 fb_nsc.txt
-rwxr--r--    1 root     0           37467 Jul 19  2002 geode_rm.txt
-rwxr--r--    1 root     0          575598 Jul 17  2002 linuxapi_prgref.pdf
-rwxr--r--    1 root     0           31168 Jun 23  2000
loadregforlinux_v1.2.pdf

-rw-rw-r--    1 500      500        788829 Jul  5  2002 ns2000manual.pdf
-rwxr--r--    1 root     0           91578 Jun 23  2000 sc1200_sc1201_tv.pdf
-rwxr--r--    1 root     0          136106 Jun 23  2000
scx200_capturevip.pdf
-rwxr--r--    1 root     0           42297 Jun 23  2000
scx200_int_routing.pdf
-rwxr--r--    1 root     0           93302 Jun 23  2000
scx200_irq_expansion.pdf

-rwxr--r--    1 root     0           55786 Jun 23  2000 scx200_nand.pdf
-rwxr--r--    1 root     0          425177 Jul 17  2002
sp1sc10_stb_platform.pdf

-rwxr--r--    1 root     0          149956 Jul 17  2002 v4l2_prog_guide.pdf
bash-2.04#






From joakim.tjernlund at lumentis.se  Mon Aug 19 05:37:06 2002
From: joakim.tjernlund at lumentis.se (Joakim Tjernlund)
Date: Mon, 19 Aug 2002 11:37:06 +0200
Subject: Massive file corruption
In-Reply-To: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
Message-ID: <IGEFJKJNHJDCBKALBJLLEEMHFFAA.joakim.tjernlund@lumentis.se>

Hi again

For the second time there has been massive file corrution on one of our
boards.

In /bin there was 3 files that had been corrupted, the first 4K was all zeroes.
In /usr/bin, a ls gave me lots of Input/Output error and a load of CRC
errors in dmesg.

After reboot, ls in /usr/bin did not report Input/Output errors but there
was more corrupted files in there, with the first 4K zeroed.

Before this happened there was a lot of file I/O. ftp files to board, unpack them with rpm
delete old files etc.

No errors was reported during boot by JFFS2. Using the stable branch from ~3-4 months ago.

Any ideas?

            Jocke 






From m.palme at goepel.com  Mon Aug 19 06:55:58 2002
From: m.palme at goepel.com (Michael Palme)
Date: Mon, 19 Aug 2002 12:55:58 +0200
Subject: newbie: dynamic partition creation possible
Message-ID: <3D60CEBE.7090806@goepel.com>

hello...
i would like to know if it is possible to create flash dynamic 
partitions (i mean other way than directly in the sources). in the howto 
ive read it is impossible, but in some sources i found 
part_type="static" -- and so i've concluded "dynamic" is also an option? 
if this is possible can somebody explain the way to do it please.

thanks in advance ... Michael Palme

-- 
-------------------------------
Dipl.-Ing. (FH)
Michael Palme
software engineer
Goepel electronic GmbH

mailto: m.palme at goepel.com
phone:  +493641689682
fax:    +493641689644
inet:   http://www.goepel.com
-------------------------------





From joern at wohnheim.fh-wedel.de  Mon Aug 19 07:41:37 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 19 Aug 2002 13:41:37 +0200
Subject: newbie: dynamic partition creation possible
In-Reply-To: <3D60CEBE.7090806@goepel.com>
References: <3D60CEBE.7090806@goepel.com>
Message-ID: <20020819114137.GA9858@wohnheim.fh-wedel.de>

On Mon, 19 August 2002 12:55:58 +0200, Michael Palme wrote:
> i would like to know if it is possible to create flash dynamic 
> partitions (i mean other way than directly in the sources). in the howto 
> ive read it is impossible, but in some sources i found 
> part_type="static" -- and so i've concluded "dynamic" is also an option? 
> if this is possible can somebody explain the way to do it please.

What exactly do you mean by "dynamic"?

There are two methods to create partitions:
- Use a partition table parser and create a partition table.
- Provide a mapping driver and hard-code the partition layout in the
  driver.

Do you mean partition table?

J?rn

-- 
When you close your hand, you own nothing. When you open it up, you
own the whole world.
-- Li Mu Bai in Tiger & Dragon



From clark at esteem.com  Mon Aug 19 13:34:23 2002
From: clark at esteem.com (Conn Clark)
Date: Mon, 19 Aug 2002 10:34:23 -0700
Subject: How does one mount an existing jffs2 partition so it is writeable?
Message-ID: <3D612C1F.55297C10@esteem.com>

Hi All,

	How does one mount an existing jffs2 partition so it is writeable?
After a reboot I can mount my jffs2 and read from it, but not write to it
I can erase it first and mount it then read and write to it , but then I
lose my info on it which defeats the whole reason for having it.


Here is what I am doing.


[/]# MAKEDEV
[/]# mkdir gpig         
[/]# mount /dev/mtdblock3 /gpig
[/]# cd gpig
[/gpig]# ls
kernel_192e_V0.0.03ps
[/gpig]# cp ../bin/MAKEALL .
cp: ../bin/MAKEALL: No such file or directory
[/gpig]# 
[/gpig]# cp ../bin/MAKEDEV .
Write of 68 bytes at 0x00059a28 failed. returned 0, retlen 0
Not marking the space at 0x00059a28 as dirty because the flash driver returned retlen
zero
cp: ./MAKEDEV: Input/output error
[/gpig]# 
 
What step am I missing?


Thanks in advance

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From tglx at linutronix.de  Mon Aug 19 17:47:28 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 19 Aug 2002 23:47:28 +0200
Subject: No free space left for GC
In-Reply-To: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
References: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
Message-ID: <1029793649.22781.129.camel@thomas.tec.linutronix.de>

Some more information:

I tried to trigger GC instead of flushing the writebuffer. In principle
it works. But when do we stop GC again ? I decided to do it, when the
replacement node is written complete. Fine, if we hit a small file. If
it's rather large, we dirty a lot of space and trigger GC again, if we
are near the GC_TRESHHOLD. So we spend a lot of time in GC and increase
the erasecycles unneccecary. This depends really on the application and
on the filesizes on the filesystem. Padding can make a block dirty too,
but we get rid of the padding during GC, and can produce another
padding, when we run into wbuf_timeout. 

The 0xc4 request is sizeof(jffs2_raw_inode) + JFFS2_MIN_DATA_LEN). This
happens rather often, that it doesn't fit anymore in the block. So we
put this block on the dirty list and raised an endless gc cycle. These
blocks should be put into the clean list.

Then we have a lot of blocks with 4 bytes unused space. These blocks
should definitly always end on the clean list. 

We could put the blocks, which have more than 4 bytes dirty space on the
dirty list at mount time. When a block gets full and has less than 256
byte dirty space, we put it on the clean list to inhibit endless gc
loops on a nearly 100% full filesystem. 

On a 8MB partition I have an average dirty size of 20 bytes in 490
blocks. Not too bad. And more acceptable than loosing 48K, if one 16K
block dies. I have already 2 bad blocks there. So I accept 10k penalty
for having 96K usable flashspace. For NOR this should be no problem as
the sectorsizes are usually 64K - 128K.

On a 64MB partition I ended up with an average dirty size of 14 byte in
3200 blocks, which is a total of 58k. A lot of space, but better than
screwing up if we get near 100%. The 0xc4 request, which does not fit
into the remaining free space hits us too often to ignore it. Better to
have 58k less disk space than no chance to repair my full filesystem
other than erasing it.

The new decision function for gc and reserve_space takes only those
blocks into account, which are on the dirty and very dirty list. The
dirty space in the clean_list is ignored. This is neccecary to avoid
endless GC loops. 

Any suggestions ?

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From joern at wohnheim.fh-wedel.de  Mon Aug 19 19:42:39 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 20 Aug 2002 01:42:39 +0200
Subject: How does one mount an existing jffs2 partition so it is writeable?
In-Reply-To: <3D612C1F.55297C10@esteem.com>
References: <3D612C1F.55297C10@esteem.com>
Message-ID: <20020819234239.GA6792@wohnheim.fh-wedel.de>

On Mon, 19 August 2002 10:34:23 -0700, Conn Clark wrote:
> 	How does one mount an existing jffs2 partition so it is writeable?
> After a reboot I can mount my jffs2 and read from it, but not write to it
> I can erase it first and mount it then read and write to it , but then I
> lose my info on it which defeats the whole reason for having it.

1) Append "rw" to kernel command line.
2) mount / -o remount,rw

J?rn

-- 
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein



From clark at esteem.com  Mon Aug 19 20:01:17 2002
From: clark at esteem.com (Conn Clark)
Date: Mon, 19 Aug 2002 17:01:17 -0700
Subject: How does one mount an existing jffs2 partition so it is 
 writeable?
References: <3D612C1F.55297C10@esteem.com> <20020819234239.GA6792@wohnheim.fh-wedel.de>
Message-ID: <3D6186CD.6BCD1850@esteem.com>

J?rn Engel wrote:
> 
> On Mon, 19 August 2002 10:34:23 -0700, Conn Clark wrote:
> >       How does one mount an existing jffs2 partition so it is writeable?
> > After a reboot I can mount my jffs2 and read from it, but not write to it
> > I can erase it first and mount it then read and write to it , but then I
> > lose my info on it which defeats the whole reason for having it.
> 
> 1) Append "rw" to kernel command line.
> 2) mount / -o remount,rw
> 
> J?rn
> 
> --
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein

	Didn't work, I get the same message. Did I do it right?

[/gpig]# cd ..
[/]# mount /gpig -o remount,rw
[/]# cd gpig
[/gpig]# cp ../bin/MAKEDEV .                                                    
Write of 68 bytes at 0x00059a28 failed. returned 0, retlen 0
Not marking the space at 0x00059a28 as dirty because the flash driver returned r
etlen zero
cp: ./MAKEDEV: Input/output error
[/gpig]# 


-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From ch at murgatroid.com  Mon Aug 19 20:25:18 2002
From: ch at murgatroid.com (Christopher Hoover)
Date: Mon, 19 Aug 2002 17:25:18 -0700
Subject: How does one mount an existing jffs2 partition so it is  writeable?
In-Reply-To: <3D6186CD.6BCD1850@esteem.com>
Message-ID: <007201c247e0$1022fcd0$a15f040f@SNAGGLE>

Do you need to unlock your flash before you can write to it?  That's not
done automatically by mtd or jffs2.  There's a diff in the ARM patch
system by me that might be applicable.

-ch




From m.palme at goepel.com  Tue Aug 20 00:13:18 2002
From: m.palme at goepel.com (Michael Palme)
Date: Tue, 20 Aug 2002 06:13:18 +0200
Subject: newbie: dynamic partition creation possible
References: <3D60CEBE.7090806@goepel.com> <20020819114137.GA9858@wohnheim.fh-wedel.de>
Message-ID: <3D61C1DE.7010202@goepel.com>

thanks for the answer...

i am not sure about the terms, but i can explain what i need in more 
clear way: i would like to have support for writing binary images into 
the flash devices (no filesystem etc.). i need different "partitions" on 
the flash and i dont want to hardcode that --
i have seen in cmdline.c that this is possible via kernel parameters.
i'm not absolutely sure what kernel options are needed and what are 
unnecessary.

cheers ... Michael



J?rn Engel schrieb:

>On Mon, 19 August 2002 12:55:58 +0200, Michael Palme wrote:
>  
>
>>i would like to know if it is possible to create flash dynamic 
>>partitions (i mean other way than directly in the sources). in the howto 
>>ive read it is impossible, but in some sources i found 
>>part_type="static" -- and so i've concluded "dynamic" is also an option? 
>>if this is possible can somebody explain the way to do it please.
>>    
>>
>
>What exactly do you mean by "dynamic"?
>
>There are two methods to create partitions:
>- Use a partition table parser and create a partition table.
>- Provide a mapping driver and hard-code the partition layout in the
>  driver.
>
>Do you mean partition table?
>
>J?rn
>
>  
>




From tglx at linutronix.de  Mon Aug 19 18:34:31 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 20 Aug 2002 00:34:31 +0200
Subject: No free space left for GC
In-Reply-To: <1029793649.22781.129.camel@thomas.tec.linutronix.de>
References: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
 <1029793649.22781.129.camel@thomas.tec.linutronix.de>
Message-ID: <1029796472.22781.136.camel@thomas.tec.linutronix.de>

Forgot to attach a diff :)

Last try brought average dirty_space 11 bytes in 492 Blocks in
clean_list. I think we can live with that

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de
-------------- next part --------------
? cvs.diff
Index: fs/jffs2/background.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/background.c,v
retrieving revision 1.30
diff -u -r1.30 background.c
--- fs/jffs2/background.c	5 Aug 2002 14:46:47 -0000	1.30
+++ fs/jffs2/background.c	19 Aug 2002 22:30:39 -0000
@@ -155,18 +155,11 @@
 static int thread_should_wake(struct jffs2_sb_info *c)
 {
 	uint32_t gcnodeofs = 0;
-	int ret;
+	int ret = 0;
 
-	/* Don't count any progress we've already made through the gcblock
-	   as dirty space, for the purposes of this calculation */
-	if (c->gcblock && c->gcblock->gc_node)
-		gcnodeofs = c->gcblock->gc_node->flash_offset & ~3 & (c->sector_size-1);
-
-	if (c->nr_free_blocks + c->nr_erasing_blocks < JFFS2_RESERVED_BLOCKS_GCTRIGGER &&
-	    (c->dirty_size - gcnodeofs) > c->sector_size)
+	if (c->nr_free_blocks + c->nr_erasing_blocks < JFFS2_RESERVED_BLOCKS_GCTRIGGER && 
+		!jffs2_gc_checkspace (c, JFFS2_RESERVED_BLOCKS_BASE))
 		ret = 1;
-	else 
-		ret = 0;
 
 	D1(printk(KERN_DEBUG "thread_should_wake(): nr_free_blocks %d, nr_erasing_blocks %d, dirty_size 0x%x (mod 0x%x): %s\n", 
 		  c->nr_free_blocks, c->nr_erasing_blocks, c->dirty_size,
Index: fs/jffs2/build.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/build.c,v
retrieving revision 1.36
diff -u -r1.36 build.c
--- fs/jffs2/build.c	7 Aug 2002 18:37:32 -0000	1.36
+++ fs/jffs2/build.c	19 Aug 2002 22:30:40 -0000
@@ -43,6 +43,7 @@
 		return ret;
 
 	D1(printk(KERN_DEBUG "Scanned flash completely\n"));
+	D1(jffs2_dump_block_lists(c));
 	/* Now build the data map for each inode, marking obsoleted nodes
 	   as such, and also increase nlink of any children. */
 	for_each_inode(i, c, ic) {
@@ -54,7 +55,8 @@
 		}
 	}
 	D1(printk(KERN_DEBUG "Pass 1 complete\n"));
-
+	D1(jffs2_dump_block_lists(c));
+	
 	/* Next, scan for inodes with nlink == 0 and remove them. If
 	   they were directories, then decrement the nlink of their
 	   children too, and repeat the scan. As that's going to be
@@ -75,6 +77,7 @@
 		   and furthermore that it had children and their nlink has now
 		   gone to zero too. So we have to restart the scan. */
 		} 
+		D1(jffs2_dump_block_lists(c));
 	} while(ret == -EAGAIN);
 	
 	D1(printk(KERN_DEBUG "Pass 2 complete\n"));
@@ -99,6 +102,7 @@
 		kfree(scan);
 	}
 	D1(printk(KERN_DEBUG "Pass 3 complete\n"));
+	D1(jffs2_dump_block_lists(c));
 
 	/* Rotate the lists by some number to ensure wear levelling */
 	jffs2_rotate_lists(c);
Index: fs/jffs2/gc.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/gc.c,v
retrieving revision 1.78
diff -u -r1.78 gc.c
--- fs/jffs2/gc.c	7 Aug 2002 11:01:14 -0000	1.78
+++ fs/jffs2/gc.c	19 Aug 2002 22:30:42 -0000
@@ -33,6 +33,40 @@
 				       struct jffs2_inode_info *f, struct jffs2_full_dnode *fn,
 				       uint32_t start, uint32_t end);
 
+/* Check, if we have enough dirty space for GC */
+int jffs2_gc_checkspace (struct jffs2_sb_info *c, int blocksneeded)
+{
+	
+	if (c->dirty_size < blocksneeded * c->sector_size) {
+		
+		uint32_t dirty = 0;
+		struct list_head *this;
+		
+		if (!list_empty(&c->very_dirty_list)) {
+			list_for_each(this, &c->very_dirty_list) {
+				struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+				dirty += jeb->dirty_size;
+			}
+		}
+		if (!list_empty(&c->dirty_list)) {
+			list_for_each(this, &c->dirty_list) {
+				struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+				dirty += jeb->dirty_size;	
+			}
+		}
+		/* Add dirty size of current gc-block */
+		if (c->gcblock)
+			dirty += c->gcblock->dirty_size;
+					
+		if (dirty < c->sector_size) {
+			D1(printk(KERN_DEBUG "dirty size in dirty_lists 0x%08x < sector size 0x%08x\n", dirty, c->sector_size));
+			return 1;
+		}
+	}
+	/* yep, we can GC */
+	return 0;
+}
+
 /* Called with erase_completion_lock held */
 static struct jffs2_eraseblock *jffs2_find_gc_block(struct jffs2_sb_info *c)
 {
Index: fs/jffs2/nodelist.h
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodelist.h,v
retrieving revision 1.75
diff -u -r1.75 nodelist.h
--- fs/jffs2/nodelist.h	17 Aug 2002 22:28:04 -0000	1.75
+++ fs/jffs2/nodelist.h	19 Aug 2002 22:30:43 -0000
@@ -220,8 +220,9 @@
 /* How much dirty space before it goes on the very_dirty_list */
 #define VERYDIRTY(c, size) ((size) >= ((c)->sector_size / 2))
 
-/* check if unused space is more than sector - 2 * sizeof(struct jffs2_raw_inode) */
-#define ISDIRTY(c, size) ((size) < c->sector_size - (2 * sizeof(struct jffs2_raw_inode)))
+/* check if unused space is more than 256 Byte */
+#define ISDIRTY(c, size) ((size) < c->sector_size - 255) 
+#define MNTISDIRTY(c, size) ((size) < c->sector_size - 4) 
 
 #define PAD(x) (((x)+3)&~3)
 
@@ -299,6 +300,7 @@
 
 /* gc.c */
 int jffs2_garbage_collect_pass(struct jffs2_sb_info *c);
+int jffs2_gc_checkspace (struct jffs2_sb_info *c, int blocksneeded);
 
 /* read.c */
 int jffs2_read_dnode(struct jffs2_sb_info *c, struct jffs2_full_dnode *fd, unsigned char *buf, int ofs, int len);
Index: fs/jffs2/nodemgmt.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodemgmt.c,v
retrieving revision 1.71
diff -u -r1.71 nodemgmt.c
--- fs/jffs2/nodemgmt.c	17 Aug 2002 22:32:11 -0000	1.71
+++ fs/jffs2/nodemgmt.c	19 Aug 2002 22:30:44 -0000
@@ -62,32 +62,13 @@
 			int ret;
 
 			up(&c->alloc_sem);
-			if (c->dirty_size < c->sector_size) {
-				D1(printk(KERN_DEBUG "Short on space, but total dirty size 0x%08x < sector size 0x%08x, so -ENOSPC\n", c->dirty_size, c->sector_size));
+			
+			if (jffs2_gc_checkspace(c, blocksneeded)) {
+				D1(printk (KERN_DEBUG "Too little dirty_space for GC, returning -ENOSPC\n"));
 				spin_unlock_bh(&c->erase_completion_lock);
 				return -ENOSPC;
 			}
-			if (c->dirty_size < blocksneeded * c->sector_size) {
-				uint32_t dirty = 0;			
-				struct list_head *this;
-				if (!list_empty(&c->very_dirty_list)) {
-					list_for_each(this, &c->very_dirty_list) {
-						struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
-						dirty += jeb->dirty_size;	
-					}
-				}
-				if (!list_empty(&c->dirty_list)) {
-					list_for_each(this, &c->dirty_list) {
-						struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
-						dirty += jeb->dirty_size;	
-					}
-				}
-				if (dirty < c->sector_size) {
-					D1(printk(KERN_DEBUG "Short on space, but dirty size in dirty_lists 0x%08x < sector size 0x%08x, so -ENOSPC\n", dirty, c->sector_size));
-					spin_unlock_bh(&c->erase_completion_lock);
-					return -ENOSPC;
-				}
-			}
+			
 			D1(printk(KERN_DEBUG "Triggering GC pass. nr_free_blocks %d, nr_erasing_blocks %d, free_size 0x%08x, dirty_size 0x%08x, used_size 0x%08x, erasing_size 0x%08x, bad_size 0x%08x (total 0x%08x of 0x%08x)\n",
 				  c->nr_free_blocks, c->nr_erasing_blocks, c->free_size, c->dirty_size, c->used_size, c->erasing_size, c->bad_size,
 				  c->free_size + c->dirty_size + c->used_size + c->erasing_size + c->bad_size, c->flash_size));
@@ -498,6 +479,8 @@
 #if CONFIG_JFFS2_FS_DEBUG > 0
 void jffs2_dump_block_lists(struct jffs2_sb_info *c)
 {
+
+
 	printk(KERN_DEBUG "jffs2_dump_block_lists:\n");
 	printk(KERN_DEBUG "flash_size: %08x\n", c->flash_size);
 	printk(KERN_DEBUG "used_size: %08x\n", c->used_size);
@@ -522,31 +505,46 @@
 		printk(KERN_DEBUG "clean_list: empty\n");
 	} else {
 		struct list_head *this;
+		int	numblocks = 0;
+		uint32_t dirty = 0;
 
 		list_for_each(this, &c->clean_list) {
 			struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+			numblocks ++;
+			dirty += jeb->dirty_size;
 			printk(KERN_DEBUG "clean_list: %08x (used %08x, dirty %08x, free %08x)\n", jeb->offset, jeb->used_size, jeb->dirty_size, jeb->free_size);
 		}
+		printk (KERN_DEBUG "Contains %d blocks with total dirty size %u, average dirty size: %u\n", numblocks, dirty, dirty / numblocks);
 	}
 	if (list_empty(&c->very_dirty_list)) {
 		printk(KERN_DEBUG "very_dirty_list: empty\n");
 	} else {
 		struct list_head *this;
+		int	numblocks = 0;
+		uint32_t dirty = 0;
 
 		list_for_each(this, &c->very_dirty_list) {
 			struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+			numblocks ++;
+			dirty += jeb->dirty_size;
 			printk(KERN_DEBUG "very_dirty_list: %08x (used %08x, dirty %08x, free %08x)\n", jeb->offset, jeb->used_size, jeb->dirty_size, jeb->free_size);
 		}
+		printk (KERN_DEBUG "Contains %d blocks with total dirty size %u, average dirty size: %u\n", numblocks, dirty, dirty / numblocks);
 	}
 	if (list_empty(&c->dirty_list)) {
 		printk(KERN_DEBUG "dirty_list: empty\n");
 	} else {
 		struct list_head *this;
+		int	numblocks = 0;
+		uint32_t dirty = 0;
 
 		list_for_each(this, &c->dirty_list) {
 			struct jffs2_eraseblock *jeb = list_entry(this, struct jffs2_eraseblock, list);
+			numblocks ++;
+			dirty += jeb->dirty_size;
 			printk(KERN_DEBUG "dirty_list: %08x (used %08x, dirty %08x, free %08x)\n", jeb->offset, jeb->used_size, jeb->dirty_size, jeb->free_size);
 		}
+		printk (KERN_DEBUG "Contains %d blocks with total dirty size %u, average dirty size: %u\n", numblocks, dirty, dirty / numblocks);
 	}
 	if (list_empty(&c->erasable_list)) {
 		printk(KERN_DEBUG "erasable_list: empty\n");
Index: fs/jffs2/scan.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/scan.c,v
retrieving revision 1.80
diff -u -r1.80 scan.c
--- fs/jffs2/scan.c	17 Aug 2002 22:29:28 -0000	1.80
+++ fs/jffs2/scan.c	19 Aug 2002 22:30:47 -0000
@@ -420,7 +420,7 @@
 	if (jeb->used_size == PAD(sizeof(struct jffs2_unknown_node)) && 
 	    !jeb->first_node->next_in_ino && !jeb->dirty_size)
 		return BLK_STATE_CLEANMARKER;
-	else if (!ISDIRTY(c, jeb->used_size)) 
+	else if (!MNTISDIRTY(c, jeb->used_size)) 
 		return BLK_STATE_CLEAN;
 	else if (jeb->used_size)
 		return BLK_STATE_PARTDIRTY;

From mag at sysgo.de  Tue Aug 20 03:40:27 2002
From: mag at sysgo.de (Marius Groeger)
Date: Tue, 20 Aug 2002 09:40:27 +0200 (CEST)
Subject: newbie: dynamic partition creation possible
In-Reply-To: <3D61C1DE.7010202@goepel.com>
Message-ID: <Pine.LNX.4.40.0208200931340.17964-100000@mag.devdep.sysgo.de>

On Tue, 20 Aug 2002, Michael Palme wrote:

> the flash devices (no filesystem etc.). i need different "partitions" on
> the flash and i dont want to hardcode that --
> i have seen in cmdline.c that this is possible via kernel parameters.
> i'm not absolutely sure what kernel options are needed and what are
> unnecessary.

What is unclear with it? cmdline.c contains examples how to use it. Actually
it can be very simple. For instance, the following term will give you two
partitions, one with 1 MiB and another with all the rest. Both will be
read-write and will receive standard labels:

   mtdparts=my-mtd-id:1m,-

However, you may have to adapt the mapping driver to use the cmdline
partitioning. Here's how:

   int num_mtd_parts, result;
   struct mtd_partition *mtd_parts;
   struct mtd_info mtd;

   num_mtd_parts = parse_cmdline_partitions(&mtd, &mtd_parts, "my-mtd-id");
   result = add_mtd_partitions (&mtd, mtd_parts, num_mtd_parts);

As an aside: it is good (but rare) practice to use the various CONFIG_
options for partitioning features.

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions GmbH     mgroeger at sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com




From tglx at linutronix.de  Tue Aug 20 03:59:30 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 20 Aug 2002 09:59:30 +0200
Subject: No free space left for GC
In-Reply-To: <015501c247f3$d13176a0$b30210ac@gv.com.tw>
References: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
 <1029793649.22781.129.camel@thomas.tec.linutronix.de>
 <015501c247f3$d13176a0$b30210ac@gv.com.tw>
Message-ID: <1029830371.22775.150.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-20 at 04:46, ?? wrote:
> in our own old nand flash system
> we always keep 1 nand-flash-block for garbage collection in block device
> driver
> (8k/8MB,16k/64MB)
> it never endless gc, but when diskfull,the speed is really slow
> finally we reserved more space(512k) for gc to  make gc faster
> those reversed space is not showed in fs layer
> we report (real size-reserved space) to fs layer
> and we use minix as fs layer
> (we do  bad block management, wear leveling, error correction,
> all in block device driver not in fs layer)
> recently, we need compression , so we try jffs2:)
> i think the design of jffs2 is also better than our old one:)
1. Please keep answers to mailinglist posting on the list. Thanks.

2. The endless gc, which used up all blocks, is fixed now. I will do
some more tests and put a final version into CVS today.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Tue Aug 20 06:03:53 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 20 Aug 2002 11:03:53 +0100
Subject: No free space left for GC 
In-Reply-To: <1029796472.22781.136.camel@thomas.tec.linutronix.de> 
References: <1029796472.22781.136.camel@thomas.tec.linutronix.de>  <1029623727.2142.495.camel@thomas.tec.linutronix.de> <1029793649.22781.129.camel@thomas.tec.linutronix.de> 
Message-ID: <30887.1029837833@redhat.com>

tglx at linutronix.de said:
>  The new decision function for gc and reserve_space takes only those
> blocks into account, which are on the dirty and very dirty list. The
> dirty space in the clean_list is ignored. This is neccecary to avoid
> endless GC loops. 

> Any suggestions ?

<IRC conversation repeated, for the benefit of the peanut gallery>

Nice work, thanks. If this fixes the problem, as I believe it does, please
don't calculate the dirty size in thread_should_wake() -- use c->dirty_size 
and just don't count the wasted space in the end of blocks on the 
clean_list in that; add something like 'wasted_size' to keep track of that
instead.

And read README.Locking again. It's rare that I actually write sensible 
documentation -- make the most of it :)

--
dwmw2





From joern at wohnheim.fh-wedel.de  Tue Aug 20 06:10:20 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 20 Aug 2002 12:10:20 +0200
Subject: How does one mount an existing jffs2 partition so it is writeable?
In-Reply-To: <3D6186CD.6BCD1850@esteem.com>
References: <3D612C1F.55297C10@esteem.com> <20020819234239.GA6792@wohnheim.fh-wedel.de> <3D6186CD.6BCD1850@esteem.com>
Message-ID: <20020820101020.GA18210@wohnheim.fh-wedel.de>

On Mon, 19 August 2002 17:01:17 -0700, Conn Clark wrote:
> J?rn Engel wrote:
> > On Mon, 19 August 2002 10:34:23 -0700, Conn Clark wrote:
> > >       How does one mount an existing jffs2 partition so it is writeable?
> > > After a reboot I can mount my jffs2 and read from it, but not write to it
> > > I can erase it first and mount it then read and write to it , but then I
> > > lose my info on it which defeats the whole reason for having it.
> > 
> > 1) Append "rw" to kernel command line.
> > 2) mount / -o remount,rw
> 
> 	Didn't work, I get the same message. Did I do it right?
> 
> [/gpig]# cd ..
> [/]# mount /gpig -o remount,rw
> [/]# cd gpig
> [/gpig]# cp ../bin/MAKEDEV .                                                    
> Write of 68 bytes at 0x00059a28 failed. returned 0, retlen 0
> Not marking the space at 0x00059a28 as dirty because the flash driver returned r
> etlen zero
> cp: ./MAKEDEV: Input/output error
> [/gpig]# 

Maybe. If the locking hint from Christopher doesn't work either, we
need more information:
- Number, size and type of flash chips
- output from mount
- kernel version plus applied patches
- ...

Without knowing whether /gpid is the mounted partition in question or
not, my best answer is maybe. :)

J?rn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra



From dwmw2 at infradead.org  Tue Aug 20 06:21:05 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 20 Aug 2002 11:21:05 +0100
Subject: How does one mount an existing jffs2 partition so it is writeable? 
In-Reply-To: <007201c247e0$1022fcd0$a15f040f@SNAGGLE> 
References: <007201c247e0$1022fcd0$a15f040f@SNAGGLE> 
Message-ID: <32719.1029838865@redhat.com>

ch at murgatroid.com said:
>  Do you need to unlock your flash before you can write to it?  That's
> not done automatically by mtd or jffs2.  There's a diff in the ARM
> patch system by me that might be applicable. 

I'm beginning to wonder if we should make JFFS2 unlock automatically if it 
finds at least some JFFS2 nodes. Or put in the 'is_flash_locked' method and 
make JFFS2 notice that it's locked _before_ trying to write to it, and 
print an appropriate message and mount in read-only mode so it doesn't even 
let you _try_ to write to it.

--
dwmw2





From jamey.hicks at hp.com  Tue Aug 20 08:12:20 2002
From: jamey.hicks at hp.com (Jamey Hicks)
Date: Tue, 20 Aug 2002 08:12:20 -0400
Subject: How does one mount an existing jffs2 partition so it is writeable?
References: <007201c247e0$1022fcd0$a15f040f@SNAGGLE> <32719.1029838865@redhat.com>
Message-ID: <3D623224.1090604@hp.com>

David Woodhouse wrote:

>ch at murgatroid.com said:
>  
>
>> Do you need to unlock your flash before you can write to it?  That's
>>not done automatically by mtd or jffs2.  There's a diff in the ARM
>>patch system by me that might be applicable. 
>>    
>>
>
>I'm beginning to wonder if we should make JFFS2 unlock automatically if it 
>finds at least some JFFS2 nodes. Or put in the 'is_flash_locked' method and 
>make JFFS2 notice that it's locked _before_ trying to write to it, and 
>print an appropriate message and mount in read-only mode so it doesn't even 
>let you _try_ to write to it.
>  
>
I would much rather that JFFS2 not unlock blocks automatically.  We tend 
to lock blocks for a reason (e.g., so that we don't accidentally erase 
the boot loader with incorrect mount options).  I think it would be 
reasonable for JFFS2 to query whether flash is locked beforehand and to 
mount read-only.  I think it would also be reasonable to provide a mount 
option directing it to unlock flash.  

Jamey





From dwmw2 at infradead.org  Tue Aug 20 08:19:14 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 20 Aug 2002 13:19:14 +0100
Subject: How does one mount an existing jffs2 partition so it is writeable? 
In-Reply-To: <3D623224.1090604@hp.com> 
References: <3D623224.1090604@hp.com>  <007201c247e0$1022fcd0$a15f040f@SNAGGLE> <32719.1029838865@redhat.com> 
Message-ID: <12777.1029845954@redhat.com>

jamey.hicks at hp.com said:
>  I would much rather that JFFS2 not unlock blocks automatically.  We
> tend  to lock blocks for a reason (e.g., so that we don't accidentally
> erase  the boot loader with incorrect mount options).  I think it
> would be  reasonable for JFFS2 to query whether flash is locked
> beforehand and to  mount read-only.  I think it would also be
> reasonable to provide a mount  option directing it to unlock flash.  

Yeah -- you're probably right. That's the reason I refused to do the 
automatic unlock when it was originally suggested. We are fairly good about 
aborting a mount attempt if it really doesn't look like a JFFS2 partition, 
but if you have the partitioning wrong so that the range we try to mount 
includes some JFFS2 _and_ something important, that's still going to break.


--
dwmw2





From joern at wohnheim.fh-wedel.de  Tue Aug 20 09:12:04 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 20 Aug 2002 15:12:04 +0200
Subject: How does one mount an existing jffs2 partition so it is writeable?
In-Reply-To: <12777.1029845954@redhat.com>
References: <3D623224.1090604@hp.com> <007201c247e0$1022fcd0$a15f040f@SNAGGLE> <32719.1029838865@redhat.com> <12777.1029845954@redhat.com>
Message-ID: <20020820131204.GA25918@wohnheim.fh-wedel.de>

On Tue, 20 August 2002 13:19:14 +0100, David Woodhouse wrote:
> Yeah -- you're probably right. That's the reason I refused to do the 
> automatic unlock when it was originally suggested. We are fairly good about 
> aborting a mount attempt if it really doesn't look like a JFFS2 partition, 
> but if you have the partitioning wrong so that the range we try to mount 
> includes some JFFS2 _and_ something important, that's still going to break.

And if we have an old jffs2 partition that was partially overwritten
by cramfs. Without a prior erase, this will be identified as jffs2.

Pretty rare in production systems, though.

J?rn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu



From tglx at linutronix.de  Tue Aug 20 11:47:34 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 20 Aug 2002 17:47:34 +0200
Subject: No free space left for GC
In-Reply-To: <1029830371.22775.150.camel@thomas.tec.linutronix.de>
References: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
 <1029793649.22781.129.camel@thomas.tec.linutronix.de>
 <015501c247f3$d13176a0$b30210ac@gv.com.tw>
 <1029830371.22775.150.camel@thomas.tec.linutronix.de>
Message-ID: <1029858455.23122.191.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-20 at 09:59, Thomas Gleixner wrote:
> 2. The endless gc, which used up all blocks, is fixed now. I will do
> some more tests and put a final version into CVS today.
Is there, please try again. 

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From ch at murgatroid.com  Tue Aug 20 12:34:12 2002
From: ch at murgatroid.com (Christopher Hoover)
Date: Tue, 20 Aug 2002 09:34:12 -0700
Subject: How does one mount an existing jffs2 partition so it is writeable?
In-Reply-To: <3D623224.1090604@hp.com>
Message-ID: <000301c24867$6a81ad70$7800000a@derelict>

> I would much rather that JFFS2 not unlock blocks automatically.  We
tend 
> to lock blocks for a reason (e.g., so that we don't accidentally erase

> the boot loader with incorrect mount options).

You have a different flavor flash.  My platform uses Intel C3
StrataFlash parts.  The flash is completely locked after any power
cycle.   If I don't unlock the jffs2 partition somehow someway, I can't
write to it.

I suppose we could add yet another mount option for this
("really_and_truly_rw"!).

-ch
ch at murgatroid.com
ch at hpl.hp.com




From clark at esteem.com  Tue Aug 20 13:26:31 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 20 Aug 2002 10:26:31 -0700
Subject: How does one mount an existing jffs2 partition so it is  
 writeable?
References: <007201c247e0$1022fcd0$a15f040f@SNAGGLE>
Message-ID: <3D627BC7.DD6B6823@esteem.com>

Christopher Hoover wrote:
> 
> Do you need to unlock your flash before you can write to it?  That's not
> done automatically by mtd or jffs2.  There's a diff in the ARM patch
> system by me that might be applicable.
> 
> -ch
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

This is what I needed to know and is probably the culprit. However my unlock
utility is broken. I can tell this because it doesn't even try to move through
the sectors in the partition like the lock command does.


I think I have it under control now.

Thanks.

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From clark at esteem.com  Tue Aug 20 14:02:16 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 20 Aug 2002 11:02:16 -0700
Subject: How does one mount an existing jffs2 partition so it is  
 writeable?
References: <007201c247e0$1022fcd0$a15f040f@SNAGGLE> <3D627BC7.DD6B6823@esteem.com>
Message-ID: <3D628428.312055B5@esteem.com>

Conn Clark wrote:
> 
> Christopher Hoover wrote:
> >
> > Do you need to unlock your flash before you can write to it?  That's not
> > done automatically by mtd or jffs2.  There's a diff in the ARM patch
> > system by me that might be applicable.
> >
> > -ch
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> This is what I needed to know and is probably the culprit. However my unlock
> utility is broken. I can tell this because it doesn't even try to move through
> the sectors in the partition like the lock command does.
> 
> I think I have it under control now.
> 
> Thanks.
> 
>         Conn
 I meant to say move through the sectors like the erase command, however I
can see that the lock command works very similar to the unlock command. This
makes me suspect that I have something wrong in the kernel code.

here is what I have.

I am running on a MPC850 PowerPC processor.
I am using a single intel TE28F320C3BA110 flash chip mapped as a 16 bit device. 
I am using kernel 2.4.19 from kernel.org with the shared zlib patch.

I had to change 2 lines in cfi_cmdset_0001.c from

        extp->FeatureSupport = cfi32_to_cpu(extp->FeatureSupport);
        extp->BlkStatusRegMask = cfi32_to_cpu(extp->BlkStatusRegMask);

to

        extp->FeatureSupport = le32_to_cpu(extp->FeatureSupport);
        extp->BlkStatusRegMask = le16_to_cpu(extp->BlkStatusRegMask);

in order to fix an endian issue.

I had to create a custom map driver as well.

Any ideas on what else I have to change to get the lock/unlock commands to work?

Thanks in advance,
        Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From ch at murgatroid.com  Tue Aug 20 14:18:56 2002
From: ch at murgatroid.com (Christopher Hoover)
Date: Tue, 20 Aug 2002 11:18:56 -0700
Subject: How does one mount an existing jffs2 partition so it is   writeable?
In-Reply-To: <3D628428.312055B5@esteem.com>
Message-ID: <004001c24876$0c2ad670$7800000a@derelict>

At one point locking and unlocking flash with variable-sized blocks
(such as Intel C3 flash) simply didn't work.  I fixed it -- the correct
code is in CVS and in current 2.4 (after some release I cannot
remember), but the changes unfortunately aren't in 2.5.

Check drivers/mtd/chips/cfi_cmdset_0001.c in your sources.   You should
see a changelog entry from me dated 02/05/2002; if you don't see it, you
don't have the fix.

-ch
ch at murgatroid.com
ch at hpl.hp.com




From clark at esteem.com  Tue Aug 20 14:42:29 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 20 Aug 2002 11:42:29 -0700
Subject: How does one mount an existing jffs2 partition so it is   writeable?
References: <004001c24876$0c2ad670$7800000a@derelict>
Message-ID: <3D628D95.9447D6B6@esteem.com>

Christopher Hoover wrote:
> 
> At one point locking and unlocking flash with variable-sized blocks
> (such as Intel C3 flash) simply didn't work.  I fixed it -- the correct
> code is in CVS and in current 2.4 (after some release I cannot
> remember), but the changes unfortunately aren't in 2.5.
> 
> Check drivers/mtd/chips/cfi_cmdset_0001.c in your sources.   You should
> see a changelog entry from me dated 02/05/2002; if you don't see it, you
> don't have the fix.
> 
> -ch
> ch at murgatroid.com
> ch at hpl.hp.com

I don't have it. Can I just drop it in or are there other files I need to
get/update? I haven't used CVS before so I will need help doing that if thats
the best way of getting all relevant files. 

Thanks

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From joern at wohnheim.fh-wedel.de  Tue Aug 20 15:24:08 2002
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Tue, 20 Aug 2002 21:24:08 +0200
Subject: How does one mount an existing jffs2 partition so it is writeable?
In-Reply-To: <000301c24867$6a81ad70$7800000a@derelict>
References: <3D623224.1090604@hp.com> <000301c24867$6a81ad70$7800000a@derelict>
Message-ID: <20020820192408.GA19731@wohnheim.fh-wedel.de>

On Tue, 20 August 2002 09:34:12 -0700, Christopher Hoover wrote:
> You have a different flavor flash.  My platform uses Intel C3
> StrataFlash parts.  The flash is completely locked after any power
> cycle.   If I don't unlock the jffs2 partition somehow someway, I can't
> write to it.
> 
> I suppose we could add yet another mount option for this
> ("really_and_truly_rw"!).

If this is a problem (feature/whatever) of one flash type, why not
encapsulate it in the low level driver? It would keep the jffs2 code
clean of what could be considered a bugfix.

J?rn

-- 
I can say that I spend most of my time fixing bugs even if I have lots
of new features to implement in mind, but I give bugs more priority.
-- Andrea Arcangeli, 2000



From ch at murgatroid.com  Tue Aug 20 17:45:42 2002
From: ch at murgatroid.com (Christopher Hoover)
Date: Tue, 20 Aug 2002 14:45:42 -0700
Subject: How does one mount an existing jffs2 partition so it is writeable?
In-Reply-To: <20020820192408.GA19731@wohnheim.fh-wedel.de>
Message-ID: <004801c24892$eead6000$7800000a@derelict>

> If this is a problem (feature/whatever) of one flash type, why not
> encapsulate it in the low level driver? It would keep the jffs2 code
> clean of what could be considered a bugfix.

That was my first thought. I submitted such a patch (-- it should be in
the archives), but IIRC David didn't want it applied to CVS.  He
suggested that I move this to the SA-1100 partition code.   I did that,
but that has its own ugliness.

-ch





From dwmw2 at infradead.org  Tue Aug 20 17:46:57 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 20 Aug 2002 22:46:57 +0100
Subject: How does one mount an existing jffs2 partition so it is writeable? 
In-Reply-To: <004801c24892$eead6000$7800000a@derelict> 
References: <004801c24892$eead6000$7800000a@derelict> 
Message-ID: <10406.1029880017@redhat.com>

ch at murgatroid.com said:
> That was my first thought. I submitted such a patch (-- it should be
> in the archives), but IIRC David didn't want it applied to CVS.  He
> suggested that I move this to the SA-1100 partition code.   I did
> that, but that has its own ugliness.

I never claimed not to be fickle. If your patch did the unlock 
automatically _only_ for the C3 flash which locks itself every power cycle, 
try me again :)

--
dwmw2





From ch at murgatroid.com  Tue Aug 20 17:50:12 2002
From: ch at murgatroid.com (Christopher Hoover)
Date: Tue, 20 Aug 2002 14:50:12 -0700
Subject: How does one mount an existing jffs2 partition so it is   writeable?
In-Reply-To: <3D628D95.9447D6B6@esteem.com>
Message-ID: <005001c24893$8f78b480$7800000a@derelict>

Here's the patch against 2.5.18-rmk1. It applies cleanly to all kernels
since.

http://www.murgatroid.com/badge4/release/ch-release-2002-07-14/src/kerne
l-patches/linux-2.5.18-rmk1-mtd-intel-varsize.patch

-ch


> -----Original Message-----
> From: root at esteem.com [mailto:root at esteem.com] On Behalf Of Conn Clark
> Sent: Tuesday, August 20, 2002 11:42 AM
> To: Christopher Hoover
> Cc: MTD Mailing List
> Subject: Re: How does one mount an existing jffs2 partition 
> so it is writeable?
> 
> 
> Christopher Hoover wrote:
> > 
> > At one point locking and unlocking flash with variable-sized blocks
> > (such as Intel C3 flash) simply didn't work.  I fixed it -- 
> the correct
> > code is in CVS and in current 2.4 (after some release I cannot
> > remember), but the changes unfortunately aren't in 2.5.
> > 
> > Check drivers/mtd/chips/cfi_cmdset_0001.c in your sources.  
>  You should
> > see a changelog entry from me dated 02/05/2002; if you 
> don't see it, you
> > don't have the fix.
> > 
> > -ch
> > ch at murgatroid.com
> > ch at hpl.hp.com
> 
> I don't have it. Can I just drop it in or are there other 
> files I need to
> get/update? I haven't used CVS before so I will need help 
> doing that if thats
> the best way of getting all relevant files. 
> 
> Thanks
> 
> 	Conn
> -- 
> 
> *****************************************************************
>   If you live at home long enough, your parents will move out.
>  (Warning they may try to sell their house out from under you.)
> *****************************************************************
> 
> Conn Clark
> Engineering Stooge				clark at esteem.com
> Electronic Systems Technology Inc.		www.esteem.com
> 
> Stock Ticker Symbol				ELST
> 
> "clark at esteem.com" Copyright 2000 By Electronic Systems Technology
>  This email address may be used to communicate to Conn Clark
>  provided it is not being used for advertisement purposes, unless
>  prior written consent is given. This email address may not be 
>  sold under any circumstances. All other rights reserved.
> 




From clark at esteem.com  Tue Aug 20 20:15:57 2002
From: clark at esteem.com (Conn Clark)
Date: Tue, 20 Aug 2002 17:15:57 -0700
Subject: How does one mount an existing jffs2 partition so it is   writeable?
References: <000001c2489f$bf76d070$7c00000a@SNAGGLE>
Message-ID: <3D62DBBD.844DD24A@esteem.com>

Christopher Hoover wrote:
> 
> I assumed you were running 2.5.   Try to apply it and see how clean it
> applies.
> 

It applied with out a catch and everything seems to work like its supposed
to now.

Thank you very very much.

	Conn

-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From xjin at redswitch.com  Tue Aug 20 22:40:20 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Tue, 20 Aug 2002 19:40:20 -0700
Subject: basic question on CFI flash and JEDEC flash
Message-ID: <3D62FD94.10009@redswitch.com>

A basic question on flash memory. What's the difference between CFI and 
JEDEC flash?

I'm trying to add support of AMD Am29LV642D in MTD. After looking into 
MTD device drivers, I found three source files doing flash memory probe. 
They are cfi_probe.c, jedec_probe.c and jedec.c. The comments on jedec.c 
clearly descibe its usage. But I don't quite understand the other two 
files. Literally cfi_probe.c does cfi-compliant flash probe and 
jedec_probe.c does jedec flash probe. My confusion comes from that 
jedec_probe.c actually calls many cfi-related functions. So what should 
I do to support Am29LV642D?

BTW, I successfully added Intel I28F160F3T support, which is an JEDEC 
type flash (not sure about this, :(), by adding corresponding 
information into jedec_table[].

Thanks.

- Shawn.




From kevin at gv.com.tw  Wed Aug 21 02:44:28 2002
From: kevin at gv.com.tw (=?big5?B?pHCp+g==?=)
Date: Wed, 21 Aug 2002 14:44:28 +0800
Subject: can i use the cvs code directly in kernel 2.2.19 ?
References: <1029623727.2142.495.camel@thomas.tec.linutronix.de> <1029793649.22781.129.camel@thomas.tec.linutronix.de> <015501c247f3$d13176a0$b30210ac@gv.com.tw> <1029830371.22775.150.camel@thomas.tec.linutronix.de> <1029858455.23122.191.camel@thomas.tec.linutronix.de>
Message-ID: <000b01c248de$37c21100$b30210ac@gv.com.tw>

dear all,
another question:
can i use the cvs code directly in kernel 2.2.19 ?
(currently it work fine with kernel 2.4.17)




From tglx at linutronix.de  Wed Aug 21 03:56:54 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 21 Aug 2002 09:56:54 +0200
Subject: can i use the cvs code directly in kernel 2.2.19 ?
In-Reply-To: <000b01c248de$37c21100$b30210ac@gv.com.tw>
References: <1029623727.2142.495.camel@thomas.tec.linutronix.de>
 <1029793649.22781.129.camel@thomas.tec.linutronix.de>
 <015501c247f3$d13176a0$b30210ac@gv.com.tw>
 <1029830371.22775.150.camel@thomas.tec.linutronix.de>
 <1029858455.23122.191.camel@thomas.tec.linutronix.de>
 <000b01c248de$37c21100$b30210ac@gv.com.tw>
Message-ID: <1029916619.1695.6.camel@thomas.tec.linutronix.de>

On Wed, 2002-08-21 at 08:44, ?? wrote:
> dear all,
> another question:
> can i use the cvs code directly in kernel 2.2.19 ?
> (currently it work fine with kernel 2.4.17)
Look for the inter_module patch in the patches/ directory of CVS.
It's for 2.2.17, but should apply to 2.2.19 too. There are some more
tweaks neccecary. There are 2 mailthreads (june, august 02) about that.
Citation dwmw2:
> I know of nobody else working on a 2.2 backport. Worst case, you 
> should be able to ditch the page-based write code and call
> jffs2_write_file_range() from a jffs2_file_write() which you provide
> instead of generic_file_write().

BTW, did you test latest code in CVS ? Any problems left ?

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From stefan.thomasson at possio.com  Wed Aug 21 05:26:52 2002
From: stefan.thomasson at possio.com (Stefan Thomasson)
Date: Wed, 21 Aug 2002 11:26:52 +0200
Subject: Status of strataflash K3 ?
Message-ID: <3D635CDC.1654F5B7@possio.com>

Hi,

I saw someone asking about the K3 a couple of days ago and wondering
about the status of this driver. 

Since we are maybe going to migrate from th J3 to K3 I would 
like to know any disadvantages in having it prepared for the synchronous
modes
available, but not using it in software.

Will all cfi compliant chips work without any driver modifications? 


Regards
Stefan



From clark at esteem.com  Wed Aug 21 13:00:16 2002
From: clark at esteem.com (Conn Clark)
Date: Wed, 21 Aug 2002 10:00:16 -0700
Subject: Where do you guys hang out on the IRC?
Message-ID: <3D63C720.3325FC60@esteem.com>

Hello,

With the post of the IRC discussion, I was wondering what channel and network
you guys hang out and discuss this stuff in? 


Thanks

	Conn
-- 

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark at esteem.com
Electronic Systems Technology Inc.		www.esteem.com

Stock Ticker Symbol				ELST

"clark at esteem.com" Copyright 2000 By Electronic Systems Technology
 This email address may be used to communicate to Conn Clark
 provided it is not being used for advertisement purposes, unless
 prior written consent is given. This email address may not be 
 sold under any circumstances. All other rights reserved.



From koffer at arlut.utexas.edu  Wed Aug 21 14:43:34 2002
From: koffer at arlut.utexas.edu (Ken Offer)
Date: Wed, 21 Aug 2002 13:43:34 -0500
Subject: Cannot mount my NAND device with JFFS2
Message-ID: <E5BE2C26-B535-11D6-92ED-000393467F1A@arlut.utexas.edu>

Hi all,

I can erase and test my smart media card NAND driver just fine 
(i.e. eraseall seems to work, nandtest works, mtd0 and mtd1 show 
up in /proc/mtd).  So far so good.  However, when I try to mount 
the device with jffs2 I get:

 > mount -v -t jffs2 /dev/mtdblock1 /mnt/jffs
mount: wrong fs type, bad option, bad superblock on /dev/mtdblock1,
        or too many mounted file systems

I have:

(a) applied the 
"ftp://ftp.??.kernel.org/pub/linux/kernel/people/dwmw2/shared-
zlib/linux-2.4.19-pre10-shared-zlib.bz2" patch to a 2.4.19 
kernel,
(b) copied the latest and greatest cvs mtd/jffs2 sources into my kernel,
(c) made the appropriate changes to "file.c" for Page_uptodate,
(d) made the change for "CONFIG_JFFS2_FS_NAND" to "fs/Config.in",
(e) made a change to "include/linux/mtd/compatmac.h" to define 
"set_user_nice" (isn't defined for 2.4.19).

My driver is based on the autcpu12 driver in the nand sources.  
I have noticed that there is a "autcpu12-nvram" map driver to 
perform NVRAM mapping.  Is such a mapping device REQUIRED for 
JFFS2 support???  Or is it just for mapping the device to 
address space for other purposes?  The documentation is not 
clear (what's new...)

Got any ideas?

+-----------------------------------------------------------+
|  Ken Offer        koffer at arlut.utexas.edu         ARL:UT  |
|  Office: 512-835-3859                  Fax: 512-835-3259  |
+-----------------------------------------------------------+




From tglx at linutronix.de  Wed Aug 21 15:20:54 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 21 Aug 2002 21:20:54 +0200
Subject: Cannot mount my NAND device with JFFS2
In-Reply-To: <E5BE2C26-B535-11D6-92ED-000393467F1A@arlut.utexas.edu>
References: <E5BE2C26-B535-11D6-92ED-000393467F1A@arlut.utexas.edu>
Message-ID: <1029957655.3996.4.camel@thomas.tec.linutronix.de>

On Wed, 2002-08-21 at 20:43, Ken Offer wrote:
> Hi all,
> 
> I can erase and test my smart media card NAND driver just fine 
> (i.e. eraseall seems to work, nandtest works, mtd0 and mtd1 show 
> up in /proc/mtd).  So far so good.  However, when I try to mount 
> the device with jffs2 I get:
>  > mount -v -t jffs2 /dev/mtdblock1 /mnt/jffs
> mount: wrong fs type, bad option, bad superblock on /dev/mtdblock1,
>         or too many mounted file systems
Have you erased the flash before mount or have you copied stuff to the
flash ?
Can you please turn on JFFS2 debugging  to 1 and send the output ? 
make sure that you do
#echo 9 >proc/sys/kernel/printk

> I have:
> 
> (a) applied the 
> "ftp://ftp.??.kernel.org/pub/linux/kernel/people/dwmw2/shared-
> zlib/linux-2.4.19-pre10-shared-zlib.bz2" patch to a 2.4.19 
> kernel,
> (b) copied the latest and greatest cvs mtd/jffs2 sources into my kernel,
> (c) made the appropriate changes to "file.c" for Page_uptodate,
???
> (d) made the change for "CONFIG_JFFS2_FS_NAND" to "fs/Config.in",
> (e) made a change to "include/linux/mtd/compatmac.h" to define 
> "set_user_nice" (isn't defined for 2.4.19).
looks good. 
> My driver is based on the autcpu12 driver in the nand sources.  
good choice :)
> I have noticed that there is a "autcpu12-nvram" map driver to 
> perform NVRAM mapping.  Is such a mapping device REQUIRED for 
> JFFS2 support???  Or is it just for mapping the device to 
> address space for other purposes?  The documentation is not 
> clear (what's new...)
nvram is Non-Volatile-Ram and used for total different stuff 
> Got any ideas?
See above
-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From koffer at arlut.utexas.edu  Wed Aug 21 15:36:34 2002
From: koffer at arlut.utexas.edu (Ken Offer)
Date: Wed, 21 Aug 2002 14:36:34 -0500
Subject: Cannot mount my NAND device with JFFS2
In-Reply-To: <1029957655.3996.4.camel@thomas.tec.linutronix.de>
Message-ID: <4D4AAA26-B53D-11D6-92ED-000393467F1A@arlut.utexas.edu>

On Wednesday, August 21, 2002, at 02:20  PM, Thomas Gleixner wrote:

> On Wed, 2002-08-21 at 20:43, Ken Offer wrote:
>> Hi all,
>>
>> I can erase and test my smart media card NAND driver just fine
>> (i.e. eraseall seems to work, nandtest works, mtd0 and mtd1 show
>> up in /proc/mtd).  So far so good.  However, when I try to mount
>> the device with jffs2 I get:
>>> mount -v -t jffs2 /dev/mtdblock1 /mnt/jffs
>> mount: wrong fs type, bad option, bad superblock on /dev/mtdblock1,
>>         or too many mounted file systems
> Have you erased the flash before mount or have you copied stuff to the
> flash ?
> Can you please turn on JFFS2 debugging  to 1 and send the output ?
> make sure that you do
> #echo 9 >proc/sys/kernel/printk

Thanks for the reply!  Got it to work finally.  I had two kernel 
trees going and inadvertently forgot to turn on 
"CONFIG_JFFS2_FS_NAND" in the latest version.  I assumed it was 
on (duh, it was in the old tree...)

+-----------------------------------------------------------+
|  Ken Offer        koffer at arlut.utexas.edu         ARL:UT  |
|  Office: 512-835-3859                  Fax: 512-835-3259  |
+-----------------------------------------------------------+




From dwmw2 at infradead.org  Wed Aug 21 15:53:03 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 21 Aug 2002 20:53:03 +0100
Subject: Where do you guys hang out on the IRC? 
In-Reply-To: <3D63C720.3325FC60@esteem.com> 
References: <3D63C720.3325FC60@esteem.com> 
Message-ID: <4398.1029959583@redhat.com>

clark at esteem.com said:
> With the post of the IRC discussion, I was wondering what channel and
> network you guys hang out and discuss this stuff in? 

irc.openprojects.net #mtd

--
dwmw2





From koffer at arlut.utexas.edu  Wed Aug 21 16:01:09 2002
From: koffer at arlut.utexas.edu (Ken Offer)
Date: Wed, 21 Aug 2002 15:01:09 -0500
Subject: cp of jffs image wants to clobber /dev/mtd1 node.
Message-ID: <BC765B75-B540-11D6-92ED-000393467F1A@arlut.utexas.edu>

Anybody else run into this?

I try to copy my jffs2 image created with:

     ./mkfs.jffs2 -r simple_directory -e 16K -l -o /tmp/test.img

like so

     cp /tmp/test.img /dev/mtd1

And Linux wants to overwrite my "/dev/mtd1" node...

     cp: overwrite `/dev/mtd1'?

If I let it, Linux replaces the file "/dev/mtd1" with the 
contents of test.img, instead of copying test.img TO the DEVICE 
"/dev/mtd1".  Its acting as if "/dev/mtd1" is a simple file 
instead of a device node.

The node looks correctly created:

crw-rw----    1 root     disk      90,   2 Aug 19 08:43 /dev/mtd1

+-----------------------------------------------------------+
|  Ken Offer        koffer at arlut.utexas.edu         ARL:UT  |
|  Office: 512-835-3859                  Fax: 512-835-3259  |
+-----------------------------------------------------------+




From andrew at hainsworth.ath.cx  Wed Aug 21 22:24:14 2002
From: andrew at hainsworth.ath.cx (Andrew Hainsworth)
Date: Thu, 22 Aug 2002 12:24:14 +1000
Subject: DiskOnChip - not found?
Message-ID: <4.3.2.7.2.20020822114908.00c8ee70@10.0.0.8>

Good morning/afternoon/evening

I have only just joined this list, so please excuse me if this has been 
asked before (there were a lot of archives to troll through for answers...)

I have a 32 meg DoC2000 sitting in an ISA riser board on an i386 running 
RedHat 7.2 (catch all that?)

When I compile the kernel with MTD support, install it and reboot, I get 
this output:

Possible DiskOnChip with unknown ChipID FF found at 0xfffc8000
Possible DiskOnChip with unknown ChipID FF found at 0xfffca000
Possible DiskOnChip with unknown ChipID FF found at 0xfffcc000
Possible DiskOnChip with unknown ChipID FF found at 0xfffce000
Possible DiskOnChip with unknown ChipID FF found at 0xfffd0000
Possible DiskOnChip with unknown ChipID FF found at 0xfffd2000
Possible DiskOnChip with unknown ChipID FF found at 0xfffd4000
Possible DiskOnChip with unknown ChipID FF found at 0xfffd6000
Possible DiskOnChip with unknown ChipID FF found at 0xfffd8000
Possible DiskOnChip with unknown ChipID FF found at 0xfffda000
Possible DiskOnChip with unknown ChipID FF found at 0xfffdc000
Possible DiskOnChip with unknown ChipID FF found at 0xfffde000
Possible DiskOnChip with unknown ChipID FF found at 0xfffe0000
Possible DiskOnChip with unknown ChipID FF found at 0xfffe2000
Possible DiskOnChip with unknown ChipID FF found at 0xfffe4000
Possible DiskOnChip with unknown ChipID FF found at 0xfffe6000
Possible DiskOnChip with unknown ChipID FF found at 0xfffe8000
Possible DiskOnChip with unknown ChipID FF found at 0xfffea000
Possible DiskOnChip with unknown ChipID FF found at 0xfffec000
Possible DiskOnChip with unknown ChipID FF found at 0xfffee000
No recognised DiskOnChip devices found

All of those addresses are the ones the ISA board will use, but it cannot 
find anything!

Any ideas?  If you need more info, I will get it.

Cheers
Andrew




From dwmw2 at infradead.org  Thu Aug 22 04:18:52 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 22 Aug 2002 09:18:52 +0100
Subject: DiskOnChip - not found? 
In-Reply-To: <4.3.2.7.2.20020822114908.00c8ee70@10.0.0.8> 
References: <4.3.2.7.2.20020822114908.00c8ee70@10.0.0.8> 
Message-ID: <8941.1030004332@redhat.com>

andrew at hainsworth.ath.cx said:
>  All of those addresses are the ones the ISA board will use, but it
> cannot  find anything! 

No they're not. Turn off CONFIG_MTD_DOCPROBE_ADVANCED.

--
dwmw2





From jan.van.de.kraats at kabelfoon.nl  Thu Aug 22 10:20:14 2002
From: jan.van.de.kraats at kabelfoon.nl (Jan A van de Kraats)
Date: Thu, 22 Aug 2002 16:20:14 +0200
Subject: SPAM
Message-ID: <5.1.1.6.0.20020822160957.00b41200@pop.kabelfoon.nl>

Geachte Heer Mobach,
We hebben vorig jaar een uitgebreide briefwisseling gehad over 
http://lists.infradead.org/pipermail/linux-mtd/2001-November/003585.html
Ik heb toen mijn excuses aangeboden voor deze situatie, veroorzaakt door 
het gebruik van een email extractor die mij aanbevolen was om het saaie 
werk van handmatig opsporen van onderzoekers bij water instituten te 
omzeilen. Het bleek echter helemaal fout te zijn gegaan: vele anderen 
hadden ook een mail gekregen en waren daar terecht niet blij mee.
Ik heb uiteraard van dit programma geen gebruik meer gemaakt.
Inmiddels is het nog steeds zo dat een zoektocht voor informatie naar mij 
ogenblikkelijk naar bovenstaande site leidt, en dat terwijl ik inmiddels al 
een half jaar met pensioen ben.
Zou het mogelijk zijn deze site te verwijderen?
Bij voorbaat mijn dank!
Vriendelijke groeten,
Jan van de Kraats.





From olivier.eribon at free.fr  Tue Aug 27 02:13:21 2002
From: olivier.eribon at free.fr (olivier.eribon at free.fr)
Date: Tue, 27 Aug 2002 08:13:21 +0200 (MEST)
Subject: Cannot remove child on JFFS2 FS
Message-ID: <1030428801.3d6b1881e7ed3@imp.free.fr>

Hello,

I am using JFFS2 (from CVS july 01 2002) and 2.4.17 linux kernel on a specific 
board (ppc405gp with a nand flash : Toshiba TC58256FT/DC)

After booting on linux with nand flash FS, I create a directory (dir) and I put 
some files
> mkdir /dir
> cp /src/file* /dir
Now I remove all files from this directory
> rm /dir/*
I remove the directory too
> rmdir /dir

Now, after reboot for each FS mount and for each file on the removed directory, 
this message appears on console :
Cannot remove child "fileXXX", ino #0, because it doesn't exist

How can I solve this problem ? (because this message induce long time to
mount partition.)

Thanks in advance for your time and your help !

Best regards,

Olivier



From tglx at linutronix.de  Tue Aug 27 03:13:08 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 27 Aug 2002 09:13:08 +0200
Subject: Cannot remove child on JFFS2 FS
In-Reply-To: <1030428801.3d6b1881e7ed3@imp.free.fr>
References: <1030428801.3d6b1881e7ed3@imp.free.fr>
Message-ID: <1030432389.12249.0.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-27 at 08:13, olivier.eribon at free.fr wrote:
> Now, after reboot for each FS mount and for each file on the removed directory, 
> this message appears on console :
> Cannot remove child "fileXXX", ino #0, because it doesn't exist
> 
> How can I solve this problem ? (because this message induce long time to
> mount partition.)
Use latest CVS code. It's fixed there.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From m.palme at goepel.com  Tue Aug 27 15:03:25 2002
From: m.palme at goepel.com (Michael Palme)
Date: Tue, 27 Aug 2002 21:03:25 +0200
Subject: flash file system for production use
Message-ID: <3D6BCCFD.4090707@goepel.com>

hello...

i've got a strongarm system with 32mb intel strata flash. i need a 
mechanism for storing configuration files etc in the flashes. for this 
purpose 20mb of the flashes are free. the performance/ stability thing 
is very important for me. i cant wait 10 secs fot mounting/ checking 
etc. i' ve tried jffs2 from CVS and it seems to be "fast" on a nearly 
empty flash partition, but i have no suggestion about what happens in 
hard production use, when the flash will be written  over and over again 
and the wear leveling takes place. the device is never shutdown'ed in a 
clean way -- always hard power off...

because i have 20megs free and only small information to store i think 
there is no need for a complex wear leveling mechanism but im not an expert.

what the best solution fot my problems???

please give some hints....


thanks in advance ... Michael Palme

-- 
-------------------------------
Dipl.-Ing. (FH)
Michael Palme
software engineer
Goepel electronic GmbH

mailto: m.palme at goepel.com
phone:  +493641689682
fax:    +493641689644
inet:   http://www.goepel.com
-------------------------------





From dwmw2 at infradead.org  Tue Aug 27 15:24:56 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 27 Aug 2002 20:24:56 +0100
Subject: flash file system for production use 
In-Reply-To: <3D6BCCFD.4090707@goepel.com> 
References: <3D6BCCFD.4090707@goepel.com> 
Message-ID: <27451.1030476296@redhat.com>

m.palme at goepel.com said:
>  i need a  mechanism for storing configuration files etc in the
> flashes. for this  purpose 20mb of the flashes are free. the
> performance/ stability thing  is very important for me. i cant wait 10
> secs fot mounting/ checking  etc. i' ve tried jffs2 from CVS and it
> seems to be "fast" on a nearly  empty flash partition, but i have no
> suggestion about what happens in  hard production use, when the flash
> will be written  over and over again  and the wear leveling takes
> place. the device is never shutdown'ed in a  clean way -- always hard
> power off... 

JFFS2 from CVS should be fine. It hasn't had as much hard testing as the
stable branch, but I have no particular reason to expect it to be broken on
NOR flash. I wouldn't ship it to a customer before doing some serious
retesting, but you can do that yourself and report anything you find -- I
don't expect anything to break.

There are other things we can do to improve performance and mount time even
more than we've already done in CVS. They're listed in the TODO file, and if
you're likely to actually implement them I'm happy to give more explicit
pointers -- or I can set our salesdroids on you if that would be useful :)

--
dwmw2





From m.palme at goepel.com  Tue Aug 27 15:38:33 2002
From: m.palme at goepel.com (Michael Palme)
Date: Tue, 27 Aug 2002 21:38:33 +0200
Subject: flash file system for production use
References: <3D6BCCFD.4090707@goepel.com> <27451.1030476296@redhat.com>
Message-ID: <3D6BD539.4050101@goepel.com>

okay... thanks for the answer.
i will do some serious testing myself. what would be a real life 
scenario ??? is a random loop with creating, writing and deleting files 
mixed with mounting and unmounting and some random powerfaults???

i think the salesdroids- thing will not work: they only thing they want 
is to get a product to the market as fast as they can...

David Woodhouse schrieb:

>m.palme at goepel.com said:
>  
>
>> i need a  mechanism for storing configuration files etc in the
>>flashes. for this  purpose 20mb of the flashes are free. the
>>performance/ stability thing  is very important for me. i cant wait 10
>>secs fot mounting/ checking  etc. i' ve tried jffs2 from CVS and it
>>seems to be "fast" on a nearly  empty flash partition, but i have no
>>suggestion about what happens in  hard production use, when the flash
>>will be written  over and over again  and the wear leveling takes
>>place. the device is never shutdown'ed in a  clean way -- always hard
>>power off... 
>>    
>>
>
>JFFS2 from CVS should be fine. It hasn't had as much hard testing as the
>stable branch, but I have no particular reason to expect it to be broken on
>NOR flash. I wouldn't ship it to a customer before doing some serious
>retesting, but you can do that yourself and report anything you find -- I
>don't expect anything to break.
>
>There are other things we can do to improve performance and mount time even
>more than we've already done in CVS. They're listed in the TODO file, and if
>you're likely to actually implement them I'm happy to give more explicit
>pointers -- or I can set our salesdroids on you if that would be useful :)
>
>--
>dwmw2
>
>  
>





From tglx at linutronix.de  Tue Aug 27 15:44:06 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 27 Aug 2002 21:44:06 +0200
Subject: flash file system for production use
In-Reply-To: <3D6BCCFD.4090707@goepel.com>
References: <3D6BCCFD.4090707@goepel.com>
Message-ID: <1030477447.11505.9.camel@thomas.tec.linutronix.de>

On Tue, 2002-08-27 at 21:03, Michael Palme wrote:
> hello...
> 
> i've got a strongarm system with 32mb intel strata flash. i need a 
> mechanism for storing configuration files etc in the flashes. for this 
> purpose 20mb of the flashes are free. the performance/ stability thing 
> is very important for me. i cant wait 10 secs fot mounting/ checking 
> etc. i' ve tried jffs2 from CVS and it seems to be "fast" on a nearly 
> empty flash partition, but i have no suggestion about what happens in 
> hard production use, when the flash will be written  over and over again 
> and the wear leveling takes place. the device is never shutdown'ed in a 
> clean way -- always hard power off...
> 
> because i have 20megs free and only small information to store i think 
> there is no need for a complex wear leveling mechanism but im not an expert.
> 
> what the best solution fot my problems???
> 
You have to decide, whats more important stability or preformance. If
you write small but important information and your system has the
possibility of power loss, then you have to use a stable, journalling
flash file system like JFFS2 and accept some performance penalty. The
actual JFFS2 code in CVS is faster than the stable branch. It needs some
serious testing. And there is place for further improvents. You're
heartly intvited to join us and implement some of the things, which are
listed in the TODO file.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From dwmw2 at infradead.org  Tue Aug 27 16:49:43 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 27 Aug 2002 21:49:43 +0100
Subject: flash file system for production use 
In-Reply-To: <3D6BD539.4050101@goepel.com> 
References: <3D6BD539.4050101@goepel.com>  <3D6BCCFD.4090707@goepel.com> <27451.1030476296@redhat.com> 
Message-ID: <29072.1030481383@redhat.com>

m.palme at goepel.com said:
> okay... thanks for the answer. i will do some serious testing myself.
> what would be a real life  scenario ??? is a random loop with
> creating, writing and deleting files  mixed with mounting and
> unmounting and some random powerfaults???

Yeah -- coupled with sanity checking every existing file on the file system 
at every remount, etc. And make them _real_ powerfaults, with an X10 
controller or something. You get really weird behaviour out of flash chips 
that way -- which we should deal with just fine.

If you're going to report any faults, it's best to do the testing with 
CONFIG_JFFS2_FS_DEBUG=1 and _logging_ the kernel messages over a serial 
port. But that of course slows down the test run. YMMV. A 230400 baud 
serial console helps :)

--
dwmw2





From xjin at redswitch.com  Tue Aug 27 17:55:32 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Tue, 27 Aug 2002 14:55:32 -0700
Subject: how to get mtd_info in kernel space?
Message-ID: <3D6BF554.3090102@redswitch.com>

Hi,

get_mtd_device() is used to get an MTD device with a specific minor 
number. I have several MTD devices enabled and how can I get their minor 
numbers which can be used to invoke get_mtd_device()? What function call?

Thanks.

- Shawn.




From dwmw2 at infradead.org  Tue Aug 27 18:03:19 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 27 Aug 2002 23:03:19 +0100
Subject: how to get mtd_info in kernel space? 
In-Reply-To: <3D6BF554.3090102@redswitch.com> 
References: <3D6BF554.3090102@redswitch.com> 
Message-ID: <30372.1030485799@redhat.com>

xjin at redswitch.com said:
>  get_mtd_device() is used to get an MTD device with a specific minor
> number. I have several MTD devices enabled and how can I get their
> minor  numbers which can be used to invoke get_mtd_device()? What
> function call? 

At the moment you can't. You have to get each one from 0 to MAX_MTD_DEVICES 
and check whether it's the one you want. We could perhaps implement a 
get_mtd_device_byname() since JFFS2 wants that too now.

What do you want it for?

--
dwmw2





From dwmw2 at infradead.org  Tue Aug 27 18:04:31 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 27 Aug 2002 23:04:31 +0100
Subject: how to get mtd_info in kernel space? 
In-Reply-To: <3D6BF554.3090102@redswitch.com> 
References: <3D6BF554.3090102@redswitch.com> 
Message-ID: <30390.1030485871@redhat.com>

Er, note also that if you've got a special device which contains only 
something odd like MAC address for a built-in network card, you don't have 
to register it with the core MTD code; you can make it available only to 
your network card driver via some private mechanism if you want.

--
dwmw2





From xjin at redswitch.com  Tue Aug 27 19:22:01 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Tue, 27 Aug 2002 16:22:01 -0700
Subject: how to get mtd_info in kernel space?
References: <3D6BF554.3090102@redswitch.com> <30390.1030485871@redhat.com>
Message-ID: <3D6C0999.4020507@redswitch.com>

Thanks for the answer. My proposed device will contain basically some 
configuration data. But they are not as simple as MAC address. The size 
will grow dynamically.

I want such a flexible function to get minor number because our 
partitions may be changed later thus those numbers cannot be fixed. 
Anyway, since now the only way is to use the fix minor number, I'm OK 
with current mechanism. ;)

- Shawn.




From m.palme at goepel.com  Wed Aug 28 03:07:28 2002
From: m.palme at goepel.com (Michael Palme)
Date: Wed, 28 Aug 2002 09:07:28 +0200
Subject: flash file system for production use
Message-ID: <3D6C76B0.2080001@goepel.com>


[forget CC to the list...]

> hello...
>
> there are 7 mtd partitions on the 32Mb NOR flash right now. (256k
> bootloader, 256k kernel parameters, 1M kernel1, 4M ramdisk1, 1M kernel2,
> 4M ramdisk2 and the rest (21.5M) goes to 1 jffs2 data partition. i want
> no flash- rootfs because of performance issues -- i think a ramdisk is
> always the fastest.
>
> the reason behind the _very_big_ jffs2 partition is that i want to
> assure that the flash will never(?) fail because of weak blocks sometimes.
>
> but thats also my fear -- i think the bigger the jffs partition the
> slower it gets after some time of use because of the effort of the wear
> leveling??? is this right???

I think it gets slower due to fragmentation. A JFFSx file system must scan at 
start up. A big fagmented partition will scan slower. I don't know enough 
about JFFSx, my main knowledge is about YAFFS which works on NAND.

>
> so what i want to know is: is a smaller jffs2 partiton better from the
> performance view??? i will have no complex tree structure on the
> partition, only 2 directorys with some small files...
>
> cheers Michael Palme
>
> Charles Manning schrieb:
> >Have you considered partitioning?
> >
> >One partition for config files etc (stuff you need ASAP on boot).
> >Another for verbose guff that you can mount at leasure.
> >
> >-- Charles
> >
> >On Wed, 28 Aug 2002 07:03, you wrote:
> >>hello...
> >>
> >>i've got a strongarm system with 32mb intel strata flash. i need a
> >>mechanism for storing configuration files etc in the flashes. for this
> >>purpose 20mb of the flashes are free. the performance/ stability thing
> >>is very important for me. i cant wait 10 secs fot mounting/ checking
> >>etc. i' ve tried jffs2 from CVS and it seems to be "fast" on a nearly
> >>empty flash partition, but i have no suggestion about what happens in
> >>hard production use, when the flash will be written  over and over again
> >>and the wear leveling takes place. the device is never shutdown'ed in a
> >>clean way -- always hard power off...
> >>
> >>because i have 20megs free and only small information to store i think
> >>there is no need for a complex wear leveling mechanism but im not an
> >>expert.
> >>
> >>what the best solution fot my problems???
> >>
> >>please give some hints....
> >>
> >>
> >>thanks in advance ... Michael Palme





From wd at denx.de  Tue Aug 27 19:35:16 2002
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 28 Aug 2002 01:35:16 +0200
Subject: DOC / NFTL problem, and fix
Message-ID: <20020827233522.0F5481182F@denx.denx.de>

Hi,

I noticed a problem when trying to initialize a DOC  device  like  an
ordinary  harddisk,  i. e. when trying to run a command sequence like
this one:

	bash# eraseall /dev/mtdchar0
	bash# nftl_format /dev/mtdchar0 0x00300000
	bash# fdisk /dev/nftla
	(create partitions, and write partition table)
	bash# reboot

Usually the DOC would be unusable after this, with no valid partition
table at all. Depending on the timing it would sometimes work - if  I
add a long delay before the "reboot", it works.


It turns out that some internal data structures of the  NFTL  driver,
which are initialized only at boot-time, become invalid after you run
nftl_format.

To fix this issue, we added an IOCTL  command  to  the  NFTL  driver,
which would instruct the driver to re-read appropriate meta-data from
the  DOC  device.  Nftl_format was modified to invoke this command to
accomplish its operation.

Patch attached.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have made mistakes, but have never made the mistake of  claiming  I
never made one.                                     - James G. Bennet

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd_nftl.patch
Type: application/x-patch
Size: 6104 bytes
Desc: mtd_nftl.patch
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020828/d7c0179e/attachment.bin 

From hno at marasystems.com  Wed Aug 28 09:52:05 2002
From: hno at marasystems.com (Henrik Nordstrom)
Date: Wed, 28 Aug 2002 15:52:05 +0200
Subject: DOC2000, Linux-2.4.18
Message-ID: <200208281552.05987.hno@marasystems.com>

Hi.

I am trying to get some grips on how to access a DOC2000 from Linux, but I do 
not have much luck..

The chip gets detected properly by the driver and I can access the flash as a 
char device, but NFTL does not like what it sees

DiskOnChip 2000 found at address 0xD6000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
3 flash chips found. Total DiskOnChip size: 24 MiB

NFTL driver: nftlcore.c $Revision: 1.82 $, nftlmount.c $Revision: 1.25 $
Sorry, we don't support UnitSizeFactor of != 1 yet.
Could not find valid boot record
Could not mount NFTL device


Same thing for the DOC patch to GRUB.



I found in the CVS tree that there is some pending fixes related to this in 
the kernel sources (but not the GRUB patch), but when I try to upgrade the 
kernel with the mtd CVS sources then it cannot compile, failing on 
recalc_sigpending IIRC.  (RedHat-7.3 system). Unfortunately I have lost the 
exact compiler error message. Can recreate it if there is need to..

Regards
Henrik



From olivier.eribon at free.fr  Wed Aug 28 10:27:33 2002
From: olivier.eribon at free.fr (olivier.eribon at free.fr)
Date: Wed, 28 Aug 2002 16:27:33 +0200 (MEST)
Subject: Cannot remove child on JFFS2 FS with latest CVS
Message-ID: <1030544853.3d6cddd5501b2@imp.free.fr>

Hello,

Now with latest CVS Aug 28 2002, and 2.4.17 linux kernel on a specific 
board (ppc405gp with a nand flash : Toshiba TC58256FT/DC), 
I have always the same message :

Cannot remove child "fileXXX", ino #0, because it doesn't exist

How can I solve this problem ? (because this message induce long time to
mount partition.)

Thanks in advance for your time and your help !

Best regards,

Olivier



From dwmw2 at infradead.org  Wed Aug 28 10:31:23 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 28 Aug 2002 15:31:23 +0100
Subject: Cannot remove child on JFFS2 FS with latest CVS 
In-Reply-To: <1030544853.3d6cddd5501b2@imp.free.fr> 
References: <1030544853.3d6cddd5501b2@imp.free.fr> 
Message-ID: <14081.1030545083@redhat.com>

olivier.eribon at free.fr said:
>  Now with latest CVS Aug 28 2002, and 2.4.17 linux kernel on a
> specific  board (ppc405gp with a nand flash : Toshiba TC58256FT/DC),
> I have always the same message :

> Cannot remove child "fileXXX", ino #0, because it doesn't exist 

You don't have the latest code. Check the $Id$ tag in fs/jffs2/build.c.

 * $Id: build.c,v 1.38 2002/08/23 12:21:36 dwmw2 Exp $


Note the check of fd->ino which was added the first time this was reported:

		while(ic->scan->dents) {
			struct jffs2_inode_cache *child_ic;

			fd = ic->scan->dents;
			ic->scan->dents = fd->next;

			if (!fd->ino) {
				/* It's a deletion dirent. Ignore it */
				D1(printk(KERN_DEBUG "Child \"%s\" is a deletion dirent, skipping...\n", fd->name));
				jffs2_free_full_dirent(fd);
				continue;
			}
			if (!whinged) {
				whinged = 1;
				printk(KERN_NOTICE "Inode #%u was a directory with children - removing those too...\n", ic->ino);
			}

			D1(printk(KERN_DEBUG "Removing child \"%s\", ino #%u\n",
				  fd->name, fd->ino));
			
			child_ic = jffs2_get_ino_cache(c, fd->ino);
			if (!child_ic) {
				printk(KERN_NOTICE "Cannot remove child \"%s\", ino #%u, because it doesn't exist\n", fd->name, fd->ino);
				jffs2_free_full_dirent(fd);
				continue;
			}
			jffs2_free_full_dirent(fd);
			child_ic->nlink--;
		}
--
dwmw2





From sriramneelakandan at yahoo.com  Wed Aug 28 11:00:35 2002
From: sriramneelakandan at yahoo.com (Sriram Neelakandan Iyer)
Date: Wed, 28 Aug 2002 08:00:35 -0700 (PDT)
Subject: cramfs gives decompression error on my flash
Message-ID: <20020828150035.16625.qmail@web14903.mail.yahoo.com>

I have 3 partitions on my flash..
1 tiny bootloader
2 big cramfs which i use for binaries & libs
3 and a tiny jffs2 used for storing config.

The kernel mounts only second(cramfs) & third(jffs2)
partions.

i hit upon errors as shown in snip below...not very
consistent..should rather say very rare.

Scanning thru the kernel code i found that these are
from fs/cramfs/uncompress.c 

Has anybody seen such errors before?
any clues ?? suggestions welcome.
i am stranded.

TIA
sriram

--snip--

Error -5 while decompressing!
821c7b26(1618)->82fe2000(4096)
Error -5 while decompressing!
821ca0d2(2451)->82fdd000(4096)
Error -3 while decompressing!
821cba65(2119)->82fdc000(4096)
udp:Done
Error -3 while decompressing!ddress 3894657708x
e823c2ac(-1711732818)->82fdb000(4096)
Err96)
Unable to handle kernel paging request at virtual
address f601c08a, epc 
== 82072
f7c, ra == 8207100c
Oops in fault.c:do_page_fault, line 192:
$0 : 00000000 821c0000 f601c08a 00000001 821d9f60
821d9f60 00000000 
8c1b06fd
$8 : 00000044 00000001 82190d44 00000000 00000000
821bfc86 fffffff8 
ffffffff
$16: 821cecc0 fffffffb fffffffb 8c1b06fd f601c08a
821a4180 0000001d 
82fe7210
$24: 00000000 00000000                   823ee000
823ef8f8 823f7efc 
8207100c
Status: 10004304
Cause : 00000008
Process init (pid: 1, stackpage=823ee000)
Stack: 82072d2c 821a4180 0000001d 82fe7210 821cecc0
00001000 82fd9000 
8207100c
       823ee000 823ef948 8c1b06fd 822de5c8 822fbe00
73ea73ea 8c1b06fd 
822de5c8
       822fbe00 73ea73ea 00000000 82070e48 00000005
00000001 00000000 
82fef120
       822de5c8 82fef120 0000001b 00000004 823f7ef8
8202caa4 50020000 
00000003
       821cfed0 821d00d0 00000000 82fe7210 0000001c
00000001 821a4180 
82fef120
       0000001d ...
Call Trace: [<82072d2c>] [<8207100c>] [<82070e48>]
[<8202caa4>] 
[<8202e6f8>] [<8
203a898>] [<820290e4>] [<8201067c>] [<82029334>]
[<820292b4>] 
[<820113a8>] [<820
71f28>] [<82071c18>] [<8204573c>] [<8200f0c0>]
[<8202debc>] 
[<82065738>] [<82141
a14>] [<82065db8>] [<82065ca4>] [<82029c24>]
[<82029aec>] 
[<82066970><82065fd8>]
 [<820513c4>] [<820517f4>] [<8209da38>] [<8200dda0>]
[<8216729c>] 
[<8200e7c4>] [
<8216729c>] [<8216729c>] [<820179d4>] [<8218088c>]
[<82167346>] 
[<820080e4>] [<8
200824c>] [<82008150>] [<8216721c>] [<82007f78>] ...
Code: 8e04001c  24630001  ae030008 <90430000> 24420001
 ac830004  
ae020000  3063
000f  24020008




__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From xjin at redswitch.com  Wed Aug 28 22:49:42 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Wed, 28 Aug 2002 19:49:42 -0700
Subject: the latest MTD code from CVS has compilation errors
Message-ID: <3D6D8BC6.8000909@redswitch.com>

Hi,

I tried to compile the latest MTD code got from CVS tree on linux 2.4.4 
(from DENX). When fs/jffs2/background.c is compiled, it complains that
   background.c:108: arguments given to macro 'recalc_sigpending'
   background.c:155: arguments given to macro 'recalc_sigpending'
errors. I looked into the code and included header file. In 
linux/mtd/compatmac.h the macro is re-defined to have no arguments at 
all if kernel version < 2.5.5. So in my case 108 and 155 should be 
changed to have no arguments.

Anybody reported this "bug" before?

- Shawn.

PS: compatmac.h's modification date is 2002/08/07, version v1.39.




From yanhy at tsinghua.org.cn  Thu Aug 29 00:06:18 2002
From: yanhy at tsinghua.org.cn (yanhy at tsinghua.org.cn)
Date: Thu, 29 Aug 2002 12:06:18 +0800
Subject: Can anyone give me some suggestions on using jffs(1/2)
Message-ID: <E17kGYc-0003Dy-00@pentafluge.infradead.org>

Hi!I'm a new comer here and I am new to uClinux.I want to use jffs(1 or 2) as the
root filesystem on target M5272C3.But i failed to do that though i tried a lot
according to "jffs-howto.txt".Can you tell me how to begin?
well,I have download uClinux-2.4.x( uClinux-dist-20020701.tar.gz.tar) from
www.uclinux.org, and i'v succesfully run the kernel on the M5272C3 target using
romfs as root fs(BTW:i use ppcboot as the bootloader,which can receive
kernel+romfs image via ethernet port and then put it in ram at 0x20000.Then i can
run the kernel by typing command "go 20000") .
Now, i want to use jffs as the root fs instead of romfs,but i failed to compile
the kernel when i select MTD support, MTD partitions support and jffs support as 
jffs-howto.txt says.
Can you give me some suggestions how to build the jffs(2 or 1) as root fs? Are any
patches required ?
Thanks so much!
Best wishes
Yan





From besthomebiz at subdimension.com  Thu Aug 29 04:47:28 2002
From: besthomebiz at subdimension.com (Opt-inList)
Date: Thu, 29 Aug 2002 03:47:28 -0500
Subject: Everybody Gets Paid - No Recruiting Needed
Message-ID: <E17kJpY-00055t-00@pentafluge.infradead.org>

Everybody gets paid.  No recruiting required.

Join and reserve a position for free now.
Program is 18 weeks old and it's paying.

Everybody gets in line to get paid by all
the new people coming in (but it's NOT a
traditional straightline)...EVERYONE makes money...
and those that sponsor make more....

<html>
<a href="mailto:gmt101info at profitresponder.com?subject=send-more-info"<b>
Click here to request for more information</b></a>

<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>












<a href="mailto:stockbuyer at netzero.net?subject=REMOVE"<b>
We belong to the same opt-in list. But if wish to have your email
address REMOVE from our database please click here</b></a>
</html>





From startec at ms11.hinet.net  Thu Aug 29 04:39:37 2002
From: startec at ms11.hinet.net (Steve Tsai)
Date: Thu, 29 Aug 2002 16:39:37 +0800
Subject: I need some help about nand flash.
References: <000501c24f26$2d8cf800$09090d0a@paul2k>
Message-ID: <3D6DDDC9.2080106@ms11.hinet.net>

I do not know your condition very well, but I think all the pins of the
flash you connect correctly. What's the WE and RE timimg diagram in your
board? In my board, I use CS to control WE and RE and I have not enought
WE pull-high hold time, when two continue writeb functions are called in
nand_command. I delay few nsec between writeb funciotns to solve my
problem. You can try this and if you can provide more information about
your system, maybe I can give you more sugestion.

Steve Tsai

>Hi:
>    I have read your post http://lists.infradead.org/pipermail/linux-mtd/2002-June/005286.html.
>    
>    Now I encounter the same problem as you. 
>    The flash I used is TC58128AFTI manufacted by Toshiba.
>    I can read Device ID,read Status and Reset it successfully,but I can't read data.
>    I captured the timing diagram with a logic analyzer .It meets all requirements stated in 
>the chip's datasheet. 
>    When I perform a read operation(the command code is 0x00),the RY/BY# keeps high when the third address has been latched and that the data I read is always 0x00.
>   
>   
>   Any advice will be apreciated.
>
>   Thank you very much.
>
>
>
>  
>






From hno at marasystems.com  Thu Aug 29 04:55:16 2002
From: hno at marasystems.com (Henrik Nordstrom)
Date: Thu, 29 Aug 2002 10:55:16 +0200
Subject: [patch] Re: the latest MTD code from CVS has compilation errors
In-Reply-To: <3D6D8BC6.8000909@redswitch.com>
References: <3D6D8BC6.8000909@redswitch.com>
Message-ID: <200208291055.16498@henrik.marasystems.com>

I have the same problem with 2.4.18. See post a few days ago about 
DOC2000.

A closer look at the problem inticates the problem is not the CVS 
sources but the patchin.sh script used to apply them to the kernel 
tree. It does not apply the new jffs2 sources to the kernel tree, 
crashing the old jffs2 code by replacing mtd headers..

However, applying the new code to stock 2.4.18 does not work either 
due to a missing include/linux/crc32.h (is in fs/jffs2/crc32.h)

Attached is a small patch to the patchin.sh script to have the new 
jffs2 code applied to the kernel tree.

Regards
Henrik

On Thursday 29 August 2002 04.49, Xiaogeng (Shawn) Jin wrote:
> Hi,
>
> I tried to compile the latest MTD code got from CVS tree on linux
> 2.4.4 (from DENX). When fs/jffs2/background.c is compiled, it
> complains that background.c:108: arguments given to macro
> 'recalc_sigpending' background.c:155: arguments given to macro
> 'recalc_sigpending' errors. I looked into the code and included
> header file. In linux/mtd/compatmac.h the macro is re-defined to
> have no arguments at all if kernel version < 2.5.5. So in my case
> 108 and 155 should be changed to have no arguments.
>
> Anybody reported this "bug" before?
>
> - Shawn.
>
> PS: compatmac.h's modification date is 2002/08/07, version v1.39.
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd-2.4.patch
Type: text/x-diff
Size: 1082 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020829/ac2338c6/attachment.bin 

From m.palme at goepel.com  Thu Aug 29 10:07:09 2002
From: m.palme at goepel.com (Michael Palme)
Date: Thu, 29 Aug 2002 16:07:09 +0200
Subject: 2.4.18-rmk7 + CVS jffs2 ld error (zlib)
Message-ID: <3D6E2A8D.4000502@goepel.com>

hello...

i know this was discussed some times ago in the list but i'read the old 
threads but no success.
i have kernel 2.4.18-rmk7 and i would like to build it with jffs2 from 
latest CVS. i have patched /patches/patchin.sh with patch from Henrik 
Nordstrom posted today, and applied on the kernel sources. on building i 
get lots of errors at the final linking:

arm/tools/chain/bin/arm-uclibc-ld -p -X -T arch/arm/vmlinux.lds 
arch/arm/kernel/head-armv.o arch/arm/kernel/init_task.o init/main.o 
init/version.o --start-group arch/arm/kernel/kernel.o arch/arm/mm/mm.o 
arch/arm/mach-sa1100/sa1100.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o 
drivers/serial/serial.o drivers/char/char.o drivers/block/block.o 
drivers/misc/misc.o drivers/net/net.o drivers/media/media.o 
drivers/mtd/mtdlink.o net/network.o arch/arm/nwfpe/math-emu.o 
arch/arm/lib/lib.a /usr/arm/krnl-2.4.18-rmk7/lib/lib.a --end-group -o 
vmlinux

fs/fs.o: In function `jffs2_zlib_compress':
fs/fs.o(.text+0x2ab58): undefined reference to `zlib_deflateInit_'
fs/fs.o(.text+0x2abb0): undefined reference to `zlib_deflate'
fs/fs.o(.text+0x2abbc): undefined reference to `zlib_deflateEnd'
fs/fs.o(.text+0x2ac3c): undefined reference to `zlib_deflate'
fs/fs.o(.text+0x2ac78): undefined reference to `zlib_deflateEnd'
fs/fs.o: In function `jffs2_zlib_decompress':
fs/fs.o(.text+0x2ad4c): undefined reference to `zlib_inflateInit_'
fs/fs.o(.text+0x2ad78): undefined reference to `zlib_inflate'
fs/fs.o(.text+0x2ad98): undefined reference to `zlib_inflateEnd'
fs/fs.o: In function `jffs2_garbage_collect_thread':
fs/fs.o(.text+0x363a0): undefined reference to `set_user_nice'
fs/fs.o: In function `jffs2_zlib_init':
fs/fs.o(.text.init+0x16b8): undefined reference to 
`zlib_deflate_workspacesize'
fs/fs.o(.text.init+0x16d8): undefined reference to 
`zlib_inflate_workspacesize'
fs/fs.o(.text.init+0x1700): undefined reference to 
`zlib_inflate_workspacesize'
fs/fs.o(.text.init+0x1720): undefined reference to 
`zlib_deflate_workspacesize'
make: *** [vmlinux] Error 1



so i grepped around in the list archive and found a possible solution to 
remove compr_zlib.o from COMPR_OBJS in jffs2/Makefile. Now after 
rebuilding i get:


/arm/tools/chain/bin/arm-uclibc-ld -p -X -T arch/arm/vmlinux.lds 
arch/arm/kernel/head-armv.o arch/arm/kernel/init_task.o init/main.o 
init/version.o --start-group arch/arm/kernel/kernel.o arch/arm/mm/mm.o 
arch/arm/mach-sa1100/sa1100.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o 
drivers/serial/serial.o drivers/char/char.o drivers/block/block.o 
drivers/misc/misc.o drivers/net/net.o drivers/media/media.o 
drivers/mtd/mtdlink.o net/network.o arch/arm/nwfpe/math-emu.o 
arch/arm/lib/lib.a /usr/arm/krnl-2.4.18-rmk7/lib/lib.a --end-group -o 
vmlinux

fs/fs.o: In function `jffs2_compress':
fs/fs.o(.text+0x29fac): undefined reference to `jffs2_zlib_compress'
fs/fs.o: In function `jffs2_decompress':
fs/fs.o(.text+0x2a0b4): undefined reference to `jffs2_zlib_decompress'
fs/fs.o: In function `jffs2_garbage_collect_thread':
fs/fs.o(.text+0x36040): undefined reference to `set_user_nice'
fs/fs.o: In function `init_jffs2_fs':
fs/fs.o(.text.init+0x1868): undefined reference to `jffs2_zlib_init'
fs/fs.o(.text.init+0x18a4): undefined reference to `jffs2_zlib_exit'
make: *** [vmlinux] Error 1

i tried also to apply the patches from 
ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib on top of 
my kernel but this is something tricky...

so i would like to know if someone has a fast workaround ???

thanks in advance ... Michael Palme








From dwmw2 at infradead.org  Thu Aug 29 10:11:27 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 29 Aug 2002 15:11:27 +0100
Subject: 2.4.18-rmk7 + CVS jffs2 ld error (zlib) 
In-Reply-To: <3D6E2A8D.4000502@goepel.com> 
References: <3D6E2A8D.4000502@goepel.com> 
Message-ID: <24260.1030630287@redhat.com>


m.palme at goepel.com said:
>  so i grepped around in the list archive and found a possible solution
> to  remove compr_zlib.o from COMPR_OBJS in jffs2/Makefile. Now after
> rebuilding i get:

Don't do that. Apply 

http://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib/linux-2.4.19-pre10-shared-zlib.gz 



--
dwmw2





From m.palme at goepel.com  Thu Aug 29 12:10:24 2002
From: m.palme at goepel.com (Michael Palme)
Date: Thu, 29 Aug 2002 18:10:24 +0200
Subject: 2.4.18-rmk7 + CVS jffs2 ld error (zlib)
References: <3D6E2A8D.4000502@goepel.com> <24260.1030630287@redhat.com>
Message-ID: <3D6E4770.6050905@goepel.com>

thanks fot the answer.
but there is still one problem left:

background.c:92: warning: implicit declaration of function `set_user_nice'
fs/fs.o(.text+0x363a0): undefined reference to `set_user_nice'

the only place i've found this is <linux/mtd/compatmac.h> (link to the 
mtd-cvs):


#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
         /* Is this right? */
#define set_user_nice(tsk, n) do { (tsk)->priority = 20-(n); } while(0)
#elif LINUX_VERSION_CODE < KERNEL_VERSION(2,4,18)
#define set_user_nice(tsk, n) do { (tsk)->nice = n; } while(0)
#endif

so in 2.4.18 there is nothing related....

what should i do??? (i think of #elif LINUX_VERSION_CODE < 
KERNEL_VERSION(2,4,19) )

thanks in advance ... Michael Palme



David Woodhouse schrieb:
> 
> m.palme at goepel.com said:
> 
>> so i grepped around in the list archive and found a possible solution
>>to  remove compr_zlib.o from COMPR_OBJS in jffs2/Makefile. Now after
>>rebuilding i get:
> 
> 
> Don't do that. Apply 
> 
> http://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib/linux-2.4.19-pre10-shared-zlib.gz 
> 
> 
> 
> --
> dwmw2




From dwmw2 at infradead.org  Thu Aug 29 12:11:52 2002
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 29 Aug 2002 17:11:52 +0100
Subject: 2.4.18-rmk7 + CVS jffs2 ld error (zlib) 
In-Reply-To: <3D6E4770.6050905@goepel.com> 
References: <3D6E4770.6050905@goepel.com>  <3D6E2A8D.4000502@goepel.com> <24260.1030630287@redhat.com> 
Message-ID: <3487.1030637512@redhat.com>

m.palme at goepel.com said:
>  background.c:92: warning: implicit declaration of function
> `set_user_nice' fs/fs.o(.text+0x363a0): undefined reference to
> `set_user_nice' 

Just comment out the offending line in background.c

--
dwmw2





From xjin at redswitch.com  Thu Aug 29 13:54:40 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Thu, 29 Aug 2002 10:54:40 -0700
Subject: 2.4.18-rmk7 + CVS jffs2 ld error (zlib)
References: <3D6E2A8D.4000502@goepel.com> <24260.1030630287@redhat.com>
Message-ID: <3D6E5FE0.2020600@redswitch.com>

> http://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib/linux-2.4.19-pre10-shared-zlib.gz 

Is this patch suitable for 2.4.4? The compilation errror is that 
linux/completion.h couldn't be found.

Thanks,

- Shawn.




From hno at marasystems.com  Thu Aug 29 15:24:57 2002
From: hno at marasystems.com (Henrik Nordstrom)
Date: Thu, 29 Aug 2002 21:24:57 +0200
Subject: JFFS2 and DOC
Message-ID: <200208292124.57483.hno@marasystems.com>

What is the current status of JFFS2 and DOC?

>From what I understand the current CVS includes many fixes for DOC, but is 
there also support for JFFS2 ontop of DOC?

Is the intention to run JFFS2 directly on the flash, or ontop of NTFL?

Regards
Henrik



From xjin at redswitch.com  Thu Aug 29 17:16:53 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Thu, 29 Aug 2002 14:16:53 -0700
Subject: Why this error
Message-ID: <3D6E8F45.70905@redswitch.com>

Hi,

I use the following code to get mtd device pointer:
     mtd = get_mtd_device(NULL, MTD_MINOR);
The compiler always complains that parse error before ;
/* MTD_MINOR is a defined macro. */

But when I call get_mtd_device() in this way, no complain at all.
     int mtd_minor = MTD_MINOR;
     mtd = get_mtd_device(NULL, mtd_minor);

Why does this error happen? Anybody encountered such errors before?

Thanks.

- Shawn.




From tglx at linutronix.de  Thu Aug 29 17:39:09 2002
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 29 Aug 2002 23:39:09 +0200
Subject: JFFS2 and DOC
In-Reply-To: <200208292124.57483.hno@marasystems.com>
References: <200208292124.57483.hno@marasystems.com>
Message-ID: <1030657149.11505.72.camel@thomas.tec.linutronix.de>

On Thu, 2002-08-29 at 21:24, Henrik Nordstrom wrote:
> What is the current status of JFFS2 and DOC?
> 
> >From what I understand the current CVS includes many fixes for DOC, but is 
> there also support for JFFS2 ontop of DOC?
No
> Is the intention to run JFFS2 directly on the flash, or ontop of NTFL?
The intention is to run direct on the flash. The generic nand driver
could handle doc with some minor modifications. And a DOC driver
matching the nand driver has to be written. I will do this, if I have
some time for it or somebody convinces me with a contract to have time
for it.

-- 
Thomas 
____________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de




From hno at marasystems.com  Thu Aug 29 15:14:16 2002
From: hno at marasystems.com (Henrik Nordstrom)
Date: Thu, 29 Aug 2002 21:14:16 +0200
Subject: [patch] mkfs.jffs2
Message-ID: <200208292114.16531.hno@marasystems.com>

Noticed mkfs.jffs2 does not build in CVS due to the change in jffs2 byte 
orderered types.

Attached is a patch to allow mkfs.jffs2 to build again. It is merely an 
search-replace of the existing code to match the new types. Have not tried if 
it does what it should as I do not (yet) have a system where I can use JFFS2.

Regards
Henrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkfs.jffs2.patch
Type: text/x-diff
Size: 2807 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20020829/9faf9c48/attachment.bin 

From mateo at posta.star.si  Fri Aug 30 03:00:55 2002
From: mateo at posta.star.si (Mateo Anderson)
Date: Fri, 30 Aug 2002 00:00:55 -0700 (PDT)
Subject: DOC 2000 on PC104 +
Message-ID: <20020830070056.094013948@sitemail.everyone.net>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20020830/693a8a06/attachment.pl 

From sriramneelakandan at yahoo.com  Fri Aug 30 08:29:42 2002
From: sriramneelakandan at yahoo.com (Sriram Neelakandan Iyer)
Date: Fri, 30 Aug 2002 05:29:42 -0700 (PDT)
Subject: jffs2 with rootmount_flags = rw
Message-ID: <20020830122942.61137.qmail@web14905.mail.yahoo.com>

I have a jffs2 root partition mounted thru MTD.
I would like to know if i can mount jffs2 as rw
directly from mount_root().
In other words are there any implications if i do a
read_super on jjfs2 with root_mountflags = rw.

Read only mount make sense for filesystems that could 
be fscked.. but on jffs2 what is the use of mounting
read only. and i am going to always do a remount,rw

tia
sriram



__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com



From mateo at posta.star.si  Fri Aug 30 10:04:07 2002
From: mateo at posta.star.si (Mateo Anderson)
Date: Fri, 30 Aug 2002 07:04:07 -0700 (PDT)
Subject: 48meg DOC
Message-ID: <20020830140409.A7B5B11DE6@sitemail.everyone.net>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20020830/31a272be/attachment.pl 

From hno at marasystems.com  Fri Aug 30 11:49:24 2002
From: hno at marasystems.com (Henrik Nordstrom)
Date: Fri, 30 Aug 2002 17:49:24 +0200
Subject: 48meg DOC
In-Reply-To: <20020830140409.A7B5B11DE6@sitemail.everyone.net>
References: <20020830140409.A7B5B11DE6@sitemail.everyone.net>
Message-ID: <200208301749.24444.hno@marasystems.com>

Have been playing with a 24megs DOC2000 lately, and soon gave up on the stock 
Linux drivers. Haven't had time to test the CVS version of the MTD drivers 
yet.

What I have ended up doing for the time beeing until I have more time is the 
simplest possible path.. M-Systems 5.1.2 firmware, a single DOS partition 
covering the whole DOC drive, and a normal GRUB as boot loader loaded in the 
normal manners via MBR (not the DOC enabled GRUB firmware).

GRUB loads the kernel and a compressed romfs root image from the DOS partition 
and starts the system. To access the DOC from within Linux for configuration 
data storage and upgrades the 5.0.0 Linux driver from M-Systems is used.

My final goal is to be able to partition the DOC in five pieces and to not 
having to depend on binary only drivers (is a hassle to have to use a initrd 
to be able to boot)..  1 binary flash partition for boot loader (GRUB), plus 
4 partitions for system (ro) and configuration (rw), two of each.

Boot area (GRUB in the binary flash partition)

System image (RO while running, compressed)

Primary configuration database (RW)

+ secondary system image and configuration database.

The configuration databases should preferably be journaled and flash friendly, 
but the write frequency is very low with small amounts of data so it is not 
critical.

But I have not yet figured out how to do this in a stable manner. GRUB does 
not like my DOC chips complaining about a UnitSizeFactor parameter in the 
NFTL header (perhaps because of them being formatted by the new firmware? I 
do not know. Was not aware there was firmware related problems), and if I 
partition the DOC in more than one partition using fdisk then it seems the 
M-Systems firmware craps out and I get all kinds of wierd results and the 
system cannot be booted from DOC. (once booted however it seems to be fine 
when accessed using the 5.0.0 version Linux driver, but I have occationally 
lost the flash disk partition when playing with this so I am not sure...)


> I am not sure, what is map installer?

The LILO map installer is /sbin/lilo. This creates the boot map in /boot/map. 
The boot map contains the block numbers of /boot/boot.b and your kernels or 
initrd images.

Regards
Henrik



From koffer at arlut.utexas.edu  Fri Aug 30 18:02:48 2002
From: koffer at arlut.utexas.edu (Ken Offer)
Date: Fri, 30 Aug 2002 17:02:48 -0500
Subject: Smart card 64 MB v. 128 MB
Message-ID: <3850FE6A-BC64-11D6-9352-000393467F1A@arlut.utexas.edu>

Hello all,

Does anyone know why a nand-driver which works for a 64 MB smart card 
would NOT work for a 128 MB smart card?  I've checked the data sheets 
and the two devices look very similar (same block size, same ecc size, 
same 22-pads, etc.)  My driver mounts the device just fine but when I 
try to erase I get I/O errors.  I'm going to look into the software 
side of this but I thought I'd consult the group to find if there are 
any hardware issues.

Thanks!

+-----------------------------------------------------------+
|  Ken Offer        koffer at arlut.utexas.edu         ARL:UT  |
|  Office: 512-835-3859                  Fax: 512-835-3259  |
+-----------------------------------------------------------+




From xjin at redswitch.com  Fri Aug 30 20:13:19 2002
From: xjin at redswitch.com (Xiaogeng (Shawn) Jin)
Date: Fri, 30 Aug 2002 17:13:19 -0700
Subject: mtd write takes 5 minutes
Message-ID: <3D700A1F.9040208@redswitch.com>

Hi,

I have a weird problem when writing hundreds of bytes to an mtd device. 
It takes about 5 minutes. The situation is as follows.

In module A initialization, a kernel thread is created to update some 
configuration which is stored in an mtd device. But this thead spent 
almost 5 minutes to finish writing hundreds of bytes data. What caused 
this problem? I guess the mtd write was waiting for resources. If so, 
what kind of resources did it wait for?

Thanks.

- Shawn.




From yanhy at tsinghua.org.cn  Sat Aug 31 04:18:39 2002
From: yanhy at tsinghua.org.cn (yanhy at tsinghua.org.cn)
Date: Sat, 31 Aug 2002 16:18:39 +0800
Subject: Help needed for jffs2
Message-ID: <E17l3Rw-00083Q-00@pentafluge.infradead.org>

Hi,friends!I'm new to uClinux.
I am trying to port uClinx on Coldfire M5272C3.The kernel is linux-2.4.x.
Now, if i select MTD and romfs support, the kernel works well on the target.
I can see the four pre-defined flash patitions and erase them and cp files to
them.
Now,I want to use jffs1/2 .but when i select jffs1/2 support, compiling problems 
come as:
mkfs.jffs2.c:113: `__BYTE_ORDER' undeclared here (not in a function)
mkfs.jffs2.c:114: `__BYTE_ORDER' undeclared here (not in a function)
mkfs.jffs2.c: In function `create_target_filesystem':
mkfs.jffs2.c:980: warning: assignment makes pointer from integer without a cast
mkfs.jffs2.c:981: `DT_DIR' undeclared (first use in this function)
mkfs.jffs2.c:981: (Each undeclared identifier is reported only once
mkfs.jffs2.c:981: for each function it appears in.)
mkfs.jffs2.c:991: warning: assignment makes pointer from integer without a cast
mkfs.jffs2.c:999: `DT_SOCK' undeclared (first use in this function)
mkfs.jffs2.c:1004: `DT_FIFO' undeclared (first use in this function)
mkfs.jffs2.c:1024: `DT_LNK' undeclared (first use in this function)
mkfs.jffs2.c:1039: `DT_REG' undeclared (first use in this function)
mkfs.jffs2.c:1046: `DT_CHR' undeclared (first use in this function)
mkfs.jffs2.c:1051: `DT_BLK' undeclared (first use in this function)
mkfs.jffs2.c: In function `main':
mkfs.jffs2.c:1202: `__LITTLE_ENDIAN' undeclared (first use in this function)
mkfs.jffs2.c:1206: `__BIG_ENDIAN' undeclared (first use in this function)
make[2]: *** [mkfs.jffs2.o] Error 1
make[2]: Leaving directory `/user/snap-gear-uclinux/uClinux-dist/user/mt
d-utils'

What's the matter?Do i need some jffs2 patch or fix it manually?
Thanks
Yan





From maseko_h3 at yahoo.com  Sat Aug 31 07:49:11 2002
From: maseko_h3 at yahoo.com (MRS. M. SESE SEKO)
Date: Sat, 31 Aug 2002 12:49:11 +0100
Subject: Urgent Assistance Needed
Message-ID: <E17l6pR-000095-00@phoenix.infradead.org>

FROM:MRS. M SESE-SEKO

DEAR FRIEND,

I AM MRS. SESE-SEKO WIDOW OF LATE PRESIDENT MOBUTU
SESE-SEKO OF ZAIRE? NOW KNOWN AS DEMOCRATIC REPUBLIC
OF CONGO (DRC). I AM MOVED TO WRITE YOU THIS LETTER,
THIS WAS IN CONFIDENCE CONSIDERING MY PRESENT
CIRCUMSTANCE AND SITUATION.

I ESCAPED ALONG WITH MY HUSBAND AND TWO OF OUR SONS
JAMES KONGOLO AND BASHER OUT OF DEMOCRATIC REPUBLIC OF
CONGO (DRC) TO ABIDJAN, COTE D'IVOIRE WHERE MY FAMILY
AND I SETTLED, WHILE WE LATER MOVED TO SETTLED IN
MORROCO WHERE MY HUSBAND LATER DIED OF CANCER
DISEASE. HOWEVER DUE TO THIS SITUATION WE DECIDED TO
CHANGED MOST OF MY HUSBAND'S BILLIONS OF DOLLARS
DEPOSITED IN SWISS BANK AND OTHER COUNTRIES INTO OTHER
FORMS OF MONEY CODED FOR SAFE PURPOSE BECAUSE THE NEW
HEAD OF STATE OF (DR) MR LAURENT KABILA HAS MADE
ARRANGEMENT WITH THE SWISS GOVERNMENT AND OTHER
EUROPEAN COUNTRIES TO FREEZE ALL MY LATE HUSBAND'S
TREASURES DEPOSITED IN SOME EUROPEAN COUNTRIES. HENCE
MY CHILDREN AND I DECIDED LAYING LOW IN AFRICA TO
STUDY THE SITUATION TILL WHEN THINGS GETS BETTER,
LIKE NOW THAT PRESIDENT KABILA IS DEAD AND THE SON
TAKING OVER (JOSEPH KABILA). ONE OF MY LATE HUSBAND'S
CHATEAUX IN SOUTHERN FRANCE WAS CONFISCATED BY THE
FRENCH GOVERNMENT, AND AS SUCH I HAD TO CHANGE MY
IDENTITY SO THAT MY INVESTMENT WILL NOT BE TRACED AND
CONFISCATED. I HAVE DEPOSITED THE SUM OF EIHGTEEN
MILLION UNITED STATE DOLLARS(US$18,000,000,00.) WITH A
SECURITY COMPANY , FOR SAFEKEEPING. THE FUNDS ARE
SECURITY CODED TO PREVENT THEM FROM KNOWING THE
CONTENT. WHAT I WANT YOU TO DO IS TO INDICATE YOUR
INTEREST THAT YOU WILL ASSIST US BY RECEIVING 
THE MONEY ON OUR BEHALF.ACKNOWLEDGE THIS MESSAGE, SO
THAT I CAN INTRODUCE YOU TO MY SON (KONGOLO ) WHO HAS
THE OUT MODALITIES FOR THE CLAIM OF THE SAID FUNDS. I
WANT YOU TO ASSIST IN INVESTING THIS MONEY, BUT 
I WILL NOT WANT MY IDENTITY REVEALED. I WILL ALSO WANT
TO BUY PROPERTIES AND STOCK IN MULTI-NATIONAL COMPANIES
AND TO ENGAGE IN OTHER SAFE AND NON-SPECULATIVE 
INVESTMENTS. MAY I AT THIS POINT EMPHASISE THE HIGH
LEVEL OF CONFIDENTIALITY,WHICH THIS BUSINESS DEMANDS,
AND HOPE YOU WILL NOT BETRAY THE TRUST AND CONFIDENCE,
WHICH I REPOSE IN YOU. IN CONCLUSION,IF YOU WANT
TO ASSIST US , MY SON SHALL PUT YOU IN THE PICTURE OF
THE BUSINESS,TELL YOU WHERE THE FUNDS ARE CURRENTLY
BEING MAINTAINED AND ALSO DISCUSS OTHER MODALITIES
INCLUDING REMUNERATION FOR YOUR SERVICES.

FOR THIS REASON KINDLY FURNISH US YOUR CONTACT
INFORMATION, AND YOUR PERSONAL TELEPHONE AND FAX
NUMBER FOR VALIDATION PROCESSES.

BEST REGARDS,

MRS M. SESE SEKO










