daniel.haensse | 1 Oct 2003 07:43
Picon

JFFS2 MTD NAND with two banks

Hi list,

Jffs2 is usable now on our small platform with a 68vz328 (Thanks David for the 
kind support). 

A 32MB Flash chip is mounted within 37 seconds.

Now I would like to add the smart media slot on our board. After reading the 
nand tech document, I still do not understand how to access the smart media 
chip. We use two chips (NAND flash and Smart Media Card)  to share the ALE 
and CLE lines. So how must I adapt the your_hwcontrol mechanism or  do I need 
to write a second independing driver (how could I handle concurrent access in 
that case).

Thanks a lot

regards

Dani

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com

David Woodhouse | 1 Oct 2003 09:16
Favicon

Re: JFFS2 MTD NAND with two banks

On Wed, 2003-10-01 at 07:43 +0200, daniel.haensse <at> alumni.ethz.ch wrote:
> Hi list,
> 
> Jffs2 is usable now on our small platform with a 68vz328 (Thanks David for the 
> kind support). 
> 
> A 32MB Flash chip is mounted within 37 seconds.
> 
> Now I would like to add the smart media slot on our board. After reading the 
> nand tech document, I still do not understand how to access the smart media 
> chip. We use two chips (NAND flash and Smart Media Card)  to share the ALE 
> and CLE lines. So how must I adapt the your_hwcontrol mechanism or  do I need 
> to write a second independing driver (how could I handle concurrent access in 
> that case).

If you provide your own select_chip() function for each chip, then it
can do mutual exclusion and allow only one to be accessed at a time.

--

-- 
dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo <at> axis.com

David Woodhouse | 9 Oct 2003 09:10
Picon
Favicon

[ANNOUNCE] JFFS2 support for NAND flash..

I'm happy to announce that the JFFS2 support for NAND flash has finally
reached a state in which it can be considered sane to use it in
production.

Thanks to generous sponsorship from Texas Instruments, the final
difficult parts of the NAND flash support have now been implemented.

Those were, for those who weren't paying attention, the details of
flushing the write-behind buffer appropriately upon fsync(), sync() and
other stimuli, and the code to deal with _failure_ to write the
write-behind buffer -- recovering its contents and writing them out
elsewhere on the flash to avoid data loss.

Other bugs were also found and fixed in the process of testing, and the
CVS tree also now contains changes to the garbage-collector which affect
the way it merges data nodes, which should significantly improve its
progress. These should be of benefit even on NOR flash, and may well
allow us to reduce the free-block thresholds which people keep
complaining about.

While I'm fairly confident of the behaviour and it's been stress testing
both with and without simulated errors on a DiskOnChip on my desk for
the best part of a week now, it remains relatively new code and should
therefore be treated with respect. You are advised to undertake your own
testing under your own particular usage patterns.

In addition to Texas Instruments, who kindly paid Red Hat to lock me in
a room for a few weeks with the JFFS2 code, some NAND flash and a vat of
coffee, I should also mention the efforts of Thomas Gleixner, who has
done a lot of work on JFFS2/NAND too, and also on the NAND hardware
(Continue reading)

Kevin Liao | 9 Oct 2003 09:39
Picon

Re: [ANNOUNCE] JFFS2 support for NAND flash..

Congratulations and thanks a lot for all your effort! Does mtd-snapshot-20031008.tar.bz2 contains all thses?

Regards,
Kevin

----- Original Message ----- 
From: "David Woodhouse" <dwmw2 <at> redhat.com>
To: <jffs-dev <at> axis.com>; <linux-mtd <at> lists.infradead.org>; <etux <at> embeddedtux.org>
Sent: Thursday, October 09, 2003 3:10 PM
Subject: [ANNOUNCE] JFFS2 support for NAND flash..

> I'm happy to announce that the JFFS2 support for NAND flash has finally
> reached a state in which it can be considered sane to use it in
> production.
> 
> Thanks to generous sponsorship from Texas Instruments, the final
> difficult parts of the NAND flash support have now been implemented.
> 
> Those were, for those who weren't paying attention, the details of
> flushing the write-behind buffer appropriately upon fsync(), sync() and
> other stimuli, and the code to deal with _failure_ to write the
> write-behind buffer -- recovering its contents and writing them out
> elsewhere on the flash to avoid data loss.
> 
> Other bugs were also found and fixed in the process of testing, and the
> CVS tree also now contains changes to the garbage-collector which affect
> the way it merges data nodes, which should significantly improve its
> progress. These should be of benefit even on NOR flash, and may well
> allow us to reduce the free-block thresholds which people keep
> complaining about.
(Continue reading)

David Woodhouse | 9 Oct 2003 09:51
Picon
Favicon

Re: [ANNOUNCE] JFFS2 support for NAND flash..

On Thu, 2003-10-09 at 15:39 +0800, Kevin Liao wrote:
> Congratulations and thanks a lot for all your effort! Does mtd-snapshot-20031008.tar.bz2 contains all thses?

Thanks. No it doesn't, at least not entirely -- although all the NAND
wbuf handling has been there for a while, some of the tuning changes to
the GC were actually committed in the small hours of this morning. The
next snapshot will have it.

Your question was worth answering on all three lists; further followups
to only one please.

--

-- 
dwmw2

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

Ingo Flaschberger | 10 Oct 2003 05:13
Picon
Favicon

kmalloc jffs2_do_mount_fs

Hi

after 3 nights... debugging why my sharp zaurus do not boot from my
initrd.. i found:

kmalloc does not give you more than 128k (only i you "hack" it).
jffs2 with a filesystem about 40Mb need more when mounting..
to fix this.. i have luckily found a patch at the list:
http://lists.infradead.org/pipermail/linux-mtd/2002-December/006577.html

but why doe you not apply it to the source or warn because of this
"jffs2" problem???

thnx & bye, Ingo

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

David Woodhouse | 10 Oct 2003 07:46
Favicon

Re: kmalloc jffs2_do_mount_fs

On Fri, 2003-10-10 at 05:13 +0200, Ingo Flaschberger wrote:
> but why doe you not apply it to the source or warn because of this
> "jffs2" problem???

Partly because I'm unconvinced that we want to actually _use_ such a
small erasesize. It means you split far more page writes into two nodes
to avoid crossing block boundaries, and hence waste space.

I suspect the main reason Thomas objected to my original 'min 64KiB' was
because of the 5-erase-block threshold. Since I've just wound that
threshold _up_ on NAND because and it's also based in part on nr_blocks
now, we could perhaps rethink the minimum erasesize. I didn't manage to
tie him down on #mtd yesterday though.

--

-- 
dwmw2

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

Ingo Flaschberger | 10 Oct 2003 16:53
Picon
Favicon

Re: kmalloc jffs2_do_mount_fs

Hi

> On Fri, 2003-10-10 at 05:13 +0200, Ingo Flaschberger wrote:
> > but why doe you not apply it to the source or warn because of this
> > "jffs2" problem???
>
> Partly because I'm unconvinced that we want to actually _use_ such a
> small erasesize. It means you split far more page writes into two nodes
> to avoid crossing block boundaries, and hence waste space.
>
> I suspect the main reason Thomas objected to my original 'min 64KiB' was
> because of the 5-erase-block threshold. Since I've just wound that
> threshold _up_ on NAND because and it's also based in part on nr_blocks
> now, we could perhaps rethink the minimum erasesize. I didn't manage to
> tie him down on #mtd yesterday though.

i use 16k erase block size but the jffs2 partition is

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

Jörn Engel | 10 Oct 2003 19:50
Picon

Re: kmalloc jffs2_do_mount_fs

On Fri, 10 October 2003 06:46:21 +0100, David Woodhouse wrote:
> 
> Partly because I'm unconvinced that we want to actually _use_ such a
> small erasesize. It means you split far more page writes into two nodes
> to avoid crossing block boundaries, and hence waste space.
> 
> I suspect the main reason Thomas objected to my original 'min 64KiB' was
> because of the 5-erase-block threshold. Since I've just wound that
> threshold _up_ on NAND because and it's also based in part on nr_blocks
> now, we could perhaps rethink the minimum erasesize. I didn't manage to
> tie him down on #mtd yesterday though.

But this is wrong (TM).  You missed at least one variable in your
equation.  Five erase blocks is quite enough for NAND, as long as you
don't have more blocks total than on a similar NOR device.  The
problems start when you have too many blocks - you need more free
blocks.

This means that you need what I tried to start with one - dynamic 1)
numbers of erase blocks and possibly dynamic block sizes as well.
Anything else may be a decent assumption for one device or another,
but not for all.

1) dynamic for compile time - it should stay static for any given
device.

Jörn

--

-- 
Fancy algorithms are buggier than simple ones, and they're much harder
(Continue reading)

David | 15 Oct 2003 20:45
Picon
Favicon

How to behave nicely on JFFS2

Hello all

We are developing/porting some software onto an
embedded system that will have 32MB flash based on
Intel chips with a JFFS2 file system on it. My
question is what pattern of
read,write,insert,delete,... operations does JFFS2
like and dislike ??

Basically how must applications behave in order to not
cause too much wasted space in terms of fragmentation
and the overhead that comes with it or to avoid
putting the file system in a state that makes it less
efficient/slower ?

Example of questions that come to mind for me are :

1. Should data be stored in memory until its a certain
amount before it is appended to a file ?  

2. Is it better to delete and rewrite a file then to
update a portion of a file ???

I can't find any guidelines for programmers to follow
when developing against a JFF2 file system. 
I have read the "JFFS : The Journalling Flash File
System" paper by David Woodhouse Red Hat, Inc. and
also I have gone through this mailing list.

Thanks in advance for you help, and sorry if i yip yap
(Continue reading)


Gmane