How to use MTD

I'd really like to start experimenting with MTD, but I'm afraid I've only
got half a clue about how to use it.

Here's what I'd like to do:

	1) Create an ext2 filesystem on an mtd block device and mount
	   it read-write from linux. This is to experiment with MTD
	   without the flash.
	2) Create an ext2 filesystem on a set of flash devices from an
	   embedded system running linux. The underlying flash devices
	   are Intel's StrataFlash; they support CFI and JEDEC.

To accomplish (1), I thought I should:

	# insmod mtd
	# insmod slram
	# insmod mtdblock
	# mkfs -t ext2 /dev/mtdblock0
but mkfs says:
        mke2fs 1.15.6, 13-Aug-1999 for EXT2 FS 0.5b, 95/08/09
        /dev/mtdblock0: Invalid argument passed to ext2 library while setting up        superblock

Can someone please explain the fundamentals?

Thanks!

-Michael Thompson
mickey <at> berkeley.innomedia.com

mtd comments

Hi,

I'm just browsing trough the mtd code.
Here are some comments:

The following code in mtd.c::mtd_read() is pretty bad from a security
standpoint:

if (!mtd->point || (ret = MTD_POINT(mtd, *ppos, count, &retlen, &mtdbuf)) != 0)
{
   /* mtd->point() failed; use mtd->read instead */
   ret = MTD_READ(mtd, *ppos, count, &retlen, buf);

The passing of buf, which is a userspace pointer to a kernel API is
dubious at the very least. And in the case of i.e. slram.c the 
physmem_read() function in fact just does an memcpy leading to a direct
security problem. 

FTL uses the read functions directly to though, so read must be able to
handle kernel pointers also.

Is the buffer pointer in the read call supposed to be a kernel or
userspace pointer? Who is responsible for verifying it?
Maybe there needs to be two API:s, one for userspace buffers and one for
kernelspace buffers. In this context the MTD_POINT api is actually very
nice.

Also, what is oob (out of band) blocks? And how are flash-memories that
have non-constant erase-sector size (i.e. boot sectors etc.) handled?

Booting from the flash

It appears that nftl_format deletes M-Systems' firmware.  I 
remember that David wrote something about fixing that.  
doc_loadbios seems to destroy the partition entirely.  Neither M-
Systems' drivers nor MTD drivers can recognize anything on the 
flash after doc_loadbios.

Is there a way to boot from a DOC2000 flash using MTD drivers?

[BTW:  I was only successful at creating a 2.3 kernel with MTD 
drivers.  2.2 kernels don't seem to work.  I think I have an idea what 
could be wrong, and I'll try to test it soon]

---------
Dvir Oren <dvir <at> lucidvon.com>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org

Re: Booting from the flash

Dvir Oren wrote:
> 
> It appears that nftl_format deletes M-Systems' firmware.  I
> remember that David wrote something about fixing that.
> doc_loadbios seems to destroy the partition entirely.  Neither M-
> Systems' drivers nor MTD drivers can recognize anything on the
> flash after doc_loadbios.
> 
> Is there a way to boot from a DOC2000 flash using MTD drivers?

Yes, I've just gone through this.  I've had mixed results resurrecting devices
after destroying their firmware this way: a 4 MB DiskOnChip 2000 was
recoverable, while a 2 MB unit was not.

What I learned is that doc_loadbios seems to need an image captured by "dd
if=/dev/mtd0 ...".  Given this, I was able to destroy and reload the M-Systems
firmware on the 4 MB device.  I confess, after the lack of success with the 2 MB
unit, I didn't try too hard to explore the failure modes in this process, so I'm
not promising it's foolproof.

Of course if that firmware is already gone, you can't capture an image of it!  I
managed to get out of this situation by using the DOS utilities from M-Systems'
web site, and thrashing around booting Linux and DOS from a floppy.  First, I
used the firmware image (DOC121.EXB) and doc_loadbios to load it.  This isn't
enough to make the firmware work, but it's enough to persuade DUPDATE.EXE
(running under DOS, I didn't try dosemu) that the DiskOnChip is present so it
would write the firmware the right way.

After you've succeeded in restoring the boot code (or, preferably, before you've
destroyed it), dd it off of /dev/mtd0 to make an image that works with

Re: Booting from the flash

Dvir Oren wrote:
    It appears that nftl_format deletes M-Systems' firmware.  I
    remember that David wrote something about fixing that.
    doc_loadbios seems to destroy the partition entirely.  Neither M-
    Systems' drivers nor MTD drivers can recognize anything on the
    flash after doc_loadbios.

    Is there a way to boot from a DOC2000 flash using MTD drivers?

    [BTW:  I was only successful at creating a 2.3 kernel with MTD
    drivers.  2.2 kernels don't seem to work.  I think I have an idea what
    could be wrong, and I'll try to test it soon]
in my case I had some experience about it
1:get mtd-20000131 release and grub from GNU's CVS

2:change doc_stage1.S like this
.......
   3. Return, and wait for our INT 18h to be called.
 */

  /* Store the DiskOnChip segment */
 movw %ds, %cs:doc_seg

  /* Find top of memory */
 xorw %ax, %ax
 movw %ax, %ds
 movw 0x0413, %ax

  /* Set up our shiny net INT 18h handler */

Test mtd ram device

Since I'm playing around with the MTD stuff i needed a test device that i
can use on my normal machine. I've attached a device that just vmalloc()s
some space and registers as an mtd device. 

/ Alex

/* 
 * mtdram - a test mtd device
 *
 * Author: Alexander Larsson <alex <at> cendio.se> 
 *
 * Copyright (c) 1999 Alexander Larsson <alex <at> cendio.se>
 *
 * This code is GPL
 *
 */

#include <linux/module.h>
#include <linux/malloc.h>
#include <linux/ioport.h>
#include <linux/init.h>
#include <linux/vmalloc.h>
#include <linux/mtd/mapped.h>

#if LINUX_VERSION_CODE < 0x20300
#define __exit
#endif

#define MTDRAM_TOTAL_SIZE 1024*1024*2

Re: We are ready and need additional ptr

(Copied to the list to prevent duplication - hope you don't mind)

wlim <at> vrcomm.com said:
> 1.  Is this DOC driver modelled after the one provided by M-System's
> flobj.obj which you have a disassembly version on mtd/pub web site?

Not really. Only the detection of the DiskOnChip is taken from there (that's 
why it used to have variables like 'long dx' etc ;)

> 2.  In the "README" file v 1.3 2000/01/28 for "HOW TO GET GRUB BOOTING
> FROM DiskOnChip", there is a reference of "Copy the 'stage2/
> pre_stage2' file to this directoray, where is this file located, in
> GRUB 0.5?

If you are using Grub from the FSF CVS tree then yes, it's located in the Grub 
build tree after you've built Grub.

In Grub 0.5 (the older version from Erich Boleyn) there is no pre_stage2; only
stage2. If you're using that version of Grub, you have to change mtd/grub/
Makefile accordingly - see the first few lines of the Makefile.

Grub only works on Intel machines, though.

> 3.  In the "README" file v 1.3 2000/01/28 for "HOW TO GET GRUB BOOTING
> FROM DiskOnChip", there is a reference of DiskOnChip has a built-in
> ROM.  Is this built-in ROM modifiable?

It has a tiny built-in ROM, which on Intel machines just loads the first 8Kb of
the flash itself, then passes control to it. You can't change the ROM itself,

Re: mtd comments

(this found in my drafts folder - evidently it never got sent - sorry for the 
delay)

> Hi,
> 
> I'm just browsing trough the mtd code.

Thanks - it's high time this was done. 

> The following code in mtd.c::mtd_read() is pretty bad from a security
> standpoint:
> 
> if (!mtd->point || (ret = MTD_POINT(mtd, *ppos, count, &retlen, &mtdbuf)) != 0)
> {
>    /* mtd->point() failed; use mtd->read instead */
>    ret = MTD_READ(mtd, *ppos, count, &retlen, buf);
> 
> The passing of buf, which is a userspace pointer to a kernel API is
> dubious at the very least. And in the case of i.e. slram.c the 
> physmem_read() function in fact just does an memcpy leading to a direct
> security problem. 

I wasn't sure how to do this at the time I wrote this section of code (about
three years ago), but now I think we ought to declare that the MTD read() et
al. functions ought to take user-space pointers and use verify_area/
copy_{to,from}_user.

If they're actually called with a kernel-space buffer, we use 
set_fs(KERNEL_DS) beforehand, which handles the rest of your question.

Re: mtd comments

On Tue, 7 Mar 2000, David Woodhouse wrote:

> > Hi,
> > 
> > I'm just browsing trough the mtd code.
> 
> Thanks - it's high time this was done. 

The core (interfaces etc.) is very good. Some parts could probably
use some polish though.

> > The following code in mtd.c::mtd_read() is pretty bad from a security
> > standpoint:
> > 
> > if (!mtd->point || (ret = MTD_POINT(mtd, *ppos, count, &retlen, &mtdbuf)) != 0)
> > {
> >    /* mtd->point() failed; use mtd->read instead */
> >    ret = MTD_READ(mtd, *ppos, count, &retlen, buf);
> > 
> > The passing of buf, which is a userspace pointer to a kernel API is
> > dubious at the very least. And in the case of i.e. slram.c the 
> > physmem_read() function in fact just does an memcpy leading to a direct
> > security problem. 
> 
> I wasn't sure how to do this at the time I wrote this section of code (about
> three years ago), but now I think we ought to declare that the MTD read() et
> al. functions ought to take user-space pointers and use verify_area/
> copy_{to,from}_user.
> 
> If they're actually called with a kernel-space buffer, we use 

Re: mtd comments

alex <at> cendio.se said:
>  .
> This is mainly used as a bootsector type of thing. The idea seems to
> be that if your boot-code is a lot less than 64k you don't waste so
> much space. And you can also store configuration data in one of the
> smaller sectors, and rewrite it without destroying the boot sector. 

Options include...

1. Ignore the smaller erasesize - pretend it's 64Kb and force you to erase the 
whole lot at once.

2. Treat the parts with different erasesize as different logical devices as 
far as the MTD layer is concerned.

3. Change the MTD interface so it can handle variable sector sizes somehow.

As you seem to be implying that the parts with different sector sizes are used 
for a different purpose than the majority of the flash device, I'm inclined 
to favour #2 for now.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to majordomo <at> infradead.org