Hey Sandeep
This sounds like an interesting project. I will be interested in hearing
about your results. Any useful things you come up with will be appreciated.
The questions you ask below are mtd questions more than YAFFS ones, but I
will give some answers below.
If you're really interested in the filesystem algorithms themselves, then I
suggest you try build the file system in userspace (like I have with yaffs
direct). This is far easier/faster to debug and develop than in kernel space.
It also means you don't spend most of your time trying to figure outhow to
hook up with the Linux VFS.
I do all the algorithmic (ie yaffs_guts.c) development using yaffs direct and
a nand-on-disk emulation or nand-on-ram emulation. See yaffs/direct/fileem.c
In kernel space I also use yaffsram which uses a ram emulation to allow you
to play with YAFFS in the kernel without having to worry about NAND support.
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 chips.
>
> 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 software:
mtdconcat: allows multiple devices to be concatenated to look like one device.
mtdpart: allows a single device to be split up into multiple logical devices.
I hope some of that helps.
-- Charles
(text/plain)