[Yaffs] YAFFS, DOC - newbie questions

[Charles Manning]

Hey Sandeep

This sounds like an interesting project. I will be interested in hearing=20
about your results. Any useful things you come up with will be appreciate=
d.

The questions you ask below are mtd questions more than YAFFS ones, but I=
=20
will give some answers below.

If you're really interested in the filesystem algorithms themselves, then=
 I=20
suggest you try build the file system in userspace (like I have with yaff=
s=20
direct). This is far easier/faster to debug and develop than in kernel sp=
ace.=20
It also means you don't spend most of your time trying to figure outhow t=
o=20
hook up with the Linux VFS.

I do all the algorithmic (ie yaffs_guts.c) development using yaffs direct=
 and=20
a nand-on-disk emulation or nand-on-ram emulation. See yaffs/direct/filee=
m.c

In kernel space I also use yaffsram which uses a ram emulation to allow y=
ou=20
to play with YAFFS in the kernel without having to worry about NAND suppo=
rt.=20
THis makes it very easy to use it on a PC.



On Friday 15 October 2004 12:43, Sudeep Jain wrote:
> hello,
>
> As part of my masters project, I am planning to
> implement a new flash file system that shall be log
> structured in nature. The goal is not to have a
> production quality file system, but something that
> allows me to demonstrate and contribute one or two key
> ideas, and get results about optimizing
> writes/reads/erases etc. As Ive never done any kernel
> hacking before, neither have I worked with flash
> memory, so I have no idea as to how difficult/easy
> this job is going to be.
>
> From the hardware aspect, I need a flash memory
> package that
>
> a) has multiple flash chips within. (I need at least
> 3, preferably 4)
> b) which hooks up into a standard interface (say
> IDE/USB)
> c) allows me access to write data on whichever (chip,
> block, page) I want to.
> d) Has all the lower level drivers in a pretty stable
> condition.
>
> From these requirements, it appears that the M-Systems
> Disk on Chip devices are the best, as they are
> supported by MTD (are they ?), they hook up into a
> standard IDE interface, dont emulate a hard disk, and
> hopefuly (at least the larger disk sizes) have
> multiple flash chips inside which I can then access in
> parallel.

Some/most DOC devices are suypported by MTD.

You can also use SmartMedia or XD devices. These are just packaged NAND c=
hips.

>
> Questions
> 1) Can the DOC devices be changed to allow access by
> the host system at a (chip, block, page) level ?
> 2) Do the MTD drivers work with DOC devices, and can
> they provide this level of access ?
Yes, DOC can be accessed as NAND.
> 3) Do the MTD devices have multiple NAND chips inside
> ? How do I find how many there are ?
MTD can support multiple devices. It has two very nifty peices of softwar=
e:
mtdconcat: allows multiple devices to be concatenated to look like one de=
vice.
mtdpart: allows a single device to be split up into multiple logical devi=
ces.


I hope some of that helps.

-- Charles