From tglx at linutronix.de  Fri Apr  1 03:23:34 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 01 Apr 2005 10:23:34 +0200
Subject: oobavail issues
In-Reply-To: <200503311029.46475.mreimer@vpop.net>
References: <424B4FFA.7050906@joshuawise.com>
	<200503310929.59763.mreimer@vpop.net>
	<1112296829.4228.75.camel@tglx.tec.linutronix.de>
	<200503311029.46475.mreimer@vpop.net>
Message-ID: <1112343814.4228.79.camel@tglx.tec.linutronix.de>

On Thu, 2005-03-31 at 10:29 -0800, Matthew Reimer wrote:
> > I will fix this. But I still wonder why you hit this problem with JFFS2.
> > JFFS2 does not provide a filesystem buffer for oob data, so the memcpy
> > in nand_prepare_oobbuf is never invoked.
> 
> IIRC it wasn't jffs2 but the MTD_WRITEECC() we were doing to write a kernel to 
> a partition, which we had to do in preparation for mounting jffs2. Sorry for 
> the confusion.

Ok. Fixed in CVS. Thanks for pointing this out.

tglx





From mreimer at vpop.net  Fri Apr  1 12:27:47 2005
From: mreimer at vpop.net (Matthew Reimer)
Date: Fri, 1 Apr 2005 09:27:47 -0800
Subject: oobavail issues
In-Reply-To: <1112343814.4228.79.camel@tglx.tec.linutronix.de>
References: <424B4FFA.7050906@joshuawise.com>
	<200503311029.46475.mreimer@vpop.net>
	<1112343814.4228.79.camel@tglx.tec.linutronix.de>
Message-ID: <200504010927.47300.mreimer@vpop.net>

On Friday 01 April 2005 12:23 am, Thomas Gleixner wrote:
> On Thu, 2005-03-31 at 10:29 -0800, Matthew Reimer wrote:
> > > I will fix this. But I still wonder why you hit this problem with
> > > JFFS2. JFFS2 does not provide a filesystem buffer for oob data, so the
> > > memcpy in nand_prepare_oobbuf is never invoked.
> >
> > IIRC it wasn't jffs2 but the MTD_WRITEECC() we were doing to write a
> > kernel to a partition, which we had to do in preparation for mounting
> > jffs2. Sorry for the confusion.
>
> Ok. Fixed in CVS. Thanks for pointing this out.

Thanks, looks good!

Matt



From manningc2 at actrix.gen.nz  Sun Apr  3 15:03:11 2005
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Mon, 4 Apr 2005 07:03:11 +1200
Subject: JFFS2 and eCOS
Message-ID: <20050403190352.396F21585F@desire.actrix.co.nz>

Is JFFS2 kept current in eCOS or is it periodically merged?
If merged, when did this last happen?

-- Charles



From estelle.hammache at st.com  Mon Apr  4 04:19:23 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Mon, 04 Apr 2005 10:19:23 +0200
Subject: JFFS2 and eCOS
References: <20050403190352.396F21585F@desire.actrix.co.nz>
Message-ID: <4250F88B.7942F7EB@st.com>

Charles Manning wrote:
> 
> Is JFFS2 kept current in eCOS or is it periodically merged?

Yes it is periodically merged - from eCos to MTD for
ecos-specific files, and from MTD to eCos for all other
files.

> If merged, when did this last happen?

This is the most recent MTD-to-eCos merge I found:
http://ecos.sourceware.org/ml/ecos-cvs/2005/msg00015.html

For more eCos information, here is the eCos mailing 
lists index:
http://ecos.sourceware.org/intouch.html

bye
Estelle



From dedekind at yandex.ru  Mon Apr  4 08:58:16 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Mon, 04 Apr 2005 16:58:16 +0400
Subject: JFFS2 & NAND failure
In-Reply-To: <41C02F29.92D2B5A@st.com>
References: <419B8715.4036BDBB@st.com>	<1100795260.8191.7333.camel@hades.cambridge.redhat.com>	<419CE1E8.F20DD890@st.com>	<1100870238.8191.7368.camel@hades.cambridge.redhat.com>	<419E1DE0.FDD5DEC0@st.com>	<1100978366.7949.38.camel@localhost.localdomain>	<1100988787.7949.46.camel@localhost.localdomain>	<1102604262.6694.17.camel@hades.cambridge.redhat.com>	<41B88622.4BCD78EC@st.com>
	<41C02F29.92D2B5A@st.com>
Message-ID: <425139E8.5000508@yandex.ru>

Estelle HAMMACHE wrote:
> Hi everyone,
> 
> it seems there is a problem with jffs2_wbuf_recover and
> the wbuf_sem...
> 
> jffs2_flash_writev
> ** down_write(&c->wbuf_sem);  !!!
> ** __jffs2_flush_wbuf
> **** jffs2_wbuf_recover
> ******  jffs2_block_refile
> ********  nextblock = NULL;
> ******  jffs2_reserve_space_gc
> ********  jffs2_do_reserve_space
> **********  jffs2_erase_pending_blocks
> ************  jffs2_mark_erased_block
> **************  jffs2_flash_read
> ****************  down_read(&c->wbuf_sem); !!!
> 
> I believe that when checking a newly erased block, the
> wbuf should not be used anyway, so this is probably easy to
> correct. Is it ok to create a jffs2_flash_read_nobuf function
> and call it only from jffs2_mark_erased_block ?
> 
Hello Estelle,

I've found that JFFS2 has wbuf problems on SMP again. The reason are the 
changes which were made to fix the deadlock you've spotted.
The wbuf_sem rwsem doesn't help if it is locked after you've read flash 
because by the time you copy data from wbuf it might have been chaneged. 
I.e:

/* A part of our data is in wbuf at this point */
mtd->read_ecc(...)
/* At this point another CPU fills wbuf and flushes it, so in contains 
the wrong data */
down_read(&c->wbuf_sem)
memcpy(buf, c->wbuf, len)
up_read(&c->wbuf_sem)

I'd prefer not to use jffs2_flash_read() in jffs2_mark_erased_block() 
but to directly read flash since it wbuf anyway must not correspond to a 
newly erased block.

Please, look at the attached patch.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wbuf_sem-1.diff
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20050404/7fab643a/attachment.pl 

From giangiammy at yahoo.com  Mon Apr  4 09:58:49 2005
From: giangiammy at yahoo.com (Gianluca Moro)
Date: Mon, 4 Apr 2005 15:58:49 +0200 (CEST)
Subject: JFFS2 and frequent/small write operations
Message-ID: <20050404135849.4689.qmail@web52705.mail.yahoo.com>

Hi all,

I need to use an embedded system to log some events,
which will be small as registered size (16 bytes each)
and frequent (up to 10 events/s).
The log file will be some sort of FIFO queue, 
as I will delete the old events to make space for
the new one when I'll go out of space.

I need to save on flash, I cannot keep them in RAM
and write from time to time as I cannont loose data
in a power fail event.

Does anyone have experience of using JFFS2 in this
way? do you think JFFS2 is the correct choice?
Does this type of usage can create problems?

Do you know of benchmark which analize a bhaviour
of this type?

sorry for all the questions, but I must choose
how to start my project.

thank
giammy





		
___________________________________ 
Nuovo Yahoo! Messenger: E' molto pi? divertente: Audibles, Avatar, Webcam, Giochi, Rubrica
 Scaricalo ora! 
http://it.messenger.yahoo.it



From estelle.hammache at st.com  Mon Apr  4 09:58:45 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Mon, 04 Apr 2005 15:58:45 +0200
Subject: JFFS2 & NAND failure
References: <419B8715.4036BDBB@st.com>	<1100795260.8191.7333.camel@hades.cambridge.redhat.com>	<419CE1E8.F20DD890@st.com>	<1100870238.8191.7368.camel@hades.cambridge.redhat.com>	<419E1DE0.FDD5DEC0@st.com>	<1100978366.7949.38.camel@localhost.localdomain>	<1100988787.7949.46.camel@localhost.localdomain>	<1102604262.6694.17.camel@hades.cambridge.redhat.com>	<41B88622.4BCD78EC@st.com>
	<41C02F29.92D2B5A@st.com> <425139E8.5000508@yandex.ru>
Message-ID: <42514815.AD64923B@st.com>

Hi Artem,

I ran the deadlock test with your patch and did not
observe any deadlock nor any other problem.


> -                       ret = jffs2_flash_read(c, ofs, readlen, &retlen, ebuf);
> +                       if (!jffs2_is_writebuffered(c) || !jffs2_cleanmarker_oob(c))
> +                               ret = c->mtd->read(c->mtd, ofs, readlen, &retlen, ebuf);
> +                       else
> +                               ret = c->mtd->read_ecc(c->mtd, ofs, readlen, &retlen, ebuf, NULL, c->oobinfo);
> +
>                         if (ret) {
>                                 printk(KERN_WARNING "Read of newly-erased block at 0x%08x failed: %d. Putting on bad_list\n", ofs, ret);
>                                 goto bad;


However I don't use MTD drivers, and I have no ECC 
implementation so far, so I don't know whether 
read_ecc could return an error (maybe EBADMSG) when 
it finds that the page and OOB are all FF.
Maybe just calling mtd->read unconditionally is 
good here ?

bye
Estelle



From zerivirgo at infocell-its.com  Mon Apr  4 11:05:41 2005
From: zerivirgo at infocell-its.com (Zeri Virgo)
Date: Mon, 04 Apr 2005 16:05:41 +0100
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <424CAE31.8040302@ieee.org>
References: <4249C357.2040600@ieee.org>
	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>
	<424CA4EA.8090904@infocell-its.com> <424CAE31.8040302@ieee.org>
Message-ID: <425157C5.4040007@infocell-its.com>

Dan Brown wrote:
> Don't even bother trying it with a resized firmware tomorrow :)
Been far too busy, anyway :)

> So is it correct to say that you've just switched from the diskonchip 
> driver which is distributed as part of 2.6.11.5, to the diskonchip 
> driver from the MTD CVS repository?
> 
> If so, then any of the changes between the MTD version in 2.6.11.5 and 
> the current CVS are potentially the problem, not just my latest change 
> to diskonchip.c
Exactly. I didn't feel the need to use latest MTD sources for the
diskonchip driver until your patch. Looks like the problem is in 
nand_base.c.

> The version of diskonchip.c in 2.6.11.5 is 1.45.  I don't see anything 
> in the changes between then and now (1.50) that should cause the 
> behavior you're seeing, which means either the problem is in a different 
> file or I'm just not seeing it :)
The call stack goes from mtd->read into nand_base.c nand_read() then 
nand_do_read_ecc() passing NULL to oob_buf and oob_sel. The pointer 
dereference occurs on oobsel when defining ecc_calc and ecc_code... I 
(nervously) replaced these with hard values and the probing completed 
successfully. I think most of the activity lower down does null checks 
on oobsel or doesn't use these values due to the eccmode.

I have no idea what the fix should be! Maybe move the definitions of 
ecc_calc and ecc_code below the check and set of oobsel to &mtd->oobinfo?

- Zeri



From dedekind at infradead.org  Mon Apr  4 10:47:57 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 04 Apr 2005 18:47:57 +0400
Subject: JFFS2 & NAND failure
In-Reply-To: <42514815.AD64923B@st.com>
References: <419B8715.4036BDBB@st.com>
	<1100795260.8191.7333.camel@hades.cambridge.redhat.com>
	<419CE1E8.F20DD890@st.com>
	<1100870238.8191.7368.camel@hades.cambridge.redhat.com>
	<419E1DE0.FDD5DEC0@st.com>	<1100978366.7949.38.camel@localhost.localdomain>
	<1100988787.7949.46.camel@localhost.localdomain>
	<1102604262.6694.17.camel@hades.cambridge.redhat.com>
	<41B88622.4BCD78EC@st.com> <41C02F29.92D2B5A@st.com>
	<425139E8.5000508@yandex.ru>  <42514815.AD64923B@st.com>
Message-ID: <1112626077.19212.1.camel@sauron.oktetlabs.ru>

On Mon, 2005-04-04 at 15:58 +0200, Estelle HAMMACHE wrote:
> However I don't use MTD drivers, and I have no ECC 
> implementation so far, so I don't know whether 
> read_ecc could return an error (maybe EBADMSG) when 
> it finds that the page and OOB are all FF.
It should be fine.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From dan_brown at ieee.org  Mon Apr  4 14:04:23 2005
From: dan_brown at ieee.org (Dan Brown)
Date: Mon, 04 Apr 2005 14:04:23 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <425157C5.4040007@infocell-its.com>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>
	<424CAE31.8040302@ieee.org> <425157C5.4040007@infocell-its.com>
Message-ID: <425181A7.2010809@ieee.org>

Zeri Virgo wrote:

> The call stack goes from mtd->read into nand_base.c nand_read() then 
> nand_do_read_ecc() passing NULL to oob_buf and oob_sel. The pointer 
> dereference occurs on oobsel when defining ecc_calc and ecc_code... I 
> (nervously) replaced these with hard values and the probing completed 
> successfully. I think most of the activity lower down does null checks 
> on oobsel or doesn't use these values due to the eccmode.
>
> I have no idea what the fix should be! Maybe move the definitions of 
> ecc_calc and ecc_code below the check and set of oobsel to &mtd->oobinfo?


You're 100% correct.  A recent modification to support variable-sized 
ecc_calc and ecc_code arrays didn't take into account the possibility of 
NULL oobsel.  Fixed in CVS.

Let me know if DOCBoot finally works for you, please!

    -Dan




From sergei.sharonov at halliburton.com  Mon Apr  4 13:15:52 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Mon, 4 Apr 2005 17:15:52 +0000 (UTC)
Subject: JFFS2 and frequent/small write operations
References: <20050404135849.4689.qmail@web52705.mail.yahoo.com>
Message-ID: <loom.20050404T173154-376@post.gmane.org>

Hi,

> I need to use an embedded system to log some events,
> which will be small as registered size (16 bytes each)
> and frequent (up to 10 events/s).

I am in the same boat except my chunk size is 1 kB.
Check out recent discussion on "atomic" file operations. 
>From what I understood your 16 byte write will be atomic
unless you cross page boundary (?) but my 1 kB may not.
In order to make sure that data is committed to flash
you will need to sync or fsync. I was told that O_SYNC
flag for open does not work with JFFS2 (!?).
Now, each write will create a node(s). Large number of
nodes will drastically increase RAM usage and mount time.
With a big NAND device mount time can be REALLY, REALLY
bad. I am doing some testing and will post results shortly.
One possible way to mitigate it is to store you 16 byte
chunks in some temp file(s) and then append it to your 
main log file. Here is where you will hit data integrity 
problem, e.g. you need: start transaction, append temp
file(s), remove temp files, close transaction. 

> The log file will be some sort of FIFO queue, 
> as I will delete the old events to make space for
> the new one when I'll go out of space.

Come to think of it, may be you need a transactional
database on top of JFFS2. Otherwise implementing power
fail safe FIFO operations will not be simple.

> I need to save on flash, I cannot keep them in RAM
> and write from time to time as I cannont loose data
> in a power fail event.

How is data acception by storage system handshaked?

> Does anyone have experience of using JFFS2 in this
> way? 

I am in the process of trying it out.

> do you think JFFS2 is the correct choice?

One can use open source journaling filesystem to
preserve filesystem integrity and put something on
top to guarantee data integrity.
There are also commercial transactional filesystems
but I have no experience with any of them.

> Does this type of usage can create problems?

See the above about extra data integrity layer, RAM usage
and mount time.

> Do you know of benchmark which analize a bhaviour
> of this type?

I am going to test it with my application. I don't care 
about any general purpose benchmark in this case.

 
> sorry for all the questions, but I must choose
> how to start my project.

Don't be. These are all good questions with no out
of the box solution. Your not the first to bring them
up. See discussions started by Vipin Malik in 2001 and
discussion I started of 3/22/2005.

Sergei Sharonov






From dwmw2 at infradead.org  Mon Apr  4 14:55:33 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 04 Apr 2005 19:55:33 +0100
Subject: JFFS2 and frequent/small write operations
In-Reply-To: <loom.20050404T173154-376@post.gmane.org>
References: <20050404135849.4689.qmail@web52705.mail.yahoo.com>
	<loom.20050404T173154-376@post.gmane.org>
Message-ID: <1112640934.24487.375.camel@hades.cambridge.redhat.com>

On Mon, 2005-04-04 at 17:15 +0000, Sergei Sharonov wrote:
> I was told that O_SYNC flag for open does not work with JFFS2 (!?).

You misunderstood. On NOR flash, O_SYNC does nothing because JFFS2 is
entirely synchronous anyway. On NAND flash, I believe that O_SYNC does
what it is supposed to -- any write will have reached the medium before
the write() system call returns.

This has nothing to do with atomicity of writes with respect to power
failure.

-- 
dwmw2




From sergei.sharonov at halliburton.com  Mon Apr  4 17:08:35 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Mon, 4 Apr 2005 21:08:35 +0000 (UTC)
Subject: JFFS2 and frequent/small write operations
References: <20050404135849.4689.qmail@web52705.mail.yahoo.com>
	<loom.20050404T173154-376@post.gmane.org>
	<1112640934.24487.375.camel@hades.cambridge.redhat.com>
Message-ID: <loom.20050404T224215-1@post.gmane.org>

Hi,
> On Mon, 2005-04-04 at 17:15 +0000, Sergei Sharonov wrote:
> > I was told that O_SYNC flag for open does not work with JFFS2 (!?).
> 
> You misunderstood. On NOR flash, O_SYNC does nothing because JFFS2 is
> entirely synchronous anyway. On NAND flash, I believe that O_SYNC does
> what it is supposed to -- any write will have reached the medium before
> the write() system call returns.

Thanks, that is good to know. It was suggested by others
http://article.gmane.org/gmane.linux.drivers.mtd/12175/match=+sync
that it may not work on JFFS2. Estelle?
 
> This has nothing to do with atomicity of writes with respect to power
> failure.

Sorry for the confusion. I did not mean that O_SYNC has anything to do 
with atomicity, only that it is usually one of the ways to assure that
all the data is flushed to media. I guess I heard that O_SYNC does
not work with JFFS2, did not want to accept it and was provoking people 
to confirm or disprove it ;-)

Sergei Sharonov







From MUSTHAFAAS at nestec.net  Tue Apr  5 01:47:41 2005
From: MUSTHAFAAS at nestec.net (MUSTHAFA ADIL SAEED)
Date: Tue, 5 Apr 2005 11:17:41 +0530 
Subject: Linux support for AMD S29GL256N flash
Message-ID: <273ED687CFB4D411986100306E0013BC07CF76DF@pdc1.nestec.net>

Hi,
I would like to know whether there is support for AMD S29GL256N flash chip
as part of the 
support for AMD/Fujitsu flash chips. 

 Are any modifications required in the file driver/mtd/chips/amd_flash.c in 
order to support the above said chip.

Thanks in Advance,
Adil.


---------------------------------------------------------------------------
       "This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged
information. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

       Any unauthorized review, use, disclosure, dissemination, forwarding,
printing or copying of this email or any action taken upon this e-mail is
strictly prohibited and may be unlawful."
---------------------------------------------------------------------------



From estelle.hammache at st.com  Tue Apr  5 04:43:41 2005
From: estelle.hammache at st.com (Estelle HAMMACHE)
Date: Tue, 05 Apr 2005 10:43:41 +0200
Subject: JFFS2 and frequent/small write operations
References: <20050404135849.4689.qmail@web52705.mail.yahoo.com>
	<loom.20050404T173154-376@post.gmane.org>
	<1112640934.24487.375.camel@hades.cambridge.redhat.com>
	<loom.20050404T224215-1@post.gmane.org>
Message-ID: <42524FBD.C418A0E6@st.com>

Hi Sergei,

Sergei Sharonov wrote:
> 
> Hi,
> > On Mon, 2005-04-04 at 17:15 +0000, Sergei Sharonov wrote:
> > > I was told that O_SYNC flag for open does not work with JFFS2 (!?).
> >
> > You misunderstood. On NOR flash, O_SYNC does nothing because JFFS2 is
> > entirely synchronous anyway. On NAND flash, I believe that O_SYNC does
> > what it is supposed to -- any write will have reached the medium before
> > the write() system call returns.
> 
> Thanks, that is good to know. It was suggested by others
> http://article.gmane.org/gmane.linux.drivers.mtd/12175/match=+sync
> that it may not work on JFFS2. Estelle?

In the quoted message it was pretty clear that I don't know 
one way or another (don't use linux VFS).
I was referring to previous discussions such as
"jffs2_get_inode_nodes(): Data CRC failed on NAND device" in the
February archive, where O_SYNC is _not_ proposed as a solution
to force fsync.
Sorry for the confusion... I'm glad this erroneous notion
is corrected.

bye
Estelle



From dwmw2 at infradead.org  Tue Apr  5 05:27:30 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 05 Apr 2005 10:27:30 +0100
Subject: JFFS2 and frequent/small write operations
In-Reply-To: <42524FBD.C418A0E6@st.com>
References: <20050404135849.4689.qmail@web52705.mail.yahoo.com>
	<loom.20050404T173154-376@post.gmane.org>
	<1112640934.24487.375.camel@hades.cambridge.redhat.com>
	<loom.20050404T224215-1@post.gmane.org>  <42524FBD.C418A0E6@st.com>
Message-ID: <1112693250.4397.27.camel@localhost.localdomain>

On Tue, 2005-04-05 at 10:43 +0200, Estelle HAMMACHE wrote:
> Sorry for the confusion... I'm glad this erroneous notion
> is corrected.

Actually -- looking briefly at generic_osync_inode(), I'm not entirely
convinced that we _do_ correctly flush after an O_SYNC write. Do we need
to set I_DIRTY_DATASYNC when we have outstanding data in the wbuf, and
implement write_inode() to make it get flushed?

-- 
dwmw2




From zerivirgo at infocell-its.com  Tue Apr  5 08:00:21 2005
From: zerivirgo at infocell-its.com (Zeri Virgo)
Date: Tue, 05 Apr 2005 13:00:21 +0100
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <425181A7.2010809@ieee.org>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>
	<424CAE31.8040302@ieee.org> <425157C5.4040007@infocell-its.com>
	<425181A7.2010809@ieee.org>
Message-ID: <42527DD5.4080009@infocell-its.com>

Dan Brown wrote:
> A recent modification to support variable-sized
> ecc_calc and ecc_code arrays didn't take into account the possibility of 
> NULL oobsel.  Fixed in CVS.
> 
> Let me know if DOCBoot finally works for you, please!

OK... diskonchip probing was fine with a fresh chip. Here's what I've
tried...

Built a kernel with MTD etc linked in (temporarily including hard-disk
stuff) and verified booting it from the hard-disk (obviously the 
diskonchip driver doesn't show the firmware partition, but that's ok).

Used M-Systems dformat (from tffs_5.1.4_DOS_TOOLS.zip) to resize the
firmware area
     A:\> DFORMAT /WIN:D000 /BDKL0:2M

Rebooted into a kernel with modules and ran
     # modprobe diskonchip show_firmware_partition=1
     # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 04000000 00004000 "DiskOnChip 2000 (NFTL Model)"
mtd1: 00208000 00004000 " DiskOnChip Firmware / Media Header partition"
mtd2: 03df8000 00004000 " DiskOnChip BDTL partition"

Edited docboot/cmdline to
     root=/dev/mtdblock1 rootfstype=jffs2 ro

Uncommented "#define OLD_DOC2K" in doc_bootstub.h

Copied in the bzImage I'd tested booting from hard-disk.
     # make
     # flash_eraseall /dev/mtd1
     # nandwrite -o /dev/mtd1 doc_spl
     # flash_eraseall -j /dev/mtd2

Tested mounting and unmounting /dev/mtdblock2 which seemed OK. (My 
cmdline above assumes that this will show as /dev/mtdblock1 when the 
linked-in driver is loaded.)
Rebooted and disabled/removed all other boot devices. As the BIOS gets 
going, I see "Installing DOCBoot." then a "System Configurations" page with
     ...<snip>...
     Verifying DMI Pool Data .........
     Loading kernel... _

where the "_" is a flashing cursor. The keyboard is unresponsive and 
nothing further happens :(

By the way, I have not yet copied any files to the jffs2 filesystem on 
/dev/mtdblock1 except a small text file to test the filesystem.

Any ideas? I'd really like to get this going.

Thanks again,

- Zeri



From dedekind at yandex.ru  Tue Apr  5 12:22:26 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Tue, 05 Apr 2005 20:22:26 +0400
Subject: [PATCH]  NAND I/O instruction support
In-Reply-To: <424BFC76.8020101@setabox.com>
References: <424BFC76.8020101@setabox.com>
Message-ID: <4252BB42.6010907@yandex.ru>



William J Beksi wrote:
> This patch is to implement reading and writing nand flash by I/O 
> instructions. I have only been able to test on the x86 architecture.
> 
> Questions, comments, criticisms are welcome.
Why didn't you use request_region()/release_region() to allocate IO ports?

I wonder, for what do you need this? Shouldn't you redefine 
nand_read_byte() and the like *in your driver* instead.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dan_brown at ieee.org  Tue Apr  5 15:51:57 2005
From: dan_brown at ieee.org (Dan Brown)
Date: Tue, 05 Apr 2005 15:51:57 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <42527DD5.4080009@infocell-its.com>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>
	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>
	<42527DD5.4080009@infocell-its.com>
Message-ID: <4252EC5D.4090806@ieee.org>

Zeri Virgo wrote:

> Rebooted and disabled/removed all other boot devices. As the BIOS gets 
> going, I see "Installing DOCBoot." then a "System Configurations" page 
> with
>     ...<snip>...
>     Verifying DMI Pool Data .........
>     Loading kernel... _
>
> where the "_" is a flashing cursor. The keyboard is unresponsive and 
> nothing further happens :(


OK, I'm slightly stumped.  So, I've just checked into CVS some 
additional changes to DOCBoot.  There is a small (but important) fix to 
memory size detection, which shouldn't affect you since you're not using 
initrd (I think).

There is also a new option in doc_bootstub.h: #define DEBUG_BUILD.  This 
will print out some interesting info during the "Installing DOCBoot" 
phase, and wait for a keypress.  Please copy it down and let me know 
what it says.  It will also be more verbose during the actual kernel 
loading phase; hopefully that will let us pin down exactly where it's 
hanging.

    -Dan



From mikelee at hello.com  Wed Apr  6 04:20:41 2005
From: mikelee at hello.com (mike lee)
Date: Wed, 06 Apr 2005 16:20:41 +0800
Subject: porting flash
Message-ID: <42539BD9.9060800@hello.com>

Hi all
    I am porting mtd mapping driver to MXLADS board from motorola. It
embedded two 16bit 8MB AMD CFI flash to interleave 32 bit bus. I have
set the geometry function on 2-chip interleave.
   I have no idea on this oops, Do anybody have ideas on this?
  Thanks for helping

elevator: using deadline as default io scheduler
NOR flash:(size->0x800000 mem->0x10000000)
NOR flash: try bankwidth 32bit, probing...
NOR Flash: Found 2 x16 devices at 0x0 in 32-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
NOR Flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
NOR flash driver: Use static partition allocation
Creating 5 MTD partitions on "NOR Flash 1":
0x00000000-0x00100000 : "bootloader"
0x00100000-0x00300000 : "kernel"
0x00300000-0x00500000 : "System RFS"
0x00500000-0x00700000 : "User Application"
0x00700000-0x00800000 : "User Data"
Bluetooth: HCI UART driver ver 2.1
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
Bluetooth: L2CAP ver 2.6
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.3
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0
PC is at __wake_up_common+0x28/0x7c
LR is at 0x0
pc : [<c00318e0>]    lr : [<00000000>]    Not tainted
sp : c035be4c  ip : c035be78  fp : c035be74
r10: 00000003  r9 : 00000000  r8 : 00000000
r7 : c0198494  r6 : c035a000  r5 : c027dcf4  r4 : 00000001
r3 : 00000000  r2 : 00000001  r1 : 00000003  r0 : c027dcf4
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
Control: C000717F  Table: 08004000  DAC: 0000001D
Process mtdblockd (pid: 10, stack limit = 0xc035a190)
Stack: (0xc035be4c to 0xc035c000)
be40:                            c035a000 60000013 c035a000 c0198494
c027dcd8
be60: c027dcd8 00000000 c035be90 c035be78 c0031974 c00318c8 00000000
00000000
be80: c027dca0 c035beb8 c035be94 c00fe5f4 c0031944 c027dca0 00000000
c027dca0
bea0: c035a000 00000200 c0198494 c035bf0c c035bebc c00fe848 c00fe4cc
00000000
bec0: 00000000 c027dca0 00300000 00300000 00000000 00000200 c027dca0
00000200
bee0: 00000000 00000000 00000200 00000000 00000200 c035bf54 00000000
c038c000
bf00: c035bf44 c035bf10 c00f7dec c00fe614 c035bf54 c038c000 00000001
c035bf44
bf20: 00000200 00000000 00000200 c0363de0 c038c000 00020000 c035bf80
c035bf48
bf40: c00fa818 c00f7d64 c035bf54 c038c000 c0347200 00000000 00000008
00000000
bf60: c038c000 c0198334 c035ef60 00000000 c0349304 c035bfa4 c035bf84
c00fabf4
bf80: c00fa750 c035ef70 c035a000 c035ef60 c035068c c0198334 c035bff4
c035bfa8
bfa0: c00fae58 c00fab94 00000000 c02cd560 c00318a0 00000000 00000000
00000000
bfc0: c02cd560 c00318a0 00000000 00000000 00000000 00000000 00000000
00000000
bfe0: 00000000 00000000 00000000 c035bff8 c0037c50 c00fac88 00000000
00000000
Backtrace:
[<c00318b8>] (__wake_up_common+0x0/0x7c) from [<c0031974>]
(__wake_up+0x40/0x64)
[<c0031934>] (__wake_up+0x0/0x64) from [<c00fe5f4>] (put_chip+0x138/0x148)
 r5 = C027DCA0  r4 = 00000000
[<c00fe4bc>] (put_chip+0x0/0x148) from [<c00fe848>]
(cfi_amdstd_read+0x244/0x2bc)
 r8 = C0198494  r7 = 00000200  r6 = C035A000  r5 = C027DCA0
 r4 = 00000000
[<c00fe604>] (cfi_amdstd_read+0x0/0x2bc) from [<c00f7dec>]
(part_read+0x98/0xcc)
[<c00f7d54>] (part_read+0x0/0xcc) from [<c00fa818>]
(do_cached_read+0xd8/0x10c)
[<c00fa740>] (do_cached_read+0x0/0x10c) from [<c00fabf4>]
(do_blktrans_request+0x70/0xf4)
[<c00fab84>] (do_blktrans_request+0x0/0xf4) from [<c00fae58>]
(mtd_blktrans_thread+0x1e0/0x278)
 r8 = C0198334  r7 = C035068C  r6 = C035EF60  r5 = C035A000
 r4 = C035EF70
[<c00fac78>] (mtd_blktrans_thread+0x0/0x278) from [<c0037c50>]
(do_exit+0x0/0x534)
Code: e1a0a001 e1a04002 e1a08003 e59b9004 (e59e7000)
 <0>Kernel panic - not syncing: Aiee, killing interrupt handler!




From alfred.hitch at gmail.com  Wed Apr  6 04:32:55 2005
From: alfred.hitch at gmail.com (alfred hitch)
Date: Wed, 6 Apr 2005 04:32:55 -0400
Subject: 2nd flash detection on ixp425 based boards
Message-ID: <29f9165105040601323ef8d30@mail.gmail.com>

Hi,

This is regading cfi probe for multiple flash chips  ..

On my IXP425 based board, with 2 chips, one on CS0(16MB)
and other on CS1 (16 MB) ..

I am able to probe and write through to these devices in my probe ..
all's well .

but today, we were changing hardware configuration to have 8MB on CS1
in stead of 16MB ..
and I notice that in the gen_probe.c -> genprobe_ident_chips function ..
the for loop which checks for base size is to map->size will not pass thru ..
that is it will say find 16 + 16 <= 24 (configured as window_size)

I see a comment above it also saying that this is to check that the
size is good enough to accomodate another chip of same size in this
probe..

Please help me understand that why are we doing it this way .. is h/w
config like we are trying to have wrong ? why cannot I put base <
cfi.chipshiftsize in
that for loop and map both the devices .. why does the second one has
to be this way of size more or equal to first one ..

Cheers,
Alfred



From zerivirgo at infocell-its.com  Wed Apr  6 08:13:52 2005
From: zerivirgo at infocell-its.com (Zeri Virgo)
Date: Wed, 06 Apr 2005 13:13:52 +0100
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4252EC5D.4090806@ieee.org>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>
	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>
	<42527DD5.4080009@infocell-its.com> <4252EC5D.4090806@ieee.org>
Message-ID: <4253D280.6090308@infocell-its.com>

 > There is a small (but important) fix to
> memory size detection, which shouldn't affect you since you're not using 
> initrd (I think).
No, you're right - I'm not using initrd.

> There is also a new option in doc_bootstub.h: #define DEBUG_BUILD.  This 
> will print out some interesting info during the "Installing DOCBoot" 
> phase, and wait for a keypress.

--------------------------------------------------------------
Award Modular BIOS v4.51PG, An Energy Star Ally
...
HS-4020 VER:1.4

Cyrix MediaGX With MMX-S CPU at 300MHz
Memory Test :   64000K OK + 1536 shared memory

Award Plug and Play BIOS Extension v1.0A
...
Installing DOCBoot.
doc_seg = 0xD000    setup_seg = 0x2000
int15/88 returns 0xF600    initrd_start = 0x000000
top of low mem = 0x0280k    handler seg = 0x9FC0
   -- Press any key --
--------------------------------------------------------------

...<snip>...
Loading kernel ... page 0x.... <- this seems to start at zero and be 
going up at roughly 0x200 a second up to 0xFFFF then restarting at zero 
again over and over.

Just to give you a clearer picture, the bzImage is 1148021 bytes and 
doc_spl is 1187472 bytes. The nandwrite command wrote doc_spl from 0 up 
to the erase block at 0x118000 which is well within the 0x208000 
firmware area. The board is a Boser HS-4020 v1.4.

Unfortunately, assembler is greek to me!

- Zeri



From zerivirgo at infocell-its.com  Wed Apr  6 08:29:16 2005
From: zerivirgo at infocell-its.com (Zeri Virgo)
Date: Wed, 06 Apr 2005 13:29:16 +0100
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4253D280.6090308@infocell-its.com>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>
	<4252EC5D.4090806@ieee.org> <4253D280.6090308@infocell-its.com>
Message-ID: <4253D61C.6010109@infocell-its.com>

> Just to give you a clearer picture, the bzImage is 1148021 bytes and 
> doc_spl is 1187472 bytes. The nandwrite command writes doc_spl from 0 up 
> to the erase block at 0x118000 which is well within the 0x208000 
> firmware area.

Hey, I just noticed that 0x11c000 (0x118000 + 4000) is only 1163264 
bytes - doesn't that mean doc_spl wasn't fully written to the chip!?

- Zeri



From dan_brown at ieee.org  Wed Apr  6 09:12:54 2005
From: dan_brown at ieee.org (Dan Brown)
Date: Wed, 06 Apr 2005 09:12:54 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4253D61C.6010109@infocell-its.com>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>
	<4253D280.6090308@infocell-its.com>
	<4253D61C.6010109@infocell-its.com>
Message-ID: <4253E056.5050603@ieee.org>

Zeri Virgo wrote:

>> ...<snip>...
>> Loading kernel ... page 0x.... <- this seems to start at zero and be 
>> going up at roughly 0x200 a second up to 0xFFFF then restarting at 
>> zero again over and over.
>

The page number you see there is the offset (in 512-byte pages) on the 
diskonchip that DOCBoot is currently scanning, trying to find your 
kernel.  DOCBoot looks for a special tag in the OOB area of each page 
belonging to your kernel image.  I can think of two reasons for this 
process to loop forever:

  1) The image didn't get written properly (using nandwrite without the 
-o option would certainly have this effect, but you indicated that you 
did use -o).
  2) DOCBoot is having trouble reading your device, perhaps because my 
new non-TSOP DOC2k support is not general enough.


>> Just to give you a clearer picture, the bzImage is 1148021 bytes and 
>> doc_spl is 1187472 bytes. The nandwrite command writes doc_spl from 0 
>> up to the erase block at 0x118000 which is well within the 0x208000 
>> firmware area.
>
>
> Hey, I just noticed that 0x11c000 (0x118000 + 4000) is only 1163264 
> bytes - doesn't that mean doc_spl wasn't fully written to the chip!?


No.  Each 512-byte page on the flash is associated with 16 bytes of 
out-of-band (OOB) data.  doc_spl contains this data interspersed with 
the normal data.  nandwrite reports the page address, which only 
reflects the location of the normal data.  So, the amount of normal data 
in doc_spl is

  length * 512 / (512 + 16)

In your case that's 1151488, or 0x119200 bytes of normal data.  Thus the 
image should end in the erase block which starts at 0x118000 and ends at 
0x11C000, as reported by nandwrite.

Note that a partially-written image would NOT result in an infinite loop 
in DOCBoot, because (as you saw) it will eventually wrap all the way 
around to the start of the device if it can't find the number of tagged 
pages it's expecting.  After it wraps around, it will (stupidly) make up 
the missing pages by reloading tagged pages from the start of the device.

I'm not sure where to go next.  Can you please run "mtd_debug info 
/dev/mtd0" and tell me the result, just as a sanity check?

    -Dan



From zerivirgo at infocell-its.com  Wed Apr  6 10:48:34 2005
From: zerivirgo at infocell-its.com (Zeri Virgo)
Date: Wed, 06 Apr 2005 15:48:34 +0100
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4253E056.5050603@ieee.org>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>
	<4253D280.6090308@infocell-its.com>
	<4253D61C.6010109@infocell-its.com> <4253E056.5050603@ieee.org>
Message-ID: <4253F6C2.1080105@infocell-its.com>

>  1) The image didn't get written properly (using nandwrite without the 
> -o option would certainly have this effect, but you indicated that you 
> did use -o).
Yes, I definitely used the -o option to nandwrite.

> I'm not sure where to go next.  Can you please run "mtd_debug info 
> /dev/mtd0" and tell me the result, just as a sanity check?
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB | MTD_ECC
mtd.size = 67108864 (64M)
mtd.erasesize = 16384 (16K)
mtd.oobblock = 512
mtd.oobsize = 16
mtd.ecctype = (unknown ECC type - new MTD API maybe?)
regions = 0


This may be useless, but I did a nanddump of the first 0x208000 bytes.
0x00 to 0xff -> data

Then each of the following chunks of data (ie, not chunks of ff) are 
preceeded by OOB Data
(eg,
   OOB Data: 36 7f eb 1f 3b aa ff ff ff ff ff ff ff ff ff ff
0x000000200: 0e cd...)

0x200 to 0x2ff -> data
0x400 to 0x43a -> data
0x600 to 0x629 -> data
0x800 to 0x8ff -> data
0xa00 to 0xa75 -> data

Then a large chunk (1144949 bytes)
0xc00 to 0x119075 -> data

Some mysterious OOB Data before 0x119200, though no normal data 
following it.

Then the rest is blank.

- Zeri



From dan_brown at ieee.org  Wed Apr  6 12:29:07 2005
From: dan_brown at ieee.org (Dan Brown)
Date: Wed, 06 Apr 2005 12:29:07 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4253F6C2.1080105@infocell-its.com>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>	<4253D280.6090308@infocell-its.com>	<4253D61C.6010109@infocell-its.com>
	<4253E056.5050603@ieee.org> <4253F6C2.1080105@infocell-its.com>
Message-ID: <42540E53.8080109@ieee.org>

Zeri Virgo wrote:

> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB | MTD_ECC
> mtd.size = 67108864 (64M)
> mtd.erasesize = 16384 (16K)
> mtd.oobblock = 512
> mtd.oobsize = 16
> mtd.ecctype = (unknown ECC type - new MTD API maybe?)
> regions = 0


Looks fine.

> This may be useless, but I did a nanddump of the first 0x208000 bytes.
> 0x00 to 0xff -> data
>
> Then each of the following chunks of data (ie, not chunks of ff) are 
> preceeded by OOB Data
> (eg,
>   OOB Data: 36 7f eb 1f 3b aa ff ff ff ff ff ff ff ff ff ff
> 0x000000200: 0e cd...)
>
> 0x200 to 0x2ff -> data
> 0x400 to 0x43a -> data
> 0x600 to 0x629 -> data
> 0x800 to 0x8ff -> data
> 0xa00 to 0xa75 -> data
>
> Then a large chunk (1144949 bytes)
> 0xc00 to 0x119075 -> data
>
> Some mysterious OOB Data before 0x119200, though no normal data 
> following it.
>
> Then the rest is blank.


Sounds right, at first glance.  The OOB data actually follows each block 
(perhaps that's just a terminology issue :) )

    -Dan




From dan.brown at nrl.navy.mil  Wed Apr  6 14:23:34 2005
From: dan.brown at nrl.navy.mil (Dan Brown)
Date: Wed, 06 Apr 2005 14:23:34 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <42540E53.8080109@ieee.org>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>	<4253D280.6090308@infocell-its.com>	<4253D61C.6010109@infocell-its.com>	<4253E056.5050603@ieee.org>
	<4253F6C2.1080105@infocell-its.com> <42540E53.8080109@ieee.org>
Message-ID: <42542926.9040209@nrl.navy.mil>

Dan Brown wrote:
> Zeri Virgo wrote:
> 
>>   OOB Data: 36 7f eb 1f 3b aa ff ff ff ff ff ff ff ff ff ff
> 
> Sounds right, at first glance.  The OOB data actually follows each block 
> (perhaps that's just a terminology issue :) )

Ah, I see it!  That OOB data is actually wrong, it should be:

?? ?? ?? ?? ?? ?? 55 55 ff ff ff ff ff ff ff ff

Here's the whole sordid story:

1) The only reason DOCBoot has been working for *me* lately is because 
I've been lazy/stupid.

2) Specifically, although I've been updating my copies of the kernel 
code to keep pace with CVS changes, I have *failed* to update my 
mtd/utils subdirectory.

3) Thomas recently made a modification to nandwrite.  It forces all OOB 
bytes not designated as "free" to 0xff.  Perfectly sensible.

4) There is apparently a long-standing oddity in diskonchip.c, in which 
I set the number of ECC bytes to 6, and designate the last 8 bytes as 
"free" bytes.  This leaves two bytes (right after the ECC) unaccounted for.

5) DOCBoot puts magic numbers in those exact two OOB bytes.

6) As a result, recent versions of nandwrite will erase the information 
DOCBoot needs to identify kernel pages.  I've been blissfully unaware of 
this because I've been using an older version.

7) So, I've changed diskonchip.c to designate all of the last 10 bytes 
as "free".  It seems like the right thing to do, since only the first 6 
bytes are used by the hardware itself.  BUT ....

8) I have this nagging feeling there was a reason for 4).

9) I think this may break compatibility with any jffs2 filesystems 
written before the change, because the cleanmarker will be in the wrong 
place.  Hmm... maybe I should back out the change.  David? Thomas? Opinions?

10) AAAARRRGGGHHHH!!!!

	-Dan



From sergei.sharonov at halliburton.com  Wed Apr  6 14:47:22 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Wed, 6 Apr 2005 18:47:22 +0000 (UTC)
Subject: long umount time
Message-ID: <loom.20050406T200915-152@post.gmane.org>

Hi,
I sometimes see excessively long umount times (40-60 s) with jffs2/nand. 
The platform is a custom at91rm9200 board running linux 2.6.10 with 
mtd snapshot from 3/28/2005. Umount is from busybox. The umount time varies
but the system is mostly idle during it unlike during mount. After a few
operations with filesystem it goes away until sometime later. Has anybody 
seen that?

Sergei Sharonov





From francis.derama at eazix.com  Thu Apr  7 02:08:17 2005
From: francis.derama at eazix.com (Franz De Rama)
Date: Thu, 7 Apr 2005 14:08:17 +0800
Subject: DoC Millennium Plus on RedBoot
Message-ID: <E02DDFEE79372340B35395EDE51EFAEE2CBB31@eazix-win2ks0.eazix.com>

Resend. (subject line changed)



Hi All,

I am currently developing a code to support DiskOnChip Millennium Plus
32MB on RedBoot. Such that I could be able to detect my DoC from redboot
and load the Linux and root file system image from it. I am using a
dragonball MX1 processor with an on-board flash for booting. 

Odd as it may seem, I have added an IDE support for RedBoot and am
modifying the ide.c from redboot packages (/redboot/src/fs/ide.c) to
support DiskOnChip instead of IDEs and for the meantime, ext2 file
system.

Am I going the right direction? If not, could somebody shed light on
what I need to do to add DiskOnChip support on RedBoot?

Many thanks.




From jeanwelly at gmail.com  Thu Apr  7 05:47:17 2005
From: jeanwelly at gmail.com (zheng wei)
Date: Thu, 7 Apr 2005 17:47:17 +0800
Subject: Error found when mounting a NANDFlash block as yaffs
Message-ID: <c2bc1f405040702476af04972@mail.gmail.com>

I can't figure out what caused this error? Any comments are welcome.

linux command line is: "noinitrd root=/dev/mtdblock/3 init=/linuxrc
console=tty"MACH_TYPE = 193
NOW, Booting Linux......
Uncompressing Linux.........................................................
do.Linux version 2.4.18-rmk7-pxa1 (root at localhost.localdomain) (gcc
version 2.95.24CPU: ARM/CIRRUS Arm920Tsid(wb) revision 0
Machine: Samsung-SMDK2410
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: noinitrd root=/dev/mtdblock/3 init=/linuxrc console=ttyS0
DEBUG: timer count 15626
Console: colour dummy device 80x30
Calibrating delay loop... 99.94 BogoMIPS
Memory: 64MB = 64MB total
Memory: 62540KB available (1416K code, 434K data, 76K init)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
CPU clock = 200.000 Mhz, HCLK = 100.000 Mhz, PCLK = 50.000 Mhz
Initializing S3C2410 buffer pool for DMA workaround
S3C2410 USB Controller Core Initialized
eth0: cs8900 rev K(3.3 Volts) found at 0xd0000300
cs89x0 media RJ-45, IRQ 37
get_random_bytes called before random driver initialization
usbctl: Opened for usb-eth
usbctl: Started for usb-eth
Starting kswapd
devfs: v1.10 (20020120) Richard Gooch (rgooch at atnf.csiro.au)
devfs: boot_options: 0x1
ttyS%d0 at I/O 0x50000000 (irq = 52) is a S3C2410
ttyS%d1 at I/O 0x50004000 (irq = 55) is a S3C2410
ttyS%d2 at I/O 0x50008000 (irq = 58) is a S3C2410
Console: switching to colour frame buffer device 30x40
Installed S3C2410 frame buffer
pty: 256 Unix98 ptys configured
s3c2410-ts initialized
S3C2410 Real Time Clock Driver v0.1
block: 128 slots per queue, batch=32
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
loop: loaded (max 8 devices)
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
UDA1341 audio driver initialized
flash device information ec 76
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V)
Creating 5 MTD partitions on "NAND 64MiB 3,3V":
0x00000000-0x00020000 : "loader"
0x00020000-0x00030000 : "param"
0x00030000-0x001f0000 : "kernel"
0x00200000-0x00400000 : "root"
0x00400000-0x03ef8000 : "usr"
this is the result of add_mtd_partitions 0
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xe9000000, IRQ 26
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
port #1 suspened!
port #0 alived!
hub.c: 1 port detected
usb.c: registered new driver usblp
printer.c: v0.8:USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
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
zw:Read first block, super.magic is28cd3d45
VFS: Mounted root (cramfs filesystem).
Mounted devfs on /dev
Freeing init memory: 76K
zw: mount /etc as ramfs
zw: re-create the /etc/mtab entries
zw: /bin/mount -f -t cramfs -o remount,ro /dev/mtdblock/3 /
zw: /sbin/insmod -f /lib/yaffs.o
zw: /bin/mount -t yaffs /dev/mtdblock/4 /usr
yaffs: dev is 7940 name is "1f:04"
Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = c3eb4000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: ffffffff
CPU: 0
pc : [<c4886b70>]    lr : [<c4886940>]    Not tainted
sp : c3ebbbc4  ip : c3dac65c  fp : c3ebbbd0
r10: 0000c6a4  r9 : 00000004  r8 : 00000635
r7 : c3e12000  r6 : c3ebbbf4  r5 : c3dac640  r4 : c3ddc5dc
r3 : 00000000  r2 : c3ddc630  r1 : c3dac640  r0 : c3ddc5dc
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C000317F  Table: 33EB4000  DAC: 00000015
Process mount (pid: 18, stackpage=c3ebb000)
Stack: (0xc3ebbbb4 to 0xc3ebc000)
bba0:                                              c4886940 c4886b70 20000013
bbc0: ffffffff c3ebbe2c c3ebbbd4 c4886940 c4886b1c 00000001 00000636 c3ebbbec
bbe0: c3e2b1a0 00000000 00000001 ffd00000 c1e4030b 00000001 00000102 6f70ffff
bc00: 2e726577 006c6d78 00000000 00000000 00000000 00000000 00000000 00000000
bc20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bc40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bc60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bc80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bca0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bcc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffff0000
bd00: 000081ed 00000000 00000000 4cfa5e7d 4cfa5e7d 4cfa5e7d 00000000 ffffffff
bd20: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
bd40: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
bd60: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
bd80: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
bda0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
bdc0: 00000000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
bde0: ffffffff ffffffff ffffffff ffffffff ffffffff ffd00000 030bffff e457a966
be00: c3fff3c1 00000000 000041b6 c3e12000 c0374c00 00000200 00000000 c4889258
be20: c3ebbe48 c3ebbe30 c48873a4 c4886350 00000000 c3e12000 00000d14 c3ebbe70
be40: c3ebbe4c c4881a64 c488710c c0374c00 c0374c44 c039b160 00001f04 ffffffea
be60: 00000000 c3ebbe80 c3ebbe74 c4881bb4 c48817ec c3ebbed8 c3ebbe84 c00500e8
be80: c4881b9c c3ebbe94 00000003 c3e13000 c4889414 c3e4ab20 c02ee360 c3e04000
bea0: c02ee3e0 c3e04000 00000009 00000001 00000000 c02ee3e0 c4889414 c3e13000
bec0: c3e04000 c3e05000 c3e04000 c3ebbefc c3ebbedc c00506f0 c004fec0 c3ebbf2c
bee0: 00000000 c3ebbf2c 00000000 c039c000 c3ebbf20 c3ebbf00 c0062bf0 c005063c
bf00: 00000000 00000000 c3ebbf2c 00000000 c039c000 c3ebbf70 c3ebbf24 c0062f44
bf20: c0062bdc c3e04000 c3e13000 c3ebd1c0 c02ee320 c3e13000 00001000 00001000
bf40: 00000009 00000001 00000000 00000000 0204de50 c039c000 c0ed0000 c3eba000
bf60: bfffffbe c3ebbfa4 c3ebbf74 c0062ffc c0062df0 c3e13000 c3e13000 c3e04000
bf80: c3e05000 0204fe88 00000000 c0ed0000 00000015 c001b7c4 00000000 c3ebbfa8
bfa0: c001b640 c0062f70 0204fe88 c0021728 0204de50 0204fe78 bfffffbe c0ed0000
bfc0: 0204fe88 00000000 c0ed0000 00000000 0204fe78 00000000 bfffffbe bffffee8
bfe0: 4009eb90 bffff8a4 0201e178 4009eb9c 60000010 0204de50 00000000 00042000
Backtrace:
Function entered at [<c4886b0c>] from [<c4886940>]
Function entered at [<c4886340>] from [<c48873a4>]
Function entered at [<c48870fc>] from [<c4881a64>]
 r6 = 00000D14  r5 = C3E12000  r4 = 00000000
Function entered at [<c48817dc>] from [<c4881bb4>]
Function entered at [<c4881b8c>] from [<c00500e8>]
Function entered at [<c004feb0>] from [<c00506f0>]
Function entered at [<c005062c>] from [<c0062bf0>]
 r8 = C039C000  r7 = 00000000  r6 = C3EBBF2C  r5 = 00000000
 r4 = C3EBBF2C
Function entered at [<c0062bcc>] from [<c0062f44>]
 r8 = C039C000  r7 = 00000000  r6 = C3EBBF2C  r5 = 00000000
 r4 = 00000000
Function entered at [<c0062de0>] from [<c0062ffc>]
Function entered at [<c0062f60>] from [<c001b640>]
 r8 = C001B7C4  r7 = 00000015  r6 = C0ED0000  r5 = 00000000
 r4 = 0204FE88
Code: e581c01c e58cc004 e5903054 e2802054 (e583c004)
Segmentation fault
zw: exec /sbin/init
console=/dev/co.sole
init started:  BusyBox v0.60.3 (2002.05.13-08:36+0000) multi-c???l binary
Starting pid 21, console /dev/console: '/etc/init.d/rcS'
exec: /usr/etc/rc.local: No such file or dire???ory
Waiting for enter to start '/bin/sh' (pid 24, terminal /dev/console)
                                                                                
Please press Enter to activate this console.


-- 
---------
jeanwelly
Email:  jeanwelly at gmail.com
China



From dedekind at infradead.org  Thu Apr  7 06:15:31 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 7 Apr 2005 11:15:31 +0100 (BST)
Subject: long umount time
In-Reply-To: <loom.20050406T200915-152@post.gmane.org>
References: <loom.20050406T200915-152@post.gmane.org>
Message-ID: <Pine.LNX.4.58.0504071055520.20339@phoenix.infradead.org>

On Wed, 6 Apr 2005, Sergei Sharonov wrote:

> Hi,
> I sometimes see excessively long umount times (40-60 s) with jffs2/nand. 
> The platform is a custom at91rm9200 board running linux 2.6.10 with 
> mtd snapshot from 3/28/2005. Umount is from busybox. The umount time varies
> but the system is mostly idle during it unlike during mount. After a few
> operations with filesystem it goes away until sometime later. Has anybody 
> seen that?
>
I see 2 reasons why umounts can be slow:
1. The GC thread receives several SIGHUP signals and JFFS2 waits for 
the GC thread has processed them all and has reached the SIGKILL signal.

2. The final wbuf synchronization founds that there is no space and 
performs GC to free some room. We may imagine scenarios when this may take 
considerable time.

Please, look at jffs2_gcd_mtd thread - does it eat a lot of CPU cycles 
during these long unmounts ?

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From tglx at linutronix.de  Thu Apr  7 07:42:38 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 07 Apr 2005 13:42:38 +0200
Subject: Error found when mounting a NANDFlash block as yaffs
In-Reply-To: <c2bc1f405040702476af04972@mail.gmail.com>
References: <c2bc1f405040702476af04972@mail.gmail.com>
Message-ID: <1112874158.4228.130.camel@tglx.tec.linutronix.de>

On Thu, 2005-04-07 at 17:47 +0800, zheng wei wrote:
> do.Linux version 2.4.18-rmk7-pxa1 (root at localhost.localdomain) (gcc

1. The NAND driver in 2.4.18 is broken and not usable.

2. Please read:
http://www.linux-mtd.infradead.org/source.html#kernelversions

> VFS: Mounted root (cramfs filesystem).

CRAMFS on NAND is not a really good idea. CRAMFS is not bad block aware.

> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> pgd = c3eb4000
> ....
>  r4 = 0204FE88

Please read: linux/Documentation/oops-tracing.txt

tglx





From killekulla at rdrz.de  Thu Apr  7 07:39:09 2005
From: killekulla at rdrz.de (Raphael Zimmerer)
Date: Thu, 7 Apr 2005 13:39:09 +0200
Subject: [patch] docmilplus.c, fix compilation error
Message-ID: <20050407113909.GZ4763@rdrz.de>

When CONFIG_MTD_PARTITIONS is defined, docmilplus.c doesn't compile.

Index: mtd/drivers/mtd/nand/diskonchip.c
===================================================================
--- mtd.orig/drivers/mtd/nand/diskonchip.c	2005-04-06 09:48:10.622501508 +0200
+++ mtd/drivers/mtd/nand/diskonchip.c	2005-04-06 10:26:59.702684218 +0200
@@ -109,10 +109,10 @@
 #ifdef CONFIG_MTD_PARTITIONS
 static int no_autopart=0;
 module_param(no_autopart, int, 0);
+#endif
 
 static int show_firmware_partition=0;
 module_param(show_firmware_partition, int, 0);
-#endif
 
 #ifdef MTD_NAND_DISKONCHIP_BBTWRITE
 static int inftl_bbt_write=1;

--



From dan_brown at ieee.org  Thu Apr  7 10:27:06 2005
From: dan_brown at ieee.org (Dan Brown)
Date: Thu, 07 Apr 2005 10:27:06 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <42542926.9040209@nrl.navy.mil>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>	<4253D280.6090308@infocell-its.com>	<4253D61C.6010109@infocell-its.com>	<4253E056.5050603@ieee.org>	<4253F6C2.1080105@infocell-its.com>
	<42540E53.8080109@ieee.org> <42542926.9040209@nrl.navy.mil>
Message-ID: <4255433A.4080008@ieee.org>

Dan Brown wrote:
> 7) So, I've changed diskonchip.c to designate all of the last 10 bytes 
> as "free".  It seems like the right thing to do, since only the first 6 
> bytes are used by the hardware itself.  BUT ....
> 
> 9) I think this may break compatibility with any jffs2 filesystems 
> written before the change, because the cleanmarker will be in the wrong 
> place.  Hmm... maybe I should back out the change.  David? Thomas? 
> Opinions?

After much discussion and experimentation, a version of diskonchip.c 
which does not break older jffs2 filesystems has been checked into CVS. 
  Also, some required changes to nandwrite have been checked in as well.

Zeri, I really think this should work for you now, particularly since I 
was able to duplicate exactly the problems you were having.

	-Dan



From sergei.sharonov at halliburton.com  Thu Apr  7 11:28:41 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Thu, 7 Apr 2005 15:28:41 +0000 (UTC)
Subject: long umount time
References: <loom.20050406T200915-152@post.gmane.org>
	<Pine.LNX.4.58.0504071055520.20339@phoenix.infradead.org>
Message-ID: <loom.20050407T171509-845@post.gmane.org>

Hi,

> Please, look at jffs2_gcd_mtd thread - does it eat a lot of CPU cycles 
> during these long unmounts ?
I got the board in the oven running endurance test again.. I'll post results
once I get hardware back. I got prior results captured in text file with
Hyperterminal but the bloody thing has messed the text file (Dah!). From
what I recall user and system times were close to 0, so I suppose nothing
was eating CPU cycles.

Sergei Sharonov





From zerivirgo at infocell-its.com  Thu Apr  7 17:45:56 2005
From: zerivirgo at infocell-its.com (Zeri Virgo)
Date: Thu, 07 Apr 2005 22:45:56 +0100
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4255433A.4080008@ieee.org>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>	<4253D280.6090308@infocell-its.com>	<4253D61C.6010109@infocell-its.com>	<4253E056.5050603@ieee.org>	<4253F6C2.1080105@infocell-its.com>
	<42540E53.8080109@ieee.org> <42542926.9040209@nrl.navy.mil>
	<4255433A.4080008@ieee.org>
Message-ID: <4255AA14.80701@infocell-its.com>

> After much discussion and experimentation, a version of diskonchip.c 
> which does not break older jffs2 filesystems has been checked into CVS. 
>  Also, some required changes to nandwrite have been checked in as well.
> 
> Zeri, I really think this should work for you now, particularly since I 
> was able to duplicate exactly the problems you were having.

Yes! With the diskonchip driver, flash_eraseall and nandwrite and 
DOCBoot from CVS, my DiskOnChip now boots the Linux kernel.

Thanks for everything!

- Zeri



From dwmw2 at redhat.com  Fri Apr  8 05:50:45 2005
From: dwmw2 at redhat.com (David Woodhouse)
Date: Fri, 08 Apr 2005 10:50:45 +0100
Subject: [PATCH 2.6.12-rc2] Add flash mapping for Radstone PPC7D
In-Reply-To: <F38DEABE0E171746B133C1ABBD142D9703691AF4@radmail.Radstone.Local>
References: <F38DEABE0E171746B133C1ABBD142D9703691AF4@radmail.Radstone.Local>
Message-ID: <1112953845.5714.67.camel@localhost.localdomain>

On Fri, 2005-04-08 at 10:48 +0100, Chris Elston wrote:
> Comments/criticisms on this technique and the rest of the patch would
> be much appreciated.

vmalloc() can sleep, but you may not in your read/write map functions.

-- 
dwmw2




From wjbeksi at setabox.com  Tue Apr  5 22:39:08 2005
From: wjbeksi at setabox.com (William J Beksi)
Date: Wed, 06 Apr 2005 10:39:08 +0800
Subject: [PATCH]  NAND I/O instruction support
In-Reply-To: <4252BB42.6010907@yandex.ru>
References: <424BFC76.8020101@setabox.com> <4252BB42.6010907@yandex.ru>
Message-ID: <42534BCC.3080106@setabox.com>

Hi Artem,

Artem B. Bityuckiy wrote:
> 
> 
> William J Beksi wrote:
> 
>> This patch is to implement reading and writing nand flash by I/O 
>> instructions. I have only been able to test on the x86 architecture.
>>
>> Questions, comments, criticisms are welcome.
> 
> Why didn't you use request_region()/release_region() to allocate IO ports?
> 
> I wonder, for what do you need this? 
Because I want to use the *same* I/O port range as that used by the IDE 
interface on a PC. I think a look at my driver below will make things 
clearer ;)

> Shouldn't you redefine nand_read_byte() and the like *in your driver* instead.
Sure, it can be done like that. I am just not sure if this feature would 
be useful to other driver writers in the future, that is why I tried to 
make it as general as possible.

Thomas, should read/write using inb/outb be in my driver, or should this 
be in nand_base.c?

Thanks for your comments.
--
William


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ide.c
Type: text/x-csrc
Size: 3946 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050406/47f6fcb4/attachment.bin 

From alfred.hitch at gmail.com  Thu Apr  7 01:39:38 2005
From: alfred.hitch at gmail.com (alfred hitch)
Date: Thu, 7 Apr 2005 01:39:38 -0400
Subject: 2nd flash detection on ixp425 based boards
In-Reply-To: <29f91651050406194833bd6bda@mail.gmail.com>
References: <29f9165105040601323ef8d30@mail.gmail.com>
	<29f91651050406194833bd6bda@mail.gmail.com>
Message-ID: <29f916510504062239522af179@mail.gmail.com>

Hi,

could some one please help me understand that why is the
genprobe_ident_chips function .. working this way ?

that is in for loop adding probed device size again ??
wouldnt it cause it to miss probes for devices whose size is lower
than firsqt one .. ?

Anyone provide some input ?

and surprisingly, when I remove this check / patch it to not add .. I
am able to work with my flash just fine .. ?
so what was the reason to do it that way ?

Cheers,
Alfred

---------- Forwarded message ----------
From: alfred hitch <alfred.hitch at gmail.com>
Date: Apr 6, 2005 4:32 AM
Subject: 2nd flash detection on ixp425 based boards
To: linux-mtd at lists.infradead.org

Hi,

This is regading cfi probe for multiple flash chips  ..

On my IXP425 based board, with 2 chips, one on CS0(16MB)
and other on CS1 (16 MB) ..

I am able to probe and write through to these devices in my probe ..
all's well .

but today, we were changing hardware configuration to have 8MB on CS1
in stead of 16MB ..
and I notice that in the gen_probe.c -> genprobe_ident_chips function ..
the for loop which checks for base size is to map->size will not pass thru ..
that is it will say find 16 + 16 <= 24 (configured as window_size)

I see a comment above it also saying that this is to check that the
size is good enough to accomodate another chip of same size in this
probe..

Please help me understand that why are we doing it this way .. is h/w
config like we are trying to have wrong ? why cannot I put base <
cfi.chipshiftsize in
that for loop and map both the devices .. why does the second one has
to be this way of size more or equal to first one ..

Cheers,
Alfred



From chris.elston at radstone.co.uk  Fri Apr  8 05:48:24 2005
From: chris.elston at radstone.co.uk (Chris Elston)
Date: Fri, 8 Apr 2005 10:48:24 +0100
Subject: [PATCH 2.6.12-rc2] Add flash mapping for Radstone PPC7D
Message-ID: <F38DEABE0E171746B133C1ABBD142D9703691AF4@radmail.Radstone.Local>

This patch adds MTD mapping support for the PPC7D.  Because of the potentially
large amount of SDRAM on this platform I have had to map each bank of flash
into kernel virtual address space on demand.  I've done this by providing my
own read/write/copy_from/copy_to functions which map the required bank and then
drop straight through to the standard inline versions.  This doesn't seem to
create a large performance hit, but I don't have any quantative results to back
that up.

Comments/criticisms on this technique and the rest of the patch would be much 
appreciated.

Thanks

Chris.

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppc7d_mtd_map.patch
Type: application/octet-stream
Size: 11098 bytes
Desc: ppc7d_mtd_map.patch
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050408/222930ae/attachment.obj 

From dedekind at infradead.org  Fri Apr  8 07:09:04 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 08 Apr 2005 15:09:04 +0400
Subject: [PATCH] JFFS2 race bug fix
Message-ID: <1112958544.32299.2.camel@sauron.oktetlabs.ru>

Hello,

here is the patch which fixes a JFFS2 bug related to races.

Description
~~~~~~~~~

Suppose we append something to a file.

Look at file.c:251, here JFFS2 calls jffs2_write_inode_range() which
writes new nodes.

After the node has been written, JFFS2 updates the i_size field at the
'struct inode' object (look at file.c:270) (in our example it increases
it).

Now take a glimpse a the jffs2_write_inode_range() function in
write.c:452. This function may break the peace of data to be written
into 2 smaller chunks (if there is no enough room at the current block).
After the first chunk A has been written, we free f->sem. In this point
the inode->i_size has its old value, while the real size of inode is
equivalent to the old value + the the length of node A.

Suppose we are preempted at this point and GC starts. Picks some node
belonging to our file and tries to move it, probably merge it, etc.

Garbage Collector uses the i_size value (which is, as we remember,
wrong, since it wasn't updated yet) in some places. Just do:

grep JFFS2_F_I_SIZE *
gc.c:   ri.isize = cpu_to_je32(JFFS2_F_I_SIZE(f));
gc.c:   ri.isize = cpu_to_je32(JFFS2_F_I_SIZE(f));
gc.c:           BUG_ON(end > JFFS2_F_I_SIZE(f));
gc.c:           ri.isize = cpu_to_je32(JFFS2_F_I_SIZE(f));
os-linux.h:#define JFFS2_F_I_SIZE(f) (OFNI_EDONI_2SFFJ(f)->i_size)

So, in this case it may write nodes with wrong ri.isize and have
problems later.

Personally I hit on BUG_ON(end > JFFS2_F_I_SIZE(f)) at gc:1171 when I
tested JFFS2 on an SMP host with preemption enabled.

Here is the proposed patch, please, review.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jffs2-smp-1.diff
Type: text/x-patch
Size: 2564 bytes
Desc: not available
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20050408/f5df6351/attachment.bin 

From dwmw2 at infradead.org  Fri Apr  8 07:32:57 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Apr 2005 12:32:57 +0100
Subject: [PATCH] JFFS2 race bug fix
In-Reply-To: <1112958544.32299.2.camel@sauron.oktetlabs.ru>
References: <1112958544.32299.2.camel@sauron.oktetlabs.ru>
Message-ID: <1112959978.24487.473.camel@hades.cambridge.redhat.com>

On Fri, 2005-04-08 at 15:09 +0400, Artem B. Bityuckiy wrote:
> Here is the proposed patch, please, review.

Looks correct; please commit.

-- 
dwmw2




From dan_brown at ieee.org  Fri Apr  8 11:41:40 2005
From: dan_brown at ieee.org (Dan Brown)
Date: Fri, 08 Apr 2005 11:41:40 -0400
Subject: [UPDATE] DOCBoot support for NFTL-based DOC2000
In-Reply-To: <4255AA14.80701@infocell-its.com>
References: <4249C357.2040600@ieee.org>	<424C1C58.3000905@infocell-its.com>	<424C5F16.8010809@ieee.org>	<424CA4EA.8090904@infocell-its.com>	<424CAE31.8040302@ieee.org>	<425157C5.4040007@infocell-its.com>	<425181A7.2010809@ieee.org>	<42527DD5.4080009@infocell-its.com>	<4252EC5D.4090806@ieee.org>	<4253D280.6090308@infocell-its.com>	<4253D61C.6010109@infocell-its.com>	<4253E056.5050603@ieee.org>	<4253F6C2.1080105@infocell-its.com>
	<42540E53.8080109@ieee.org> <42542926.9040209@nrl.navy.mil>
	<4255433A.4080008@ieee.org> <4255AA14.80701@infocell-its.com>
Message-ID: <4256A634.4000005@ieee.org>

Zeri Virgo wrote:

> Yes! With the diskonchip driver, flash_eraseall and nandwrite and 
> DOCBoot from CVS, my DiskOnChip now boots the Linux kernel.
>
> Thanks for everything!
>
Very glad to hear it!

    -Dan



From joern at wohnheim.fh-wedel.de  Fri Apr  8 13:01:59 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 8 Apr 2005 19:01:59 +0200
Subject: [PATCH] simplify list rotation code
Message-ID: <20050408170159.GD2292@wohnheim.fh-wedel.de>

After the other parts of my patch were vetoed against, how about this
one?

Instead of counting the list length, it simply rotates by up to 64
elements.  This is O(1) instead of O(n) and makes the code nicer to
read.

J?rn

-- 
When I am working on a problem I never think about beauty.  I think
only how to solve the problem.  But when I have finished, if the
solution is not beautiful, I know it is wrong.
-- R. Buckminster Fuller


Signed-off-by: J?rn Engel <joern at wohnheim.fh-wedel.de>
---

 fs/jffs2/scan.c |  104 +++++++-------------------------------------------------
 1 files changed, 13 insertions(+), 91 deletions(-)

--- linux-2.6.11cow/fs/jffs2/scan.c~jffs2_rotate	2005-03-22 23:29:29.000000000 +0100
+++ linux-2.6.11cow/fs/jffs2/scan.c	2005-03-25 16:23:30.000000000 +0100
@@ -809,108 +809,30 @@ static int jffs2_scan_dirent_node(struct
 	return 0;
 }
 
-static int count_list(struct list_head *l)
-{
-	uint32_t count = 0;
-	struct list_head *tmp;
 
-	list_for_each(tmp, l) {
-		count++;
-	}
-	return count;
-}
-
-/* Note: This breaks if list_empty(head). I don't care. You
-   might, if you copy this code and use it elsewhere :) */
 static void rotate_list(struct list_head *head, uint32_t count)
 {
 	struct list_head *n = head->next;
 
+	if (list_empty(head))
+		return;
+
 	list_del(head);
-	while(count--) {
+	while (count--)
 		n = n->next;
-	}
+
 	list_add(head, n);
 }
 
+
 void jffs2_rotate_lists(struct jffs2_sb_info *c)
 {
-	uint32_t x;
-	uint32_t rotateby;
-
-	x = count_list(&c->clean_list);
-	if (x) {
-		rotateby = pseudo_random % x;
-		D1(printk(KERN_DEBUG "Rotating clean_list by %d\n", rotateby));
-
-		rotate_list((&c->clean_list), rotateby);
-
-		D1(printk(KERN_DEBUG "Erase block at front of clean_list is at %08x\n",
-			  list_entry(c->clean_list.next, struct jffs2_eraseblock, list)->offset));
-	} else {
-		D1(printk(KERN_DEBUG "Not rotating empty clean_list\n"));
-	}
-
-	x = count_list(&c->very_dirty_list);
-	if (x) {
-		rotateby = pseudo_random % x;
-		D1(printk(KERN_DEBUG "Rotating very_dirty_list by %d\n", rotateby));
-
-		rotate_list((&c->very_dirty_list), rotateby);
-
-		D1(printk(KERN_DEBUG "Erase block at front of very_dirty_list is at %08x\n",
-			  list_entry(c->very_dirty_list.next, struct jffs2_eraseblock, list)->offset));
-	} else {
-		D1(printk(KERN_DEBUG "Not rotating empty very_dirty_list\n"));
-	}
-
-	x = count_list(&c->dirty_list);
-	if (x) {
-		rotateby = pseudo_random % x;
-		D1(printk(KERN_DEBUG "Rotating dirty_list by %d\n", rotateby));
-
-		rotate_list((&c->dirty_list), rotateby);
-
-		D1(printk(KERN_DEBUG "Erase block at front of dirty_list is at %08x\n",
-			  list_entry(c->dirty_list.next, struct jffs2_eraseblock, list)->offset));
-	} else {
-		D1(printk(KERN_DEBUG "Not rotating empty dirty_list\n"));
-	}
-
-	x = count_list(&c->erasable_list);
-	if (x) {
-		rotateby = pseudo_random % x;
-		D1(printk(KERN_DEBUG "Rotating erasable_list by %d\n", rotateby));
-
-		rotate_list((&c->erasable_list), rotateby);
-
-		D1(printk(KERN_DEBUG "Erase block at front of erasable_list is at %08x\n",
-			  list_entry(c->erasable_list.next, struct jffs2_eraseblock, list)->offset));
-	} else {
-		D1(printk(KERN_DEBUG "Not rotating empty erasable_list\n"));
-	}
-
-	if (c->nr_erasing_blocks) {
-		rotateby = pseudo_random % c->nr_erasing_blocks;
-		D1(printk(KERN_DEBUG "Rotating erase_pending_list by %d\n", rotateby));
-
-		rotate_list((&c->erase_pending_list), rotateby);
-
-		D1(printk(KERN_DEBUG "Erase block at front of erase_pending_list is at %08x\n",
-			  list_entry(c->erase_pending_list.next, struct jffs2_eraseblock, list)->offset));
-	} else {
-		D1(printk(KERN_DEBUG "Not rotating empty erase_pending_list\n"));
-	}
-
-	if (c->nr_free_blocks) {
-		rotateby = pseudo_random % c->nr_free_blocks;
-		D1(printk(KERN_DEBUG "Rotating free_list by %d\n", rotateby));
-
-		rotate_list((&c->free_list), rotateby);
+	uint32_t rotateby = pseudo_random % 64;
 
-		D1(printk(KERN_DEBUG "Erase block at front of free_list is at %08x\n",
-			  list_entry(c->free_list.next, struct jffs2_eraseblock, list)->offset));
-	} else {
-		D1(printk(KERN_DEBUG "Not rotating empty free_list\n"));
-	}
+	rotate_list((&c->clean_list), rotateby);
+	rotate_list((&c->very_dirty_list), rotateby);
+	rotate_list((&c->dirty_list), rotateby);
+	rotate_list((&c->erasable_list), rotateby);
+	rotate_list((&c->erase_pending_list), rotateby);
+	rotate_list((&c->free_list), rotateby);
 }



From joern at wohnheim.fh-wedel.de  Fri Apr  8 13:08:05 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 8 Apr 2005 19:08:05 +0200
Subject: [PATCH] restrict inter_module_* to its last users
Message-ID: <20050408170805.GE2292@wohnheim.fh-wedel.de>

Derived from a patch Arjan sent around.

J?rn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories

Next step for inter_module removal.  This patch makes the code
conditional on its last users and shrinks the kernel binary for the
huge majority of people.

Signed-off-by: J?rn Engel <joern at wohnheim.fh-wedel.de>
---

 drivers/mtd/Kconfig         |    4 ++++
 drivers/mtd/chips/Kconfig   |    1 +
 drivers/mtd/devices/Kconfig |    1 +
 kernel/Makefile             |    3 ++-
 4 files changed, 8 insertions(+), 1 deletion(-)

--- linux-2.6.11cow/drivers/mtd/Kconfig~inter_module	2005-03-04 11:40:19.000000000 +0100
+++ linux-2.6.11cow/drivers/mtd/Kconfig	2005-03-09 23:24:05.000000000 +0100
@@ -2,6 +2,10 @@
 
 menu "Memory Technology Devices (MTD)"
 
+# This doens't actually belong here, but mtd is the last user, so...
+config INTER_MODULE_CRAP
+	boolean
+
 config MTD
 	tristate "Memory Technology Device (MTD) support"
 	help
--- linux-2.6.11cow/drivers/mtd/chips/Kconfig~inter_module	2005-03-04 11:40:19.000000000 +0100
+++ linux-2.6.11cow/drivers/mtd/chips/Kconfig	2005-03-09 23:24:05.000000000 +0100
@@ -31,6 +31,7 @@ config MTD_JEDECPROBE
 
 config MTD_GEN_PROBE
 	tristate
+	select INTER_MODULE_CRAP
 
 config MTD_CFI_ADV_OPTIONS
 	bool "Flash chip driver advanced configuration options"
--- linux-2.6.11cow/drivers/mtd/devices/Kconfig~inter_module	2005-03-04 11:40:19.000000000 +0100
+++ linux-2.6.11cow/drivers/mtd/devices/Kconfig	2005-03-09 23:24:05.000000000 +0100
@@ -202,6 +202,7 @@ config MTD_DOC2001PLUS
 config MTD_DOCPROBE
 	tristate
 	select MTD_DOCECC
+	select INTER_MODULE_CRAP
 
 config MTD_DOCECC
 	tristate
--- linux-2.6.11cow/kernel/Makefile~inter_module	2004-12-28 17:31:37.000000000 +0100
+++ linux-2.6.11cow/kernel/Makefile	2005-03-09 23:24:05.000000000 +0100
@@ -6,9 +6,10 @@ obj-y     = sched.o fork.o exec_domain.o
 	    exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
 	    signal.o sys.o kmod.o workqueue.o pid.o \
-	    rcupdate.o intermodule.o extable.o params.o posix-timers.o \
+	    rcupdate.o extable.o params.o posix-timers.o \
 	    kthread.o wait.o kfifo.o sys_ni.o
 
+obj-$(CONFIG_INTER_MODULE_CRAP) += intermodule.o
 obj-$(CONFIG_FUTEX) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
 obj-$(CONFIG_SMP) += cpu.o spinlock.o



From arjan at infradead.org  Fri Apr  8 13:24:51 2005
From: arjan at infradead.org (Arjan van de Ven)
Date: Fri, 08 Apr 2005 19:24:51 +0200
Subject: [PATCH] restrict inter_module_* to its last users
In-Reply-To: <20050408170805.GE2292@wohnheim.fh-wedel.de>
References: <20050408170805.GE2292@wohnheim.fh-wedel.de>
Message-ID: <1112981091.6278.75.camel@laptopd505.fenrus.org>

On Fri, 2005-04-08 at 19:08 +0200, J?rn Engel wrote:
> Derived from a patch Arjan sent around.
> 

Signed-off-by: Arjan van de Ven <arjan at infradead.org>







From akpm at osdl.org  Fri Apr  8 13:48:26 2005
From: akpm at osdl.org (Andrew Morton)
Date: Fri, 8 Apr 2005 10:48:26 -0700
Subject: [PATCH] restrict inter_module_* to its last users
In-Reply-To: <20050408170805.GE2292@wohnheim.fh-wedel.de>
References: <20050408170805.GE2292@wohnheim.fh-wedel.de>
Message-ID: <20050408104826.3ca70fb4.akpm@osdl.org>

J?rn Engel <joern at wohnheim.fh-wedel.de> wrote:
>
> Next step for inter_module removal.  This patch makes the code
>  conditional on its last users and shrinks the kernel binary for the
>  huge majority of people.

If we do this, nobody will get around to fixing up the remaining users.



From arjan at infradead.org  Fri Apr  8 14:01:59 2005
From: arjan at infradead.org (Arjan van de Ven)
Date: Fri, 08 Apr 2005 20:01:59 +0200
Subject: [PATCH] restrict inter_module_* to its last users
In-Reply-To: <20050408104826.3ca70fb4.akpm@osdl.org>
References: <20050408170805.GE2292@wohnheim.fh-wedel.de>
	<20050408104826.3ca70fb4.akpm@osdl.org>
Message-ID: <1112983320.6278.80.camel@laptopd505.fenrus.org>

On Fri, 2005-04-08 at 10:48 -0700, Andrew Morton wrote:
> J?rn Engel <joern at wohnheim.fh-wedel.de> wrote:
> >
> > Next step for inter_module removal.  This patch makes the code
> >  conditional on its last users and shrinks the kernel binary for the
> >  huge majority of people.
> 
> If we do this, nobody will get around to fixing up the remaining users.

there is really only one, and how is this making it LESS likely? the
stuff remains deprecated and spews warnings, just like it is now....
just that other mortals now also don't get the kernel bloat...





From jdub at us.ibm.com  Fri Apr  8 13:53:33 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Fri, 08 Apr 2005 12:53:33 -0500
Subject: [PATCH] restrict inter_module_* to its last users
In-Reply-To: <20050408104826.3ca70fb4.akpm@osdl.org>
References: <20050408170805.GE2292@wohnheim.fh-wedel.de>
	<20050408104826.3ca70fb4.akpm@osdl.org>
Message-ID: <1112982813.7573.1.camel@windu.rchland.ibm.com>

On Fri, 2005-04-08 at 10:48 -0700, Andrew Morton wrote:
> J?rn Engel <joern at wohnheim.fh-wedel.de> wrote:
> >
> > Next step for inter_module removal.  This patch makes the code
> >  conditional on its last users and shrinks the kernel binary for the
> >  huge majority of people.
> 
> If we do this, nobody will get around to fixing up the remaining users.

Well, here's a good starting point to actually fix things:

http://www.kernel.org/pub/linux/kernel/people/rusty/Module/remove-inter-module-mtd.patch.bz2

josh




From joern at wohnheim.fh-wedel.de  Fri Apr  8 14:17:41 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 8 Apr 2005 20:17:41 +0200
Subject: [PATCH] restrict inter_module_* to its last users
In-Reply-To: <20050408104826.3ca70fb4.akpm@osdl.org>
References: <20050408170805.GE2292@wohnheim.fh-wedel.de>
	<20050408104826.3ca70fb4.akpm@osdl.org>
Message-ID: <20050408181741.GA12170@wohnheim.fh-wedel.de>

On Fri, 8 April 2005 10:48:26 -0700, Andrew Morton wrote:
> J?rn Engel <joern at wohnheim.fh-wedel.de> wrote:
> >
> > Next step for inter_module removal.  This patch makes the code
> >  conditional on its last users and shrinks the kernel binary for the
> >  huge majority of people.
> 
> If we do this, nobody will get around to fixing up the remaining users.

I would do that personally if someone explained inter_module_* to me.
Right now, I have absolutely no clue what the perceived problem was
and how inter_module_* supposedly solved that problem.

J?rn

-- 
The strong give up and move away, while the weak give up and stay.
-- unknown



From dwmw2 at infradead.org  Sat Apr  9 04:08:00 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 09 Apr 2005 09:08:00 +0100
Subject: [PATCH] restrict inter_module_* to its last users
In-Reply-To: <20050408104826.3ca70fb4.akpm@osdl.org>
References: <20050408170805.GE2292@wohnheim.fh-wedel.de>
	<20050408104826.3ca70fb4.akpm@osdl.org>
Message-ID: <1113033620.12012.28.camel@baythorne.infradead.org>

On Fri, 2005-04-08 at 10:48 -0700, Andrew Morton wrote:
> 
> > Next step for inter_module removal.  This patch makes the code
> >  conditional on its last users and shrinks the kernel binary for the
> >  huge majority of people.
> 
> If we do this, nobody will get around to fixing up the remaining
> users.

Oh, I'll fix them, and I'll be happy to see the back of the
inter_module_crap -- it went in over my objections in the first place.

But I want to deal with all the module / submodule loading crap first.
It all wants attention, and fixing up one deprecation warning alone is
just patching over the cracks.

-- 
dwmw2




From dwmw2 at infradead.org  Sat Apr  9 04:08:21 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 09 Apr 2005 09:08:21 +0100
Subject: FC3 hangs on ibook G4
In-Reply-To: <1113013385.11363.2.camel@jkeating2.hq.pogolinux.com>
References: <33462c0e0504081849492288f4@mail.gmail.com>
	<1113013385.11363.2.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1113033760.12012.30.camel@baythorne.infradead.org>

On Fri, 2005-04-08 at 19:23 -0700, Jesse Keating wrote:
> Make sure that it isn't trying to run rhgb.  Try forcing it to run level
> 3 w/out rhgb so that you can configure X by hand.  Take out 'quiet' too
> so that you can see whats going on.

And make sure you're using the initrd.

-- 
dwmw2




From dedekind at infradead.org  Sat Apr  9 05:44:28 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Sat, 09 Apr 2005 13:44:28 +0400
Subject: [PATCH]  NAND I/O instruction support
In-Reply-To: <42534BCC.3080106@setabox.com>
References: <424BFC76.8020101@setabox.com> <4252BB42.6010907@yandex.ru>
	<42534BCC.3080106@setabox.com>
Message-ID: <1113039868.18825.2.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-06 at 10:39 +0800, William J Beksi wrote:
> Because I want to use the *same* I/O port range as that used by the IDE 
> interface on a PC. I think a look at my driver below will make things 
> clearer ;)
Then this is rather hack then a standard thing. Hacks should stay in
drivers IMO.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From rpjday at mindspring.com  Sun Apr 10 17:41:22 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Sun, 10 Apr 2005 17:41:22 -0400 (EDT)
Subject: how little do i have to do to define flash layout on my system?
Message-ID: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>


  currently, my 8xx 2.4 kernel-based system defines its flash layout
with a proprietary driver file we installed into the "maps" directory,
but i'd like to simplify that approach.

  certainly, i can use command-line partitioning to define all of the
partitions, making the driver file *way* simpler.  can i somehow avoid
even the creation of that driver file (so i don't have to mess with
the kernel source tree at all)?

  i just read that there is a generic driver for accessing CFI flash
chips on systems that have no specific mapping driver.  does this mean
what i think it means?  that i can somehow take advantage of that
generic driver to avoid having to write my own?

  i need to be able to concatenate 2 16M chips into a single 32M
address space, then partition into 5 or 6 partitions.  am i being too
optimistic about not needing my own driver map program if i can use
the "generic" one?

rday



From cliff.brake at gmail.com  Mon Apr 11 06:55:01 2005
From: cliff.brake at gmail.com (Cliff Brake)
Date: Mon, 11 Apr 2005 05:55:01 -0500
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>
Message-ID: <f96d234e050411035522064e02@mail.gmail.com>

On Apr 10, 2005 4:41 PM, Robert P. J. Day <rpjday at mindspring.com> wrote:
> 
>   currently, my 8xx 2.4 kernel-based system defines its flash layout
> with a proprietary driver file we installed into the "maps" directory,
> but i'd like to simplify that approach.
> 
>   certainly, i can use command-line partitioning to define all of the
> partitions, making the driver file *way* simpler.  can i somehow avoid
> even the creation of that driver file (so i don't have to mess with
> the kernel source tree at all)?
> 
>   i just read that there is a generic driver for accessing CFI flash
> chips on systems that have no specific mapping driver.  does this mean
> what i think it means?  that i can somehow take advantage of that
> generic driver to avoid having to write my own?

I am using the MTD mechanism for defining the physical area where the
flash lives on several PXA systems:

CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x0
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=4

You can then use the kernel command line to define the partitions:

mtdparts=phys_mapped_flash:256k(boot)ro,0x1C0000(kernel),-(root)

The only tricky part was figuring out the above name
(phys_mapped_flash).  From reading the documentation, I thought I
could leave the name blank, but did not work for me.
 
>   i need to be able to concatenate 2 16M chips into a single 32M
> address space, then partition into 5 or 6 partitions.  am i being too
> optimistic about not needing my own driver map program if i can use
> the "generic" one?

I have not used the above with multiple chips.  MTD layer does have a 
CONFIG_MTD_CONCAT config parameter ...

Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com



From mikelee at avantwave.com  Mon Apr 11 07:15:36 2005
From: mikelee at avantwave.com (mike lee)
Date: Mon, 11 Apr 2005 19:15:36 +0800
Subject: porting flash
In-Reply-To: <42539BD9.9060800@hello.com>
References: <42539BD9.9060800@hello.com>
Message-ID: <425A5C58.1070502@avantwave.com>

Dear all
    I have added a line to cfi_cmdset_0002.c to solve the problem below.
Actually, i can not find any init wait queue in cmdset_0002, when i add
it back , the problem solved. I get mess because there is no problem
when i port another amdflash. Please correct me if i am wrong.
    I am using unpatched linux-2.6.10

struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
............
    for (i=0; i< cfi->numchips; i++) {
        cfi->chips[i].word_write_time = 1<<cfi->cfiq->WordWriteTimeoutTyp;
        cfi->chips[i].buffer_write_time = 1<<cfi->cfiq->BufWriteTimeoutTyp;
        cfi->chips[i].erase_time = 1<<cfi->cfiq->BlockEraseTimeoutTyp;
        init_waitqueue_head(&cfi->chips[i].wq); //line added by
mike,11/mar/2005
    }       

best regard
Mike,Lee


mike lee wrote:

>Hi all
>    I am porting mtd mapping driver to MXLADS board from motorola. It
>embedded two 16bit 8MB AMD CFI flash to interleave 32 bit bus. I have
>set the geometry function on 2-chip interleave.
>   I have no idea on this oops, Do anybody have ideas on this?
>  Thanks for helping
>
>elevator: using deadline as default io scheduler
>NOR flash:(size->0x800000 mem->0x10000000)
>NOR flash: try bankwidth 32bit, probing...
>NOR Flash: Found 2 x16 devices at 0x0 in 32-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
>NOR Flash: CFI does not contain boot bank location. Assuming top.
>number of CFI chips: 1
>cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
>RedBoot partition parsing not available
>NOR flash driver: Use static partition allocation
>Creating 5 MTD partitions on "NOR Flash 1":
>0x00000000-0x00100000 : "bootloader"
>0x00100000-0x00300000 : "kernel"
>0x00300000-0x00500000 : "System RFS"
>0x00500000-0x00700000 : "User Application"
>0x00700000-0x00800000 : "User Data"
>Bluetooth: HCI UART driver ver 2.1
>Bluetooth: HCI H4 protocol initialized
>Bluetooth: HCI BCSP protocol initialized
>NET: Registered protocol family 2
>IP: routing cache hash table of 512 buckets, 4Kbytes
>TCP: Hash tables configured (established 4096 bind 8192)
>NET: Registered protocol family 1
>Bluetooth: L2CAP ver 2.6
>Bluetooth: L2CAP socket layer initialized
>Bluetooth: RFCOMM ver 1.3
>Bluetooth: RFCOMM socket layer initialized
>Bluetooth: RFCOMM TTY layer initialized
>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>pgd = c0004000
>[00000000] *pgd=00000000
>Internal error: Oops: 5 [#1]
>Modules linked in:
>CPU: 0
>PC is at __wake_up_common+0x28/0x7c
>LR is at 0x0
>pc : [<c00318e0>]    lr : [<00000000>]    Not tainted
>sp : c035be4c  ip : c035be78  fp : c035be74
>r10: 00000003  r9 : 00000000  r8 : 00000000
>r7 : c0198494  r6 : c035a000  r5 : c027dcf4  r4 : 00000001
>r3 : 00000000  r2 : 00000001  r1 : 00000003  r0 : c027dcf4
>Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
>Control: C000717F  Table: 08004000  DAC: 0000001D
>Process mtdblockd (pid: 10, stack limit = 0xc035a190)
>Stack: (0xc035be4c to 0xc035c000)
>be40:                            c035a000 60000013 c035a000 c0198494
>c027dcd8
>be60: c027dcd8 00000000 c035be90 c035be78 c0031974 c00318c8 00000000
>00000000
>be80: c027dca0 c035beb8 c035be94 c00fe5f4 c0031944 c027dca0 00000000
>c027dca0
>bea0: c035a000 00000200 c0198494 c035bf0c c035bebc c00fe848 c00fe4cc
>00000000
>bec0: 00000000 c027dca0 00300000 00300000 00000000 00000200 c027dca0
>00000200
>bee0: 00000000 00000000 00000200 00000000 00000200 c035bf54 00000000
>c038c000
>bf00: c035bf44 c035bf10 c00f7dec c00fe614 c035bf54 c038c000 00000001
>c035bf44
>bf20: 00000200 00000000 00000200 c0363de0 c038c000 00020000 c035bf80
>c035bf48
>bf40: c00fa818 c00f7d64 c035bf54 c038c000 c0347200 00000000 00000008
>00000000
>bf60: c038c000 c0198334 c035ef60 00000000 c0349304 c035bfa4 c035bf84
>c00fabf4
>bf80: c00fa750 c035ef70 c035a000 c035ef60 c035068c c0198334 c035bff4
>c035bfa8
>bfa0: c00fae58 c00fab94 00000000 c02cd560 c00318a0 00000000 00000000
>00000000
>bfc0: c02cd560 c00318a0 00000000 00000000 00000000 00000000 00000000
>00000000
>bfe0: 00000000 00000000 00000000 c035bff8 c0037c50 c00fac88 00000000
>00000000
>Backtrace:
>[<c00318b8>] (__wake_up_common+0x0/0x7c) from [<c0031974>]
>(__wake_up+0x40/0x64)
>[<c0031934>] (__wake_up+0x0/0x64) from [<c00fe5f4>] (put_chip+0x138/0x148)
> r5 = C027DCA0  r4 = 00000000
>[<c00fe4bc>] (put_chip+0x0/0x148) from [<c00fe848>]
>(cfi_amdstd_read+0x244/0x2bc)
> r8 = C0198494  r7 = 00000200  r6 = C035A000  r5 = C027DCA0
> r4 = 00000000
>[<c00fe604>] (cfi_amdstd_read+0x0/0x2bc) from [<c00f7dec>]
>(part_read+0x98/0xcc)
>[<c00f7d54>] (part_read+0x0/0xcc) from [<c00fa818>]
>(do_cached_read+0xd8/0x10c)
>[<c00fa740>] (do_cached_read+0x0/0x10c) from [<c00fabf4>]
>(do_blktrans_request+0x70/0xf4)
>[<c00fab84>] (do_blktrans_request+0x0/0xf4) from [<c00fae58>]
>(mtd_blktrans_thread+0x1e0/0x278)
> r8 = C0198334  r7 = C035068C  r6 = C035EF60  r5 = C035A000
> r4 = C035EF70
>[<c00fac78>] (mtd_blktrans_thread+0x0/0x278) from [<c0037c50>]
>(do_exit+0x0/0x534)
>Code: e1a0a001 e1a04002 e1a08003 e59b9004 (e59e7000)
> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
>
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>  
>




From rpjday at mindspring.com  Mon Apr 11 07:32:37 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 07:32:37 -0400 (EDT)
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <f96d234e050411035522064e02@mail.gmail.com>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>
	<f96d234e050411035522064e02@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>

On Mon, 11 Apr 2005, Cliff Brake wrote:

> I am using the MTD mechanism for defining the physical area where the
> flash lives on several PXA systems:
>
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_START=0x0
> CONFIG_MTD_PHYSMAP_LEN=0x4000000
> CONFIG_MTD_PHYSMAP_BANKWIDTH=4
>
> You can then use the kernel command line to define the partitions:
>
> mtdparts=phys_mapped_flash:256k(boot)ro,0x1C0000(kernel),-(root)

that's exactly what i was looking at to see if it could do what i
want, but for more than one chip.

> The only tricky part was figuring out the above name
> (phys_mapped_flash).  From reading the documentation, I thought I
> could leave the name blank, but did not work for me.

based on what i've read, i'm pretty sure you need a non-empty mtd-id,
even if you have only one chip.  certainly, a quick glance at
cmdlinepart.c seems to suggest it has to have some value (see the
mtdpart_setup_real() routine).

> >   i need to be able to concatenate 2 16M chips into a single 32M
> > address space, then partition into 5 or 6 partitions.  am i being too
> > optimistic about not needing my own driver map program if i can use
> > the "generic" one?
>
> I have not used the above with multiple chips.  MTD layer does have a
> CONFIG_MTD_CONCAT config parameter ...

i did a bit more reading last night and concluded that the PHYSMAP
stuff would let me define a single flash chip but no more.  so if i
want multiple chips, it *appears* that i have to write a maps file.

rday



From xemc at yahoo.com  Mon Apr 11 12:47:01 2005
From: xemc at yahoo.com (Michael)
Date: Mon, 11 Apr 2005 09:47:01 -0700 (PDT)
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: 6667
Message-ID: <20050411164702.13787.qmail@web52707.mail.yahoo.com>


> i did a bit more reading last night and concluded that the
> PHYSMAP stuff would let me define a single flash chip but no
more.
> so if i want multiple chips, it *appears* that i have to write a
> maps file.
> 
> rday

Could an alternative be to extend the physmap stuff to handle
multiple chips?  If situations like yours are more common, this
solution will make it simpler for all.

Mike



From jdub at us.ibm.com  Mon Apr 11 13:01:11 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Mon, 11 Apr 2005 12:01:11 -0500
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>
	<f96d234e050411035522064e02@mail.gmail.com>
	<Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
Message-ID: <1113238871.7520.3.camel@windu.rchland.ibm.com>

On Mon, 2005-04-11 at 07:32 -0400, Robert P. J. Day wrote:
> On Mon, 11 Apr 2005, Cliff Brake wrote:
> 
> > I am using the MTD mechanism for defining the physical area where the
> > flash lives on several PXA systems:
> >
> > CONFIG_MTD_PHYSMAP=y
> > CONFIG_MTD_PHYSMAP_START=0x0
> > CONFIG_MTD_PHYSMAP_LEN=0x4000000
> > CONFIG_MTD_PHYSMAP_BANKWIDTH=4
> >
> > You can then use the kernel command line to define the partitions:
> >
> > mtdparts=phys_mapped_flash:256k(boot)ro,0x1C0000(kernel),-(root)
> 
> that's exactly what i was looking at to see if it could do what i
> want, but for more than one chip.
> 
> > The only tricky part was figuring out the above name
> > (phys_mapped_flash).  From reading the documentation, I thought I
> > could leave the name blank, but did not work for me.
> 
> based on what i've read, i'm pretty sure you need a non-empty mtd-id,
> even if you have only one chip.  certainly, a quick glance at
> cmdlinepart.c seems to suggest it has to have some value (see the
> mtdpart_setup_real() routine).
> 
> > >   i need to be able to concatenate 2 16M chips into a single 32M
> > > address space, then partition into 5 or 6 partitions.  am i being too
> > > optimistic about not needing my own driver map program if i can use
> > > the "generic" one?
> >
> > I have not used the above with multiple chips.  MTD layer does have a
> > CONFIG_MTD_CONCAT config parameter ...
> 
> i did a bit more reading last night and concluded that the PHYSMAP
> stuff would let me define a single flash chip but no more.  so if i
> want multiple chips, it *appears* that i have to write a maps file.

See drivers/mtd/maps/mphysmap.c

josh




From ralphs at netwinder.org  Mon Apr 11 13:08:02 2005
From: ralphs at netwinder.org (Ralph Siemsen)
Date: Mon, 11 Apr 2005 13:08:02 -0400
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>	<f96d234e050411035522064e02@mail.gmail.com>
	<Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
Message-ID: <425AAEF2.3040903@netwinder.org>

Robert P. J. Day wrote:

> i did a bit more reading last night and concluded that the PHYSMAP
> stuff would let me define a single flash chip but no more.  so if i
> want multiple chips, it *appears* that i have to write a maps file.

If the chips are of the same type, physmap.c will do what you want - 
just give it the total size of flash space.  Eg. if you have two 32M 
chips then give the size as 64M.  The MTD code is will probe and 
discover the two chips automatically.  Be sure you specify the 
interleave correctly too.

If the chips are of different types, then the more recent mphysmap.c is 
probably what you need.  (I haven't tried this one).

-R



From A21079 at motorola.com  Mon Apr 11 07:51:02 2005
From: A21079 at motorola.com (Jiang Jun-A21079)
Date: Mon, 11 Apr 2005 19:51:02 +0800
Subject: about summary patch
Message-ID: <3BCB5FB76AFFF646BCFBC02A889B64F302286D1C@ZCH07EXM05.corp.mot.com>

I found two issues about summary patch. But I can't send to Ferenc Havasi.
Can I post in list?



From jdub at us.ibm.com  Mon Apr 11 14:34:04 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Mon, 11 Apr 2005 13:34:04 -0500
Subject: about summary patch
In-Reply-To: <3BCB5FB76AFFF646BCFBC02A889B64F302286D1C@ZCH07EXM05.corp.mot.com>
References: <3BCB5FB76AFFF646BCFBC02A889B64F302286D1C@ZCH07EXM05.corp.mot.com>
Message-ID: <1113244444.7520.5.camel@windu.rchland.ibm.com>

On Mon, 2005-04-11 at 19:51 +0800, Jiang Jun-A21079 wrote:
> I found two issues about summary patch. But I can't send to Ferenc Havasi.
> Can I post in list?

Sure.  The summary stuff is officially in JFFS3, so it applies.

josh




From rpjday at mindspring.com  Mon Apr 11 15:08:05 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 15:08:05 -0400 (EDT)
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <20050411164702.13787.qmail@web52707.mail.yahoo.com>
References: <20050411164702.13787.qmail@web52707.mail.yahoo.com>
Message-ID: <Pine.LNX.4.61.0504111505580.26633@localhost.localdomain>

On Mon, 11 Apr 2005, Michael wrote:

>
> > i did a bit more reading last night and concluded that the
> > PHYSMAP stuff would let me define a single flash chip but no
> more.
> > so if i want multiple chips, it *appears* that i have to write a
> > maps file.
> >
> > rday
>
> Could an alternative be to extend the physmap stuff to handle
> multiple chips?  If situations like yours are more common, this
> solution will make it simpler for all.

i'd thought of that and was already looking at the code.  i think
that, as a start, it wouldn't be hard to add support for multiple,
*identical* chips, each with an arbitrary starting address.

this is what we have here.  is this scenario common enough to warrant
adding that kind of support to physmap?  i can't imagine it would be
that hard.

rday



From rpjday at mindspring.com  Mon Apr 11 15:09:59 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 15:09:59 -0400 (EDT)
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <1113238871.7520.3.camel@windu.rchland.ibm.com>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain> 
	<f96d234e050411035522064e02@mail.gmail.com>
	<Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
	<1113238871.7520.3.camel@windu.rchland.ibm.com>
Message-ID: <Pine.LNX.4.61.0504111509070.26633@localhost.localdomain>

On Mon, 11 Apr 2005, Josh Boyer wrote:

> See drivers/mtd/maps/mphysmap.c

ah, there is no such map file in my kernel source tree 2.6.11.7, so
that's obviously new.  CVS?

rday



From rpjday at mindspring.com  Mon Apr 11 15:11:42 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 15:11:42 -0400 (EDT)
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <425AAEF2.3040903@netwinder.org>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>
	<f96d234e050411035522064e02@mail.gmail.com>
	<Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
	<425AAEF2.3040903@netwinder.org>
Message-ID: <Pine.LNX.4.61.0504111510410.26633@localhost.localdomain>

On Mon, 11 Apr 2005, Ralph Siemsen wrote:

> Robert P. J. Day wrote:
>
> > i did a bit more reading last night and concluded that the PHYSMAP
> > stuff would let me define a single flash chip but no more.  so if i
> > want multiple chips, it *appears* that i have to write a maps file.
>
> If the chips are of the same type, physmap.c will do what you want - just give
> it the total size of flash space.  Eg. if you have two 32M chips then give the
> size as 64M.  The MTD code is will probe and discover the two chips
> automatically.  Be sure you specify the interleave correctly too.

and this would work regardless of the addresses of the two chips?
i'll have to look at the code more carefully.

> If the chips are of different types, then the more recent mphysmap.c
> is probably what you need.  (I haven't tried this one).

just got josh's post, i'll be looking into that shortly once i figure
out the best place to get it.

rday



From jdub at us.ibm.com  Mon Apr 11 15:15:41 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Mon, 11 Apr 2005 14:15:41 -0500
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <Pine.LNX.4.61.0504111509070.26633@localhost.localdomain>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain>
	<f96d234e050411035522064e02@mail.gmail.com>
	<Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
	<1113238871.7520.3.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.61.0504111509070.26633@localhost.localdomain>
Message-ID: <1113246941.7520.12.camel@windu.rchland.ibm.com>

On Mon, 2005-04-11 at 15:09 -0400, Robert P. J. Day wrote:
> On Mon, 11 Apr 2005, Josh Boyer wrote:
> 
> > See drivers/mtd/maps/mphysmap.c
> 
> ah, there is no such map file in my kernel source tree 2.6.11.7, so
> that's obviously new.  CVS?

Yep.  IIRC, it should be in the latest -mm too.

josh




From rpjday at mindspring.com  Mon Apr 11 15:30:38 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 15:30:38 -0400 (EDT)
Subject: how little do i have to do to define flash layout on my system?
In-Reply-To: <1113246941.7520.12.camel@windu.rchland.ibm.com>
References: <Pine.LNX.4.61.0504101735390.8617@localhost.localdomain> 
	<f96d234e050411035522064e02@mail.gmail.com>
	<Pine.LNX.4.61.0504110725540.6265@localhost.localdomain>
	<1113238871.7520.3.camel@windu.rchland.ibm.com> 
	<Pine.LNX.4.61.0504111509070.26633@localhost.localdomain>
	<1113246941.7520.12.camel@windu.rchland.ibm.com>
Message-ID: <Pine.LNX.4.61.0504111529210.26939@localhost.localdomain>

On Mon, 11 Apr 2005, Josh Boyer wrote:

> On Mon, 2005-04-11 at 15:09 -0400, Robert P. J. Day wrote:
> > On Mon, 11 Apr 2005, Josh Boyer wrote:
> >
> > > See drivers/mtd/maps/mphysmap.c
> >
> > ah, there is no such map file in my kernel source tree 2.6.11.7, so
> > that's obviously new.  CVS?
>
> Yep.  IIRC, it should be in the latest -mm too.

excellent.  so that CVS update should drop in nicely into a 2.6.11.x
source tree, i'm assuming.

and just one more clarification -- what is the current "physmap.c"
capable of in terms of multiple chips and auto-detection?  just
curious.

rday



From rpjday at mindspring.com  Mon Apr 11 16:04:35 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 16:04:35 -0400 (EDT)
Subject: why can i select both PHYSMAP and MULTI_PHYSMAP?
Message-ID: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>


  patched my 2.6.11.7 kernel tree with the latest mtd CVS to get the
mphysmap.c and i'm a bit confused.  in the

  Mapping drivers for chip access -->

menu, i can apparently select, simultaneously,

  <*> CFI Flash device in physical memory map
  <*> multiple CFI Flash devices in physical memory map

this seems contradictory, especially since i can deselect the first
while still select the second.  am i misreading what these mean?  or
is this some non-intuitive stuff to be backward-compatible?

rday



From jdub at us.ibm.com  Mon Apr 11 16:39:57 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Mon, 11 Apr 2005 15:39:57 -0500
Subject: why can i select both PHYSMAP and MULTI_PHYSMAP?
In-Reply-To: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>
References: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>
Message-ID: <1113251997.7500.5.camel@windu.rchland.ibm.com>

On Mon, 2005-04-11 at 16:04 -0400, Robert P. J. Day wrote:
>   patched my 2.6.11.7 kernel tree with the latest mtd CVS to get the
> mphysmap.c and i'm a bit confused.  in the
> 
>   Mapping drivers for chip access -->
> 
> menu, i can apparently select, simultaneously,
> 
>   <*> CFI Flash device in physical memory map
>   <*> multiple CFI Flash devices in physical memory map
> 
> this seems contradictory, especially since i can deselect the first
> while still select the second.  am i misreading what these mean?  or
> is this some non-intuitive stuff to be backward-compatible?

Joern (the author) is on vacation so I'll try to answer for him.

I don't believe mphysmap precludes the use of physmap.  They are
entirely separate drivers and should be able to be used as such.  For
example, you could map one chip with physmap, and 3 others with
mphysmap.

That isn't the typical intended usage though.  Normally you would use
mphysmap to map all of the chips on a board.  If you only had one chip,
you could still use mphysmap.  It's sort of backward-compatible that way
I suppose.

If mphysmap proves to be useful and stable (it is fairly new), then
maybe it can eventually replace physmap.  Until then, I suppose it's
safest to leave both there.

josh




From rpjday at mindspring.com  Mon Apr 11 16:48:07 2005
From: rpjday at mindspring.com (Robert P. J. Day)
Date: Mon, 11 Apr 2005 16:48:07 -0400 (EDT)
Subject: why can i select both PHYSMAP and MULTI_PHYSMAP?
In-Reply-To: <1113251997.7500.5.camel@windu.rchland.ibm.com>
References: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>
	<1113251997.7500.5.camel@windu.rchland.ibm.com>
Message-ID: <Pine.LNX.4.61.0504111645360.28836@localhost.localdomain>

On Mon, 11 Apr 2005, Josh Boyer wrote:

> On Mon, 2005-04-11 at 16:04 -0400, Robert P. J. Day wrote:
> >   patched my 2.6.11.7 kernel tree with the latest mtd CVS to get the
> > mphysmap.c and i'm a bit confused.  in the
> >
> >   Mapping drivers for chip access -->
> >
> > menu, i can apparently select, simultaneously,
> >
> >   <*> CFI Flash device in physical memory map
> >   <*> multiple CFI Flash devices in physical memory map
> >
> > this seems contradictory, especially since i can deselect the first
> > while still select the second.  am i misreading what these mean?  or
> > is this some non-intuitive stuff to be backward-compatible?
>
> Joern (the author) is on vacation so I'll try to answer for him.
>
> I don't believe mphysmap precludes the use of physmap.  They are
> entirely separate drivers and should be able to be used as such.
> For example, you could map one chip with physmap, and 3 others with
> mphysmap.
>
> That isn't the typical intended usage though.  Normally you would
> use mphysmap to map all of the chips on a board.  If you only had
> one chip, you could still use mphysmap.  It's sort of
> backward-compatible that way I suppose.

i'd guessed as much -- it just seemed redundant to be able to use both
physmap and mphysmap at the same time, and possibly even refer to the
same chip in both places.

> If mphysmap proves to be useful and stable (it is fairly new), then
> maybe it can eventually replace physmap.  Until then, I suppose it's
> safest to leave both there.

the one thing i don't see (perhaps i'm overlooking it) is the ability
to concatenate chips in menuconfig.  perhaps that's getting overly
ambitious, but maybe it's not such a big step to throw in an option
for "Concatenate all chips in their numerical order?".

just thinking out loud.

rday



From A21079 at motorola.com  Mon Apr 11 22:03:03 2005
From: A21079 at motorola.com (Jiang Jun-A21079)
Date: Tue, 12 Apr 2005 10:03:03 +0800
Subject: two issues about summary patch
Message-ID: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>

Our jffs2 is taken from MontaVista 3.1, and summary patch downloaded from website http://www.inf.u-szeged.hu/jffs2/mount.php

And we use NOR flash in our product.

First issue:

The scenario is:  write a lot of data into a newly create file in JFFS2, then suddenly power down the phone, at next time power on, during mounting of this JFFS2 filesystem, below info is printed out:

T[248]Eep. Child "download" (ino #3) of dir ino #1 doesn't exist!
T[249]Eep. Child "download_modules" (ino #19) of dir ino #1 doesn't exist! T[250]Eep. Child ".check" (ino #2) of dir ino #1 doesn't exist! 
T[250]Eep. Child "etc_files" (ino #20) of dir ino #1 doesn't exist! 
T[251]Eep. Child ".check_db" (ino #22) of dir ino #1 doesn't exist!
T[252]jffs2_do_read_inode() on nonexistent ino 22

         Function jffs2_sum_add_kvec() will be called by function jffs2_flash_direct_writev() in writev.c. It will add summary information into jeb->sum_collected before writing data into flash, But if we write data with function jffs2_flash_write(). It will bypass summary information. In our NOR flash case. Jffs2_flash_write() be defined with c->mtd->write().jffs2_flash_write() be called in gc.c and nodemgmt.c. in gc.c when we garbage collected pristine node, jffs2_flash_write() will be call without summary information handled. We will lose summary information of that pristine node at next power on. I think function jffs2_flash_write() in wbuf.c is better than c->mtd->write(). It will handle summary information through jffs2_flash_writev().
With jffs2_flash_write() in nodemgmt.c, if node has been obsolete, should we remove its summary information too?

Second issue:  
The scenario is: write a lot of data into a newly create file in JFFS2, when a eraseblock is full, then power down the phone. After system restarted we can't write anything to this partition. Any write will hang system.

        In our power failure test, a case is write data to flash until a erasebock is full, at this time last dnode has been wrote into this block, but summary information of this block has not been wrote. It would be write in next write requirement. In the function jffs2_write_inode_range, test case will stop system behind statement "jffs2_write_dnode()" if it found the space jffs2_reserve_space() reserved is less then variable datalen. 
We found jffs2 will call jffs2_do_reserve_space() before any writing action. In this function variable len is equal jeb->free_size reduce nofree_size.
But nofree_size is not on 4 bytes boundary, so the len is not on 4 bytes boundary too. 
When system restart and scanning this full block, any node scanned will call one of USED_SPACE , UNCHECKED_SPACE, DIRTY_SPACE and WASTED_SPACE

Four macro listed above will pad its parameter before handling. So, after last node be scanned and before actual space on flash remain for summary information. Jeb->free_size has been pad to 4 bytes boundary. The statement "if (jeb->sum_collected->sum_size + JFFS2_SUMMARY_FRAME_SIZE > jeb->free_size)" in function jffs2_scan_eraseblock() will be TRUE, then it clear members of ieb->sum_collected. Any write will call jffs2_sum_write_sumnode (c) in function jffs2_do_reserve_space. But members of jeb->sum_collected has been cleared. So system will hang up.
         We want to remove jeb->sum_collected check from jffs2_scan_eraseblock() or add statement "nofree_size = PAD(nofree_size)" behind statement "nofree_size = sumsize + jeb->sum_collected->sum_size + JFFS2_SUMMARY_FRAME_SIZE" in function jffs2_do_reserve_space().Macro JFFS2_SUMMARY_FRAME_SIZE need not plus 3 for 4 bytes boundary.

Best regards

kevin





From havasi at inf.u-szeged.hu  Tue Apr 12 04:59:11 2005
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Tue, 12 Apr 2005 10:59:11 +0200
Subject: two issues about summary patch
In-Reply-To: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>
References: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>
Message-ID: <425B8DDF.60807@inf.u-szeged.hu>

Hi Kevin,

Thank you very much for your feedback. We will fix these problems very 
soon and update the summary patch and JFFS3, too.

Ferenc




From steven.scholz at imc-berlin.de  Tue Apr 12 11:33:40 2005
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Tue, 12 Apr 2005 17:33:40 +0200
Subject: two issues about summary patch
In-Reply-To: <425B8DDF.60807@inf.u-szeged.hu>
References: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>
	<425B8DDF.60807@inf.u-szeged.hu>
Message-ID: <425BEA54.3020907@imc-berlin.de>

Hi Ferenc,

> Thank you very much for your feedback. We will fix these problems very 
> soon and update the summary patch and JFFS3, too.

Will you announce a new summary patch (for JFFS2) here?
Or do we have to poll your web site?

--
Steven



From havasi at inf.u-szeged.hu  Tue Apr 12 18:48:08 2005
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Wed, 13 Apr 2005 00:48:08 +0200
Subject: two issues about summary patch
In-Reply-To: <425BEA54.3020907@imc-berlin.de>
References: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>	<425B8DDF.60807@inf.u-szeged.hu>
	<425BEA54.3020907@imc-berlin.de>
Message-ID: <425C5028.30303@inf.u-szeged.hu>

Hi Steven,

> Will you announce a new summary patch (for JFFS2) here?
> Or do we have to poll your web site?

OK, we will announce new versions here.

Bye,
Ferenc




From tpoynor at mvista.com  Tue Apr 12 21:03:15 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Tue, 12 Apr 2005 18:03:15 -0700
Subject: Fixup Intel flash that powers up locked
Message-ID: <20050413010315.GA31632@slurryseal.ddns.mvista.com>

Another try at how to handle the longstanding problem of chips that lock
all blocks at power up.  This version handles it in a way that I think
is in accordance with previous suggestions: it checks for whether the
chip has this property (for Intel flash the data sheet for at least one
model implies that those with the Instant Individual Block Locking
feature bit set will also have the property of locking all blocks at
power up); and it rectifies the locks with the map write access flags at
probe time and at resume time.  It adds a chip driver callback when
partitions/devices are added, so that the driver can fix things up
according to the map info.

Any comments on whether this is or is not the way to go appreciated.


diff -ruN mtd/drivers/mtd/chips/cfi_cmdset_0001.c mtd-work/drivers/mtd/chips/cfi_cmdset_0001.c
--- mtd/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-12 17:53:29.000000000 -0700
+++ mtd-work/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-12 17:55:45.000000000 -0700
@@ -68,6 +68,7 @@
 static int cfi_intelext_suspend (struct mtd_info *);
 static void cfi_intelext_resume (struct mtd_info *);
 static int cfi_intelext_reboot (struct notifier_block *, unsigned long, void *);
+static void cfi_intelext_instantlock_add(struct mtd_info* mtd);
 
 static void cfi_intelext_destroy(struct mtd_info *);
 
@@ -390,6 +391,7 @@
 {
 	struct map_info *map = mtd->priv;
 	struct cfi_private *cfi = map->fldrv_priv;
+	struct cfi_pri_intelext *extp = cfi->cmdset_priv;
 	unsigned long offset = 0;
 	int i,j;
 	unsigned long devsize = (1<<cfi->cfiq->DevSize) * cfi->interleave;
@@ -444,6 +446,9 @@
 	mtd->get_user_prot_info = cfi_intelext_get_user_prot_info;
 #endif
 
+	if (extp && (extp->FeatureSupport & (1 << 5)))
+		mtd->notify_add = cfi_intelext_instantlock_add;
+
 	/* This function has the potential to distort the reality
 	   a bit and therefore should be called last. */
 	if (cfi_intelext_partition_fixup(mtd, &cfi) != 0)
@@ -2227,6 +2232,28 @@
 
 #endif
 
+static void cfi_intelext_unlockall(struct mtd_info *mtd)
+{
+	int i;
+
+	for (i = 0; i < mtd->numeraseregions; i++) {
+		int j;
+
+		for (j = 0; j < mtd->eraseregions[i].numblocks; j++){
+			mtd->unlock(mtd, mtd->eraseregions[i].offset +
+				    j * mtd->eraseregions[i].erasesize,
+				    mtd->eraseregions[i].erasesize);
+		}
+	}
+	
+}
+
+static void cfi_intelext_instantlock_add(struct mtd_info *mtd)
+{
+	if (mtd->flags & MTD_WRITEABLE)
+		cfi_intelext_unlockall(mtd);
+}
+
 static int cfi_intelext_suspend(struct mtd_info *mtd)
 {
 	struct map_info *map = mtd->priv;
@@ -2300,6 +2327,7 @@
 	struct cfi_private *cfi = map->fldrv_priv;
 	int i;
 	struct flchip *chip;
+	struct cfi_pri_intelext *extp = cfi->cmdset_priv;
 
 	for (i=0; i<cfi->numchips; i++) {
 	
@@ -2316,6 +2344,11 @@
 
 		spin_unlock(chip->mutex);
 	}
+
+
+	if (extp && (extp->FeatureSupport & (1 << 5)) &&
+	    (mtd->flags & MTD_WRITEABLE))
+		cfi_intelext_unlockall(mtd);	
 }
 
 static int cfi_intelext_reset(struct mtd_info *mtd)
diff -ruN mtd/drivers/mtd/mtdcore.c mtd-work/drivers/mtd/mtdcore.c
--- mtd/drivers/mtd/mtdcore.c	2005-03-28 17:36:04.000000000 -0800
+++ mtd-work/drivers/mtd/mtdcore.c	2005-04-12 17:55:45.000000000 -0700
@@ -60,6 +60,10 @@
 			mtd->usecount = 0;
 
 			DEBUG(0, "mtd: Giving out device %d to %s\n",i, mtd->name);
+
+			if (mtd->notify_add)				
+				mtd->notify_add(mtd);
+
 			/* No need to get a refcount on the module containing
 			   the notifier, since we hold the mtd_table_mutex */
 			list_for_each(this, &mtd_notifiers) {
diff -ruN mtd/drivers/mtd/mtdpart.c mtd-work/drivers/mtd/mtdpart.c
--- mtd/drivers/mtd/mtdpart.c	2005-03-28 17:36:04.000000000 -0800
+++ mtd-work/drivers/mtd/mtdpart.c	2005-04-12 17:55:45.000000000 -0700
@@ -435,6 +435,7 @@
 			slave->mtd.get_user_prot_info = part_get_user_prot_info;
 		if(master->get_fact_prot_info)
 			slave->mtd.get_fact_prot_info = part_get_fact_prot_info;
+		slave->mtd.notify_add = master->notify_add;
 		if (master->sync)
 			slave->mtd.sync = part_sync;
 		if (!i && master->suspend && master->resume) {
diff -ruN mtd/include/linux/mtd/mtd.h mtd-work/include/linux/mtd/mtd.h
--- mtd/include/linux/mtd/mtd.h	2005-04-12 17:53:37.000000000 -0700
+++ mtd-work/include/linux/mtd/mtd.h	2005-04-12 17:55:45.000000000 -0700
@@ -148,6 +148,10 @@
 	int (*block_isbad) (struct mtd_info *mtd, loff_t ofs);
 	int (*block_markbad) (struct mtd_info *mtd, loff_t ofs);
 
+	/* Device/partition add notifier */
+
+	void (*notify_add) (struct mtd_info *mtd);
+
 	struct notifier_block reboot_notifier;  /* default mode before reboot */
 
 	void *priv;



From nico at cam.org  Tue Apr 12 21:45:36 2005
From: nico at cam.org (Nicolas Pitre)
Date: Tue, 12 Apr 2005 21:45:36 -0400 (EDT)
Subject: Fixup Intel flash that powers up locked
In-Reply-To: <20050413010315.GA31632@slurryseal.ddns.mvista.com>
References: <20050413010315.GA31632@slurryseal.ddns.mvista.com>
Message-ID: <Pine.LNX.4.62.0504122118560.14514@localhost.localdomain>

On Tue, 12 Apr 2005, Todd Poynor wrote:

> Another try at how to handle the longstanding problem of chips that lock
> all blocks at power up.  This version handles it in a way that I think
> is in accordance with previous suggestions: it checks for whether the
> chip has this property (for Intel flash the data sheet for at least one
> model implies that those with the Instant Individual Block Locking
> feature bit set will also have the property of locking all blocks at
> power up); and it rectifies the locks with the map write access flags at
> probe time and at resume time.  It adds a chip driver callback when
> partitions/devices are added, so that the driver can fix things up
> according to the map info.
> 
> Any comments on whether this is or is not the way to go appreciated.

Properly dealing with this "feature" appears to be so messy that I'm 
starting to wonder if we should not just unconditionally unlock the 
flash at boot time and be done with it.

It's only the flash used for the root filesystem which is problematic 
anyway, right?  If so then I think there should be a mount option for 
JFFS* such that it directly unlocks the whole of the MTD device it's 
about to be mounted on when it's mounted read-write.  That's it.

As for the suspend case then you should probably just preserve the flash 
lock state before suspending and restore that state upon resume.

> +static void cfi_intelext_unlockall(struct mtd_info *mtd)
> +{
> +	int i;
> +
> +	for (i = 0; i < mtd->numeraseregions; i++) {
> +		int j;
> +
> +		for (j = 0; j < mtd->eraseregions[i].numblocks; j++){
> +			mtd->unlock(mtd, mtd->eraseregions[i].offset +
> +				    j * mtd->eraseregions[i].erasesize,
> +				    mtd->eraseregions[i].erasesize);
> +		}
> +	}
> +	
> +}

Why are you doing this block by block? You could as well just do:

	cfi_intelext_unlock(mtd, 0, mtd->size);

since the block walking is already performed by cfi_varsize_frob().


Nicolas



From bharat_joshi at infosys.com  Wed Apr 13 00:09:06 2005
From: bharat_joshi at infosys.com (Bharat Joshi)
Date: Wed, 13 Apr 2005 09:39:06 +0530
Subject: Triggering Garbage Collection
Message-ID: <1113365346.25515.11.camel@localhost.localdomain>

Hi All,

   With JFFS2, to avoid a deadlock, we must have at least
2 or more erase blocks available when garbage collection
thread is triggered.

   Just wanted to know if there is any algorithm which can
be used to trigger Garbage Collection and do it with only
one erase block kept for garbage collection.

   This was mentioned as one of the improvements in JFFS2
pdf document. So are we looking at it in JFFS3?

Thanks & Regards,
Bharat
-- 
Bharat Joshi <bharat_joshi at infosys.com>
Infosys Technologies Ltd
www.infosys.com



From dedekind at infradead.org  Wed Apr 13 04:08:27 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 13 Apr 2005 12:08:27 +0400
Subject: Triggering Garbage Collection
In-Reply-To: <1113365346.25515.11.camel@localhost.localdomain>
References: <1113365346.25515.11.camel@localhost.localdomain>
Message-ID: <1113379707.5889.1.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-13 at 09:39 +0530, Bharat Joshi wrote:
>    Just wanted to know if there is any algorithm which can
> be used to trigger Garbage Collection and do it with only
> one erase block kept for garbage collection.
I have no Idea.

>    This was mentioned as one of the improvements in JFFS2
> pdf document. So are we looking at it in JFFS3?
I'd be happy to see some analysis of this. Please, share it if you have
one.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From infolottonl at mails.de  Wed Apr 13 02:32:06 2005
From: infolottonl at mails.de (de lotto netherlands)
Date: Wed, 13 Apr 2005 08:32:06 +0200
Subject: Email Lottery Draw 2005 results
Message-ID: <9940bfdb3548f3dbb93e8342ad673068d6d165ad@mails.de>

Email Lottery Draw 2005 results

FROM: GOVERNMENT ACCREDITED LICENSED LOTTERY
PROMOTERS. WINNING NOTICE FOR CATEGORY \"B\" WINNER

Dear Lucky Winner,

RE:BONUS LOTTERY PROMOTION PRIZE AWARDS WINNING NOTIFICATION

We are pleased to inform you of the result of the just concluded annual finaldraws of De Lotto Netherlands International Lottery programs.

The online cyber lotto draws was conducted from an exclusive list of 100,000 e-mail addresses of individual and corporate bodies picked by an advanced automated random computer search from the internet from various continents of the world.No tickets were sold.

After this automated computer ballot,your e-mail address emerged as one of two winners in the category \"B\" with the following:

Ref Number: 35149/337-5247/LNI
Batch Number: 26371545-LNI/2005
Ticket Number: 54866235

You as well as the other winners are therefore to receive a cash prize of ?:500,000.00.(FIVE HUNDRED THOUSAND EUROS) each from the total payout of ?1,500,000.00 Euro in category "B".

Your prize award has been insured with your e-mail address and will be transferred to you upon meeting our requirements, statutory obligations, verifications, validations and satisfactory report.

To begin the claims processing of your prize winnings you are advised to contact our licensed and accredited claims agent for category \"B\" winners with theinformation below:

Mr. Hans Gutman
Financial Director,
Netherlands Development Finance Company,
1104 kE Poort Bijlmerplein
Amsterdam,Netherlands.
E-mail:hansgutman2 at yahoo.co.uk
Tel: 31-617-582-414
Fax: 31-205-248-664

NOTE: All winnings must be claimed not later than 30 days.After this date allunclaimed funds would be included in the next stake. Remember to quote your reference information in all correspondence.
You are to keep all lotto information away from the general public especiallyyour reference and ticket numbers.(This is important as a case of double claims will not be entertained).

Anybody under the age of 18 and members of the affiliate agencies are automatically not allowed to participate in this program.

Thank you and congratulations!!!

Yours faithfully,

Mrs. Mildred Hugo

Games/Lottery Coordinator.
De Lotto Netherlands International





From havasi at inf.u-szeged.hu  Wed Apr 13 08:47:16 2005
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Wed, 13 Apr 2005 14:47:16 +0200
Subject: two issues about summary patch
In-Reply-To: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>
References: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>
Message-ID: <425D14D4.6080408@inf.u-szeged.hu>

Hi Kevin,

We've investigated you issues about summary patch.

The second one (wrong padding) is OK, you was right, we've fixed it, the 
new patch will be released soon.

But we have some questions according the first issue:

>         Function jffs2_sum_add_kvec() will be called by function jffs2_flash_direct_writev() in writev.c. It will add summary information into jeb->sum_collected before writing data into flash, But if we write data with function jffs2_flash_write(). It will bypass summary information. In our NOR flash case. Jffs2_flash_write() be defined with c->mtd->write().jffs2_flash_write() be called in gc.c and nodemgmt.c. in gc.c when we garbage collected pristine node, jffs2_flash_write() will be call without summary information handled. We will lose summary information of that pristine node at next power on. I think function jffs2_flash_write() in wbuf.c is better than c->mtd->write(). It will handle summary information through jffs2_flash_writev().
>With jffs2_flash_write() in nodemgmt.c, if node has been obsolete, should we remove its summary information too?
>  
>
Are you sure that you used the latest version of summary patch? It was a 
problem before 20050117, but now it should work.

If summary is enabled jffs2_can_mark_obsolete(c) is set to false (in 
os-linux.h). Becauseof it the node will not be obsolated by setting the 
node accurate bit, so we don't need to delete its summary information.

If summary support is enabled jffs2_flash_write() will be not called by 
anyone. In jffs2_mark_node_obsolate() it will return before calling 
jffs2_flash_write() because jffs2_can_mark_obsolete(c) is set to false:

        if (!jffs2_can_mark_obsolete(c) || jffs2_is_readonly(c) ||
                (c->flags & JFFS2_SB_FLAG_BUILDING)) {
                /* We didn't lock the erase_free_sem */
                return;
        }

In gc.c the patches after 20050117 replace jffs2_flash_write() to 
jffs2_flash_writev().

Regards,
Ferenc




From sergei.sharonov at halliburton.com  Wed Apr 13 09:25:38 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Wed, 13 Apr 2005 13:25:38 +0000 (UTC)
Subject: mounting jffs2
Message-ID: <loom.20050413T142519-107@post.gmane.org>

Hi,

It looks like there is a long delay before filesystem becomes available 
after mount returns. Test setup: jffs2 on 256 MByte NAND chip, 2.6.10 linux
with recent mtd snapshot. Filesystem contains one 200 MByte file written 
and fsynced in 1 kByte chunks. Checking ps it appears that gcd was the only 
thing running (RWN).
Mount and touch were run immediately one after another. I think it may be
related to the long umount time problem that I reported before. At least
the symptoms are similar: something is still going on after mount completes.
Note negligible user and sys times during touch.

# time mount /mnt/flash/

real    1m33.538s
user    0m0.020s
sys     1m33.421s
# time touch /mnt/flash/junk

real    11m10.058s
user    0m0.010s
sys     0m0.010s
#

Sergei Sharonov




From dedekind at infradead.org  Wed Apr 13 09:50:25 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 13 Apr 2005 17:50:25 +0400
Subject: mounting jffs2
In-Reply-To: <loom.20050413T142519-107@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
Message-ID: <1113400225.23175.9.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-13 at 13:25 +0000, Sergei Sharonov wrote: 
> Hi,
> 
> It looks like there is a long delay before filesystem becomes available 
> after mount returns. Test setup: jffs2 on 256 MByte NAND chip, 2.6.10 linux
> with recent mtd snapshot. Filesystem contains one 200 MByte file written 
> and fsynced in 1 kByte chunks.
Believe me, if you'll write in 4K chunks, you'll effect much better
JFFS2 performance. 

> Checking ps it appears that gcd was the only 
> thing running (RWN).
It isn't bug, it is a feature. To facilitate faster mount JFFS2 defers a
lot of work to the GC thread and performs this work just after mount.
You may read filesystem but can't write. Any writer will be blocked - in
your case on 11m10.058s time interval.

> Mount and touch were run immediately one after another. I think it may be
> related to the long umount time problem that I reported before.
Measure the time of unmount just after mount. If if is also around
11m10.058s - this is a bug. Theoretically GC thread must forget its
deferred work and quit immediately.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From sergei.sharonov at halliburton.com  Wed Apr 13 10:22:15 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Wed, 13 Apr 2005 14:22:15 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
Message-ID: <loom.20050413T160136-559@post.gmane.org>

Hi,

> Believe me, if you'll write in 4K chunks, you'll effect much better
> JFFS2 performance. 

I will try that. My log data is comming in 1 kB chunks, so in order to do
4 kB at a time I will have to implement some sort of <power fail safe>
buffering.

> It isn't bug, it is a feature. To facilitate faster mount JFFS2 defers a
> lot of work to the GC thread and performs this work just after mount.
> You may read filesystem but can't write. Any writer will be blocked - in
> your case on 11m10.058s time interval.

Hmm.. ls is not a writer but it is blocked as well.
 
> > Mount and touch were run immediately one after another. I think it may be
> > related to the long umount time problem that I reported before.
> Measure the time of unmount just after mount. If if is also around
> 11m10.058s - this is a bug. Theoretically GC thread must forget its
> deferred work and quit immediately.

Doesn't seem to be the case. Continuing the previous test:

# time mount /mnt/flash/

real    1m33.527s
user    0m0.010s
sys     1m33.471s
# time touch /mnt/flash/junk

real    11m26.228s
user    0m0.010s
sys     0m0.000s
#
#   <------------- previous post ends here ----------
#
# time umount /mnt/flash/

real    0m0.255s
user    0m0.010s
sys     0m0.240s
# time mount /mnt/flash/

real    1m33.517s
user    0m0.010s
sys     1m33.431s
# time umount /mnt/flash/

real    11m25.534s
user    0m0.000s
sys     0m0.250s
#








From dedekind at infradead.org  Wed Apr 13 11:02:36 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 13 Apr 2005 19:02:36 +0400
Subject: mounting jffs2
In-Reply-To: <loom.20050413T160136-559@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
Message-ID: <1113404557.23175.23.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-13 at 14:22 +0000, Sergei Sharonov wrote:
> I will try that. My log data is comming in 1 kB chunks, so in order to do
> 4 kB at a time I will have to implement some sort of <power fail safe>
> buffering.
It isn't obligatory to write by 4K. But if you write *intensively*, it
will be very helpful. Otherwise, just stay with 1K. And of course, the
best way to try both variants. You may try 4k without the "power fail"
things and decide whether it helps or not.

> Hmm.. ls is not a writer but it is blocked as well.
It may be blocked but for shorter time (checking one ore few inodes, not
all). Do you have very big files or directories with a lot of L1
children ?

> # time umount /mnt/flash/
> 
> real    11m25.534s
> user    0m0.000s
> sys     0m0.250s
Well, this is bad. I may suggest where to dig:

on unmount jffs2_stop_garbage_collect_thread() is called, sends SIGKILL
to the GC thread and waits for it. Meanwhile, GC thread revolves around
at jffs2_garbage_collect_pass() calling jffs2_do_crccheck_inode() for
all inodes. Theoretically it returns after it checks an inode and
processes signals (background.c:115).

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From dedekind at infradead.org  Wed Apr 13 11:18:21 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 13 Apr 2005 19:18:21 +0400
Subject: mounting jffs2
In-Reply-To: <loom.20050413T160136-559@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
Message-ID: <1113405501.23175.27.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-13 at 14:22 +0000, Sergei Sharonov wrote:
> # time umount /mnt/flash/
> 
> real    11m25.534s
> user    0m0.000s
> sys     0m0.250s
Try to change 

D1(printk(KERN_DEBUG "jffs2_garbage_collect_thread(): SIGKILL
received.\n"));

to

printk(KERN_DEBUG "jffs2_garbage_collect_thread(): SIGKILL
received.\n");

at background.c:116 and see whether GC thread receives SIGKILL on
unmount and when it receives it (just after or on 11 min).

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From nickolay at protei.ru  Wed Apr 13 11:33:51 2005
From: nickolay at protei.ru (Nickolay)
Date: Wed, 13 Apr 2005 19:33:51 +0400
Subject: K9F1G08U0M NAND support
Message-ID: <425D3BDF.9030505@protei.ru>

Hallo Guys!

I has IXDP425 board with K9F1G08U0M NAND flash as secondary flash(first 
flash - NOR for booting).
Kernel version: 2.4.20_mvl31

I get mtd from CVS and just replace originally 
linux-2.4.20_mvl31/drivers/mtd with mtd/drivers/mtd.
But when does make menuconfig, i can't select CONFIG_PPCHAMELEONEVB, 
because in drivers/mtd/nand/Config.in this code:

if [ "$CONFIG_PPCHAMELEONEVB" = "y" ]; then
    dep_tristate '  NAND Flash device on PPChameleonEVB board' 
CONFIG_MTD_NAND_PPCHAMELEONEVB $CONFIG_MTD_NAND
fi

But i build kernel for IXDP425, not for PPCHAMELEONEVB.
What i should does, for configure support for K9F1G08U0M NAND flash?




From dedekind at infradead.org  Wed Apr 13 11:50:50 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 13 Apr 2005 19:50:50 +0400
Subject: K9F1G08U0M NAND support
In-Reply-To: <425D3BDF.9030505@protei.ru>
References: <425D3BDF.9030505@protei.ru>
Message-ID: <1113407451.23175.32.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-13 at 19:33 +0400, Nickolay wrote:
> Hallo Guys!
> 
> I has IXDP425 board with K9F1G08U0M NAND flash as secondary flash(first 
> flash - NOR for booting).
> Kernel version: 2.4.20_mvl31
> 
> I get mtd from CVS and just replace originally 
> linux-2.4.20_mvl31/drivers/mtd with mtd/drivers/mtd.
That's wrong. Please, read http://www.linux-
mtd.infradead.org/source.html 

And please, pay your attention at the "Kernel versions" section there.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From sergei.sharonov at halliburton.com  Wed Apr 13 13:51:01 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Wed, 13 Apr 2005 17:51:01 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
	<1113404557.23175.23.camel@sauron.oktetlabs.ru>
Message-ID: <loom.20050413T193912-984@post.gmane.org>

Hi,
> > Hmm.. ls is not a writer but it is blocked as well.
> It may be blocked but for shorter time (checking one ore few inodes, not
> all). Do you have very big files or directories with a lot of L1
> children ?

Nope. Just three files: one is 200 MBytes, two others are small. 

# time mount /mnt/flash/

real    1m33.528s
user    0m0.010s
sys     1m33.421s
# time ls /mnt/flash/
blockno1  junk      test1

real    20m54.573s
user    0m0.010s
sys     9m32.519s
#

This is not usable for embedded application. Have I run into a bug or that
is just how things are with jffs2 on big NANDs? Is that a problem with
a 200 MByte file? 

Sergei Sharonov





From jeanwelly at gmail.com  Wed Apr 13 23:57:01 2005
From: jeanwelly at gmail.com (zheng wei)
Date: Thu, 14 Apr 2005 11:57:01 +0800
Subject: How can I use NAND Flash AMDk9f1208
Message-ID: <c2bc1f405041320572082b9c8@mail.gmail.com>

I want to use K9F1208 in kernel 2.6.11 for s3c2410, 
What should I do? Thanks.

-- 
---------
jeanwelly
Email:  jeanwelly at gmail.com
China



From pranss at gmail.com  Thu Apr 14 02:30:43 2005
From: pranss at gmail.com (Franz de Rama)
Date: Thu, 14 Apr 2005 14:30:43 +0800
Subject: flash_eraseall error
Message-ID: <d59cd780050413233072eafaef@mail.gmail.com>

Hi all,

I am trying to move my DoC Millennium Plus 32mb file system from ext2
to jffs2. but when I issued the command '# flash_eraseall -j
/dev/mtd0', i get the following error message:

./flash_eraseall: /dev/mtd0: unable to get NAND oobinfo

====

This is my 'cat /proc/mtd' result:

dev:    size   erasesize  name
mtd0: 02000000 00008000 "DiskOnChip Millennium Plus"

Any ideas where i went wrong? 

Thanks in advance

-franz-



From dedekind at infradead.org  Thu Apr 14 04:41:58 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 14 Apr 2005 09:41:58 +0100 (BST)
Subject: mounting jffs2
In-Reply-To: <loom.20050413T193912-984@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
	<1113404557.23175.23.camel@sauron.oktetlabs.ru>
	<loom.20050413T193912-984@post.gmane.org>
Message-ID: <Pine.LNX.4.58.0504140941040.3328@phoenix.infradead.org>

> Nope. Just three files: one is 200 MBytes, two others are small.

That's all I need to know. JFFS2 was originally developed to work with
small NOR flashes. After NAND support was added it became possible to
utilize it on top of NAND, but with large flashes it is not very usable.
200 MB file is very large for JFFS2. It eats a lot of RAM when
you open the file and iget() is very slow with it (iget() happens when
you open the file, stat it, ls -l, etc).

This is why I started designing JFFS3, though I do this in background and 
don't really spend a lot of time (sponsors are needed :-)). Take a glimpse 
at the evolving document at 
http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf, especially at the 
"JFFS2 analysis chapter", which is far not complete though. This will help 
you to realize why it is difficult to use JFFS2 on large flashes, 
especially if you have a 200 MB file :-)

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From havasi at inf.u-szeged.hu  Thu Apr 14 05:01:40 2005
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Thu, 14 Apr 2005 11:01:40 +0200
Subject: mounting jffs2
In-Reply-To: <loom.20050413T142519-107@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
Message-ID: <425E3174.4030308@inf.u-szeged.hu>

Hi Sergei,

>It looks like there is a long delay before filesystem becomes available 
>after mount returns. Test setup: jffs2 on 256 MByte NAND chip, 2.6.10 linux
>  
>
Just an idea: you may try out our summary patch. ( 
http://www.inf.u-szeged.hu/jffs2/mount.php )

It makes the mount time faster and there is an experimental option, 
where you can disable the check the CRC of nodes which have good 
summary. (most of the nodes will have it, if you use it correctly)

Regards,
Ferenc




From steven.scholz at imc-berlin.de  Thu Apr 14 05:15:21 2005
From: steven.scholz at imc-berlin.de (Steven Scholz)
Date: Thu, 14 Apr 2005 11:15:21 +0200
Subject: SUMMARY for JFFS2?
In-Reply-To: <4226FBCB.5020007@inf.u-szeged.hu>
References: <42232855.3020408@imc-berlin.de> <4226FBCB.5020007@inf.u-szeged.hu>
Message-ID: <425E34A9.1090103@imc-berlin.de>

Ferenc Havasi wrote:

> Steven Scholz wrote:
> 
>> IIUC then the SUMMARY stuff goes into JFFS3.
>> But are there any plans to officially include it into the JFFS2 code?
>>
>> It's quite cumbersome to update MTD CVS and then merge the patch 
>> http://www.inf.u-szeged.hu/jffs2/jffs2-summary-20050211.patch by hand.
>>
>> Since its a compile time option is there anything speaking against 
>> such inclusion?
> 
> 
> If David (dwmw2) says yes, we are ready to commit. Due to Steven's and 
> some other people testing I think now it is stable.

David?
Are you going to say yes?
Or will summary for JFFS2 stay a seperate patch forever?

-- 
Steven



From dedekind at infradead.org  Thu Apr 14 05:15:33 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 14 Apr 2005 10:15:33 +0100 (BST)
Subject: mounting jffs2
In-Reply-To: <425E3174.4030308@inf.u-szeged.hu>
References: <loom.20050413T142519-107@post.gmane.org>
	<425E3174.4030308@inf.u-szeged.hu>
Message-ID: <Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>

> Just an idea: you may try out our summary patch. (
> http://www.inf.u-szeged.hu/jffs2/mount.php )
Yes, summary will help greatly with mount time, but unfortunately it 
doesn't help with memory consumption and iget() (in Sergey's case the time 
of the background checking is the same).

> It makes the mount time faster and there is an experimental option,
> where you can disable the check the CRC of nodes which have good
> summary. (most of the nodes will have it, if you use it correctly)
Albeit I used to claim it is a good attribute not to check CRCs for
blocks with summaries, now I believe it is wrong and dangerous and must 
not be used in JFFS2.

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From havasi at inf.u-szeged.hu  Thu Apr 14 05:21:51 2005
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Thu, 14 Apr 2005 11:21:51 +0200
Subject: two issues about summary patch
In-Reply-To: <425BEA54.3020907@imc-berlin.de>
References: <3BCB5FB76AFFF646BCFBC02A889B64F3022870CA@ZCH07EXM05.corp.mot.com>	<425B8DDF.60807@inf.u-szeged.hu>
	<425BEA54.3020907@imc-berlin.de>
Message-ID: <425E362F.3050907@inf.u-szeged.hu>

Dear All,

> Will you announce a new summary patch (for JFFS2) here?
> Or do we have to poll your web site?

The new summary patch version is released. JFFS3 is also updated. There 
is only a small fix related to Kevin's second issue (PAD-ing).

Bye,
Ferenc



From m.mikolaiczyk at rac.de  Thu Apr 14 05:29:35 2005
From: m.mikolaiczyk at rac.de (Marcus Mikolaiczyk)
Date: Thu, 14 Apr 2005 11:29:35 +0200
Subject: Nand Flash not found.
Message-ID: <425E37FF.5040703@rac.de>

Dear list users,

I've adapted a hardware driver for our board, and compiled the new
kernel successfully. But it doesn't find the NAND Flash. When loading
the module I get:
insmod ./btutc1130.o
./btutc1130.o: init_module: No such device or address
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters

in /var/log/messages:
Jan  1 19:25:15 10 daemon.warn klogd: No NAND device found!!!

Is there any possibility to test the 'connection' to the NAND or how can
I check/debug the problem. I think that the HW functions are not
properly configured, any idea how this can be checked.

Thanks in advance

Marcus




From wjbeksi at setabox.com  Thu Apr 14 06:11:36 2005
From: wjbeksi at setabox.com (William J Beksi)
Date: Thu, 14 Apr 2005 18:11:36 +0800
Subject: Nand Flash not found.
In-Reply-To: <425E37FF.5040703@rac.de>
References: <425E37FF.5040703@rac.de>
Message-ID: <425E41D8.5070408@setabox.com>

Hi Marcus,

Marcus Mikolaiczyk wrote:
> Dear list users,
> 
> I've adapted a hardware driver for our board, and compiled the new
> kernel successfully. But it doesn't find the NAND Flash. When loading
> the module I get:
> insmod ./btutc1130.o
> ./btutc1130.o: init_module: No such device or address
> Hint: insmod errors can be caused by incorrect module parameters,
> including invalid IO or IRQ parameters
> 
> in /var/log/messages:
> Jan  1 19:25:15 10 daemon.warn klogd: No NAND device found!!!
> 
> Is there any possibility to test the 'connection' to the NAND or how can
> I check/debug the problem. I think that the HW functions are not
> properly configured, any idea how this can be checked.

I often have this problem if I don't have a good physical connection 
between the flash device and it's socket, so recheck your connection. 
Can you post your hardware function?

-- 
William J Beksi                          <wjbeksi at users.sourceforge.net>
GPG Key Fingerprint = ED4B 32C3 69E6 C2B7 705C  263F CB2F 3253 E7E1 DB3B



From m.mikolaiczyk at rac.de  Thu Apr 14 06:27:02 2005
From: m.mikolaiczyk at rac.de (Marcus Mikolaiczyk)
Date: Thu, 14 Apr 2005 12:27:02 +0200
Subject: Nand Flash not found.
In-Reply-To: <425E41D8.5070408@setabox.com>
References: <425E37FF.5040703@rac.de> <425E41D8.5070408@setabox.com>
Message-ID: <425E4576.7030603@rac.de>

Hi William,

the connection should be ok, the hardware guys tested it - I hope so.
They use a simple test appl. which I cannot use under Linux.

the hardware function (discussion "NAND connected with address lines
based example" on this list around 31.03.2005):
...
static int BTU_NAND_BASE = 0xAE000000;
static int BTU_NAND_VIRT_BASE ;
static int BTU_NAND_RB = 0xF0000C00;
static int BTU_NAND_RB_RDY = (1<<5);
/*
 * Define partitions for flash devices
 */
extern struct nand_oobinfo jffs2_oobinfo;
#define NUM_PARTITIONS256M 1
static struct mtd_partition partition_info256M[] = {
        { name: "BTU NAND flash partition 1",
          offset:  0,
          size:    SZ_256M },
};

/*
 *      hardware specific access to control-lines via address bus
 */
static void btutc1130_hwcontrol(struct mtd_info *mtd, int cmd)
{
        struct nand_chip *this = (struct nand_chip *) mtd->priv;
        switch(cmd){
                //Command Latch Enable Settings
                case NAND_CTL_SETCLE: this->IO_ADDR_W = BTU_NAND_BASE +
1; break;
                case NAND_CTL_CLRCLE: this->IO_ADDR_W = BTU_NAND_BASE;
break;
                //Address Latch Enable Settings
                case NAND_CTL_SETALE: this->IO_ADDR_W = BTU_NAND_BASE +
2; break;
                case NAND_CTL_CLRALE: this->IO_ADDR_W = BTU_NAND_BASE;
break;
        }
}

/*
 *      read device ready pin
 */
int btutc1130_device_ready(struct mtd_info *mtd)
{
        // Gibt 0 zurueck, wenn P0.4_IN 0 ist ansonsten 1
        return ( (*(volatile unsigned char *) (BTU_NAND_RB + 0x14)) &
BTU_NAND_RB_RDY) ? 1 : 0;
}
....
....

I've got a seperate CS which is connect to the nand an too this CS the
address range 0xAE000000 is 'connected'.

I'm looking for to write a small c-appl which does some inital tests on
this.

Marcus




From A21079 at motorola.com  Thu Apr 14 06:47:28 2005
From: A21079 at motorola.com (Jiang Jun-A21079)
Date: Thu, 14 Apr 2005 18:47:28 +0800
Subject: compile error
Message-ID: <3BCB5FB76AFFF646BCFBC02A889B64F302435044@ZCH07EXM05.corp.mot.com>

Compile information:
erase.c: In function `jffs2_mark_erased_block':
erase.c:336: error: structure has no member named `wbuf'
erase.c:339: error: structure has no member named `oobinfo'

JFFS2 is a snapshot of 20050413
I compile for NOR flash and WRITEBUFFER not defined.



From sergei.sharonov at halliburton.com  Thu Apr 14 08:39:53 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Thu, 14 Apr 2005 12:39:53 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
	<1113404557.23175.23.camel@sauron.oktetlabs.ru>
	<loom.20050413T193912-984@post.gmane.org>
	<Pine.LNX.4.58.0504140941040.3328@phoenix.infradead.org>
Message-ID: <loom.20050414T140640-566@post.gmane.org>

Hi,

thanks, Artem.

> > Nope. Just three files: one is 200 MBytes, two others are small.
> 
> That's all I need to know. JFFS2 was originally developed to work with
> small NOR flashes. After NAND support was added it became possible to
> utilize it on top of NAND, but with large flashes it is not very usable.
> 200 MB file is very large for JFFS2. It eats a lot of RAM when
> you open the file and iget() is very slow with it (iget() happens when
> you open the file, stat it, ls -l, etc).

That's what I was afraid of. Looks like JFFS2 is not very usable on large
NAND chips. Will the situation improve if the 200 MByte file
is split into, say, multiple 20 MByte files? I guess not..

Other possibilities that I would like to investigate:

1. Partition NAND into two blocks. One will be small and will buffer incomming
data while the second big partition is being mounted. Problem: if power
cycles just before the readout the user will have to wait 20+ minutes before 
he can get to data. Argh..

2. Try YAFFS. Can anybody offer an opinion ;) ? 
JFFS2 is well supported, every resonable question or problem is followed 
up within hours. What about YAFFS? I also have a feeling that jffs2 has had 
a bit more testing and larger user base. How mature is YAFFS?

3. Try summary patch. How stable is it with jffs2? Is anybody using it
in production or is it still pretty much experimental? I recall that
initially summary was not created/updated dynamically, e.g. it was not 
usefull for log data. Is it still the case?

4. Combine (1) with (3). (1) will give fast write access, (3) hopefuly will
give fast read access????

5. Look for a commercial solution. I recall somebody was talking at 
Embedded Conference about porting their filesystem to linux.

> This is why I started designing JFFS3, though I do this in background and 
> don't really spend a lot of time (sponsors are needed ). Take a glimpse 
> at the evolving document at 
> http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf, especially at the 
> "JFFS2 analysis chapter", which is far not complete though. This will help 
> you to realize why it is difficult to use JFFS2 on large flashes, 
> especially if you have a 200 MB file 

What's the point in having a big NAND if you cannot fill it ;) ?

Best regards,

Sergei Sharonov





From dedekind at infradead.org  Thu Apr 14 09:11:10 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 14 Apr 2005 14:11:10 +0100 (BST)
Subject: mounting jffs2
In-Reply-To: <loom.20050414T140640-566@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
	<1113404557.23175.23.camel@sauron.oktetlabs.ru>
	<loom.20050413T193912-984@post.gmane.org>
	<Pine.LNX.4.58.0504140941040.3328@phoenix.infradead.org>
	<loom.20050414T140640-566@post.gmane.org>
Message-ID: <Pine.LNX.4.58.0504141409200.3328@phoenix.infradead.org>

Sergei Sharonov wrote:
> Hi,
Hello :-)

> That's what I was afraid of. Looks like JFFS2 is not very usable on 
large
> NAND chips. Will the situation improve if the 200 MByte file
> is split into, say, multiple 20 MByte files? I guess not..
Yes, it is an option. Some thing will be much better. If you formulate 
specific questions, I may try do get concrete answers.

> Other possibilities that I would like to investigate:
> 1. Partition NAND into two blocks.
We usually call flash sector "block", so I am confused what do you mean. 
Just split your flash on 2 partitions?

> 2. Try YAFFS. Can anybody offer an opinion ;) ? 
> JFFS2 is well supported, every resonable question or problem is followed 
> up within hours. What about YAFFS? I also have a feeling that jffs2 has 
had 
> a bit more testing and larger user base. How mature is YAFFS?
I have no Idea. And I'd like to know this too :-)

> 3. Try summary patch. How stable is it with jffs2? Is anybody using it
> in production or is it still pretty much experimental?
AFAIK, it is quite good.

> I recall that
> initially summary was not created/updated dynamically, e.g. it was not 
> usefull for log data. Is it still the case?
No, it isn't.

> 4. Combine (1) with (3). (1) will give fast write access, (3) hopefuly 
will
> give fast read access????
You'll end up with quick mount, but the "touch your_200mb_file" command 
(just after mount) should be still be slow. touch your_20mb_file will be 
~10 times faster.

> 5. Look for a commercial solution. I recall somebody was talking at 
> Embedded Conference about porting their filesystem to linux.
May be. The other case is just to start developing JFFS3. We have some 
ideas.

> What's the point in having a big NAND if you cannot fill it ;) ?
JFFS2 wasn't designed for such large flashes/files. It has scalability 
problems. And you can fill it if you're ready to spend a lot of RAM/time.


--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From sergei.sharonov at halliburton.com  Thu Apr 14 10:15:36 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Thu, 14 Apr 2005 14:15:36 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
	<loom.20050413T160136-559@post.gmane.org>
	<1113404557.23175.23.camel@sauron.oktetlabs.ru>
	<loom.20050413T193912-984@post.gmane.org>
	<Pine.LNX.4.58.0504140941040.3328@phoenix.infradead.org>
	<loom.20050414T140640-566@post.gmane.org>
	<Pine.LNX.4.58.0504141409200.3328@phoenix.infradead.org>
Message-ID: <loom.20050414T151238-645@post.gmane.org>

Hi,

> > Other possibilities that I would like to investigate:
> > 1. Partition NAND into two blocks.
> We usually call flash sector "block", so I am confused what do you mean. 
> Just split your flash on 2 partitions?

Sorry, I meant two partitions. (blocks is sense of /dev/mtdblock ;)

> > 2. Try YAFFS. Can anybody offer an opinion ;) ? 
...
> I have no Idea. And I'd like to know this too 

It looks like I would need YAFFS2 in order to handle 2 kB pages. And it is
pretty new. Also the traffic is definitely lower on yaffs list.

> > 3. Try summary patch. How stable is it with jffs2? Is anybody using it
> > in production or is it still pretty much experimental?
> AFAIK, it is quite good.

That is good to know. Thanks.

> > 4. Combine (1) with (3). (1) will give fast write access, (3) hopefuly 
> will
> > give fast read access????
> You'll end up with quick mount, but the "touch your_200mb_file" command 
> (just after mount) should be still be slow. touch your_20mb_file will be 
> ~10 times faster.

I'll run a test with 10x20 MByte files and post results.

> > 5. Look for a commercial solution. I recall somebody was talking at 
> > Embedded Conference about porting their filesystem to linux.
> May be. The other case is just to start developing JFFS3. We have some 
> ideas.

What would be a time frame for a stable JFFS3 solution assuming there is a 
support?
 
> > What's the point in having a big NAND if you cannot fill it ;) ?
> JFFS2 wasn't designed for such large flashes/files. It has scalability 
> problems. And you can fill it if you're ready to spend a lot of RAM/time.

Got 32 MB, can probably go to 64 MB. Will that be sufficient to support 
256 MB NAND assuming 1 kB writes? BTW, does it make sense to increase write 
size above 1 page (2 kB). I understood from previous discussions that jffs2 
will split it on a page boundary anyway?

Sergei Sharonov





From dedekind at yandex.ru  Thu Apr 14 11:18:03 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Thu, 14 Apr 2005 19:18:03 +0400
Subject: mounting jffs2
In-Reply-To: <loom.20050414T151238-645@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>	<1113400225.23175.9.camel@sauron.oktetlabs.ru>	<loom.20050413T160136-559@post.gmane.org>	<1113404557.23175.23.camel@sauron.oktetlabs.ru>	<loom.20050413T193912-984@post.gmane.org>	<Pine.LNX.4.58.0504140941040.3328@phoenix.infradead.org>	<loom.20050414T140640-566@post.gmane.org>	<Pine.LNX.4.58.0504141409200.3328@phoenix.infradead.org>
	<loom.20050414T151238-645@post.gmane.org>
Message-ID: <425E89AB.9030307@yandex.ru>

Sergei Sharonov wrote:
> Sorry, I meant two partitions. (blocks is sense of /dev/mtdblock ;)
It's hard to answer, I don't know your task and requirements.

> I'll run a test with 10x20 MByte files and post results.
It would be nice. If you provide mount time speeds with depending on how 
many data is placed on flash, it would be nice. I then add these numbers 
to the JFFS3 document for reference (the brief description of your 
system would be useful as well).

> What would be a time frame for a stable JFFS3 solution assuming there is a 
> support?
Design is even not ready yet. But I'd say it could take 4-6 months
depending on requirements, fetures to implement, people involved, etc.

> Got 32 MB, can probably go to 64 MB. Will that be sufficient to support 
> 256 MB NAND assuming 1 kB writes? BTW, does it make sense to increase write 
> size above 1 page (2 kB). I understood from previous discussions that jffs2 
> will split it on a page boundary anyway?
No. JFFS (even not JFFS2, but the Linux Page Cache) split on *RAM* page 
boundary which is PAGE_SIZE bytes big and is, as a rule, 4KiB. And 4KiB 
is a JFFS2's lovely size :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From killekulla at rdrz.de  Thu Apr 14 12:54:09 2005
From: killekulla at rdrz.de (Raphael Zimmerer)
Date: Thu, 14 Apr 2005 18:54:09 +0200
Subject: flash_eraseall error
In-Reply-To: <d59cd780050413233072eafaef@mail.gmail.com>
References: <d59cd780050413233072eafaef@mail.gmail.com>
Message-ID: <20050414165409.GG19001@rdrz.de>

On Thu, Apr 14, 2005 at 02:30:43PM +0800, Franz de Rama wrote:
> I am trying to move my DoC Millennium Plus 32mb file system from ext2
> to jffs2. but when I issued the command '# flash_eraseall -j

[...]

> Any ideas where i went wrong? 

What Kernel and mtd-version are you using?

A DOC Millennium Plus 32MB driver for the current nand subsystem is
in development.

- Raphael



From sergei.sharonov at halliburton.com  Thu Apr 14 16:39:14 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Thu, 14 Apr 2005 20:39:14 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<1113400225.23175.9.camel@sauron.oktetlabs.ru>
Message-ID: <loom.20050414T222445-494@post.gmane.org>

Hi

> Believe me, if you'll write in 4K chunks, you'll effect much better
> JFFS2 performance. 

200 MByte file written on a 256 MByte NAND in 4096 byte chunks instead of 1024.
It is somewhat better (?) but still unusable. Mount time is still at 1m31s, 
but any operation after that including ls or touch are 10-14 minutes and
have inconsistent real time, sys is ~6m25s.
BTW, does it make difference if I run test on pristine, freshly
erased flash or after I created and deleted a few large files?

# time mount /mnt/flash/

real    1m31.304s
user    0m0.020s
sys     1m31.199s
# time touch /mnt/flash/test1

real    14m23.449s
user    0m0.010s
sys     6m24.856s
# umount /mnt/flash/
# time mount /mnt/flash/

real    1m31.306s
user    0m0.010s
sys     1m31.219s
# time touch /mnt/flash/test1

real    10m48.944s
user    0m0.000s
sys     6m25.156s
#
# umount /mnt/flash/
# time mount /mnt/flash/

real    1m31.300s
user    0m0.010s
sys     1m31.239s
# time touch /mnt/flash/test1

real    14m30.499s
user    0m0.000s
sys     6m24.746s
#

I will try next 10 x 20 MByte files but am afraid there is no
quick fix here.

Sergei Sharonov





From joern at wohnheim.fh-wedel.de  Fri Apr 15 01:27:53 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 15 Apr 2005 07:27:53 +0200
Subject: about summary patch
In-Reply-To: <3BCB5FB76AFFF646BCFBC02A889B64F302286D1C@ZCH07EXM05.corp.mot.com>
References: <3BCB5FB76AFFF646BCFBC02A889B64F302286D1C@ZCH07EXM05.corp.mot.com>
Message-ID: <20050415052753.GA32689@wohnheim.fh-wedel.de>

On Mon, 11 April 2005 19:51:02 +0800, Jiang Jun-A21079 wrote:
> 
> I found two issues about summary patch. But I can't send to Ferenc Havasi.
> Can I post in list?

Please do.

J?rn

-- 
The wise man seeks everything in himself; the ignorant man tries to get
everything from somebody else.
-- unknown



From joern at wohnheim.fh-wedel.de  Fri Apr 15 01:35:44 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Fri, 15 Apr 2005 07:35:44 +0200
Subject: why can i select both PHYSMAP and MULTI_PHYSMAP?
In-Reply-To: <Pine.LNX.4.61.0504111645360.28836@localhost.localdomain>
References: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>
	<1113251997.7500.5.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.61.0504111645360.28836@localhost.localdomain>
Message-ID: <20050415053544.GB32689@wohnheim.fh-wedel.de>

On Mon, 11 April 2005 16:48:07 -0400, Robert P. J. Day wrote:
> On Mon, 11 Apr 2005, Josh Boyer wrote:
> >
> > Joern (the author) is on vacation so I'll try to answer for him.

Well, they do have internet cafes in Sydney. ;)

> > If mphysmap proves to be useful and stable (it is fairly new), then
> > maybe it can eventually replace physmap.  Until then, I suppose it's
> > safest to leave both there.

Yup.

> the one thing i don't see (perhaps i'm overlooking it) is the ability
> to concatenate chips in menuconfig.  perhaps that's getting overly
> ambitious, but maybe it's not such a big step to throw in an option
> for "Concatenate all chips in their numerical order?".

If someone actually needs it, such a change wouldn't be hard to do.
Right now, mphysmap needs real users (aka a test base).  Once I
receive some success reports, things can get merged to Linus and
further functionality could be added.

Writing software you don't personally need or use is a strange
business indeed.

J?rn

-- 
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca



From dwmw2 at infradead.org  Fri Apr 15 04:15:51 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 15 Apr 2005 09:15:51 +0100
Subject: why can i select both PHYSMAP and MULTI_PHYSMAP?
In-Reply-To: <20050415053544.GB32689@wohnheim.fh-wedel.de>
References: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>
	<1113251997.7500.5.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.61.0504111645360.28836@localhost.localdomain>
	<20050415053544.GB32689@wohnheim.fh-wedel.de>
Message-ID: <1113552951.12012.260.camel@baythorne.infradead.org>

On Fri, 2005-04-15 at 07:35 +0200, J?rn Engel wrote:
> Once I receive some success reports, things can get merged to Linus
> and further functionality could be added.

I think we need to finish writing a source control system before
anything can be merged to Linus :)

-- 
dwmw2





From pstudencki at yahoo.com  Fri Apr 15 05:10:25 2005
From: pstudencki at yahoo.com (Pawel Studencki)
Date: Fri, 15 Apr 2005 02:10:25 -0700 (PDT)
Subject: Can not mount root on mtd block
Message-ID: <20050415091026.33613.qmail@web51302.mail.yahoo.com>

hello Mike, 

I read your e-mails about problems with mounting ramfs
as root filesystem
and I wonder if you found a solution.
I'm trying the same thing with kernel 2.6.11 on ppc
processor. I've already
checked following:
- boot options: root=/dev/mtdblock1 ro
- debugging to/from do_mount_root function...
and slowly I'm loosing ideas...In my case function
path_lookup (in do_mount)
returns with error  -ENOENT, because there were no
inode found for "root".
It looks similar to your problem...

So if you have any hints, I will enjoy to check them
and perhaps together we
can solve this annoying problem  :) 

best regards
Pawel


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 



From jeanwelly at gmail.com  Sat Apr 16 02:39:39 2005
From: jeanwelly at gmail.com (zheng wei)
Date: Sat, 16 Apr 2005 14:39:39 +0800
Subject: How to revise MTD in 2.6.11 for yaffs
Message-ID: <c2bc1f405041523397b9354c5@mail.gmail.com>

Hi, all
    I want to use yaffs on 2.6.11. The cpu is s3c2410 and the nand
flash k9f1208.
I am not sure about what work should be done to revise the mtd for yaffs.
Additionally, I want to use yaffs as a root filesystem.

Any suggestion is welcome.

Thanks!


-- 
---------
jeanwelly
Email:  jeanwelly at gmail.com
China



From ch at murgatroid.com  Sun Apr 17 00:41:58 2005
From: ch at murgatroid.com (Christopher Hoover)
Date: Sat, 16 Apr 2005 21:41:58 -0700
Subject: Fixup Intel flash that powers up locked
In-Reply-To: <Pine.LNX.4.62.0504122118560.14514@localhost.localdomain>
Message-ID: <20050417044201.51DE1A001C7@mail.murgatroid.com>


>> Any comments on whether this is or is not the way to go appreciated.

>Properly dealing with this "feature" appears to be so messy that I'm
starting
>to wonder if we should not just unconditionally unlock the flash at boot
time
>and be done with it.

I put forward such code over two years ago.  I can dig it up again.

-ch




From carlliao at 21cn.com  Sun Apr 17 05:58:10 2005
From: carlliao at 21cn.com (carl liao)
Date: Sun, 17 Apr 2005 17:58:10 +0800
Subject: How to back port linux-mtd to 2.4.26
Message-ID: <pe949582819896.12950@send5.inner-21cn.com>

Hi, ALL! 

linux-mtd website says that ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd-snapshot-20050304.tar.bz2 will apparently works with 2.4.27 or above kernel. But the tar ball is not available on the ftp site now. It has mtd-snapshot-20020731.tar.bz2 and mtd-snapshot-20050401.tar.bz2 and so on. 

Where could I get something like mtd-snapshot-2004xxxx.tar.bz2?

I found 2.6.11 kernel use a linux-mtd version might as "$Id: mtdcore.c,v 1.44 2004/11/16 18:28:59 dwmw2 Exp $". Could someone tell me how to get a suitable linux-mtd version for 2.4.26 kernel then?

Thanks a lot!!

Carl Liao





From dedekind at yandex.ru  Sun Apr 17 06:08:16 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Sun, 17 Apr 2005 14:08:16 +0400
Subject: How to back port linux-mtd to 2.4.26
In-Reply-To: <pe949582819896.12950@send5.inner-21cn.com>
References: <pe949582819896.12950@send5.inner-21cn.com>
Message-ID: <42623590.1020202@yandex.ru>

> Where could I get something like mtd-snapshot-2004xxxx.tar.bz2?
Just download any version from CVS.
>
> I found 2.6.11 kernel use a linux-mtd version might
Try the lates. People say still works with, but I'm not sure.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dedekind at yandex.ru  Sun Apr 17 06:21:50 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Sun, 17 Apr 2005 14:21:50 +0400
Subject: How to back port linux-mtd to 2.4.26
In-Reply-To: <42623590.1020202@yandex.ru>
References: <pe949582819896.12950@send5.inner-21cn.com>
	<42623590.1020202@yandex.ru>
Message-ID: <426238BE.1060906@yandex.ru>



Artem B. Bityuckiy wrote:
  > Try the lates. People say still works with, but I'm not sure.
Well, writing 3 letters simultaneously results in such a strange
phrases. I'll make another attempt:
Try the latest. People say it still works with 2.4.x, x > 20, but I'm 
not sure.


-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From carlliao at 21cn.com  Sun Apr 17 06:29:12 2005
From: carlliao at 21cn.com (carl liao)
Date: Sun, 17 Apr 2005 18:29:12 +0800
Subject: How to back port linux-mtd to 2.4.26
Message-ID: <CA949582816789.15512@send4.inner-21cn.com>

I found 2.6.10 kernel also use something like "$Id: mtdcore.c,v 1.44 2004/11/16 18:28:59 dwmw2 Exp $".
Maybe this release is stable as it is accepted by the official kernel. Do you think so?





From jeanwelly at gmail.com  Sun Apr 17 06:56:05 2005
From: jeanwelly at gmail.com (zheng wei)
Date: Sun, 17 Apr 2005 18:56:05 +0800
Subject: ECC error on 2.6.11
Message-ID: <c2bc1f405041703564e08b32e@mail.gmail.com>

I added the Nand flash partitions in arch/arm/mach-s3c2410/devs.c.
Added 
.dev = { 
.platform_data = &s3c_nand_info 
} 
to s3c_device_nand.
Then, add &s3c_device_nand in __initdata in
arch/arm/mach-s3c2410/mach-smdk2410.c
Recompile the kernel, boot the kernel. The ECC can't not work correctly.

Thanks.





NOW, Booting Linux......
Uncompressing Linux.............................................................
............. done, booting the kernel.
Linux version 2.6.11 (root at localhost.localdomain) (gcc version 3.4.1) #12 Sun Ap
r 17 17:20:07 CST 2005
CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T)
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Machine: SMDK2410
ATAG_INITRD is deprecated; please update your bootloader.
Memory policy: ECC disabled, Data cache writeback
CPU S3C2410 (id 0x32410000)
S3C2410: core 200.000 MHz, memory 100.000 MHz, peripheral 50.000 MHz
S3C2410 Clock control, (c) 2004 Simtec Electronics
Built 1 zonelists
Kernel command line: noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0
irq: clearing pending ext status 00000300
irq: clearing subpending status 00000003
irq: clearing subpending status 00000002
PID hash table entries: 512 (order: 9, 8192 bytes)
timer tcon=00000000, tcnt a2c1, tcfg 00000200,00000000, usec 00001eb8
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 64MB = 64MB total
Memory: 62464KB available (1771K code, 503K data, 92K init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
S3C2410: Initialising architecture
S3C2410 DMA Driver, (c) 2003-2004 Simtec Electronics
DMA channel 0 at c4800000, irq 33
DMA channel 1 at c4800040, irq 34
DMA channel 2 at c4800080, irq 35
DMA channel 3 at c48000c0, irq 36
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
Real Time Clock Driver v1.12
S3C2410 RTC, (c) 2004 Simtec Electronics
S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2410
s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2410
s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2410
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
nbd: registered device at major 43
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
S3C2410 NAND Driver, (c) 2004 Simtec Electronics
s3c2410-nand: mapped registers at c4a00000
s3c2410-nand: timing: Tacls 10ns, Twrph0 40ns, Twrph1 10ns
NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit
)
Scanning device for bad blocks
Creating 5 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00020000 : "vivi"
mtd: Giving out device 0 to vivi
0x00020000-0x00030000 : "param"
mtd: Giving out device 1 to param
0x00030000-0x001f0000 : "kernel"
mtd: Giving out device 2 to kernel
0x00200000-0x00400000 : "root"
mtd: Giving out device 3 to root
0x00400000-0x04000000 : "user"
mtd: Giving out device 4 to user
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
NET: Registered protocol family 1
nand_read_ecc: Failed ECC read, page 0x00001002
nand_read_ecc: Failed ECC read, page 0x00001002
end_request: I/O error, dev mtdblock3, sector 2
EXT2-fs: unable to read superblock
nand_read_ecc: Failed ECC read, page 0x00001000
end_request: I/O error, dev mtdblock3, sector 0
FAT: unable to read boot sector
VFS: Cannot open root device "mtdblock3" or unknown-block(31,3)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)


-- 
---------
jeanwelly
Email:  jeanwelly at gmail.com
China



From joern at wohnheim.fh-wedel.de  Sun Apr 17 20:38:55 2005
From: joern at wohnheim.fh-wedel.de (=?iso-8859-1?Q?J=F6rn?= Engel)
Date: Mon, 18 Apr 2005 02:38:55 +0200
Subject: why can i select both PHYSMAP and MULTI_PHYSMAP?
In-Reply-To: <1113552951.12012.260.camel@baythorne.infradead.org>
References: <Pine.LNX.4.61.0504111600540.28647@localhost.localdomain>
	<1113251997.7500.5.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.61.0504111645360.28836@localhost.localdomain>
	<20050415053544.GB32689@wohnheim.fh-wedel.de>
	<1113552951.12012.260.camel@baythorne.infradead.org>
Message-ID: <20050418003855.GA896@wohnheim.fh-wedel.de>

On Fri, 15 April 2005 09:15:51 +0100, David Woodhouse wrote:
> On Fri, 2005-04-15 at 07:35 +0200, J?rn Engel wrote:
> > Once I receive some success reports, things can get merged to Linus
> > and further functionality could be added.
> 
> I think we need to finish writing a source control system before
> anything can be merged to Linus :)

You really expect that to take longer than receiving a success report?
;)

J?rn

-- 
A victorious army first wins and then seeks battle.
-- Sun Tzu



From dedekind at infradead.org  Mon Apr 18 04:47:11 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 18 Apr 2005 12:47:11 +0400
Subject: [PATC] small VFS change for JFFS2
Message-ID: <1113814031.31595.3.camel@sauron.oktetlabs.ru>

Hello,

tracing out an JFFS2's SMP/PREEMPT bug I've realized that I need to make
a small change in VFS in order to fix the bug gracefully.

I refer to the fs/inode.c file from the 2.6.11.5 Linux kernel.

JFFS2 supports its own accounting of inodes by means of small 'struct
jffs2_inode_cache' objects. There is a field 'state' in these objects
which indicates whether the inode is built (i.e. it is in the Linux
inode cache at the moment) or not built (i.e., it isn't in the Linux
inode cache). This is needed to facilitate fast Garbage Collection,
which is the crucial part of the Flash File System.

JFFS2 assumes that the above mentioned 'state' field is always coherent
with the real state of the inode. The state is changed on read_inode()
and clear_inode() inode operation calls.

But there is a problem with this. When kswapd prunes the Linux inode
cache, there is an interval where clear_inode() was not yet called but
the inode is already removed from the inode hash (inode->i_hash). I mean
the following piece of code at fs/inode.c:467

        inodes_stat.nr_unused -= nr_pruned;
        spin_unlock(&inode_lock);
				// <-- Here
        dispose_list(&freeable); 
        up(&iprune_sem);

This is not a bug - VFS handles things by means of I_FREEING state. But,
for JFFS2 this means, that it may assume that the inode is built, while
it actually isn't (if, say, we are preempted at the above marked point
and the JFFS2 GC starts and picks a node belonging an inode being
pruned). This leads to nasty things in JFFS2.

One obvious thing to fix this JFFS2 problem is to acquire the iprune_sem
semaphore in JFFS2 GC, but for this we need to export it. So, please,
consider the following VFS patch (against Linux 2.6.11.5):

-------------------------------------------------------
diff -auNrp linux-2.6.11.5/fs/inode.c linux-2.6.11.5_vfs_fix/fs/inode.c
--- linux-2.6.11.5/fs/inode.c   2005-03-19 09:35:04.000000000 +0300
+++ linux-2.6.11.5_vfs_fix/fs/inode.c   2005-04-18 12:09:43.000000000
+0400
@@ -92,6 +92,8 @@ DEFINE_SPINLOCK(inode_lock);
  */
 DECLARE_MUTEX(iprune_sem);

+EXPORT_SYMBOL(iprune_sem);
+
 /*
  * Statistics gathering..
  */
-------------------------------------------------------

P.S. Probably we may fix this without VFS changes (albeit I'm not sure),
but it will be more difficult and much uglier.

The following is the correspondent patch for JFFS2 (against MTD CVS
Head):

-------------------------------------------------------
diff -auNrp --exclude=CVS mtd-pristine/fs/jffs2/gc.c mtd/fs/jffs2/gc.c
--- mtd-pristine/fs/jffs2/gc.c  2005-04-11 13:13:29.000000000 +0400
+++ mtd/fs/jffs2/gc.c   2005-04-18 12:20:40.390920376 +0400
@@ -126,15 +126,17 @@ int jffs2_garbage_collect_pass(struct jf
        struct jffs2_eraseblock *jeb;
        struct jffs2_raw_node_ref *raw;
        int ret = 0, inum, nlink;
+       int iprune_sem_up = 0;

        if (down_interruptible(&c->alloc_sem))
                return -EINTR;

        for (;;) {
-               spin_lock(&c->erase_completion_lock);
                if (!c->unchecked_size)
                        break;

+               spin_lock(&c->erase_completion_lock);
+
                /* We can't start doing GC yet. We haven't finished
checking
                   the node CRCs etc. Do it now. */

@@ -206,6 +208,17 @@ int jffs2_garbage_collect_pass(struct jf
                return ret;
        }

+       /*
+        * To be sure the ic->state's value stays consistent, we need to
+        * forbid kswapd to prune our inode. Otherwise, we may end up
+        * with the situation where the ic->state = INO_STATE_PRESENT
+        * while it isn't actually in the inode cache (since it was just
+        * pruned by kswapd, but clear_inode() wasn't yet called).
+        */
+       down(&iprune_sem);
+
+       spin_lock(&c->erase_completion_lock);
+
        /* First, work out which block we're garbage-collecting */
        jeb = c->gcblock;

@@ -215,6 +228,7 @@ int jffs2_garbage_collect_pass(struct jf
        if (!jeb) {
                D1 (printk(KERN_NOTICE "jffs2: Couldn't find erase block
to garbage collect!\n"));
                spin_unlock(&c->erase_completion_lock);
+               up(&iprune_sem);
                up(&c->alloc_sem);
                return -EIO;
        }
@@ -224,6 +238,7 @@ int jffs2_garbage_collect_pass(struct jf
           printk(KERN_DEBUG "Nextblock at  %08x, used_size %08x,
dirty_size %08x, wasted_size %08x, free_size %08x\n", c->n
extblock->offset, c->nextblock->used_size, c->nextblock->dirty_size, c-
>nextblock->wasted_size, c->nextblock->free_size));

        if (!jeb->used_size) {
+               up(&iprune_sem);
                up(&c->alloc_sem);
                goto eraseit;
        }
@@ -239,6 +254,7 @@ int jffs2_garbage_collect_pass(struct jf
                               jeb->offset, jeb->free_size, jeb-
>dirty_size, jeb->used_size);
                        jeb->gc_node = raw;
                        spin_unlock(&c->erase_completion_lock);
+                       up(&iprune_sem);
                        up(&c->alloc_sem);
                        BUG();
                }
@@ -253,6 +269,7 @@ int jffs2_garbage_collect_pass(struct jf
                   we don't grok that has JFFS2_NODETYPE_RWCOMPAT_COPY,
we should do so */
                spin_unlock(&c->erase_completion_lock);
                jffs2_mark_node_obsolete(c, raw);
+               up(&iprune_sem);
                up(&c->alloc_sem);
                goto eraseit_lock;
      @@ -283,6 +300,8 @@ int jffs2_garbage_collect_pass(struct jf
                   We can just copy any pristine nodes, but have
                   to prevent anyone else from doing read_inode() while
                   we're at it, so we set the state accordingly */
+               iprune_sem_up += 1;
+               up(&iprune_sem);
                if (ref_flags(raw) == REF_PRISTINE)
                        ic->state = INO_STATE_GC;
                else {
@@ -305,6 +324,7 @@ int jffs2_garbage_collect_pass(struct jf
                */
                printk(KERN_CRIT "Inode #%u already in state %d in
jffs2_garbage_collect_pass()!\n",
                       ic->ino, ic->state);
+               up(&iprune_sem);
                up(&c->alloc_sem);
                spin_unlock(&c->inocache_lock);
                BUG();
@@ -316,6 +336,7 @@ int jffs2_garbage_collect_pass(struct jf
                   the alloc_sem() (for marking nodes invalid) so we
must
                   drop the alloc_sem before sleeping. */

+               up(&iprune_sem);
                up(&c->alloc_sem);
                D1(printk(KERN_DEBUG "jffs2_garbage_collect_pass()
waiting for ino #%u in state %d\n",
                          ic->ino, ic->state));
@@ -367,6 +388,8 @@ int jffs2_garbage_collect_pass(struct jf
        spin_unlock(&c->inocache_lock);

        f = jffs2_gc_fetch_inode(c, inum, nlink);
+       if (!iprune_sem_up)
+               up(&iprune_sem);
        if (IS_ERR(f)) {
                ret = PTR_ERR(f);
                goto release_sem;
  }
-------------------------------------------------------

Comments?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From hch at infradead.org  Mon Apr 18 04:51:21 2005
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 18 Apr 2005 09:51:21 +0100
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
Message-ID: <20050418085121.GA19091@infradead.org>

On Mon, Apr 18, 2005 at 12:47:11PM +0400, Artem B. Bityuckiy wrote:
> JFFS2 assumes that the above mentioned 'state' field is always coherent
> with the real state of the inode. The state is changed on read_inode()
> and clear_inode() inode operation calls.
 
> One obvious thing to fix this JFFS2 problem is to acquire the iprune_sem
> semaphore in JFFS2 GC, but for this we need to export it. So, please,
> consider the following VFS patch (against Linux 2.6.11.5):

No, exporting locks is a really bad idea.  Please try to find a better
method to fix your problem that doesn't export random kernel symbols.




From dedekind at infradead.org  Mon Apr 18 04:58:50 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 18 Apr 2005 12:58:50 +0400
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <20050418085121.GA19091@infradead.org>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
Message-ID: <1113814730.31595.6.camel@sauron.oktetlabs.ru>

On Mon, 2005-04-18 at 09:51 +0100, Christoph Hellwig wrote:
> No, exporting locks is a really bad idea.  Please try to find a better
> method to fix your problem that doesn't export random kernel symbols.
> 
In general it must be true. But this specific case I believe is
reasonable enough to export the mutext (as an exception).

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From hch at infradead.org  Mon Apr 18 06:53:01 2005
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 18 Apr 2005 11:53:01 +0100
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <1113814730.31595.6.camel@sauron.oktetlabs.ru>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
Message-ID: <20050418105301.GA21878@infradead.org>

On Mon, Apr 18, 2005 at 12:58:50PM +0400, Artem B. Bityuckiy wrote:
> On Mon, 2005-04-18 at 09:51 +0100, Christoph Hellwig wrote:
> > No, exporting locks is a really bad idea.  Please try to find a better
> > method to fix your problem that doesn't export random kernel symbols.
> > 
> In general it must be true. But this specific case I believe is
> reasonable enough to export the mutext (as an exception).

Umm, no.  It's absolutely not a good reason.  What jffs2 is doing right
now is to poke into VFS internals it shouldn't, and exporting more internals
to prevent it from doing so isn't making the situation any better.

The VFS already has a method for freeing an struct inode pointer, and that
is ->destroy_inode.  You're probably better off updating your GC state from
that place.




From dedekind at infradead.org  Mon Apr 18 07:46:21 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 18 Apr 2005 15:46:21 +0400
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <20050418105301.GA21878@infradead.org>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
Message-ID: <1113824781.2125.12.camel@sauron.oktetlabs.ru>

On Mon, 2005-04-18 at 11:53 +0100, Christoph Hellwig wrote: 
> The VFS already has a method for freeing an struct inode pointer, and that
> is ->destroy_inode.  You're probably better off updating your GC state from
> that place.
destroy_inode() does not help. JFFS2 already makes use of clear_inode()
which is in fact called even earlier (inode.c from 2.6.11.5, line 298):

static void dispose_list(struct list_head *head)
{
        int nr_disposed = 0;

        while (!list_empty(head)) {
                struct inode *inode;

                inode = list_entry(head->next, struct inode, i_list);
                list_del(&inode->i_list);

                if (inode->i_data.nrpages)
                        truncate_inode_pages(&inode->i_data, 0);
                clear_inode(inode); /* <--------- here --------- */
                destroy_inode(inode);
                nr_disposed++;
        }
        spin_lock(&inode_lock);
        inodes_stat.nr_inodes -= nr_disposed;
        spin_unlock(&inode_lock);
}

I'll repeat my problem, please look tat the code and read my comments in
it (inode.c:443):

static void prune_icache(int nr_to_scan)
{
        LIST_HEAD(freeable);
        int nr_pruned = 0;
        int nr_scanned;
        unsigned long reap = 0;

        down(&iprune_sem);
        spin_lock(&inode_lock);
        for (nr_scanned = 0; nr_scanned < nr_to_scan; nr_scanned++) {
                struct inode *inode;

                if (list_empty(&inode_unused))
                        break;

                inode = list_entry(inode_unused.prev, struct inode,
i_list);

                if (inode->i_state || atomic_read(&inode->i_count)) {
                        list_move(&inode->i_list, &inode_unused);
                        continue;
                }
                if (inode_has_buffers(inode) || inode->i_data.nrpages) {
                        __iget(inode);
                        spin_unlock(&inode_lock);
                        if (remove_inode_buffers(inode))
                                reap += invalidate_inode_pages(&inode-
>i_data);
                        iput(inode);
                        spin_lock(&inode_lock);

                        if (inode != list_entry(inode_unused.next,
                                                struct inode, i_list))
                                continue;       /* wrong inode or
list_empty */
                        if (!can_unuse(inode))
                                continue;
                }
                hlist_del_init(&inode->i_hash);
                list_move(&inode->i_list, &freeable);

/* we have removed inode from the inode hash and from this moment
   forth it is not in the inode cache */

                inode->i_state |= I_FREEING;
                nr_pruned++;
        }
        inodes_stat.nr_unused -= nr_pruned;
        spin_unlock(&inode_lock);

/* we unlocked the spinlock an may be, say, preempted here.
   now inodes are not in the inode cache, but
   clear_inode()/destroy_inode() hasn't been called yet.
  JFFS2 thinks the inode in the inode cache and makes wrong things */

        dispose_list(&freeable);
        up(&iprune_sem);

        if (current_is_kswapd())
                mod_page_state(kswapd_inodesteal, reap);
        else
                mod_page_state(pginodesteal, reap);
}

> Umm, no.  It's absolutely not a good reason.  What jffs2 is doing right
> now is to poke into VFS internals it shouldn't, and exporting more internals
> to prevent it from doing so isn't making the situation any better.

I fully agree with you that we ought to be very picky about exports.
But this mutex is special case - it protects from races with the "external"
kswapd. I suspect I'm not the last person who will ask
to export it. If you or David suggest a workaround, you're welcome. 

Cheers,
Artem.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From hch at infradead.org  Mon Apr 18 07:52:20 2005
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 18 Apr 2005 12:52:20 +0100
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <1113824781.2125.12.camel@sauron.oktetlabs.ru>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
Message-ID: <20050418115220.GA22750@infradead.org>

On Mon, Apr 18, 2005 at 03:46:21PM +0400, Artem B. Bityuckiy wrote:
> On Mon, 2005-04-18 at 11:53 +0100, Christoph Hellwig wrote: 
> > The VFS already has a method for freeing an struct inode pointer, and that
> > is ->destroy_inode.  You're probably better off updating your GC state from
> > that place.
> destroy_inode() does not help. JFFS2 already makes use of clear_inode()
> which is in fact called even earlier (inode.c from 2.6.11.5, line 298):

Oh, I thought the problem is that JFFS2 thought an inode was freed when
it still was in use.  So you're problem is actually that it's no in the
hash anymore but you don't know yet?

Anyway, please explain in detail why you need all this information, what
errors you see, etc so we can find a way to fix it properly.



From dedekind at infradead.org  Mon Apr 18 08:31:06 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 18 Apr 2005 16:31:06 +0400
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <20050418115220.GA22750@infradead.org>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
Message-ID: <1113827466.2125.47.camel@sauron.oktetlabs.ru>

On Mon, 2005-04-18 at 12:52 +0100, Christoph Hellwig wrote:
> Oh, I thought the problem is that JFFS2 thought an inode was freed when
> it still was in use.  So you're problem is actually that it's no in the
> hash anymore but you don't know yet?
Yes, exactly. VFS developers may always say "it is your problem -
redesign JFFS2", but I think it is too late to redesign it.

> Anyway, please explain in detail why you need all this information, what
> errors you see, etc so we can find a way to fix it properly.
Well, I suspect I explained why I need the mutex. If people will find
the explanation vague, I'll make another attempt.

The error I see is:

Eep. Trying to read_inode #15601 when it's already in state 2!

I debugged this a lot before I've realized the reason. And I believe I
know JFFS2 very well to claim that redesigning it is very painful. 

The erroneous  code flow is like this:

kswapd: removes the inode 15601 from the inode hash (inode.c:478).
kswapd: is preempted at inode.c:485
JFFS2 writer: awakes, runs GC to reclaim some space.
JFFS2 writer: picks a JFFS2 node belonging to the inode 15601
JFFS2 writer: looks at the inode state, realizes it is in state PRESENT,
i.e. it is in the inode cache (which is wrong).
JFFS2 writer: runs iget() to acquire a pointer to the struct inode of
the inode 15601.
JFFS2 writer: iget() calls ->read_inode(), i.e., jffs2_read_inode().
JFFS2 writed: JFFS2 is surprised why read_inode() is called for the
already built inode 15601.

Or may be VFS is buggy, I'm not sure. May be it shouldn't remove inode
from the inode hash in that point (inode.c:487). It sets the I_FREENG
state to the inode being freed, and iget() may wait in find_inode_fast()
while the inode is actually destroyed (inode.c:562). The inode may be
removed from the inode hash later, in dispose_list() (inode.c:292).

Or may be this isn't a bug but a feature to make the inode_lock less
contended. Not sure, I'm not a VFS guru.

In that above described case the code flow would be:

kswapd: remove inode 15601 from the inode hash (inode.c:478).
kswapd: preempted at inode.s:485
JFFS2 writer: awakes, runs GC to reclaim some space.
JFFS2 writer: picks a JFFS2 node belonging to inode 15601
JFFS2 writer: looks at the inode state, realizes it is in state PRESENT,
i.e. it is in the inode cache (which is wrong).
JFFS2 writer: runs iget() to get the pointer to the struct inode of the
inode 15601.
JFFS2 writer goes sleep in find_inode_fast(), waiting for freeing
completion.
kswapd: calls dispose_list(), calls clear_inode() for 15601.
JFFS2 writed: read_inode() is called and all is OK since clear_inode()
was called before.

The latter scenario looks very logical for me.

Cheers, Artem.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From hch at infradead.org  Mon Apr 18 08:46:56 2005
From: hch at infradead.org (Christoph Hellwig)
Date: Mon, 18 Apr 2005 13:46:56 +0100
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <1113827466.2125.47.camel@sauron.oktetlabs.ru>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
Message-ID: <20050418124656.GA23387@infradead.org>

On Mon, Apr 18, 2005 at 04:31:06PM +0400, Artem B. Bityuckiy wrote:
> On Mon, 2005-04-18 at 12:52 +0100, Christoph Hellwig wrote:
> > Oh, I thought the problem is that JFFS2 thought an inode was freed when
> > it still was in use.  So you're problem is actually that it's no in the
> > hash anymore but you don't know yet?
> Yes, exactly. VFS developers may always say "it is your problem -
> redesign JFFS2", but I think it is too late to redesign it.

I don't think it's too late ever ;-)

> > Anyway, please explain in detail why you need all this information, what
> > errors you see, etc so we can find a way to fix it properly.
> Well, I suspect I explained why I need the mutex. If people will find
> the explanation vague, I'll make another attempt.
> 
> The error I see is:
> 
> Eep. Trying to read_inode #15601 when it's already in state 2!
> 
> I debugged this a lot before I've realized the reason. And I believe I
> know JFFS2 very well to claim that redesigning it is very painful. 
> 
> The erroneous  code flow is like this:
> 
> kswapd: removes the inode 15601 from the inode hash (inode.c:478).
> kswapd: is preempted at inode.c:485
> JFFS2 writer: awakes, runs GC to reclaim some space.
> JFFS2 writer: picks a JFFS2 node belonging to the inode 15601
> JFFS2 writer: looks at the inode state, realizes it is in state PRESENT,
> i.e. it is in the inode cache (which is wrong).
> JFFS2 writer: runs iget() to acquire a pointer to the struct inode of
> the inode 15601.
> JFFS2 writer: iget() calls ->read_inode(), i.e., jffs2_read_inode().

Why doesn't __wait_on_freeing_inode get called? prune_icache sets I_FREEING
before it's dropping the inode lock.

Any, this sounds like you'd want to use ilookup because you don't want to
read the inode in the cache anyway, right?

> JFFS2 writed: JFFS2 is surprised why read_inode() is called for the
> already built inode 15601.
> 
> Or may be VFS is buggy, I'm not sure. May be it shouldn't remove inode
> from the inode hash in that point (inode.c:487). It sets the I_FREENG
> state to the inode being freed, and iget() may wait in find_inode_fast()
> while the inode is actually destroyed (inode.c:562). The inode may be
> removed from the inode hash later, in dispose_list() (inode.c:292).
> 
> Or may be this isn't a bug but a feature to make the inode_lock less
> contended. Not sure, I'm not a VFS guru.

Yes, it's a feature.




From dwmw2 at infradead.org  Mon Apr 18 08:46:44 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Apr 2005 22:46:44 +1000
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <1113827466.2125.47.camel@sauron.oktetlabs.ru>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
Message-ID: <1113828405.5286.19.camel@localhost.localdomain>

On Mon, 2005-04-18 at 16:31 +0400, Artem B. Bityuckiy wrote:
> Yes, exactly. VFS developers may always say "it is your problem -
> redesign JFFS2", but I think it is too late to redesign it.

Bear in mind that the reason I added the state tracking to the internal
jffs2_inode_cache state was specifically to deal with the fact that the
VFS can call read_inode() for an inode which was previously in core and
for which it hasn't yet called clear_inode().

I suspect that there's a way we could work around this problem in JFFS2,
and if not hch is probably right -- exporting the lock isn't good
enough; if we're going to change the VFS we should fix the actual
problem.

I'm confused by this though -- I thought we'd already _fixed_ this in
the VFS. What you describe shouldn't happen because I believe you're
missing a step:

> JFFS2 writer: looks at the inode state, realizes it is in state PRESENT,
> i.e. it is in the inode cache (which is wrong).
> JFFS2 writer: runs iget() to acquire a pointer to the struct inode of
> the inode 15601.

wait_for_freeing_inode() waits for the existing inode in state I_FREEING
to finish being cleared...

> JFFS2 writer: iget() calls ->read_inode(), i.e., jffs2_read_inode().
> JFFS2 writed: JFFS2 is surprised why read_inode() is called for the
> already built inode 15601.

... and this shouldn't happen.

-- 
dwmw2




From dedekind at yandex.ru  Mon Apr 18 08:56:54 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Mon, 18 Apr 2005 16:56:54 +0400
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <20050418124656.GA23387@infradead.org>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
	<20050418124656.GA23387@infradead.org>
Message-ID: <4263AE96.5080707@yandex.ru>

Christoph Hellwig wrote:
> Why doesn't __wait_on_freeing_inode get called? prune_icache sets I_FREEING
> before it's dropping the inode lock.
I suppose because the inode is *deleted* from i_hash. But 
find_inode_fast looks for inode using *->i_hash*. Of course it will not 
find anything and call read_inode() immediately. Did I miss something?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From dwmw2 at infradead.org  Mon Apr 18 09:08:26 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Apr 2005 23:08:26 +1000
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <20050418124656.GA23387@infradead.org>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
	<20050418124656.GA23387@infradead.org>
Message-ID: <1113829708.5286.30.camel@localhost.localdomain>

On Mon, 2005-04-18 at 13:46 +0100, Christoph Hellwig wrote:
> Any, this sounds like you'd want to use ilookup because you don't want
> to read the inode in the cache anyway, right?

We use ilookup() in some circumstances -- if the inode has zero nlink
and hence we definitely don't want to pull it back again if it's gone.

But sometimes we really do mean to use iget() to bring it into core. And
it's in that case that I believe Artem has found the problem, because if
I understand correctly he's still seeing two consecutive calls to
read_inode() for the same inode, without a clear_inode() in between.

prune_icache() is removing the inode from i_hash at line 457 of inode.c,
then being preempted when it drops the inode_lock at line 464, which is
_before_ it calls dispose_list() to actually get rid of the inode(s) in
question. So when iget() is called, the VFS ends up calling read_inode()
again instead of waiting for the original inode to finish going away.

-- 
dwmw2




From dwmw2 at infradead.org  Mon Apr 18 09:16:51 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Apr 2005 23:16:51 +1000
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <20050418124656.GA23387@infradead.org>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
	<20050418124656.GA23387@infradead.org>
Message-ID: <1113830212.5286.33.camel@localhost.localdomain>

On Mon, 2005-04-18 at 13:46 +0100, Christoph Hellwig wrote:
> Why doesn't __wait_on_freeing_inode get called? prune_icache sets
> I_FREEING before it's dropping the inode lock.

Because prune_icache() _also_ removes the inode from the hash before
dropping the inode lock. It shouldn't -- the inode should only get
removed from the hash when it's actually been cleared. That's the real
bug -- and I agree that the fix isn't to expose internal locks to let
JFFS2 work around it.

prune_icache() (and probably invalidate_inodes() too) needs to leave the
inode on the hash list while it's being freed.

-- 
dwmw2




From dedekind at infradead.org  Mon Apr 18 10:07:32 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Mon, 18 Apr 2005 18:07:32 +0400
Subject: [PATC] small VFS change for JFFS2
In-Reply-To: <1113830212.5286.33.camel@localhost.localdomain>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
	<20050418124656.GA23387@infradead.org>
	<1113830212.5286.33.camel@localhost.localdomain>
Message-ID: <1113833252.2125.52.camel@sauron.oktetlabs.ru>

On Mon, 2005-04-18 at 23:16 +1000, David Woodhouse wrote:
> On Mon, 2005-04-18 at 13:46 +0100, Christoph Hellwig wrote:
> > Why doesn't __wait_on_freeing_inode get called? prune_icache sets
> > I_FREEING before it's dropping the inode lock.
> 
> Because prune_icache() _also_ removes the inode from the hash before
> dropping the inode lock. It shouldn't -- the inode should only get
> removed from the hash when it's actually been cleared. That's the real
> bug -- and I agree that the fix isn't to expose internal locks to let
> JFFS2 work around it.
> 
> prune_icache() (and probably invalidate_inodes() too) needs to leave the
> inode on the hash list while it's being freed.
> 

Please, then consider the following patch (I didn't test it well,
though).


Signed-off-by: Artem B. Bityuckiy <dedekind at infradead.org>

diff -auNrp linux-2.6.11.5/fs/inode.c linux-2.6.11.5_fixed/fs/inode.c
--- linux-2.6.11.5/fs/inode.c   2005-03-19 09:35:04.000000000 +0300
+++ linux-2.6.11.5_fixed/fs/inode.c     2005-04-18 17:54:16.000000000
+0400
@@ -284,6 +284,12 @@ static void dispose_list(struct list_hea
                if (inode->i_data.nrpages)
                        truncate_inode_pages(&inode->i_data, 0);
                clear_inode(inode);
+
+               spin_lock(&inode_lock);
+               hlist_del_init(&inode->i_hash);
+               list_del_init(&inode->i_sb_list);
+               spin_unlock(&inode_lock);
+
                destroy_inode(inode);
                nr_disposed++;
        }
@@ -319,8 +325,6 @@ static int invalidate_list(struct list_h
                inode = list_entry(tmp, struct inode, i_sb_list);
                invalidate_inode_buffers(inode);
                if (!atomic_read(&inode->i_count)) {
-                       hlist_del_init(&inode->i_hash);
-                       list_del(&inode->i_sb_list);
                        list_move(&inode->i_list, dispose);
                        inode->i_state |= I_FREEING;
                        count++;
@@ -455,8 +459,6 @@ static void prune_icache(int nr_to_scan)
                        if (!can_unuse(inode))
                                continue;
                }
-               hlist_del_init(&inode->i_hash);
-               list_del_init(&inode->i_sb_list);
                list_move(&inode->i_list, &freeable);
                inode->i_state |= I_FREEING;
                nr_pruned++;

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From carlliao at 21cn.com  Mon Apr 18 10:26:04 2005
From: carlliao at 21cn.com (carl liao)
Date: Mon, 18 Apr 2005 22:26:04 +0800
Subject: 2.6.10 nand driver -- drivers/mtd/nand/au1550nd.c
Message-ID: <d3949581777141.19232@send5.inner-21cn.com>

I am confused by the codes in 2.6.10 nand driver drivers/mtd/nand/au1550nd.c:

407:	au_writel((1<<28) | (NAND_PHYS_ADDR>>4) | 
408:			(((NAND_PHYS_ADDR + 0x1000)-1) & (0x3fff<<18)>>18), 
409:			MEM_STADDR1); 
410:	au_sync();
411:
412:	p_nand = ioremap(NAND_PHYS_ADDR, 0x1000);        

I think it should be like the following assuming 4KB NAND:
		au_writel((1<<28) | (NAND_PHYS_ADDR>>4) | 
				(~(0x1000-1) & (0x3fff<<18) >> 18), 
				MEM_STADDR1); 

Could someone give me a hint? Thanks!




From dedekind at infradead.org  Tue Apr 19 08:38:44 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Tue, 19 Apr 2005 16:38:44 +0400
Subject: [PATCH] VFS bugfix: two read_inode() calles without clear_inode()
	call between
Message-ID: <1113914324.2125.61.camel@sauron.oktetlabs.ru>

Hello,

here is a patch to fix the problem discussed at the "[PATC] small VFS
change for JFFS2" thread in LKML (http://lkml.org/lkml/2005/4/18/77).

The problem description:
~~~~~~~~~~~~~~~~~~~~~~

prune_icache() removes inodes from the inode hash (inode->i_hash) and
drops the node_lock spinlock. If at that moment iget() is called, we end
up with the situation when VFS calls ->read_inode() twice for the same
inode without calling ->clear_inode() between. This happens despite of
the I_FREEING inode state because the inode is already removed from the
hash by the time find_inode_fast() is invoked.

The fix is: do not remove the inode from the hash too early.

The following patch fixes the problem. It was tested with JFFS2 (only)
and works perfectly.

Comments?



Signed-off-by: Artem B. Bityuckiy <dedekind at infradead.org>


diff -auNrp linux-2.6.11.5/fs/inode.c linux-2.6.11.5_fixed/fs/inode.c
--- linux-2.6.11.5/fs/inode.c   2005-03-19 09:35:04.000000000 +0300
+++ linux-2.6.11.5_fixed/fs/inode.c     2005-04-18 17:54:16.000000000
+0400
@@ -284,6 +284,12 @@ static void dispose_list(struct list_hea
                if (inode->i_data.nrpages)
                        truncate_inode_pages(&inode->i_data, 0);
                clear_inode(inode);
+
+               spin_lock(&inode_lock);
+               hlist_del_init(&inode->i_hash);
+               list_del_init(&inode->i_sb_list);
+               spin_unlock(&inode_lock);
+
                destroy_inode(inode);
                nr_disposed++;
        }
@@ -319,8 +325,6 @@ static int invalidate_list(struct list_h
                inode = list_entry(tmp, struct inode, i_sb_list);
                invalidate_inode_buffers(inode);
                if (!atomic_read(&inode->i_count)) {
-                       hlist_del_init(&inode->i_hash);
-                       list_del(&inode->i_sb_list);
                        list_move(&inode->i_list, dispose);
                        inode->i_state |= I_FREEING;
                        count++;
@@ -455,8 +459,6 @@ static void prune_icache(int nr_to_scan)
                        if (!can_unuse(inode))
                                continue;
                }
-               hlist_del_init(&inode->i_hash);
-               list_del_init(&inode->i_sb_list);
                list_move(&inode->i_list, &freeable);
                inode->i_state |= I_FREEING;
                nr_pruned++;

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From ian at brightstareng.com  Wed Apr 20 09:40:30 2005
From: ian at brightstareng.com (Ian McDonnell)
Date: Wed, 20 Apr 2005 09:40:30 -0400
Subject: Suggestion: Give JFFS its own mail list.
Message-ID: <200504200940.30757.ian@brightstareng.com>

Is it time to give JFFS/JFFS2 a mail list of its own?

I am a user intested in MTD and below but not jffs, and
it seams like there's a lot of jffs adn jffs/mtd discussion on 
the MTD list.

Decoupling the two mail lists may indirectly help improve the 
MTD/mtd-clent (JFFS2,YAFFS,Char-IO/Block-IO) API by focusing
more on the abstract interface and less on application specifics.

-ian



From jdub at us.ibm.com  Wed Apr 20 09:59:16 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Wed, 20 Apr 2005 08:59:16 -0500
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <200504200940.30757.ian@brightstareng.com>
References: <200504200940.30757.ian@brightstareng.com>
Message-ID: <1114005556.7517.0.camel@windu.rchland.ibm.com>

On Wed, 2005-04-20 at 09:40 -0400, Ian McDonnell wrote:
> Is it time to give JFFS/JFFS2 a mail list of its own?

It already has one.  jffs-dev at axis.com

josh




From dedekind at infradead.org  Wed Apr 20 10:23:11 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 20 Apr 2005 18:23:11 +0400
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <200504200940.30757.ian@brightstareng.com>
References: <200504200940.30757.ian@brightstareng.com>
Message-ID: <1114006991.32582.11.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-20 at 09:40 -0400, Ian McDonnell wrote:
> Is it time to give JFFS/JFFS2 a mail list of its own?
> 
> I am a user intested in MTD and below but not jffs, and
> it seams like there's a lot of jffs adn jffs/mtd discussion on 
> the MTD list.
> 
> Decoupling the two mail lists may indirectly help improve the 
> MTD/mtd-clent (JFFS2,YAFFS,Char-IO/Block-IO) API by focusing
> more on the abstract interface and less on application specifics.
> 
<stress>IMO<\stress>, the list is very low-volume to split it.
Personally I have no problems seeing discussions of things to which I am
not involved.




From steve.wahl at qlogic.com  Wed Apr 20 10:39:58 2005
From: steve.wahl at qlogic.com (Steve Wahl)
Date: Wed, 20 Apr 2005 09:39:58 -0500
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <1114006991.32582.11.camel@sauron.oktetlabs.ru>
References: <200504200940.30757.ian@brightstareng.com>
	<1114006991.32582.11.camel@sauron.oktetlabs.ru>
Message-ID: <20050420143958.GI1915@qlogic.com>

On Wed, Apr 20, 2005 at 06:23:11PM +0400, Artem B. Bityuckiy wrote:
> On Wed, 2005-04-20 at 09:40 -0400, Ian McDonnell wrote:
> > Is it time to give JFFS/JFFS2 a mail list of its own?
> > 
> > I am a user intested in MTD and below but not jffs, and
> > it seams like there's a lot of jffs adn jffs/mtd discussion on 
> > the MTD list.
> > 
> > Decoupling the two mail lists may indirectly help improve the 
> > MTD/mtd-clent (JFFS2,YAFFS,Char-IO/Block-IO) API by focusing
> > more on the abstract interface and less on application specifics.
> > 
> <stress>IMO<\stress>, the list is very low-volume to split it.
> Personally I have no problems seeing discussions of things to which I am
> not involved.

But actual MTD issues seem to get ignored, perhaps because the list is
so swampped with JFFS issues.

At least I think that's the reason I was completely ignored when I
posted (twice) about a bug with AMD 29LV800 parts (and thus gave
up)...

--> Steve




From carlliao at 21cn.com  Wed Apr 20 10:47:24 2005
From: carlliao at 21cn.com (carl liao)
Date: Wed, 20 Apr 2005 22:47:24 +0800
Subject: NAND Flash Device and JFFS2 support
Message-ID: <VF949579774981.21346@send6.inner-21cn.com>

Hi All,

I back ported mtd snapshot 20050416 codes to 2.4.26 for AMD Au1200.
The NAND device could be identified and accessed via /dev/mtd/0 interface.
I even could mount /dev/mtdblock/0, copy file to it and umount it. But there is
so many warnings or ecc error messages!

So in order to properly use NAND Flash, how could I format and read/write
data to it? I want to put Linux root file system on the NAND. Is it a right choice?

Thanks in advance for you suggestions and help!

Carl Liao







From dedekind at infradead.org  Wed Apr 20 10:49:35 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 20 Apr 2005 18:49:35 +0400
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <20050420143958.GI1915@qlogic.com>
References: <200504200940.30757.ian@brightstareng.com>
	<1114006991.32582.11.camel@sauron.oktetlabs.ru>
	<20050420143958.GI1915@qlogic.com>
Message-ID: <1114008575.32582.15.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-20 at 09:39 -0500, Steve Wahl wrote:
> > <stress>IMO<\stress>, the list is very low-volume to split it.
> > Personally I have no problems seeing discussions of things to which I am
> > not involved.
> 
> But actual MTD issues seem to get ignored, perhaps because the list is
> so swampped with JFFS issues.
> 
> At least I think that's the reason I was completely ignored when I
> posted (twice) about a bug with AMD 29LV800 parts (and thus gave
> up)...

Nonetheless I have had no problems to be subscribed to several lists if
the current one would be split. :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From sergei.sharonov at halliburton.com  Wed Apr 20 10:59:50 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Wed, 20 Apr 2005 14:59:50 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<425E3174.4030308@inf.u-szeged.hu>
	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
Message-ID: <loom.20050420T165531-253@post.gmane.org>

Hi,
> > Just an idea: you may try out our summary patch. (
> > http://www.inf.u-szeged.hu/jffs2/mount.php )
> Yes, summary will help greatly with mount time, but unfortunately it 
> doesn't help with memory consumption and iget() (in Sergey's case the time 
> of the background checking is the same).

Hmm.. then what improvement does summary patch provide? In my case mount
returns in 1.5 minutes but then I cannot do anything to flash for
another 20+ minutes.

Sergei Sharonov






From dedekind at infradead.org  Wed Apr 20 11:15:01 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 20 Apr 2005 19:15:01 +0400
Subject: NAND Flash Device and JFFS2 support
In-Reply-To: <VF949579774981.21346@send6.inner-21cn.com>
References: <VF949579774981.21346@send6.inner-21cn.com>
Message-ID: <1114010101.32582.24.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-20 at 22:47 +0800, carl liao wrote:
Hi All,
> 
> I back ported mtd snapshot 20050416 codes to 2.4.26 for AMD Au1200.
> The NAND device could be identified and accessed via /dev/mtd/0
interface.
> I even could mount /dev/mtdblock/0, copy file to it and umount it. But
there is
> so many warnings or ecc error messages!
> This is not normal that you see "so many warnings or ecc error
messages". Presumably you have problems with your driver.

So in order to properly use NAND Flash, how could I format and
read/write
> data to it?
> flash_eraseall -j to format.

Please, investigate carefully web site at
http://www.linux-mtd.infradead.org/index.html

> I want to put Linux root file system on the NAND. Is it a right
choice?
Depends on your requirements.

JFFS2 is a generally good choice if:
* you need on-flight compression
* you need unclean-reboot tolerance
* your flash isn't large, say, not larger then 64 MiB

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From dedekind at infradead.org  Wed Apr 20 11:20:17 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Wed, 20 Apr 2005 19:20:17 +0400
Subject: mounting jffs2
In-Reply-To: <loom.20050420T165531-253@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
	<425E3174.4030308@inf.u-szeged.hu>
	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
	<loom.20050420T165531-253@post.gmane.org>
Message-ID: <1114010417.32582.30.camel@sauron.oktetlabs.ru>

On Wed, 2005-04-20 at 14:59 +0000, Sergei Sharonov wrote:
> Hmm.. then what improvement does summary patch provide? In my case mount
> returns in 1.5 minutes but then I cannot do anything to flash for
> another 20+ minutes.
Poor poor you :-)

Summary should accelerate mounting but leave the other characteristics 
inact in theory.

If you see that mount time only grows, that's a bug.

Read the chapter I referred you to - it will help you to understand the
nature of JFFS2 limitations.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From jdub at us.ibm.com  Wed Apr 20 11:28:11 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Wed, 20 Apr 2005 10:28:11 -0500
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <20050420143958.GI1915@qlogic.com>
References: <200504200940.30757.ian@brightstareng.com>
	<1114006991.32582.11.camel@sauron.oktetlabs.ru>
	<20050420143958.GI1915@qlogic.com>
Message-ID: <1114010891.7517.11.camel@windu.rchland.ibm.com>

On Wed, 2005-04-20 at 09:39 -0500, Steve Wahl wrote:
> On Wed, Apr 20, 2005 at 06:23:11PM +0400, Artem B. Bityuckiy wrote:
> > On Wed, 2005-04-20 at 09:40 -0400, Ian McDonnell wrote:
> > > Is it time to give JFFS/JFFS2 a mail list of its own?
> > > 
> > > I am a user intested in MTD and below but not jffs, and
> > > it seams like there's a lot of jffs adn jffs/mtd discussion on 
> > > the MTD list.
> > > 
> > > Decoupling the two mail lists may indirectly help improve the 
> > > MTD/mtd-clent (JFFS2,YAFFS,Char-IO/Block-IO) API by focusing
> > > more on the abstract interface and less on application specifics.
> > > 
> > <stress>IMO<\stress>, the list is very low-volume to split it.
> > Personally I have no problems seeing discussions of things to which I am
> > not involved.
> 
> But actual MTD issues seem to get ignored, perhaps because the list is
> so swampped with JFFS issues.
> 
> At least I think that's the reason I was completely ignored when I
> posted (twice) about a bug with AMD 29LV800 parts (and thus gave
> up)...

Hm, I don't think that's the reason.  I read your posts, and they made
sense to me.  But I don't have any similar hardware, and can't confirm,
debug, or otherwise make a useful contribution.  That may be more of a
reason for nobody responding.

Another reason is that people are generally busy and just don't have
time to read the list.  We aren't ignoring you on purpose, so please
don't give up.

Patches always get more attention too :).

josh




From nico at cam.org  Wed Apr 20 11:28:34 2005
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 20 Apr 2005 11:28:34 -0400 (EDT)
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <20050420143958.GI1915@qlogic.com>
References: <200504200940.30757.ian@brightstareng.com>
	<1114006991.32582.11.camel@sauron.oktetlabs.ru>
	<20050420143958.GI1915@qlogic.com>
Message-ID: <Pine.LNX.4.62.0504201122450.26129@localhost.localdomain>

On Wed, 20 Apr 2005, Steve Wahl wrote:

> But actual MTD issues seem to get ignored, perhaps because the list is
> so swampped with JFFS issues.

I really doubt that.  I don't think it would be any different even with 
JFFS issues being moved elsewhere.

> At least I think that's the reason I was completely ignored when I
> posted (twice) about a bug with AMD 29LV800 parts (and thus gave
> up)...

If you were ignored that's probably because no one currently has a clue 
at hand to give you.  Spliting the list won't change anything to that.


Nicolas



From sergei.sharonov at halliburton.com  Wed Apr 20 12:34:01 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Wed, 20 Apr 2005 16:34:01 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>
	<425E3174.4030308@inf.u-szeged.hu>
	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
	<loom.20050420T165531-253@post.gmane.org>
	<1114010417.32582.30.camel@sauron.oktetlabs.ru>
Message-ID: <loom.20050420T180411-538@post.gmane.org>

Hi,
> On Wed, 2005-04-20 at 14:59 +0000, Sergei Sharonov wrote:
> > Hmm.. then what improvement does summary patch provide? In my case mount
> > returns in 1.5 minutes but then I cannot do anything to flash for
> > another 20+ minutes.
> Poor poor you 

More like stuck ;-)
I believe I got the hardware and the OS right - the only trouble is
a filesystem. I cannot believe that I am the only one who runs linux
with large FLASH and requires power-fail safe operation. So far I
checked into:
1. JFFS2 - seems stable, good support, mainstream, but long mount time
makes it unusable with large NAND FLASH.
2. YAFFS2 - still playing with it. Has a lot of promise but is not
IMHO a stable/usable product at this point of time.
3. Reliance/FlashFX Pro - a commercial product that promises to do
what I need but is not yet available for linux. I was told end of Q2,
early Q3.
4. Samsung RFS - there were a few announcements last summer. They never
answered my email though.
5. Stuff like TargetFFS, etc. that has not been ported (and no
intention?) to linux.
6. JFFS3 - still in design stage.
7. M-Systems software - AFAIK I cannot use it with raw NAND FLASH.

If anybody knows of a solution, please post.


> Summary should accelerate mounting but leave the other characteristics 
> inact in theory.

What exactly can I do after mount returns: ls is blocked, write is blocked..

Sergei Sharonov 
 








From manningc2 at actrix.gen.nz  Wed Apr 20 15:30:24 2005
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Thu, 21 Apr 2005 07:30:24 +1200
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <1114005556.7517.0.camel@windu.rchland.ibm.com>
References: <200504200940.30757.ian@brightstareng.com>
	<1114005556.7517.0.camel@windu.rchland.ibm.com>
Message-ID: <20050420193029.BD330419C@blood.actrix.co.nz>

On Thursday 21 April 2005 01:59, Josh Boyer wrote:
> On Wed, 2005-04-20 at 09:40 -0400, Ian McDonnell wrote:
> > Is it time to give JFFS/JFFS2 a mail list of its own?
>
> It already has one.  jffs-dev at axis.com
>
> josh

Then JFFSx postings to mtd should be labelled OT and sent to jffs-dev

I would like to monitor mtd (as part of my YAFFS work), but I'd rather not 
get all the JFFSx stuff.

-- Charles



From jdub at us.ibm.com  Wed Apr 20 16:08:02 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Wed, 20 Apr 2005 15:08:02 -0500
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <20050420193029.BD330419C@blood.actrix.co.nz>
References: <200504200940.30757.ian@brightstareng.com>
	<1114005556.7517.0.camel@windu.rchland.ibm.com>
	<20050420193029.BD330419C@blood.actrix.co.nz>
Message-ID: <1114027682.7517.24.camel@windu.rchland.ibm.com>

On Thu, 2005-04-21 at 07:30 +1200, Charles Manning wrote:
> On Thursday 21 April 2005 01:59, Josh Boyer wrote:
> > On Wed, 2005-04-20 at 09:40 -0400, Ian McDonnell wrote:
> > > Is it time to give JFFS/JFFS2 a mail list of its own?
> >
> > It already has one.  jffs-dev at axis.com
> >
> > josh
> 
> Then JFFSx postings to mtd should be labelled OT and sent to jffs-dev

I guess I don't disagree, but it'll take enforcement from everyone to
make that happen.

> I would like to monitor mtd (as part of my YAFFS work), but I'd rather not 
> get all the JFFSx stuff.

Maybe another reason that the existing JFFSx list isn't used is because
it's off on some non-infradead server.  People probably see that
everything else is on *.infradead.org somewhere and just use the MTD
list for that reason.

If we could figure out a way to preserve all the archives, perhaps we
could move the JFFSx list onto lists.infradead.org.  David, thoughts?

josh




From nico at cam.org  Wed Apr 20 16:27:26 2005
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 20 Apr 2005 16:27:26 -0400 (EDT)
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <1114027682.7517.24.camel@windu.rchland.ibm.com>
References: <200504200940.30757.ian@brightstareng.com>
	<1114005556.7517.0.camel@windu.rchland.ibm.com>
	<20050420193029.BD330419C@blood.actrix.co.nz>
	<1114027682.7517.24.camel@windu.rchland.ibm.com>
Message-ID: <Pine.LNX.4.62.0504201625440.26129@localhost.localdomain>

On Wed, 20 Apr 2005, Josh Boyer wrote:

> Maybe another reason that the existing JFFSx list isn't used is because
> it's off on some non-infradead server.  People probably see that
> everything else is on *.infradead.org somewhere and just use the MTD
> list for that reason.
> 
> If we could figure out a way to preserve all the archives, perhaps we
> could move the JFFSx list onto lists.infradead.org.  David, thoughts?

Is it worth the trouble?

It's not like if this very list was high traffic.


Nicolas



From jdub at us.ibm.com  Wed Apr 20 16:41:12 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Wed, 20 Apr 2005 15:41:12 -0500
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <Pine.LNX.4.62.0504201625440.26129@localhost.localdomain>
References: <200504200940.30757.ian@brightstareng.com>
	<1114005556.7517.0.camel@windu.rchland.ibm.com>
	<20050420193029.BD330419C@blood.actrix.co.nz>
	<1114027682.7517.24.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.62.0504201625440.26129@localhost.localdomain>
Message-ID: <1114029672.7517.31.camel@windu.rchland.ibm.com>

On Wed, 2005-04-20 at 16:27 -0400, Nicolas Pitre wrote:
> On Wed, 20 Apr 2005, Josh Boyer wrote:
> 
> > Maybe another reason that the existing JFFSx list isn't used is because
> > it's off on some non-infradead server.  People probably see that
> > everything else is on *.infradead.org somewhere and just use the MTD
> > list for that reason.
> > 
> > If we could figure out a way to preserve all the archives, perhaps we
> > could move the JFFSx list onto lists.infradead.org.  David, thoughts?
> 
> Is it worth the trouble?
> 
> It's not like if this very list was high traffic.

If it's not a lot of trouble, I don't see why we wouldn't preserve the
archives.  People do search them when they can find them [1].  But if
it's going to take more than a couple hours, then maybe you're right and
it doesn't really matter.

Along the same lines, JFFSx might benefit from it's own homepage as
opposed to a few references on the linux-mtd page.  However, both the
new list and a new website require admin and upkeep which is why I was
asking David what his thoughts were.  Ultimately, it's his machines and
time that are required if they are to be on infradead.org.

josh

[1] I just noticed that a link to the existing jffs-dev mailing list
seems to be missing from the linux-mtd homepage.  This should probably
be corrected.




From nico at cam.org  Wed Apr 20 16:49:06 2005
From: nico at cam.org (Nicolas Pitre)
Date: Wed, 20 Apr 2005 16:49:06 -0400 (EDT)
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <1114029672.7517.31.camel@windu.rchland.ibm.com>
References: <200504200940.30757.ian@brightstareng.com>
	<1114005556.7517.0.camel@windu.rchland.ibm.com>
	<20050420193029.BD330419C@blood.actrix.co.nz>
	<1114027682.7517.24.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.62.0504201625440.26129@localhost.localdomain>
	<1114029672.7517.31.camel@windu.rchland.ibm.com>
Message-ID: <Pine.LNX.4.62.0504201648010.26129@localhost.localdomain>

On Wed, 20 Apr 2005, Josh Boyer wrote:

> On Wed, 2005-04-20 at 16:27 -0400, Nicolas Pitre wrote:
> > On Wed, 20 Apr 2005, Josh Boyer wrote:
> > 
> > > Maybe another reason that the existing JFFSx list isn't used is because
> > > it's off on some non-infradead server.  People probably see that
> > > everything else is on *.infradead.org somewhere and just use the MTD
> > > list for that reason.
> > > 
> > > If we could figure out a way to preserve all the archives, perhaps we
> > > could move the JFFSx list onto lists.infradead.org.  David, thoughts?
> > 
> > Is it worth the trouble?
> > 
> > It's not like if this very list was high traffic.
> 
> If it's not a lot of trouble, I don't see why we wouldn't preserve the
> archives.

I meant moving/splitting the lists around.


Nicolas



From jdub at us.ibm.com  Wed Apr 20 17:03:17 2005
From: jdub at us.ibm.com (Josh Boyer)
Date: Wed, 20 Apr 2005 16:03:17 -0500
Subject: Suggestion: Give JFFS its own mail list.
In-Reply-To: <Pine.LNX.4.62.0504201648010.26129@localhost.localdomain>
References: <200504200940.30757.ian@brightstareng.com>
	<1114005556.7517.0.camel@windu.rchland.ibm.com>
	<20050420193029.BD330419C@blood.actrix.co.nz>
	<1114027682.7517.24.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.62.0504201625440.26129@localhost.localdomain>
	<1114029672.7517.31.camel@windu.rchland.ibm.com>
	<Pine.LNX.4.62.0504201648010.26129@localhost.localdomain>
Message-ID: <1114030997.7517.36.camel@windu.rchland.ibm.com>

On Wed, 2005-04-20 at 16:49 -0400, Nicolas Pitre wrote:
> On Wed, 20 Apr 2005, Josh Boyer wrote:
> 
> > On Wed, 2005-04-20 at 16:27 -0400, Nicolas Pitre wrote:
> > > On Wed, 20 Apr 2005, Josh Boyer wrote:
> > > 
> > > > Maybe another reason that the existing JFFSx list isn't used is because
> > > > it's off on some non-infradead server.  People probably see that
> > > > everything else is on *.infradead.org somewhere and just use the MTD
> > > > list for that reason.
> > > > 
> > > > If we could figure out a way to preserve all the archives, perhaps we
> > > > could move the JFFSx list onto lists.infradead.org.  David, thoughts?
> > > 
> > > Is it worth the trouble?
> > > 
> > > It's not like if this very list was high traffic.
> > 
> > If it's not a lot of trouble, I don't see why we wouldn't preserve the
> > archives.
> 
> I meant moving/splitting the lists around.

Oh :).

Personally, the JFFSx stuff in the MTD list doesn't bother me.  I was
just offering up an idea that might help those who are bothered.  I
don't really have any convictions about it one way or another.

josh




From wojciech.kromer at dgt.com.pl  Thu Apr 21 03:21:38 2005
From: wojciech.kromer at dgt.com.pl (Wojciech Kromer)
Date: Thu, 21 Apr 2005 09:21:38 +0200
Subject: jffs2 boot
Message-ID: <42675482.1010908@dgt.com.pl>

Hi there.

I have problem booting jffs2 device.
I can mount, read, write an test all files on my jffs2 mtd device,
but when i'm booting from it it says:


jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 
0x2705 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 
0x4154 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: 
0x322e instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 
0x3720 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014: 
0x6570 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 
0x3220 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c: 
0x3033 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020: 
0x2031 instead
......
Further such events for this erase block will not be printed
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
empty_blocks 2, bad_blocks 0, c->nr_blocks 6


What's wrong? I've tried several mtd versions on linux-2.4.25 from denx.de




From dedekind at infradead.org  Thu Apr 21 03:48:43 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 21 Apr 2005 11:48:43 +0400
Subject: mounting jffs2
In-Reply-To: <loom.20050420T165531-253@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>
	<425E3174.4030308@inf.u-szeged.hu>
	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
	<loom.20050420T165531-253@post.gmane.org>
Message-ID: <1114069723.32582.34.camel@sauron.oktetlabs.ru>

Sergei Sharonov wrote:
> What exactly can I do after mount returns: ls is blocked, write is
blocked..

ls mustn't not blocked in theory.

Again shortly:

* ls needs iget() of the ls-ed directory inode and of all its parent
inodes.
* ls -l is ls + iget() of all L1 children inodes of the ls-ed directory.
* iget() is slow for large files like your 200MiB 
* iget() is slow for large directories (i.e., tere are a lot of L1
direntries)
* just after mount JFFS2 performs checking
* checking = fake iget() of all the filesystem inodes; fake means iget()
without actually going to the Linux Inode Cache;
* GC cant proceed while checking is in progress;
* reads may proceed;

If you have one 200MiB file then just after mount:
* jffs2 starts checking fs, you must see it typing 'top';
* ls must be quick;
* ls -l needs iget() and will do iget() of your large file.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From carlliao at 21cn.com  Thu Apr 21 05:28:41 2005
From: carlliao at 21cn.com (carl liao)
Date: Thu, 21 Apr 2005 17:28:41 +0800
Subject: NAND Flash Device and JFFS2 support
Message-ID: <Pt949578826864.08914@send1.inner-21cn.com>

HI Artem,

On 2005-04-20 23:15:01, Artem B. Bityuckiy at dedekind at infradead.org wrote:

>On Wed, 2005-04-20 at 22:47 +0800, carl liao wrote:

>>I back ported mtd snapshot 20050416 codes to 2.4.26 for AMD Au1200.
>>The NAND device could be identified and accessed via /dev/mtd/0.
>>I even could mount /dev/mtdblock/0, copy file to it and umount it. 
>>But there is so many warnings or ecc error messages!
>
>This is not normal that you see "so many warnings or ecc error
>messages". Presumably you have problems with your driver.
>

So I will double check my NAND chip driver first of all.

>>So in order to properly use NAND Flash, how could I format and
>>read/write data to it?
>
>flash_eraseall -j to format.
>
>Please, investigate carefully web site at
>http://www.linux-mtd.infradead.org/index.html
>

Thanks all! I found a good post "Can you really write a jffs2 image with
nandwrite?"
at http://lists.infradead.org/pipermail/linux-mtd/2005-March/012045.html

>>I want to put Linux root file system on the NAND. Is it a right choice?
>
>Depends on your requirements.
>
>JFFS2 is a generally good choice if:
>    * you need on-flight compression
>    * you need unclean-reboot tolerance
>    * your flash isn't large, say, not larger then 64 MiB
>

If I just want to use the NAND /dev/mtdblock/0 as a raw device without JFFS2,
and just put a ramdisk iamge on it, how could I do? Will NTFL help in this
case?

Thanks in advance to all!

Carl Liao





From carlliao at 21cn.com  Thu Apr 21 06:16:10 2005
From: carlliao at 21cn.com (carl liao)
Date: Thu, 21 Apr 2005 18:16:10 +0800
Subject: Why nandwrite success but mount complain?
Message-ID: <DB949578818096.01258@send2.inner-21cn.com>

--------------------------------------------------------------------------------
Hi,

My kernel is 2.4.26 mipsel with mtd snapshot 20050416. I erase and program my 
nand device this way:
# flash_eraseall -j /dev/mtd/3
# mkfs.jffs2 -n -e 16KiB -m none -o nddemo.jffs2 -d /demo
# nandwrite -p /dev/mtd/3 nddemo.jffs2 
# mount /dev/mtdblock/3 /mnt

The mount did succeed! But there are some dumping messeges and ECC errors.
After mounted, some of programs under /mnt could be executed correctly but some
others couldn't.

The error messages are like the following during mounting a NAND partition:

#mount /dev/mtdblock3 /mnt
......
--> mtd->read(0x400 bytes from 0xc000) returned ECC error 
--> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000c154: 
0x05b7 instead
--> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000c158: 
0x83a0 instead
......

I nanddump the data from /dev/mtd/3 to a file nandmtd3.dump and look at it:
--> 0x0000c150: 12 00 0b 00 b7 05 00 00 a0 83 41 00 00 00 00 00

I hexedit my JFFS2 image nddemo.jffs2 and look at it:
--> 0x0000c150: 8C 48 44 00 85 19 02 E0 44 10 00 00 6D 58 D1 84

The data indicate the complaints from while mounting JFFS2 is really 
justified!

Then why nandwrite programing most of data within nddemo.jffs2 correctly but 
not all of them? BTW, my nddemo.jffs2 is about 8MB.

Which codes should I dig into:
    1) NAND Flash drvier?
    2) NAND Flash core layer?
    3) JFFS2 wbuf.c and other JFFS2 codes in the kernel?
    4) the nandwrite program itself?

Please give me some suggestions. Thanks!

Carl Liao





From andymorris at beirut.com  Thu Apr 21 04:18:36 2005
From: andymorris at beirut.com (andymorris at beirut.com)
Date: Thu, 21 Apr 2005 04:18:36 -0400
Subject: Westpac Banking Corporation.
Message-ID: <1114071516.426761dc1e926@www.beirut.com>

Having obtained your contact from the internet and 
coupled with my deep interest to invest in your country, I decided 
to contact and solicit your mutual assistance. 
I am Mr. Andy Morris ,Branch Manager, Westpac Banking 
Corporation London. 

On January 6th 1999, one Mr. Mohamed Kamal Yasser ,an 
Egyptian National,a consultant/contractor with Gardiner & 
Theobald,a leading firm of project and cost management 
consultants, made a numbered time (Fixed) Deposit, 
valued at 19,500,000.00(Nineteen Million,Five Hundred Thousand 
Pounds) for twelve calender months in my Bank Branch. 
Upon Maturity, we sent a routine notification to his 
forwarding address but got no reply. After a month, 
we sent a reminder and finally we discovered from his 
contract employers (Gardiner & Theobald) that Mr. Mohamed 
Kamal Yasser died from air disaster in October 31st, 1999. 

(http://www.greatdreams.com/PassEAir990.htm)

On further investigation, it was discovered that he died 
without making a WILL (En-state) and all attempts to trace 
his next of kin was fruitless.
On further investigations, it was discovered that Late Mr 
Mohamed Kamal Yasser did not declare any next of kin or 
relations in all his official documents, including his Bank 
Deposit paper work here at the Bank. 
The total sum, 19,500,000.00 pounds is still in my bank and the 
interest is being rolled over with the principal sum at the 
end of each year. No one will ever come forward to 
claim it. 

In accordance with the Banking Federal Laws and 
constitution, at the expiration of 5 (five) years, the 
money will revert to the ownership of the Government 
if nobody applies as the next of Kin to claim the funds. 
Consequently, I shall present you as a foreign partner to 
stand in as the next of kin to late Mr. Mohamed Kamal 
Yasser so that you and I can benefit from the fruits 
of this old man's labour to enhance humanitarian Organisation 
Worldwide. 

Upon acceptance of this proposal, I shall send to you 
either by fax or email a scanned copy of the Westpac 
Banking Corporation "Next of Kin Payment Application 
Form" as well as detailed information on how this deal 
would be transacted. 
We shall employ the services of a solicitor for the 
drafting of the LAST WILL & TESTAMENT of Late Mr. 
Mohamed Kamal Yasser and to obtain all other relevant papers 
in your name for the necessary documentation for payment 
approval in my bank headquarters in your favour. 
The money will be shared in the ratio: 
Sixty percent for me, thirty five percent for you and 
five percent for any arising contigencies during the 
course of this transaction. 

I guarantee that this will be executed under legitimate 
arrangements that will protect you from any breach of 
the law as I will use my position as the Bank's Branch 
Manager to secure approvals and guarantee the successful 
execution of this transaction. It will take only 7-10 working 
days to conclude this transaction. 
Please be informed that your utmost confidentiality 
is required. If this interests you, please reply me immediately
 through my private email adress(andymorris at seeqmail.com) 
and include your private phone number for voice contact 
and fax number so that I can provide you with more details and
relevant documents that will help you understand the 
transaction. 

Awaiting your urgent reply. 
Thanks, 
Andy Morris

andymorris at seeqmail.com




-------------------------------------------------
This mail was sent through http://www.beirut.com



From dedekind at infradead.org  Thu Apr 21 06:48:22 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 21 Apr 2005 14:48:22 +0400
Subject: Why nandwrite success but mount complain?
In-Reply-To: <DB949578818096.01258@send2.inner-21cn.com>
References: <DB949578818096.01258@send2.inner-21cn.com>
Message-ID: <1114080502.32582.39.camel@sauron.oktetlabs.ru>

On Thu, 2005-04-21 at 18:16 +0800, carl liao wrote:
> Which codes should I dig into:
>     1) NAND Flash drvier?
>     2) NAND Flash core layer?
>     3) JFFS2 wbuf.c and other JFFS2 codes in the kernel?
>     4) the nandwrite program itself?
> 
I suspect 1.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From Vikrant_Basotra at Satyam.com  Thu Apr 21 07:10:50 2005
From: Vikrant_Basotra at Satyam.com (Vikrant_Basotra)
Date: Thu, 21 Apr 2005 16:40:50 +0530
Subject: JFFS2 File System Problem for ST MICRO ELECTRONICS FLASH
Message-ID: <D8595042F3765A4285B848A78A2C2ED1016149@bsdmsg002.corp.satyam.ad>

Hello All,
My board has one 16-bit flash: ST M29W640DB.

M29W640DB (16 bit bus): 

0x00000000-0x00700000 : "Root"
0x00700000-0x00720000 : "U-Boot Bootloader"
0x00720000-0x01000000 : "Linux Kernel"

When power on, Linux kernel boots from flash and print out info such as:
"
..............................................
PPP generic driver version 2.4.2
..............................................
EP8248 flash map (size->0x800000 mem->0xFF800000)
Amd/Fujitsu Extended Query Table v1.3 at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 3 MTD partitions on "EP8248 flash memory":
0x00000000-0x00700000 : "Root"
0x00700000-0x00720000 : "U-Boot Bootloader"
0x00720000-0x01000000 : "Linux Kernel"

......................................
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060000: 0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060004: 0x22df instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006000c: 0x0008 instead
Further such events for this erase block will not be printed
................................................................
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x003a0000 is not formatted. It will be erased
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0000: 0x0020 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0004: 0x22df instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c000c: 0x0008 instead

Further such events for this erase block will not be printed
JFFS2: Erase block at 0x003c0000 is not formatted. It will be erased
....................................................................
....................................................................
"
In u-boot, I entered commands to display memory:
u-boot=> md 0xff000000 
The magic number 0x1985 IS here!No 0x0020 exists at all!! 

It's quite strange!! Why Linux detects 0x0020 instead?


Why U-boot can read the data on flash correctly while linux can't?

Why linux always read all data as 0x0020?

When I simply replace ST M29W640DB with AMD AM29DL640D (the two chips are 
pin-to-pin compatible,) JFFS2 works very fine!

What's the problem?  

I don't want to use AMD FLASH, can u suggest me what necessary changes are to be made in the code so that the ST M29W640DB Flash work,


Regards,
VB






















DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.



From pajko at kukac.halom.u-szeged.hu  Thu Apr 21 07:16:45 2005
From: pajko at kukac.halom.u-szeged.hu (Kluba Patrik)
Date: Thu, 21 Apr 2005 13:16:45 +0200 (CEST)
Subject: Why nandwrite success but mount complain?
In-Reply-To: <DB949578818096.01258@send2.inner-21cn.com>
References: <DB949578818096.01258@send2.inner-21cn.com>
Message-ID: <Pine.LNX.4.61.0504211306400.1991@kukac.halom.u-szeged.hu>


This "bug" relates to JFFS2.
User space tools are able to build a file system using 16KiB erase block size, 
but the kernel part of JFFS2 itself does not support it.
This is because JFFS2 uses kmalloc for allocating memory for jffs2_eraseblock 
structs. Smaller erase block size means more of this and more memory needed for 
storage. And kmalloc allows max. 128K allocations. (using 32K block size instead 
of 16K block size halves the memory requirements)

See jffs2_do_fill_super in fs.c

It's not very easy to circumvent this problem. Memory allocation and handling of 
jffs2_eraseblocks should be modified.

Bye,

   Patrik Kluba



From alfred.hitch at gmail.com  Thu Apr 21 10:01:12 2005
From: alfred.hitch at gmail.com (alfred hitch)
Date: Thu, 21 Apr 2005 10:01:12 -0400
Subject: JFFS2 File System Problem for ST MICRO ELECTRONICS FLASH
In-Reply-To: <D8595042F3765A4285B848A78A2C2ED1016149@bsdmsg002.corp.satyam.ad>
References: <D8595042F3765A4285B848A78A2C2ED1016149@bsdmsg002.corp.satyam.ad>
Message-ID: <29f91651050421070154aa1afc@mail.gmail.com>

I am not too sure, but cna u try eraseall on the mtd partition 
and then write ur image using netflash or whatever u use .. 
also make sure ur jffs2 image was padded correctly.

Cheers,
Alfred

On 4/21/05, Vikrant_Basotra <Vikrant_Basotra at satyam.com> wrote:
> Hello All,
> My board has one 16-bit flash: ST M29W640DB.
> 
> M29W640DB (16 bit bus):
> 
> 0x00000000-0x00700000 : "Root"
> 0x00700000-0x00720000 : "U-Boot Bootloader"
> 0x00720000-0x01000000 : "Linux Kernel"
> 
> When power on, Linux kernel boots from flash and print out info such as:
> "
> ..............................................
> PPP generic driver version 2.4.2
> ..............................................
> EP8248 flash map (size->0x800000 mem->0xFF800000)
> Amd/Fujitsu Extended Query Table v1.3 at 0x0040
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling fast programming due to code brokenness.
> Creating 3 MTD partitions on "EP8248 flash memory":
> 0x00000000-0x00700000 : "Root"
> 0x00700000-0x00720000 : "U-Boot Bootloader"
> 0x00720000-0x01000000 : "Linux Kernel"
> 
> ......................................
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060000: 0x0020 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060004: 0x22df instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006000c: 0x0008 instead
> Further such events for this erase block will not be printed
> ................................................................
> Further such events for this erase block will not be printed
> JFFS2: Erase block at 0x003a0000 is not formatted. It will be erased
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0000: 0x0020 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0004: 0x22df instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c000c: 0x0008 instead
> 
> Further such events for this erase block will not be printed
> JFFS2: Erase block at 0x003c0000 is not formatted. It will be erased
> ....................................................................
> ....................................................................
> "
> In u-boot, I entered commands to display memory:
> u-boot=> md 0xff000000
> The magic number 0x1985 IS here!No 0x0020 exists at all!!
> 
> It's quite strange!! Why Linux detects 0x0020 instead?
> 
> Why U-boot can read the data on flash correctly while linux can't?
> 
> Why linux always read all data as 0x0020?
> 
> When I simply replace ST M29W640DB with AMD AM29DL640D (the two chips are
> pin-to-pin compatible,) JFFS2 works very fine!
> 
> What's the problem?
> 
> I don't want to use AMD FLASH, can u suggest me what necessary changes are to be made in the code so that the ST M29W640DB Flash work,
> 
> Regards,
> VB
> 
> DISCLAIMER:
> This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



From havasi at inf.u-szeged.hu  Thu Apr 21 10:30:07 2005
From: havasi at inf.u-szeged.hu (Ferenc Havasi)
Date: Thu, 21 Apr 2005 16:30:07 +0200
Subject: mounting jffs2
In-Reply-To: <loom.20050420T165531-253@post.gmane.org>
References: <loom.20050413T142519-107@post.gmane.org>	<425E3174.4030308@inf.u-szeged.hu>	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
	<loom.20050420T165531-253@post.gmane.org>
Message-ID: <4267B8EF.6000803@inf.u-szeged.hu>

Hi Sergei,

>Hmm.. then what improvement does summary patch provide? In my case mount
>returns in 1.5 minutes but then I cannot do anything to flash for
>another 20+ minutes.
>  
>
Yes, that is the CRC checking time.

Anyway, we are now working on a new boot time speed up technique. We 
call it centralized summary. The "old" summary is erase block summary.

Centralized summary will store information not at the end of every erase 
block, but in a centralized space. It'll stores it at the umount time, 
so if you do a clean umount the next mount will be very fast. Now it a 
prototype state.

If you would like to test it I can send a patch. I would be also useful 
for us, because we don't have real NAND device, so we cannot make real 
measurements. (Forutnatelly we can use Artem's NAND simulator.)

Bye,
Ferenc

P.s.: Artem: you wrote that you don't think that swithing off the CRC 
checking of summarized node is safe. Can you explain why? (I don't know 
the behavior of NAND deeply) Becuse it may help for Sergei...




From dedekind at infradead.org  Thu Apr 21 11:31:30 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Thu, 21 Apr 2005 19:31:30 +0400
Subject: mounting jffs2
In-Reply-To: <4267B8EF.6000803@inf.u-szeged.hu>
References: <loom.20050413T142519-107@post.gmane.org>
	<425E3174.4030308@inf.u-szeged.hu>
	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
	<loom.20050420T165531-253@post.gmane.org>
	<4267B8EF.6000803@inf.u-szeged.hu>
Message-ID: <1114097490.21485.1.camel@sauron.oktetlabs.ru>

Hello Ferenc,

> Yes, that is the CRC checking time.

I doubt that actual CRC checking takes so much time. It is mainly *read*
operation.

> P.s.: Artem: you wrote that you don't think that swithing off the CRC 
> checking of summarized node is safe. Can you explain why? (I don't
know 
> the behavior of NAND deeply) Becuse it may help for Sergei...

Because what your option does is

+#ifdef CONFIG_JFFS2_SUMMARY_NOCRCCHECK	
+	ic->state = INO_STATE_CHECKEDABSENT;
+#endif

which is incorrect. You should not skip the checking process for inodes.
When I proposed not to check CRCs I meant another thing. And now I'm
uncertain that what I proposed is absolutely correct.

Please, bear in mind that the primary goal of the checking process is
not to check CRCs but rather to detect which nodes are valid, which are
obsolete. This is done by building fake fragtrees.

Correct me if I'm wrong.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From sergei.sharonov at halliburton.com  Thu Apr 21 11:34:12 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Thu, 21 Apr 2005 15:34:12 +0000 (UTC)
Subject: mounting jffs2
References: <loom.20050413T142519-107@post.gmane.org>	<425E3174.4030308@inf.u-szeged.hu>	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>
	<loom.20050420T165531-253@post.gmane.org>
	<4267B8EF.6000803@inf.u-szeged.hu>
Message-ID: <loom.20050421T171656-701@post.gmane.org>

Hi,
> Anyway, we are now working on a new boot time speed up technique. We 
> call it centralized summary. The "old" summary is erase block summary.
..................
> If you would like to test it I can send a patch. I would be also useful 
> for us, because we don't have real NAND device, so we cannot make real 
> measurements. (Forutnatelly we can use Artem's NAND simulator.)

Ferenc, I appreciate your help. Unfortunately I don't think the patch will
improve my situation since I need to handle un-clean umounts. e.g. power 
failures and still preserve reasonable mount time.

I did a few tests with yaffs1 and yaffs2. With yaffs1, 128 MByte NAND and 100
MBytes worth of files I am getting 18 s mount time. And after 18 s filesystem
seems to be fully operational (touch, ls -l, etc.) Treat data as 
preliminary since I just built yaffs1 yesterday ;-)
I also did write/read/verify/erase of total of 6.8 GBytes of data without any 
errors. Have not done any power fail testing yet.

Now, the bad news yaffs2 did not work for me - files would disapear or get
corrupted. I would need yaffs2 to handle devices with 2 kB page size.

Sergei Sharonov





From alfred.hitch at gmail.com  Thu Apr 21 22:47:42 2005
From: alfred.hitch at gmail.com (alfred hitch)
Date: Thu, 21 Apr 2005 22:47:42 -0400
Subject: JFFS2 File System Problem for ST MICRO ELECTRONICS FLASH
In-Reply-To: <B2627A2E13B6DE4BADE1746A7DFBFA7E07B7A9@aimsg.corp.audiocodes.com>
References: <B2627A2E13B6DE4BADE1746A7DFBFA7E07B7A9@aimsg.corp.audiocodes.com>
Message-ID: <29f91651050421194778a08471@mail.gmail.com>

hey did u guys  try correct block size while making jffs2 images ?

Cheers,
Alfred

On 4/21/05, Murali Sampath <msampath at ai-logix.com> wrote:
> HI
> 
> I am using the Uboot and also I have AMD29LV640 flash device. I still get the jffs2_scan_erase_block errors.
> I am stuck not able to get JFFS2 to work right. Any suggestions will  be greatly appreciated. I have no problem in using NFS.
> Thanks
> When I dump the memory I see the file system flashed in correctly. Iam still missing something.
> 
> *************************************************************************
> Trace on my board looks like the following.
> 
> PPP generic driver version 2.4.2
> PPP Deflate Compression module registered
> PowerPC/UBoot 8xx/8xxx flash device: 0x800000 bytes at 0xff800000 (16 bits wide)
> PowerPC/Uboot 8xx/8xxx boards: Found 1 x16 devices at 0x0 in 16-bit mode
>  Amd/Fujitsu Extended Query Table at 0x0040
> PowerPC/Uboot 8xx/8xxx boards: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> 
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> 
> Creating 4 MTD partitions on "PowerPC/Uboot 8xx/8xxx boards":
> 0x00000000-0x00040000 : "UbootConfig"
> mtd: Giving out device 0 to UbootConfig
> 0x00040000-0x00700000 : "JFFS2"
> mtd: Giving out device 1 to JFFS2
> 0x00700000-0x00780000 : "U-Boot"
> mtd: Giving out device 2 to U-Boot
> 0x00780000-0x00800000 : "Linux"
> mtd: Giving out device 3 to Linux
> 
> ******
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030000: 0x0808 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030004: 0x0808 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030008: 0x6666 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0003000c: 0x6666 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030010: 0x0606 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030014: 0x0606 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030018: 0x4646 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0003001c: 0x4646 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030100: 0x3aa0 instead
> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00030104: 0x6000
> *******
> -----Original Message-----
> From: linux-mtd-bounces at lists.infradead.org
> [mailto:linux-mtd-bounces at lists.infradead.org]On Behalf Of alfred hitch
> Sent: Thursday, April 21, 2005 10:01 AM
> To: Vikrant_Basotra
> Cc: linux-mtd at lists.infradead.org
> Subject: Re: JFFS2 File System Problem for ST MICRO ELECTRONICS FLASH
> 
> I am not too sure, but cna u try eraseall on the mtd partition
> and then write ur image using netflash or whatever u use ..
> also make sure ur jffs2 image was padded correctly.
> 
> Cheers,
> Alfred
> 
> On 4/21/05, Vikrant_Basotra <Vikrant_Basotra at satyam.com> wrote:
> > Hello All,
> > My board has one 16-bit flash: ST M29W640DB.
> >
> > M29W640DB (16 bit bus):
> >
> > 0x00000000-0x00700000 : "Root"
> > 0x00700000-0x00720000 : "U-Boot Bootloader"
> > 0x00720000-0x01000000 : "Linux Kernel"
> >
> > When power on, Linux kernel boots from flash and print out info such as:
> > "
> > ..............................................
> > PPP generic driver version 2.4.2
> > ..............................................
> > EP8248 flash map (size->0x800000 mem->0xFF800000)
> > Amd/Fujitsu Extended Query Table v1.3 at 0x0040
> > number of CFI chips: 1
> > cfi_cmdset_0002: Disabling fast programming due to code brokenness.
> > Creating 3 MTD partitions on "EP8248 flash memory":
> > 0x00000000-0x00700000 : "Root"
> > 0x00700000-0x00720000 : "U-Boot Bootloader"
> > 0x00720000-0x01000000 : "Linux Kernel"
> >
> > ......................................
> > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060000: 0x0020 instead
> > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00060004: 0x22df instead
> > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0006000c: 0x0008 instead
> > Further such events for this erase block will not be printed
> > ................................................................
> > Further such events for this erase block will not be printed
> > JFFS2: Erase block at 0x003a0000 is not formatted. It will be erased
> > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0000: 0x0020 instead
> > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c0004: 0x22df instead
> > jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003c000c: 0x0008 instead
> >
> > Further such events for this erase block will not be printed
> > JFFS2: Erase block at 0x003c0000 is not formatted. It will be erased
> > ....................................................................
> > ....................................................................
> > "
> > In u-boot, I entered commands to display memory:
> > u-boot=> md 0xff000000
> > The magic number 0x1985 IS here!No 0x0020 exists at all!!
> >
> > It's quite strange!! Why Linux detects 0x0020 instead?
> >
> > Why U-boot can read the data on flash correctly while linux can't?
> >
> > Why linux always read all data as 0x0020?
> >
> > When I simply replace ST M29W640DB with AMD AM29DL640D (the two chips are
> > pin-to-pin compatible,) JFFS2 works very fine!
> >
> > What's the problem?
> >
> > I don't want to use AMD FLASH, can u suggest me what necessary changes are to be made in the code so that the ST M29W640DB Flash work,
> >
> > Regards,
> > VB
> >
> > DISCLAIMER:
> > This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



From tpoynor at mvista.com  Thu Apr 21 23:04:55 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Thu, 21 Apr 2005 20:04:55 -0700
Subject: Fixup Intel flash that powers up locked
In-Reply-To: <Pine.LNX.4.62.0504122118560.14514@localhost.localdomain>
References: <20050413010315.GA31632@slurryseal.ddns.mvista.com>
	<Pine.LNX.4.62.0504122118560.14514@localhost.localdomain>
Message-ID: <426869D7.3050202@mvista.com>

Nicolas Pitre wrote:

> Properly dealing with this "feature" appears to be so messy that I'm 
> starting to wonder if we should not just unconditionally unlock the 
> flash at boot time and be done with it.

Or leave all blocks locked to err on the side of safety and require 
userspace init scripts to unlock writeable partitions.

> It's only the flash used for the root filesystem which is problematic 
> anyway, right?  If so then I think there should be a mount option for 
> JFFS* such that it directly unlocks the whole of the MTD device it's 
> about to be mounted on when it's mounted read-write.  That's it.

Read-only root with writeable partitions mounted afterwards is what I 
suggest, I imagine there's reasons not to do it that way, though.

> As for the suspend case then you should probably just preserve the flash 
> lock state before suspending and restore that state upon resume.

I'm guessing the code for that would trigger the messy alarms as well...

Am finding the frob DEBUG_LOCK_BITS logic doesn't read lock status 
properly on this board's chip (blocks that appear to be writeable still 
read status non-zero).  This makes it difficult to setup the bitmap at 
suspend time.  Now, I could maintain the bitmap at each block 
lock/unlock time, but the frob code doesn't pass the eraseregion info 
(useful to understand region size and maintain per-region bitmap) to the 
chip driver (which knows whether the chip has this powers-up-locked 
property).  Alas.  I will play with this some more.

> Why are you doing this block by block? You could as well just do:
> 
> 	cfi_intelext_unlock(mtd, 0, mtd->size);
> 
> since the block walking is already performed by cfi_varsize_frob().

Aargh, that code predated the frob on multi-partition flash fix, sorry. 
  Thanks,


-- 
Todd



From ktdann at gmail.com  Fri Apr 22 04:09:42 2005
From: ktdann at gmail.com (Daniel Ann)
Date: Fri, 22 Apr 2005 17:09:42 +0900
Subject: Question regarding to 2.4 kernel and MTD
Message-ID: <9b7ca6570504220109161b2afc@mail.gmail.com>

Hey folks,

I know I've read enuf times that 2.4 series are considered ancient and
everything, but I really need to give it a try on 2.4.21. My question
is, how come I cant seem to locate any snapshots between 2002 and 2005
?

Did people of MTD went on long holiday ? :)

Closest one I've found was snapshot made on the 2005.3.4, but even
that file is missing from the FTP server.

If anyone carries anything that is remotely similar to what Im doing,
I'd love to give it a go.

Many thanks in advance.

-- 
Daniel



From dedekind at yandex.ru  Fri Apr 22 04:31:00 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Fri, 22 Apr 2005 12:31:00 +0400
Subject: Question regarding to 2.4 kernel and MTD
In-Reply-To: <9b7ca6570504220109161b2afc@mail.gmail.com>
References: <9b7ca6570504220109161b2afc@mail.gmail.com>
Message-ID: <4268B644.6080008@yandex.ru>

Daniel Ann wrote:
> I know I've read enuf times that 2.4 series are considered ancient and
> everything, but I really need to give it a try on 2.4.21. My question
> is, how come I cant seem to locate any snapshots between 2002 and 2005
> ?
People say the recent snapshot works with 2.4, may be with some tweaks.

Old snapshots may be fetched from CVS I suppose.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From ktdann at gmail.com  Fri Apr 22 04:40:54 2005
From: ktdann at gmail.com (Daniel Ann)
Date: Fri, 22 Apr 2005 17:40:54 +0900
Subject: Question regarding to 2.4 kernel and MTD
In-Reply-To: <4268B644.6080008@yandex.ru>
References: <9b7ca6570504220109161b2afc@mail.gmail.com>
	<4268B644.6080008@yandex.ru>
Message-ID: <9b7ca657050422014040f4e23c@mail.gmail.com>

On 4/22/05, Artem B. Bityuckiy <dedekind at yandex.ru> wrote:
> People say the recent snapshot works with 2.4, may be with some tweaks.

Im currently giving a go with the snapshot made on the april first
2005. May be I should work with at least april the second :P

> Old snapshots may be fetched from CVS I suppose.

Ahhh.. do you think I could get some pointer in checking out older
version from CVS ? I have no problem checking out latest, but my
knowledge in CVS seems very limited at this stage. small quick tip
would go a long way :)

-- 
Daniel



From dedekind at infradead.org  Fri Apr 22 04:58:34 2005
From: dedekind at infradead.org (Artem B. Bityuckiy)
Date: Fri, 22 Apr 2005 12:58:34 +0400
Subject: Question regarding to 2.4 kernel and MTD
In-Reply-To: <9b7ca657050422014040f4e23c@mail.gmail.com>
References: <9b7ca6570504220109161b2afc@mail.gmail.com>
	<4268B644.6080008@yandex.ru>
	<9b7ca657050422014040f4e23c@mail.gmail.com>
Message-ID: <1114160314.21485.5.camel@sauron.oktetlabs.ru>

On Fri, 2005-04-22 at 17:40 +0900, Daniel Ann wrote:
> Ahhh.. do you think I could get some pointer in checking out older
> version from CVS ? I have no problem checking out latest, but my
> knowledge in CVS seems very limited at this stage. small quick tip
> would go a long way :)
> 
Ex.: cvs -D 2002-04-22

See 'man cvs' for details.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.




From tpoynor at mvista.com  Fri Apr 22 15:53:24 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Fri, 22 Apr 2005 12:53:24 -0700
Subject: DEBUG_LOCK_BITS fix for Intel NOR flash
Message-ID: <20050422195324.GA12115@slurryseal.ddns.mvista.com>

This patch seems to correctly access block lock status bits for at least
one Intel StrataFlash model.  Without at least half of this patch (the
chip->start adjustment), DEBUG_LOCK_BITS won't work well with
multi-partition flash, at the least.

I also needed to change the code to follow the flowchart given in a
recent StrataFlash datasheet: write command 0x90 followed by the block
address + 2, then read block address + 2.  The old code writes command
0x90 followed by hardcoded address 0x55, then reads block address + 2.

Can anybody verify whether Intel flash models exist that require the
0x55 address for block lock query?  If so, know of any way to
distinguish the two cases?

Absent any dissent this patch will go into CVS.  (Why all the concern
over a debug feature?  Because I want to also write code to query lock
status for other reasons.)  Thanks -- Todd

Index: linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c
===================================================================
--- linux-mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-22 19:15:05.000000000 +0000
+++ linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-22 19:39:12.000000000 +0000
@@ -1823,8 +1823,9 @@
 	struct cfi_private *cfi = map->fldrv_priv;
 	int status, ofs_factor = cfi->interleave * cfi->device_type;
 
+	adr += chip->start;
 	xip_disable(map, chip, adr+(2*ofs_factor));
-	cfi_send_gen_cmd(0x90, 0x55, 0, map, cfi, cfi->device_type, NULL);
+	map_write(map, CMD(0x90), adr+(2*ofs_factor));
 	chip->state = FL_JEDEC_QUERY;
 	status = cfi_read_query(map, adr+(2*ofs_factor));
 	xip_enable(map, chip, 0);




From tpoynor at mvista.com  Fri Apr 22 19:22:41 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Fri, 22 Apr 2005 16:22:41 -0700
Subject: Fixup Intel flash that powers up locked
In-Reply-To: <Pine.LNX.4.62.0504122118560.14514@localhost.localdomain>
References: <20050413010315.GA31632@slurryseal.ddns.mvista.com>
	<Pine.LNX.4.62.0504122118560.14514@localhost.localdomain>
Message-ID: <20050422232241.GA10813@slurryseal.ddns.mvista.com>

On Tue, Apr 12, 2005 at 09:45:36PM -0400, Nicolas Pitre wrote:

> As for the suspend case then you should probably just preserve the flash 
> lock state before suspending and restore that state upon resume.

Here's a patch which does just that.  The lock bitmap is in the generic
eraseregion data structure to facilitate compact bitmap size based on
erase region size, but could be moved to per mtd cfi private.  Comments
appreciated, thanks. -- Todd

Index: linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c
===================================================================
--- linux-mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-21 23:26:08.000000000 +0000
+++ linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c	2005-04-22 22:48:45.000000000 +0000
@@ -30,6 +30,7 @@
 #include <linux/delay.h>
 #include <linux/interrupt.h>
 #include <linux/reboot.h>
+#include <linux/bitmap.h>
 #include <linux/mtd/xip.h>
 #include <linux/mtd/map.h>
 #include <linux/mtd/mtd.h>
@@ -431,6 +432,7 @@
 		       i,mtd->eraseregions[i].offset,
 		       mtd->eraseregions[i].erasesize,
 		       mtd->eraseregions[i].numblocks);
+		mtd->eraseregions[i].lockmap = NULL;
 	}
 
 #ifdef CONFIG_MTD_OTP
@@ -2235,10 +2237,50 @@
 
 #endif
 
+static void cfi_intelext_save_locks(struct mtd_info *mtd)
+{
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+	int ofs_factor = cfi->interleave * cfi->device_type;
+	int i;
+
+	for (i = 0; i < mtd->numeraseregions; i++) {
+		struct mtd_erase_region_info *region = &mtd->eraseregions[i];
+		int mapsize = region->numblocks / 8 + 1;
+
+		if (region->lockmap ||
+		    (region->lockmap = kmalloc(mapsize, GFP_KERNEL))) {
+			int block;
+
+			memset(region->lockmap, 0, mapsize);
+
+			for (block = 0; block < region->numblocks; block++){
+				struct flchip *chip;
+				int status, chipnum;
+				unsigned long adr = region->offset +
+					block * region->erasesize;
+
+				chipnum = adr >> cfi->chipshift;
+				chip = &cfi->chips[chipnum];
+				xip_disable(map, chip, adr+(2*ofs_factor));
+				map_write(map, CMD(0x90), adr+(2*ofs_factor));
+				chip->state = FL_JEDEC_QUERY;
+				status = cfi_read_query(map, 
+							adr+(2*ofs_factor));
+				xip_enable(map, chip, 0);
+
+				if (status & 0x1)
+					set_bit(block, region->lockmap);
+			}
+		}
+	}
+}
+
 static int cfi_intelext_suspend(struct mtd_info *mtd)
 {
 	struct map_info *map = mtd->priv;
 	struct cfi_private *cfi = map->fldrv_priv;
+	struct cfi_pri_intelext *extp = cfi->cmdset_priv;
 	int i;
 	struct flchip *chip;
 	int ret = 0;
@@ -2279,6 +2321,9 @@
 		spin_unlock(chip->mutex);
 	}
 
+	if (! ret && extp && (extp->FeatureSupport & (1 << 5)))
+		cfi_intelext_save_locks(mtd);
+
 	/* Unlock the chips again */
 
 	if (ret) {
@@ -2302,10 +2347,47 @@
 	return ret;
 }
 
+static void cfi_intelext_restore_locks(struct mtd_info *mtd)
+{
+	struct map_info *map = mtd->priv;
+	struct cfi_private *cfi = map->fldrv_priv;
+	int ofs_factor = cfi->interleave * cfi->device_type;
+	int i;
+
+	for (i = 0; i < mtd->numeraseregions; i++) {
+		struct mtd_erase_region_info *region = &mtd->eraseregions[i];
+		int block;
+
+		if (! region->lockmap)
+			continue;
+
+		for (block = 0; block < region->numblocks; block++){
+			struct flchip *chip;
+			int status, chipnum;
+			unsigned long adr = region->offset +
+				block * region->erasesize;
+
+			chipnum = adr >> cfi->chipshift;
+			chip = &cfi->chips[chipnum];
+
+			if (! test_bit(block, region->lockmap)) {
+				xip_disable(map, chip, adr+(2*ofs_factor));
+				do_xxlock_oneblock(map, chip,
+						   adr - chip->start,
+						   region->erasesize,
+						   DO_XXLOCK_ONEBLOCK_UNLOCK);
+				xip_enable(map, chip, 0);
+			}
+			
+		}
+	}
+}
+
 static void cfi_intelext_resume(struct mtd_info *mtd)
 {
 	struct map_info *map = mtd->priv;
 	struct cfi_private *cfi = map->fldrv_priv;
+	struct cfi_pri_intelext *extp = cfi->cmdset_priv;
 	int i;
 	struct flchip *chip;
 
@@ -2324,6 +2406,9 @@
 
 		spin_unlock(chip->mutex);
 	}
+
+	if (extp && (extp->FeatureSupport & (1 << 5)))
+		cfi_intelext_restore_locks(mtd);
 }
 
 static int cfi_intelext_reset(struct mtd_info *mtd)
Index: linux-mtd/include/linux/mtd/mtd.h
===================================================================
--- linux-mtd.orig/include/linux/mtd/mtd.h	2005-04-21 23:26:08.000000000 +0000
+++ linux-mtd/include/linux/mtd/mtd.h	2005-04-21 23:34:52.000000000 +0000
@@ -55,6 +55,7 @@
 	u_int32_t offset;			/* At which this region starts, from the beginning of the MTD */
 	u_int32_t erasesize;		/* For this region */
 	u_int32_t numblocks;		/* Number of blocks of erasesize in this region */
+	unsigned long *lockmap;		/* If keeping bitmap of locks */
 };
 
 struct mtd_info {




From ktdann at gmail.com  Sun Apr 24 02:35:41 2005
From: ktdann at gmail.com (Daniel Ann)
Date: Sun, 24 Apr 2005 15:35:41 +0900
Subject: Question regarding to 2.4 kernel and MTD
In-Reply-To: <9b7ca657050422014040f4e23c@mail.gmail.com>
References: <9b7ca6570504220109161b2afc@mail.gmail.com>
	<4268B644.6080008@yandex.ru>
	<9b7ca657050422014040f4e23c@mail.gmail.com>
Message-ID: <9b7ca65705042323352c6da93c@mail.gmail.com>

On 4/22/05, Daniel Ann <ktdann at gmail.com> wrote:
> On 4/22/05, Artem B. Bityuckiy <dedekind at yandex.ru> wrote:
> > People say the recent snapshot works with 2.4, may be with some tweaks.
> 
> Im currently giving a go with the snapshot made on the april first
> 2005. May be I should work with at least april the second :P

Just so people know, it worked :)

-- 
Daniel



From weth at inf.u-szeged.hu  Tue Apr 26 09:35:22 2005
From: weth at inf.u-szeged.hu (Zoltan Sogor)
Date: Tue, 26 Apr 2005 15:35:22 +0200
Subject: mounting jffs2
In-Reply-To: <1114097490.21485.1.camel@sauron.oktetlabs.ru>
References: <loom.20050413T142519-107@post.gmane.org>	<425E3174.4030308@inf.u-szeged.hu>	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>	<loom.20050420T165531-253@post.gmane.org>	<4267B8EF.6000803@inf.u-szeged.hu>
	<1114097490.21485.1.camel@sauron.oktetlabs.ru>
Message-ID: <426E439A.2050301@inf.u-szeged.hu>

Hi Artem!

Artem B. Bityuckiy wrote:

>Because what your option does is
>
>+#ifdef CONFIG_JFFS2_SUMMARY_NOCRCCHECK	
>+	ic->state = INO_STATE_CHECKEDABSENT;
>+#endif
>
>which is incorrect. You should not skip the checking process for inodes.
>When I proposed not to check CRCs I meant another thing. And now I'm
>uncertain that what I proposed is absolutely correct.
>
>Please, bear in mind that the primary goal of the checking process is
>not to check CRCs but rather to detect which nodes are valid, which are
>obsolete. This is done by building fake fragtrees.
>
>Correct me if I'm wrong.
>  
>
I think our nocrc support works fine, and it is correct.

Everything is checkd and built but not at mount time. It will be checked
at the moment when you want to use the inode:

Mount:
Function jffs2_do_crccheck_inode() calls jffs2_do_read_inode_internal(),
which calls jffs2_get_inode_nodes() to collect some necessary info and
do sanity checks (crc, page boundary, ...).
After then jffs2_get_inode_nodes() can appoint which node is valid and
which is obsolated.

Read:
If you want to read an inode then the kernel calls jffs2_do_read_inode()
to get the inode.
jffs2_do_read_inode() checks that the inode is in which state
(UNCHECKED, CHECKEDABSENT, PRESENT, CHECKING, ...) In our point of view
state UNCHECKED and CHECKEDABSENT are the same, it means that in both
cases it calls jffs2_do_read_inode_internal().

In both situation nodes are checked.

I think it is necessery because if you mount the fs as readonly these
checks should happen.

Zoltan Sogor









From dedekind at oktetlabs.ru  Tue Apr 26 09:51:01 2005
From: dedekind at oktetlabs.ru (Artem B. Bityuckiy)
Date: Tue, 26 Apr 2005 17:51:01 +0400
Subject: mounting jffs2
In-Reply-To: <426E439A.2050301@inf.u-szeged.hu>
References: <loom.20050413T142519-107@post.gmane.org>	<425E3174.4030308@inf.u-szeged.hu>	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>	<loom.20050420T165531-253@post.gmane.org>	<4267B8EF.6000803@inf.u-szeged.hu>
	<1114097490.21485.1.camel@sauron.oktetlabs.ru>
	<426E439A.2050301@inf.u-szeged.hu>
Message-ID: <426E4745.5050606@oktetlabs.ru>

Hello Zoltan,

> Read:
> If you want to read an inode then the kernel calls jffs2_do_read_inode()
> to get the inode.
But if I don't want? There are thousands of inodes and I don't have to 
read them all. What then? Will GC move dirt along with valid data? Will 
I see fewer free space then there is actually present? I suppose yes and 
this is incorrect.

-- 
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind at oktetlabs.ru, web: http://www.oktetlabs.ru



From eddie at embeddedx86.com  Tue Apr 26 16:33:59 2005
From: eddie at embeddedx86.com (Eddie Dawydiuk)
Date: Tue, 26 Apr 2005 13:33:59 -0700 (MST)
Subject: Bad Blocks...
Message-ID: <32985.192.168.0.136.1114547639.squirrel@oz.embeddedx86.com>

Hello Yaffers,

After running some stress tests on a 128MB NAND Flash I have found some
strange behavior while using the Yaffs filesystem... The stress test
creates a ring-buffer of 5 directories, each directory contains 10,000
files with a size of 1248 bytes (Please find the source code attached). 
When running this application on a 32MB NAND Flash I am able to fill the
disk and then delete the files as expected... Although when running the
test on a 128MB NAND Flash(with the same kernel) I find that after
creating slightly over 35,000 files I am unable to write any more files to
disk(my board hangs). After rebooting the board, when I attempt to delete
the files only some of the files are deleted successfully(on the first
attempt). After attempting several more times I am able to delete all of
the files but I find that I have hundreds of bad blocks(there are no error
messages when I attempt to delete a file and it is unsucessfully deleted).
I have provided the output of /proc/yaffs below(after running the stress
test multiple times) and am using a 2.4.26 kernel... I have read the other
posts refering to bad block management
(http://www.aleph1.co.uk/pipermail/yaffs/2005q1/000955.html) and have
ensured the fixes suggested have been made. If anyone has any suggestions
I would appreciate them...

$ cat /proc/yaffs
YAFFS built:Apr 26 2005 10:44:45
$Id: yaffs_fs.c,v 1.3 2005/01/25 00:38:25 eddie Exp $
$Id: yaffs_guts.c,v 1.41 2005/04/24 08:54:36 charles Exp $

Device yaffs
startBlock......... 1
endBlock........... 7999
chunkGroupBits..... 2
chunkGroupSize..... 4
nErasedBlocks...... 1575
nTnodesCreated..... 35000
nFreeTnodes........ 21790
nObjectsCreated.... 34400
nFreeObjects....... 21795
nFreeChunks........ 142801
nPageWrites........ 71420
nPageReads......... 2573700
nBlockErasures..... 4021
nGCCopies.......... 317
garbageCollections. 3599
passiveGCs......... 3599
nRetriedWrites..... 0
nRetireBlocks...... 2397
eccFixed........... 0
eccUnfixed......... 0
tagsEccFixed....... 0
tagsEccUnfixed..... 654
cacheHits.......... 0
nDeletedFiles...... 22161
nUnlinkedFiles..... 22162
nBackgroudDeletions 0
useNANDECC......... 1

Thanks,
Eddie




From rgadams at cox.net  Tue Apr 26 16:54:38 2005
From: rgadams at cox.net (rick adams)
Date: Tue, 26 Apr 2005 13:54:38 -0700
Subject: Fixup Intel flash that powers up locked
In-Reply-To: <E1DLiOu-0006Ah-1b@canuck.infradead.org>
References: <E1DLiOu-0006Ah-1b@canuck.infradead.org>
Message-ID: <1114548884.9606.123.camel@laptop.sandiego.IdealSolutions.com>

On Wed, 2005-04-13 at 09:59 -0400, linux-mtd-
request at lists.infradead.org 
> Message: 2
> Date: Tue, 12 Apr 2005 18:03:15 -0700
> From: Todd Poynor <tpoynor at mvista.com>
> Subject: Fixup Intel flash that powers up locked
>
> Any comments on whether this is or is not the way to go appreciated.
> 

What I have done when I have encountered this Intel "feature" of their
version "K" of their stataFlash devices is to unlock all sectors in the
boot code. This is done before the kernel even loads, so the kernel
doesn't even know it's not using the "J" version of the part (the device
the driver was written for). The boot code reads the device ID register
and if it's not a "J" version it unlocks all the sectors. I had to do
this anyhow in the boot code since my boot code needs to write to FLASH.
There are several reasons I feel this is a better approach to address
the Intel "feature" the most important reason is the KISS philosophy.
Why add all the complexity to the kernel when it can be done simply in
the boot code and the kernel doesn't even know (or need to know) the
joys of these version differences of the FLASH chip on the board. It
just needs to now that it can talk to either the "J" or "K" version with
the same code. If you don't do the boot code and have a problem with
this dependency on non kernel code, you can always add it to head.s,
headxxxx.s, or some board specific code that runs before the file system
(or any write to FLASH) is used.

NOTE:: Intel is obsoleting the "J" part and selling the "K" part as a
direct replacement. So if you have a product in production that uses the
Intel StrataFLASH device you may want to address this "feature" before
you get the call that production has stopped (accompanied by more help
from management they you can imagine).

Rick Adams
rick at thePTRgroup.com





From manningc2 at actrix.gen.nz  Tue Apr 26 18:43:10 2005
From: manningc2 at actrix.gen.nz (Charles Manning)
Date: Wed, 27 Apr 2005 10:43:10 +1200
Subject: Bad Blocks...
In-Reply-To: <32985.192.168.0.136.1114547639.squirrel@oz.embeddedx86.com>
References: <32985.192.168.0.136.1114547639.squirrel@oz.embeddedx86.com>
Message-ID: <20050426224942.92AA3160C8@desire.actrix.co.nz>

On Wednesday 27 April 2005 08:33, Eddie Dawydiuk wrote:
> Hello Yaffers,
>
> After running some stress tests on a 128MB NAND Flash I have found some
> strange behavior while using the Yaffs filesystem... The stress test
> creates a ring-buffer of 5 directories, each directory contains 10,000
> files with a size of 1248 bytes (Please find the source code attached).
> When running this application on a 32MB NAND Flash I am able to fill the
> disk and then delete the files as expected... Although when running the
> test on a 128MB NAND Flash(with the same kernel) I find that after
> creating slightly over 35,000 files I am unable to write any more files to
> disk(my board hangs). After rebooting the board, when I attempt to delete
> the files only some of the files are deleted successfully(on the first
> attempt). After attempting several more times I am able to delete all of
> the files but I find that I have hundreds of bad blocks(there are no error
> messages when I attempt to delete a file and it is unsucessfully deleted).
> I have provided the output of /proc/yaffs below(after running the stress
> test multiple times) and am using a 2.4.26 kernel... I have read the other
> posts refering to bad block management
> (http://www.aleph1.co.uk/pipermail/yaffs/2005q1/000955.html) and have
> ensured the fixes suggested have been made. If anyone has any suggestions
> I would appreciate them...


Hi Eddie

I have not tried making 35000 files on a Linux box myself, but all of this 
should work fine.

The core problem, it seems to me, is the excessive number of bad blocks being 
generated. nRetiredBlocks of 2397 shows that over a quarter of your blocks 
have been marked bad in just one run.  Anything over 1-2% in a product 
lifetime is unlhealthy.

Sever block failures will cause flow-on failures like garbage collection 
problems etc.

Block failures are generally a result of ecc errors. I see you're using NAND 
ecc, so make sure that is doing the right thing.

I suggest adding some of the low level tracing (eg. YAFFS_TRACE_BAD_BLOCKS) 
and maybe turn on more mtd tracing. Feel free to add your own too :-)

-- Charles




From mikelee at avantwave.com  Wed Apr 27 03:15:59 2005
From: mikelee at avantwave.com (mike lee)
Date: Wed, 27 Apr 2005 15:15:59 +0800
Subject: no wait queue init in cfi_cmd0002
Message-ID: <426F3C2F.7040503@avantwave.com>

Dear all
    I have added a line to cfi_cmdset_0002.c to solve kernel oops of my mapping driver. Actually, i can not find any init wait queue in cmdset_0002, when i add it back , the problem solved. I get mess because there is no problem when i port another amdflash. Please correct me if i am wrong.
    I am using unpatched linux-2.6.10

struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
............
    for (i=0; i< cfi->numchips; i++) {
        cfi->chips[i].word_write_time = 1<<cfi->cfiq->WordWriteTimeoutTyp;
        cfi->chips[i].buffer_write_time = 1<<cfi->cfiq->BufWriteTimeoutTyp;
        cfi->chips[i].erase_time = 1<<cfi->cfiq->BlockEraseTimeoutTyp;
        init_waitqueue_head(&cfi->chips[i].wq);  //line added by mike,11/apr/2005
    }       

best regard
Mike,Lee




From timm at ipi.ac.ru  Wed Apr 27 03:34:59 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Wed, 27 Apr 2005 11:34:59 +0400
Subject: nand locking
Message-ID: <426F40A3.8010308@ipi.ac.ru>

Hi.

Is there a straight way to lock/unlock nand pages?

The nand_scan() does "mtd_info->lock = NULL;" unconditionally,
though the nand chip is capable of locking.

Regards.
   	Timofei.



From tglx at linutronix.de  Wed Apr 27 05:00:03 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 27 Apr 2005 11:00:03 +0200
Subject: nand locking
In-Reply-To: <426F40A3.8010308@ipi.ac.ru>
References: <426F40A3.8010308@ipi.ac.ru>
Message-ID: <1114592403.879.175.camel@tglx.tec.linutronix.de>

On Wed, 2005-04-27 at 11:34 +0400, Timofei V. Bondarenko wrote:
>
> Is there a straight way to lock/unlock nand pages?
> 
> The nand_scan() does "mtd_info->lock = NULL;" unconditionally,
> though the nand chip is capable of locking.

I'm not aware of page locking features in NAND chips. The only locking
I'm aware of is the write protection pin, which protects the whole chip.

You talk about "the nand chip". Which chip is it exactly and what makes
you believe that it has a per page locking feature ?

tglx





From timm at ipi.ac.ru  Wed Apr 27 05:09:21 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Wed, 27 Apr 2005 13:09:21 +0400
Subject: nand locking
In-Reply-To: <1114592403.879.175.camel@tglx.tec.linutronix.de>
References: <426F40A3.8010308@ipi.ac.ru>
	<1114592403.879.175.camel@tglx.tec.linutronix.de>
Message-ID: <426F56C1.6020204@ipi.ac.ru>

Thomas Gleixner wrote:
> On Wed, 2005-04-27 at 11:34 +0400, Timofei V. Bondarenko wrote:
> 
>>Is there a straight way to lock/unlock nand pages?
>>
> 
> You talk about "the nand chip". Which chip is it exactly and what makes
> you believe that it has a per page locking feature ?

Samsung k9f5608u0c-d

http://www.samsung.com/Products/Semiconductor/Flash/NAND/256Mbit/K9F5608U0C/K9F5608U0C.htm

http://www.samsung.com/Products/Semiconductor/Flash/NAND/256Mbit/K9F5608U0C/ds_k9f5608u0c_rev32.pdf

See the 'Block Lock Mode' chapter.

Lock block: 2Ah
Unlock Block: 23h - start block - 24h - end block
Lock tight: 2Ch
Block Lock Status Read: 7Ah - block address

I'm really using that chip and could provide some code.
The chip is locked at power on.
So i'm checking the locking status at startup and then unlocking it
(using range of pages).

It would be nice to unlock the rw partitions only.
But it's weird a bit:
the mtd_partition may be incomplete before add_mtd_partitions() done.
After add_mtd_partitions() my startap code has no handle to actual 
partition info.
The mtd_partition.mtdp seems only choice, though it prevents partitions 
from registering...
So, could couple of lines in add_mtd_partitions() do that work?

BTW. Can I post patches to this list?
I've already sent one as attacment, but that message gets bounced
"awaits moderator approval".

Regards.
	Timofei.



From weth at inf.u-szeged.hu  Wed Apr 27 05:39:28 2005
From: weth at inf.u-szeged.hu (Zoltan Sogor)
Date: Wed, 27 Apr 2005 11:39:28 +0200
Subject: mounting jffs2
In-Reply-To: <426E4745.5050606@oktetlabs.ru>
References: <loom.20050413T142519-107@post.gmane.org>	<425E3174.4030308@inf.u-szeged.hu>	<Pine.LNX.4.58.0504141014400.3328@phoenix.infradead.org>	<loom.20050420T165531-253@post.gmane.org>	<4267B8EF.6000803@inf.u-szeged.hu>
	<1114097490.21485.1.camel@sauron.oktetlabs.ru>
	<426E439A.2050301@inf.u-szeged.hu> <426E4745.5050606@oktetlabs.ru>
Message-ID: <426F5DD0.8050008@inf.u-szeged.hu>

Hello Artem!

Artem B. Bityuckiy wrote:

> Hello Zoltan,
>
>> Read:
>> If you want to read an inode then the kernel calls jffs2_do_read_inode()
>> to get the inode.
>
> But if I don't want? There are thousands of inodes and I don't have to 
> read them all. What then? Will GC move dirt along with valid data? 
> Will I see fewer free space then there is actually present? I suppose 
> yes and this is incorrect.
>
In this point of view I think you are right! The nocrc option is
incorrect and it will be removed from our summary patch.

But ... :)

We are developing a new technologic solution for faster mount. The name
of the solution is Centralized Summary. It stores summary information
from the whole flash in contrast to summary (Erase Block Summary). It
can cooperate with summary for fast recover after powerloss.

Zoltan




From tglx at linutronix.de  Wed Apr 27 06:45:06 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 27 Apr 2005 12:45:06 +0200
Subject: nand locking
In-Reply-To: <426F56C1.6020204@ipi.ac.ru>
References: <426F40A3.8010308@ipi.ac.ru>
	<1114592403.879.175.camel@tglx.tec.linutronix.de>
	<426F56C1.6020204@ipi.ac.ru>
Message-ID: <1114598706.879.185.camel@tglx.tec.linutronix.de>

On Wed, 2005-04-27 at 13:09 +0400, Timofei V. Bondarenko wrote:
> Thomas Gleixner wrote:
> See the 'Block Lock Mode' chapter.
> 
> Lock block: 2Ah
> Unlock Block: 23h - start block - 24h - end block
> Lock tight: 2Ch
> Block Lock Status Read: 7Ah - block address

Ah, I see. Yes I remember that I have seen that before, but I was
puzzled by your per page locking question :)

> It would be nice to unlock the rw partitions only.
> But it's weird a bit:
> the mtd_partition may be incomplete before add_mtd_partitions() done.
> After add_mtd_partitions() my startap code has no handle to actual 
> partition info.
> The mtd_partition.mtdp seems only choice, though it prevents partitions 
> from registering...
> So, could couple of lines in add_mtd_partitions() do that work?

I'm not quite understanding, what your problem is.

Lock/unlock are general features and should be added to nand_base.c.
I guess the chips which have those functions can be identified and an
appropriate option flag set in the ID list, which then lets nand_scan
decide whether to fill in the lock/unlock function pointers or not.

> BTW. Can I post patches to this list?

Yes

> I've already sent one as attacment, but that message gets bounced
> "awaits moderator approval".

Thats list policy. Attachments have to be approved

tglx





From timm at ipi.ac.ru  Wed Apr 27 06:27:41 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Wed, 27 Apr 2005 14:27:41 +0400
Subject: nand locking
In-Reply-To: <1114598706.879.185.camel@tglx.tec.linutronix.de>
References: <426F40A3.8010308@ipi.ac.ru>	
	<1114592403.879.175.camel@tglx.tec.linutronix.de>	
	<426F56C1.6020204@ipi.ac.ru>
	<1114598706.879.185.camel@tglx.tec.linutronix.de>
Message-ID: <426F691D.50905@ipi.ac.ru>

Thomas Gleixner wrote:
>>It would be nice to unlock the rw partitions only.
>>But it's weird a bit:
>>the mtd_partition may be incomplete before add_mtd_partitions() done.
>>After add_mtd_partitions() my startap code has no handle to actual 
>>partition info.
>>The mtd_partition.mtdp seems only choice, though it prevents partitions 
>>from registering...
>>So, could couple of lines in add_mtd_partitions() do that work?
> 
> 
> I'm not quite understanding, what your problem is.
> 
> Lock/unlock are general features and should be added to nand_base.c.
> I guess the chips which have those functions can be identified and an
> appropriate option flag set in the ID list, which then lets nand_scan
> decide whether to fill in the lock/unlock function pointers or not.

An easy problem: I'm looking for the simplest way to protect
read-only mtd partitions by hardware lock.
The current nand_base seems lack of this feature.
Should i hack the nand_base? Or is there a correct workaround?

>>I've already sent one as attacment, but that message gets bounced
>>"awaits moderator approval".
> 
> Thats list policy. Attachments have to be approved

It awaits since 18 Apr - longer than a week... is it ok?
Are there other ways to submit a patch? (a small bugfix to cmdlinepart).
AFAIK, placing diffs into message text is not welcomed too.

Thanks.
	Timofei.



From dedekind at yandex.ru  Wed Apr 27 06:32:17 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Wed, 27 Apr 2005 14:32:17 +0400
Subject: nand locking
In-Reply-To: <426F691D.50905@ipi.ac.ru>
References: <426F40A3.8010308@ipi.ac.ru>		<1114592403.879.175.camel@tglx.tec.linutronix.de>		<426F56C1.6020204@ipi.ac.ru>	<1114598706.879.185.camel@tglx.tec.linutronix.de>
	<426F691D.50905@ipi.ac.ru>
Message-ID: <426F6A31.4010000@yandex.ru>

Timofei V. Bondarenko wrote:
  > It awaits since 18 Apr - longer than a week... is it ok?
> Are there other ways to submit a patch? (a small bugfix to cmdlinepart).
> AFAIK, placing diffs into message text is not welcomed too.

Insert the patch to the mail body then.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From tglx at linutronix.de  Wed Apr 27 07:35:47 2005
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 27 Apr 2005 13:35:47 +0200
Subject: nand locking
In-Reply-To: <426F691D.50905@ipi.ac.ru>
References: <426F40A3.8010308@ipi.ac.ru>
	<1114592403.879.175.camel@tglx.tec.linutronix.de>
	<426F56C1.6020204@ipi.ac.ru>
	<1114598706.879.185.camel@tglx.tec.linutronix.de>
	<426F691D.50905@ipi.ac.ru>
Message-ID: <1114601747.879.199.camel@tglx.tec.linutronix.de>

On Wed, 2005-04-27 at 14:27 +0400, Timofei V. Bondarenko wrote:
> > Lock/unlock are general features and should be added to nand_base.c.
> > I guess the chips which have those functions can be identified and an
> > appropriate option flag set in the ID list, which then lets nand_scan
> > decide whether to fill in the lock/unlock function pointers or not.
> 
> An easy problem: I'm looking for the simplest way to protect
> read-only mtd partitions by hardware lock.
> The current nand_base seems lack of this feature.
> Should i hack the nand_base? Or is there a correct workaround?

As I said above, it is functionality which should be integrated cleanly
into nand_base.c. It should be automatically available for those chips
which support it.

There is no workaround. Its missing and must be added. I'm happy if you
can provide a patch.

> It awaits since 18 Apr - longer than a week... is it ok?

David Woodhouse was travelling last week

> Are there other ways to submit a patch? (a small bugfix to cmdlinepart).
> AFAIK, placing diffs into message text is not welcomed too.

It's a correct way to do it, when your mail client can handle the
whitespace (tabs) correct and does no line truncating at 80, which is
requested for the mail text itself.

tglx





From timm at ipi.ac.ru  Wed Apr 27 07:03:54 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Wed, 27 Apr 2005 15:03:54 +0400
Subject: misaligned memory access in cmdlinepart.c
Message-ID: <426F719A.2000903@ipi.ac.ru>

Hi,

in mtdpart_setup_real()/newpart() command line parser
'this_mtd' structure can be misaligned,
it may cause exception on some kind of CPU.

That happened because the structure allocated in a variable length area 
and got mixed with partition names.

The patch follows.

Regards.
	Timofei.

--- cmdlinepart.c	2005-04-18 18:06:43.000000000 +0400
+++ linux-2.6.x/drivers/mtd/cmdlinepart.c	2005-04-18 18:40:02.971778640 
+0400
@@ -234,12 +234,14 @@ static int mtdpart_setup_real(char *s)
  		 * parse one mtd. have it reserve memory for the
  		 * struct cmdline_mtd_partition and the mtd-id string.
  		 */
+#define THIS_MTD_ALIGN_CONST (sizeof(void*)-1)
  		parts = newpart(p + 1,		/* cmdline */
  				&s,		/* out: updated cmdline ptr */
  				&num_parts,	/* out: number of parts */
  				0,		/* first partition */
  				(unsigned char**)&this_mtd, /* out: extra mem */
-				mtd_id_len + 1 + sizeof(*this_mtd));
+				mtd_id_len + 1 + sizeof(*this_mtd) +
+                                THIS_MTD_ALIGN_CONST);
  		if(!parts)
  		{
  			/*
@@ -252,7 +254,11 @@ static int mtdpart_setup_real(char *s)
  			 return 0;
  		 }

-		/* enter results */	
+		/* align this_mtd */
+                this_mtd = (struct cmdline_mtd_partition *)
+                  (~THIS_MTD_ALIGN_CONST &
+                    THIS_MTD_ALIGN_CONST + (unsigned long)(char*)this_mtd);
+		/* enter results */
  		this_mtd->parts = parts;
  		this_mtd->num_parts = num_parts;
  		this_mtd->mtd_id = (char*)(this_mtd + 1);



From timm at ipi.ac.ru  Wed Apr 27 07:19:54 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Wed, 27 Apr 2005 15:19:54 +0400
Subject: nand locking
In-Reply-To: <1114601747.879.199.camel@tglx.tec.linutronix.de>
References: <426F40A3.8010308@ipi.ac.ru>	<1114592403.879.175.camel@tglx.tec.linutronix.de>	<426F56C1.6020204@ipi.ac.ru>	<1114598706.879.185.camel@tglx.tec.linutronix.de>	<426F691D.50905@ipi.ac.ru>
	<1114601747.879.199.camel@tglx.tec.linutronix.de>
Message-ID: <426F755A.5030304@ipi.ac.ru>

Thomas Gleixner wrote:
> 
> There is no workaround. Its missing and must be added. I'm happy if you
> can provide a patch.

Unfortunately, I have no sufficient expirience with nand devices to make
such patch generic enough.


	Timofei.



From jaredeh at gmail.com  Wed Apr 27 12:01:31 2005
From: jaredeh at gmail.com (Jared Hulbert)
Date: Wed, 27 Apr 2005 09:01:31 -0700
Subject: DEBUG_LOCK_BITS fix for Intel NOR flash
In-Reply-To: <20050422195324.GA12115@slurryseal.ddns.mvista.com>
References: <20050422195324.GA12115@slurryseal.ddns.mvista.com>
Message-ID: <6934efce05042709017bb77d95@mail.gmail.com>

On 4/22/05, Todd Poynor <tpoynor at mvista.com> wrote:
> This patch seems to correctly access block lock status bits for at least
> one Intel StrataFlash model.  Without at least half of this patch (the
> chip->start adjustment), DEBUG_LOCK_BITS won't work well with
> multi-partition flash, at the least.
> 
> I also needed to change the code to follow the flowchart given in a
> recent StrataFlash datasheet: write command 0x90 followed by the block
> address + 2, then read block address + 2.  The old code writes command
> 0x90 followed by hardcoded address 0x55, then reads block address + 2.
> 
> Can anybody verify whether Intel flash models exist that require the
> 0x55 address for block lock query?  If so, know of any way to
> distinguish the two cases?
> 
> Absent any dissent this patch will go into CVS.  (Why all the concern
> over a debug feature?  Because I want to also write code to query lock
> status for other reasons.)  Thanks -- Todd
> 
> Index: linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c
> ===================================================================
> --- linux-mtd.orig/drivers/mtd/chips/cfi_cmdset_0001.c  2005-04-22 19:15:05.000000000 +0000
> +++ linux-mtd/drivers/mtd/chips/cfi_cmdset_0001.c       2005-04-22 19:39:12.000000000 +0000
> @@ -1823,8 +1823,9 @@
>         struct cfi_private *cfi = map->fldrv_priv;
>         int status, ofs_factor = cfi->interleave * cfi->device_type;
> 
> +       adr += chip->start;
>         xip_disable(map, chip, adr+(2*ofs_factor));
> -       cfi_send_gen_cmd(0x90, 0x55, 0, map, cfi, cfi->device_type, NULL);
> +       map_write(map, CMD(0x90), adr+(2*ofs_factor));
>         chip->state = FL_JEDEC_QUERY;
>         status = cfi_read_query(map, adr+(2*ofs_factor));
>         xip_enable(map, chip, 0);
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Not sure where the 0x55 came from.  This code looks generic enough to
work for multi and single partition Intel flash.



From tpoynor at mvista.com  Wed Apr 27 14:27:09 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Wed, 27 Apr 2005 11:27:09 -0700
Subject: nand locking
In-Reply-To: <426F56C1.6020204@ipi.ac.ru>
References: <426F40A3.8010308@ipi.ac.ru>	<1114592403.879.175.camel@tglx.tec.linutronix.de>
	<426F56C1.6020204@ipi.ac.ru>
Message-ID: <426FD97D.9000105@mvista.com>

Timofei V. Bondarenko wrote:

> It would be nice to unlock the rw partitions only.
> But it's weird a bit:
> the mtd_partition may be incomplete before add_mtd_partitions() done.
> After add_mtd_partitions() my startap code has no handle to actual 
> partition info.
> The mtd_partition.mtdp seems only choice, though it prevents partitions 
> from registering...
> So, could couple of lines in add_mtd_partitions() do that work?

If I understand correctly, it may be the same issue I ran into on Intel 
NOR flash: the chip driver (which may have the knowledge of whether the 
particular chips are locked or lockable) gets to see the "whole device" 
struct mtd_info at probe time, but doesn't see the "partition" structs 
registered later via add_mtd_partitions(), which have the per-partition 
r/w flags.

I tried adding a callback to the chip driver at each device/partition 
add (see first patch attempt in recent "Fixup Intel flash that powers up 
locked" thread).  But I believe that was part of what was (justifiably) 
deemed messy about the patch.

So far the general verdict on these flashes that power up locked seems 
to be either leave all blocks locked or unlock all blocks (either in the 
bootloader or at flash probe time), and let custom code in userspace 
lock/unlock what is needed.  I do like the idea of the kernel rectifying 
lock status with the map flags myself, though...

-- 
Todd



From timm at ipi.ac.ru  Thu Apr 28 03:00:15 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Thu, 28 Apr 2005 11:00:15 +0400
Subject: nand locking
In-Reply-To: <426FD97D.9000105@mvista.com>
References: <426F40A3.8010308@ipi.ac.ru>	<1114592403.879.175.camel@tglx.tec.linutronix.de>
	<426F56C1.6020204@ipi.ac.ru> <426FD97D.9000105@mvista.com>
Message-ID: <427089FF.4020704@ipi.ac.ru>

Todd Poynor wrote:
> Timofei V. Bondarenko wrote:
> 
>> It would be nice to unlock the rw partitions only.
>> After add_mtd_partitions() my startap code has no handle to actual 
>> partition info.
>> The mtd_partition.mtdp seems only choice, though it prevents 
>> partitions from registering...
>> So, could couple of lines in add_mtd_partitions() do that work?
> 
> If I understand correctly, it may be the same issue I ran into on Intel 
> NOR flash: the chip driver (which may have the knowledge of whether the 
> particular chips are locked or lockable) gets to see the "whole device" 
> struct mtd_info at probe time, but doesn't see the "partition" structs 
> registered later via add_mtd_partitions(), which have the per-partition 
> r/w flags.

Yes, exactly.

> I tried adding a callback to the chip driver at each device/partition 
> add (see first patch attempt in recent "Fixup Intel flash that powers up 
> locked" thread).  But I believe that was part of what was (justifiably) 
> deemed messy about the patch.

Do you mean 'mtd_info::notify_add' ?
I've mentioned the 'mtd_partition::mtdp' - it could be an alternative
(a bit complicated though). The register_mtd_user() also may help...

> So far the general verdict on these flashes that power up locked seems 
> to be either leave all blocks locked or unlock all blocks (either in the 
> bootloader or at flash probe time), and let custom code in userspace 
> lock/unlock what is needed.  I do like the idea of the kernel rectifying 
> lock status with the map flags myself, though...

I'm not complaining about.

--
	Timofei



From olsombergs at elvismen.com  Thu Apr 28 07:22:33 2005
From: olsombergs at elvismen.com (olsombergs)
Date: Thu, 28 Apr 2005 20:22:33 +0900
Subject: YUKOS OIL
Message-ID: <38e96947772f13bed72879ad81f788aa@elvismen.com>

Dear Friend,


I am Mr Olsom Berghart a personal treasurer to Mikhail Khodorkovsky the
richest man in Russia and owner of the following companies:Chairman 
CEO:
YUKOS OIL (Russian Most Largest Oil Company)Chairman CEO: Menatep SBP 
Bank
(A well reputable financial institution with its 
branches
all over the world)
SOURCE OF FUNDS:
I have a profiling amount in an excess of US$100.5M, which I seek your
partnership in accommodating for me. You will be rewarded with 4% of 
the
total sum for your partnership. Can you be my partner on this?  
INTRODUCTION OF MY SELF
As a personal consultant to him, authority was handed over to me in 
transfer
of money of an American oil merchant for his last oil deal with my boss
Mikhail Khodorkovsky. Already the funds have left the shore of Russia 
to an
European private bank where the final
crediting is expected to be carried out. While I was on the process, My 
Boss
got arrested for his involvement in politics by financing the leading 
and
opposing political parties (the Union of Right Forces,
led by Boris Nemtsov, and Yabloko, a liberal/social democratic party 
led by
Gregor Yavlinsky) which poses treat to President Vladimir Putin second
tenure as Russian president. You can catch more of the story on this
website: http://www.opendemocracy.net/debates/article-3-56-1409.jspor
http://newsfromrussia.com/main/2003/11/13/51215.html  
YOUR ROLE:
All I need from you is to stand as the beneficiary of the above quoted 
sum
and I will re-profile the funds with your name, which will enable the
European bank transfer the sum to you. I have decided to use this sum 
to
relocate to American continent and never to be connected to any 
of
Mikhail Khodorkovsky conglomerates. The transaction has to be concluded 
in 2
weeks before Mikhail Khodorkovsky is out on bail. As
soon as I confirm your readiness to conclude the transaction with me, I 
will
provide you with the details.
Thank you very much
 
Regards

Olsom Berghart(Mr)

NB: Do contact me through this secure email olsom_bergs_111 at yahoo.fr




From davidelis at walla.com  Thu Apr 28 11:53:33 2005
From: davidelis at walla.com (davidelis)
Date: Thu, 28 Apr 2005 22:53:33 +0700
Subject: God Mercy!!!!
Message-ID: <200504281553.j3SFrX001314@w3s1.websitethailand.com>


Hello, 

My name is DAVID ELLIS, a nationality of United Kingdom,I
have been diagnosed with Esophageal cancer .It has defiled all
forms of medical treatment, andright now I have only about a few months to live, according to medical experts.I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and onlyfocused  on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world.I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. 

Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends.I want God to be merciful to me and accept my soul so, I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have
distributed money to some charity organizations in the U.A.E, Somalia and Malaysia.Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which no one knows of is the huge cash deposit of Twenty Eight Million
dollars($28,000,000,00) that I have with a finance/Security Company
abroad. I will want you to help me collect this deposit and despatch it
to charity organizations.
 
 
 I have set aside 20% for you and for your time.
 
 God be with you.


DAVID ELLIS



___________________________________________________________________________
Mail sent from WebMail service at PHP-Nuke Powered Site
- http://yoursite.com



From temoc at didtec.com.mx  Thu Apr 28 15:38:51 2005
From: temoc at didtec.com.mx (Cuauhtemoc Covarrubias Carranza)
Date: Thu, 28 Apr 2005 14:38:51 -0500
Subject: pxa263 flash memory (Strataflash K3)
Message-ID: <42713BCB.8080107@didtec.com.mx>

Hi,
We are developing a PDA using Intel's PXA263 which contains K3 flash 
memory. I'm using kernel 2.4.19-rmk7-pxa2

The problem is the following:
After powerup, any operation on the flash partitions (unlock, erase, 
mount) finishes with a timeout, but only if the partition already has 
data (i.e. if the partition is blank, all operations are completed ok).

I believe there is because I have a buggy K3.
Is there a patch for this kernel version who resolves this issue? or 
what kernel version must be used?

Thanks

-- 
--
Cuauhtemoc Covarrubias
Hardware Design Engineer
Dise?o y Desarrollo Tecnologico, S.C.
Tel./Fax +52 33 3126 0861
temoc at didtec.com.mx

--
Esta comunicaci?n es confidencial y dirigida solamente para el
destinatario. Se proh?be cualquier revisi?n, uso, acceso o distribuci?n
no autorizada. Si usted cree que este mensaje se le ha enviado por error,
notificar por favor el remitente contestando a esta transmisi?n y borrar
este mensaje sin divulgarlo. Gracias.

Los correos electr?nicos que incluyen archivos adjuntos, son susceptibles
a la corrupci?n de informaci?n, interrupci?n o enmiendas no autorizadas,
falsificaci?n y virus, por lo tanto nosotros solamente enviamos y recibimos
correos electr?nicos bajo la base de que no somos responsables por ning?n
tipo de corrupci?n, enmienda, intercepci?n, falsificaci?n o virus o por
cualquier consecuencia derivada de lo anterior.
----------------------------------------------------------------------------
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please
request a hard-copy version.




From dedekind at yandex.ru  Fri Apr 29 02:44:39 2005
From: dedekind at yandex.ru (Artem B. Bityuckiy)
Date: Fri, 29 Apr 2005 10:44:39 +0400
Subject: pxa263 flash memory (Strataflash K3)
In-Reply-To: <42713BCB.8080107@didtec.com.mx>
References: <42713BCB.8080107@didtec.com.mx>
Message-ID: <4271D7D7.1070801@yandex.ru>

 >This message contains confidential information and is intended only for
 >the individual named. If you are not the named addressee you should not
 >disseminate, distribute or copy this e-mail.

Probably it is illegal to answer to such mails.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.



From tozyagcilar at gmail.com  Fri Apr 29 10:15:27 2005
From: tozyagcilar at gmail.com (Talat Ozyagcilar)
Date: Fri, 29 Apr 2005 10:15:27 -0400
Subject: mtd erase error
Message-ID: <57258408050429071549faab15@mail.gmail.com>

Hi All,

I am trying to write a rootfs on flash.  I have made an jffs2 image of
the rootfs and I am using "cat rootfs.jffs2 > /dev/mtdblock/3", but I
am getting the following output:
----------------------------------------------------------
# cat rootfs.jffs2 > /dev/mtdblock/3
mtdblock_open
ok
mtdblock: read on "RootFS" at 0x282000, size 0x1000
mtdblock: write on "RootFS" at 0x0, size 0x1000
mtdblock: write on "RootFS" at 0x1000, size 0x1000
mtdblock: write on "RootFS" at 0x2000, size 0x1000
mtdblock: write on "RootFS" at 0x3000, size 0x1000
mtdblock: write on "RootFS" at 0x4000, size 0x1000
mtdblock: write on "RootFS" at 0x5000, size 0x1000
mtdblock: write on "RootFS" at 0x6000, size 0x1000
mtdblock: write on "RootFS" at 0x7000, size 0x1000
mtdblock: write on "RootFS" at 0x8000, size 0x1000
mtdblock: write on "RootFS" at 0x9000, size 0x1000
mtdblock: write on "RootFS" at 0xa000, size 0x1000
mtdblock: write on "RootFS" at 0xb000, size 0x1000
mtdblock: write on "RootFS" at 0xc000, size 0x1000
mtdblock: write on "RootFS" at 0xd000, size 0x1000
mtdblock: write on "RootFS" at 0xe000, size 0x1000
mtdblock: write on "RootFS" at 0xf000, size 0x1000
mtdblock: write on "RootFS" at 0x10000, size 0x1000
mtdblock: write on "RootFS" at 0x11000, size 0x1000
mtdblock: write on "RootFS" at 0x12000, size 0x1000
mtdblock: write on "RootFS" at 0x13000, size 0x1000
mtdblock: write on "RootFS" at 0x14000, size 0x1000
mtdblock: write on "RootFS" at 0x15000, size 0x1000
mtdblock: write on "RootFS" at 0x16000, size 0x1000
mtdblock: write on "RootFS" at 0x17000, size 0x1000
mtdblock: write on "RootFS" at 0x18000, size 0x1000
mtdblock: write on "RootFS" at 0x19000, size 0x1000
mtdblock: write on "RootFS" at 0x1a000, size 0x1000
mtdblock: write on "RootFS" at 0x1b000, size 0x1000
mtdblock: write on "RootFS" at 0x1c000, size 0x1000
mtdblock: write on "RootFS" at 0x1d000, size 0x1000
mtdblock: write on "RootFS" at 0x1e000, size 0x1000
mtdblock: write on "RootFS" at 0x1f000, size 0x1000
mtdblock: write on "RootFS" at 0x20000, size 0x1000
mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
Chip reports voltage low on erase: status 0xa8
mtdblock: erase of region [0x0, 0x20000] on "RootFS" failed
end_request: I/O error, dev 1f:03 (mtdblock), sector 256
mtdblock: write on "RootFS" at 0x21000, size 0x1000
mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
Chip reports voltage low on erase: status 0xa8
mtdblock: erase of region [0x0, 0x20000] on "RootFS" failed
end_request: I/O error, dev 1f:03 (mtdblock), sector 264
mtdblock: write on "RootFS" at 0x22000, size 0x1000
mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
Chip reports voltage low on erase: status 0xa8
mtdblock: erase of region [0x0, 0x20000] on "RootFS" failed
end_request: I/O error, dev 1f:03 (mtdblock), sector 272
mtdblock: write on "RootFS" at 0x23000, size 0x1000
mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
Chip reports voltage low on erase: status 0xa8
mtdblock: erase of region [0x0, 0x20000] on "RootFS" failed
end_request: I/O error, dev 1f:03 (mtdblock), sector 280
mtdblock: write on "RootFS" at 0x24000, size 0x1000
mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
Chip reports voltage low on erase: status 0xa8
mtdblock: erase of region [0x0, 0x20000] on "RootFS" failed
end_request: I/O error, dev 1f:03 (mtdblock), sector 288
mtdblock: write on "RootFS" at 0x25000, size 0x1000
mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
Chip reports voltage low on erase: status 0xa8
mtdblock: erase of region [0x0, 0x20000] on "RootFS" failed
end_request: I/O error, dev 1f:03 (mtdblock), sector 296
mtdblock: write on "RootFS" at 0x26000, size 0x1000
------------------------------------------------------

Is this really a hardware problem, or has anybody come across this? 
Any help is appreciated...

Regards



From sergei.sharonov at halliburton.com  Fri Apr 29 10:30:27 2005
From: sergei.sharonov at halliburton.com (Sergei Sharonov)
Date: Fri, 29 Apr 2005 14:30:27 +0000 (UTC)
Subject: summary patch
Message-ID: <loom.20050429T162520-770@post.gmane.org>

Hi,

after applying summary patch I start getting messages like:

JFFS2: not enough space for summary, padsize = -530
JFFS2: not enough space for summary, padsize = -199
JFFS2: not enough space for summary, padsize = -992
JFFS2: not enough space for summary, padsize = -127

Is that a note, a warning or an error?
kernel 2.6.10 with March 28th 2005 mtd snapshot.

Sergei Sharonov




From temoc at didtec.com.mx  Fri Apr 29 11:41:05 2005
From: temoc at didtec.com.mx (Cuauhtemoc Covarrubias Carranza)
Date: Fri, 29 Apr 2005 10:41:05 -0500
Subject: pxa263 flash memory (Strataflash K3)
In-Reply-To: <4271D7D7.1070801@yandex.ru>
References: <42713BCB.8080107@didtec.com.mx> <4271D7D7.1070801@yandex.ru>
Message-ID: <42725591.8010405@didtec.com.mx>

Artem B. Bityuckiy wrote:

> >This message contains confidential information and is intended only for
> >the individual named. If you are not the named addressee you should not
> >disseminate, distribute or copy this e-mail.
>
> Probably it is illegal to answer to such mails.
>
Please accept my apologies, the disclaimer was included on a mistake, 
please ignore it.

-- 
--
Cuauhtemoc Covarrubias Carranza
Hardware Design Engineer
Dise?o y Desarrollo Tecnologico, S.C.
Tel./Fax +52 33 3126 0861
temoc at didtec.com.mx






From anhmn at yahoo.com  Fri Apr 29 17:24:10 2005
From: anhmn at yahoo.com (Sam Pham)
Date: Fri, 29 Apr 2005 14:24:10 -0700 (PDT)
Subject: mtd emulation
Message-ID: <20050429212410.49709.qmail@web54109.mail.yahoo.com>

I'd like to evaluate JFFS2.  Has anyone done this
before?  Does linux have the capability of emulating
mtd block device and mtd memory so that I can run
JFFS2 on top of it without using the actual flash?

Thanks.

Sam

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From ralphs at netwinder.org  Fri Apr 29 17:49:51 2005
From: ralphs at netwinder.org (Ralph Siemsen)
Date: Fri, 29 Apr 2005 17:49:51 -0400
Subject: mtd emulation
In-Reply-To: <20050429212410.49709.qmail@web54109.mail.yahoo.com>
References: <20050429212410.49709.qmail@web54109.mail.yahoo.com>
Message-ID: <4272ABFF.7070709@netwinder.org>

Sam Pham wrote:
> I'd like to evaluate JFFS2.  Has anyone done this
> before?  Does linux have the capability of emulating
> mtd block device and mtd memory so that I can run
> JFFS2 on top of it without using the actual flash?

I believe you can use MTD_MTDRAM for this.  There are a few associated 
parameters (total size, erase block size) to be fiddled as well.  See 
the the file linux-2.6.x/drivers/mtd/devices/mtdram.c

-R




From tpoynor at mvista.com  Fri Apr 29 18:00:57 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Fri, 29 Apr 2005 15:00:57 -0700
Subject: mtd erase error
In-Reply-To: <57258408050429071549faab15@mail.gmail.com>
References: <57258408050429071549faab15@mail.gmail.com>
Message-ID: <4272AE99.6090008@mvista.com>

Talat Ozyagcilar wrote:
...
> mtdblock: writing cached data for "RootFS" at 0x0, size 0x20000
> Chip reports voltage low on erase: status 0xa8
...
> Is this really a hardware problem, or has anybody come across this? 

It means the driver for the chip's connection to your board (probably) 
isn't raising the voltage to the proper level (called VPP in the mtd 
code) required by the chip for an erase operation.  Various code paths 
can nest VPP enables/disables in unbalanced ways, often causing 
problems.  If this is the case in your situation, info in
http://lists.infradead.org/pipermail/linux-mtd/2005-January/011517.html
may help.

-- 
Todd



From tpoynor at mvista.com  Fri Apr 29 18:19:28 2005
From: tpoynor at mvista.com (Todd Poynor)
Date: Fri, 29 Apr 2005 15:19:28 -0700
Subject: nand locking
In-Reply-To: <427089FF.4020704@ipi.ac.ru>
References: <426F40A3.8010308@ipi.ac.ru>	<1114592403.879.175.camel@tglx.tec.linutronix.de>
	<426F56C1.6020204@ipi.ac.ru> <426FD97D.9000105@mvista.com>
	<427089FF.4020704@ipi.ac.ru>
Message-ID: <4272B2F0.3090803@mvista.com>

Timofei V. Bondarenko wrote:
> Todd Poynor wrote:
...
>> I tried adding a callback to the chip driver at each device/partition 
>> add...
> 
> 
> Do you mean 'mtd_info::notify_add' ?

Yes.

> I've mentioned the 'mtd_partition::mtdp' - it could be an alternative
> (a bit complicated though). The register_mtd_user() also may help...

I originally tried the register_mtd_user() route, but in the case of 
partitions it is passed the "slave" struct mtd_info, while only the 
"master" whole-device struct has been filled in with chip-driver-private 
info (and only mtdpart.c knows how to map the slave back to the master), 
so that would need some ugly tweaks as well...

-- 
Todd



From bunk at stusta.de  Mon Apr 11 17:07:11 2005
From: bunk at stusta.de (Adrian Bunk)
Date: Mon, 11 Apr 2005 21:07:11 -0000
Subject: 2.6.12-rc2-mm3: CONFIG_MODULES=n MTD compile error
In-Reply-To: <20050411012532.58593bc1.akpm@osdl.org>
References: <20050411012532.58593bc1.akpm@osdl.org>
Message-ID: <20050411210507.GC5863@stusta.de>

On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc2-mm2:
>...
> +remove-inter-module-mtd.patch
> 
>  Remove intermodule_foo() usage from mtd.
>...

This breaks the compilation with CONFIG_MODULES=n:

<--  snip  -->

...
  CC      drivers/mtd/devices/docprobe.o
drivers/mtd/devices/docprobe.c: In function `DoC_Probe':
drivers/mtd/devices/docprobe.c:311: warning: implicit declaration of 
function `__symbol_get'
drivers/mtd/devices/docprobe.c:311: warning: assignment makes pointer 
from integer without a cast
drivers/mtd/devices/docprobe.c:315: warning: implicit declaration of function `__symbol_put'
...
  LD      .tmp_vmlinux1
drivers/built-in.o(.init.text+0x60f20): In function `DoC_Probe':
: undefined reference to `__symbol_get'
drivers/built-in.o(.init.text+0x60f3b): In function `DoC_Probe':
: undefined reference to `__symbol_put'
drivers/built-in.o(.init.text+0x610a4): In function `DoC_Probe':
: undefined reference to `__symbol_get'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




From aia21 at cam.ac.uk  Mon Apr 18 09:38:24 2005
From: aia21 at cam.ac.uk (Anton Altaparmakov)
Date: Mon, 18 Apr 2005 13:38:24 -0000
Subject: ntfs ->iput use - was: Re: [PATC] small VFS change for JFFS2
In-Reply-To: <1113829708.5286.30.camel@localhost.localdomain>
References: <1113814031.31595.3.camel@sauron.oktetlabs.ru>
	<20050418085121.GA19091@infradead.org>
	<1113814730.31595.6.camel@sauron.oktetlabs.ru>
	<20050418105301.GA21878@infradead.org>
	<1113824781.2125.12.camel@sauron.oktetlabs.ru>
	<20050418115220.GA22750@infradead.org>
	<1113827466.2125.47.camel@sauron.oktetlabs.ru>
	<20050418124656.GA23387@infradead.org>
	<1113829708.5286.30.camel@localhost.localdomain>
Message-ID: <1113831474.13640.2.camel@imp.csi.cam.ac.uk>

Hi Christoph,

If you remember you complained about ntfs' "fishy use of iput"?

I think that David's explanation below is exactly the reason why I had
to do it IIRC...  So if the vfs is fixed so the below can _never_ happen
anymore then I believe it would be safe to do as you and Al suggest and
stop using iput in a "fishy" way in ntfs...

Best regards,

	Anton

On Mon, 2005-04-18 at 23:08 +1000, David Woodhouse wrote:
> On Mon, 2005-04-18 at 13:46 +0100, Christoph Hellwig wrote:
> > Any, this sounds like you'd want to use ilookup because you don't want
> > to read the inode in the cache anyway, right?
> 
> We use ilookup() in some circumstances -- if the inode has zero nlink
> and hence we definitely don't want to pull it back again if it's gone.
> 
> But sometimes we really do mean to use iget() to bring it into core. And
> it's in that case that I believe Artem has found the problem, because if
> I understand correctly he's still seeing two consecutive calls to
> read_inode() for the same inode, without a clear_inode() in between.
> 
> prune_icache() is removing the inode from i_hash at line 457 of inode.c,
> then being preempted when it drops the inode_lock at line 464, which is
> _before_ it calls dispose_list() to actually get rid of the inode(s) in
> question. So when iget() is called, the VFS ends up calling read_inode()
> again instead of waiting for the original inode to finish going away.

-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/




From timm at ipi.ac.ru  Mon Apr 18 11:30:42 2005
From: timm at ipi.ac.ru (Timofei V. Bondarenko)
Date: Mon, 18 Apr 2005 15:30:42 -0000
Subject: Bug: misaligned memory access in cmdlinepart.c
Message-ID: <4263D29B.704@ipi.ac.ru>

Hi,

in mtdpart_setup_real()/newpart() command line parser
'this_mtd' structure can be misaligned,
it may cause exception on some kind of CPU.

That happened because the structure got mixed with partition names 
allocated in a variable length area.

I've attached a simle patch, not very elegant though.

Regards.
	Timofei.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alignnewpart.diff
Url: http://lists.infradead.org/pipermail/linux-mtd/attachments/20050418/588cebda/attachment.pl 

