MTD Device Drivers.
matrix reloaded
Hi,
I am going through the code for device drivers of MTD [Memory Technology
Devices] and found that code in "mtdblock.c" uses interface which is for block
devices [like register_blkdev(), blk_init_queue() etc], but there is one mor folder
inside it named "devices" [drivers/mtd/devices] where there are some drivers for
doc1000, doc2000 and doc2001 etc. But here the interface used for implementing
driver is totally that of MTD devices only [like inter_module_register(),
inter_module_unregister() etc].
Can anyone please tell me why is it like this ?
Is it something like that mtd devices drivers can be written as block device as well
as mtd device... Actually if you see mtd device is also a block device, for example
if you check with the hardware details of "Disk On Chip Pro" [mtd device] you will
find an IDE interface and its driver can be written as that for block device driver...
Anyone please help me...
TIA.
Sumit Sharma
IBM, Bangalore.
David Woodhouse
> I am going through the code for device drivers of MTD [Memory Technology
> Devices] and found that code in "mtdblock.c" uses interface which is for block
> devices [like register_blkdev(), blk_init_queue() etc], but there is one mor folder
> inside it named "devices" [drivers/mtd/devices] where there are some drivers for
> doc1000, doc2000 and doc2001 etc. But here the interface used for implementing
> driver is totally that of MTD devices only [like inter_module_register(),
> inter_module_unregister() etc].
>
> Can anyone please tell me why is it like this ?
The MTD device driver infrastructure is for devices which appear to the
system as flash -- you can directly perform read/write/erase operations
on them.
On top of a flash device, you can implement a 'translation layer' -- a
kind of hackish pseudo-filesystem which is used to make it pretend to be
a normal block device, while taking care of wear levelling, bad block
remapping etc. We support a handful of these, including a _really_
simple one we call 'mtdblock' which does no wear levelling or remapping
but simply responds to a 'sector' write by reading the entire eraseblock
to which it corresponds, erasing that block, and then writing back the
whole block. Thus 'mtdblock' is quite useful just for dumping images to
the flash but you should never really be using it with a 'real' file
system on it in writable mode.
There are many types of device which have flash _inside_ them but which
also have a microcontroller to do this kind of 'translation layer' for
you. These really appear to the system as if they were a hard drive --
CompactFlash is like this. The MTD system is not relevant for those.
There are saner ways of using flash than making it pretend to be a block
device. JFFS2 is a log-structured file system which works directly on
flash, rather than through an extra layer of indirection.
JFFS2 should on the supported models of DiskOnChip, although we do
support M-Systems' 'NFTL' and 'INFTL' translation layers too.
However M-Systems _do_ make some devices which appear just as an IDE
drive. It's _possible_ that you're correct when you say that's what you
have, although _many_ people claim it's an IDE drive "just because it
says it's C: in DOS".
--
dwmw2
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
matrix reloaded
Hi David,
Thanks for this really great explaination. But one more thing I would like to ask
is whether doc1000, doc2000 and all are not treated as a block device by there
kernel ? What my understanding is, first you have to insert module for doc1000 ,
doc2000 and etc... and then you can insert module for mtdblock.c if they are blockk
devices or mtdchar.c if they are treated as char devices. Am I right ?
Because doc1000.c code inserts the entry [mtd_info] into mtd_table and then
mtdblock.c or mtdchar.c then uses this entry while calling various read, write and
other operations ...
Please tell me if I am wrong somewher...
Thanks.
Sumit Sharma
IBM, Bangalore.
David Woodhouse
You are top-posting, your broken mail lacks References: headers, and
your lines are too long. Also, you quoted far more of my previous
message than you need to.
On Thu, 2004-09-23 at 10:12 +0000, matrix reloaded wrote:
> is whether doc1000, doc2000 and all are not treated as a block device
> by there kernel ? What my understanding is, first you have to insert
> module for doc1000 , doc2000 and etc... and then you can insert module
> for mtdblock.c if they are blockk devices or mtdchar.c if they are
> treated as char devices. Am I right ?
You seem to be asking if there's some ordering constraint. You don't
have to load the low-level hardware driver first; you can have the
'mtdchar' device and the translation layers built in to the kernel, or
you can load them first. They'll notice when a new hardware device is
registered.
You shouldn't use mtdblock.c with doc1000 or doc2000 if you intend to be
compatible with what M-Systems use on those devices. The doc1000 should
be used with FTL, and the doc2000 with NFTL.
You probably shouldn't use mtdblock at _all_, in fact.
matrix reloaded
On Thu, 23 Sep 2004 David Woodhouse wrote :
>Please read http://david.woodhou.se/email.html
Thanks for the link
>They'll notice when a new hardware device is
>registered.
Can you tell me where the code for detecting a newly added device is ?
>
>You probably shouldn't use mtdblock at _all_, in fact.
>
I've seen an implementation where for Disk On Chip Pro, mtdblock.c was used. Basically in that case the requirement was just for making a filesysetem on DOC, putting kernel image, boot image. Ofcourse there was partition table information also in the starting sectors.
Thanks.
Sumit Sharma.