mtdblock module & I'm Back again

mtdblock module & I'm Back again

[Gregory Schallert]

I'm back again with a couple of more generic questions...  As a reminder
this is my project.

I am currently working on a project that (will) store the linux
kernel/os on
flash.  We are using the ElanSC400 chip and a board that has 3 pairs of
AM29F016EC Flash Chips arranged such that the high byte of the data goes
to
one chip and the low byte goes to the other. I've been able to configure
the windows on the SC400 to allow me to see what is on the chips by
using the mmap() function.  I would like for the flash to emulate a
block device so I've started playing around with the mtdblock.c file.
My questions are these:

1)  when I compile the mtdblock.c file I get a referenced symbol
"invalidate_buffers"  Any Ideas why?

I have currently have a MTD release that is about a month old.  I'm
going to download the new one and see if I still get the same problem.

2)  What does mtdblock.c actually do? If I load mtd.o, mapped.o, and
mtdblock.o  what additional functionality do I need to program to get a
minix file system on the flash chips?

Thanx

Gregory Schallert
Dawning Technologies, Inc.



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdblock module & I'm Back again

[Nicolas Pitre]

On Wed, 1 Nov 2000, Gregory Schallert wrote:

> 1)  when I compile the mtdblock.c file I get a referenced symbol
> "invalidate_buffers"  Any Ideas why?
> 
> I have currently have a MTD release that is about a month old.  I'm
> going to download the new one and see if I still get the same problem.

It should have been fixed in the current CVS.

> 2)  What does mtdblock.c actually do? If I load mtd.o, mapped.o, and
> mtdblock.o  what additional functionality do I need to program to get a
> minix file system on the flash chips?

IMHO mtdblock is currently broken.  It works read-only.  I'm implementing
the write support at the moment.

However, in the mean time, you might consider investigating JFFS which
might just do what you want.  Even if JFFS requires mtdblock it is used
only to identify the flash device so the issue with mtdblock write support
doesn't apply to JFFS.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdblock module & I'm Back again

[David Woodhouse]

On Wed, 1 Nov 2000, Nicolas Pitre wrote:

> IMHO mtdblock is currently broken.  It works read-only.  I'm implementing
> the write support at the moment.
> 
> However, in the mean time, you might consider investigating JFFS which
> might just do what you want.  Even if JFFS requires mtdblock it is used
> only to identify the flash device so the issue with mtdblock write support
> doesn't apply to JFFS.

That's also being worked on. It won't take too much to remove the
FS_REQUIRES_DEV flag from the jffs filesystem and allow you to use it
without having to have the placebo mtdblock device present. 

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdblock module & I'm Back again

[Nicolas Pitre]

On Wed, 1 Nov 2000, David Woodhouse wrote:

> On Wed, 1 Nov 2000, Nicolas Pitre wrote:
> 
> > However, in the mean time, you might consider investigating JFFS which
> > might just do what you want.  Even if JFFS requires mtdblock it is used
> > only to identify the flash device so the issue with mtdblock write support
> > doesn't apply to JFFS.
> 
> That's also being worked on. It won't take too much to remove the
> FS_REQUIRES_DEV flag from the jffs filesystem and allow you to use it
> without having to have the placebo mtdblock device present. 

Be sure it is still usable for root filesystems as it does now...


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdblock module & I'm Back again

[David Woodhouse]

On Wed, 1 Nov 2000, Nicolas Pitre wrote:

> Be sure it is still usable for root filesystems as it does now...

Yep. Most of the systems I'm testing JFFS on now have their root
filesystem on JFFS.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

mtdblock: module -vs- kernel

[Gregory Schallert]

Ok I finally have the initial hardware to do some testing.

Short story...

I can get the mtd char and block drivers to work as modules, but when I
compile them into the kernel only the char device driver works. Any Ideas?

Long story...

I have hacked physmap.c and jedec.c (my chips do not support CFI) and can now
mount a filesystem on my flash device.  Everything works wonderful as a
modules ( both block and char devices)....

Now I want to make the flash device a root filesystem.  I have edited
init/main.c and added the /dev/flash I node number and init_mtd function.

When I boot with mtdblock0 as my boot device It will uncompress the kernel and
load it.  It then recognizes /dev/mtdblock0 as the boot device, but when it
tries to load the filesystem it crashes.

If  I do not set mtdblock0 as my boot device( and boot from floppy), the mtd
char driver seems to be working fine when compiled into the kernel but I can
not mount a block device. The proc/dev/ dir contains both mtd and mtdblock.
the /proc/mtd dir only contains mtd0, and will not recognize mtdblock0 as a
valid block device. (that means I can not mount any flash chips)

I have a good understanding about the kernel boot flags and really don't think
that is where the problem is...Is there something I am missing about booting
from the flash device?

Gregory Schallert
Dawning Technologies, Inc.



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdblock: module -vs- kernel

[Nicolas Pitre]

On Thu, 18 Jan 2001, Gregory Schallert wrote:

> I have hacked physmap.c and jedec.c (my chips do not support CFI) and can now
> mount a filesystem on my flash device.  Everything works wonderful as a
> modules ( both block and char devices)....
>
> Now I want to make the flash device a root filesystem.  I have edited
> init/main.c and added the /dev/flash I node number and init_mtd function.

Why adding init_mtd?

> When I boot with mtdblock0 as my boot device It will uncompress the kernel and
> load it.  It then recognizes /dev/mtdblock0 as the boot device, but when it
> tries to load the filesystem it crashes.
>
> If  I do not set mtdblock0 as my boot device( and boot from floppy), the mtd
> char driver seems to be working fine when compiled into the kernel but I can
> not mount a block device. The proc/dev/ dir contains both mtd and mtdblock.
> the /proc/mtd dir only contains mtd0, and will not recognize mtdblock0 as a
> valid block device. (that means I can not mount any flash chips)

What does /proc/devices say?


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

compiling DOC

[Brian Michalk]

I first dabbled in DOC about a year ago, successfully making the modules,
etc.  I've been monitoring the email, and thought it would be easy to get
the code compiled into the kernel to boot from DOC.

I went back through the archives.

I downloaded several different kernels to match the patches available
through FTP.  Here is what I have tried:

1)  "Just download the big tarball and drop it on top of your kernel tree".
Well, that didn't work.

2) Download 2.2.16 kernel.
untar mtd-20000704
modify patchin.sh because it didn't work out of the box
execute patchin.sh
patch -p0 -d /usr/src/linux <mtd-patch-2.2.16
It all eventually went without errors, but I still can't get a make
menuconfig to come up with the prompt to compile the MTD drivers.

I tried with 2.4 kernels as well.  I know you guys are busy, but I would
like a little cookbook help to be able to compile a kernel, and then boot
off DOC.

Thanks.



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: compiling DOC

[David Woodhouse]

michalk@awpi.com said:
>  I tried with 2.4 kernels as well.  I know you guys are busy, but I
> would like a little cookbook help to be able to compile a kernel, and
> then boot off DOC.

Get stock 2.4.0 kernel.
Do this:

CONFIG_MTD=y
CONFIG_MTD_DOC2000=y
CONFIG_MTD_DOCPROBE_ADDRESS=0  ( autoprobe)
CONFIG_MTD_DOCPROBE_HIGH=n
CONFIG_MTD_DOCPROBE_55AA=y
CONFIG_NFTL=y
CONFIG_NFTL_RW=y


boot with root=/dev/nftla1 (or /dev/nftla2)


If you have to use 2.2, there are patches at 
ftp://ftp.linux-mtd.infradead.org/pub/mtd/patches/

If you apply these, you can then get the latest code from CVS (Don't use 
the ancient tarballs) and drop in the contents of the include/linux/mtd and 
drivers/mtd directories. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

fdisk problems

[Brian Michalk]

After reviewing the archives, and going over the steps, I found that I
should be able to fdisk /dev/nftla device.  When I do:
embed: fdisk /dev/nftla
Unable to open /dev/nftla

embed: fdisk /dev/nftla1
Unable to open /dev/nftla1

I am not using modules, as I will be booting the DOC.
Here is the relevant information in my .config file.

CONFIG_MTD=y
CONFIG_MTD_DOC2000=y
CONFIG_MTD_DOCPROBE_ADDRESS=0
CONFIG_MTD_DOCPROBE_HIGH=n
CONFIG_MTD_DOCPROBE_55AA=y
CONFIG_FTL=y
CONFIG_NFTL=y
CONFIG_NFTL_RW=y

This is an edited dump of dmesg:
Linux version 2.4.0 (root@embed) (gcc version 2.95.2 19991024 (release)) #2
SMP Wed Jan 24 10:29:15 CST 2001
Kernel command line: auto BOOT_IMAGE=mtdkern1 ro root=303
Detected 133.637 MHz processor.
SMP motherboard not detected. Using dummy APIC emulation.
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
SIS5513: chipset revision 193
SIS5513: not 100% native mode: will probe irqs later
hda: ST36422A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 12500460 sectors (6400 MB) w/256KiB Cache, CHS=778/255/63
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
DiskOnChip 2000 found at address 0xE0000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
9 flash chips found. Total DiskOnChip size: 72 Mb
DiskOnChip 2000 found at address 0xE2000
Flash chip found: Manufacturer ID: EC, Chip ID: E6 (Samsung KM29U64000)
9 flash chips found. Total DiskOnChip size: 72 Mb
ftl_cs: FTL header not found.
ftl_cs: FTL header not found.
M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI
$Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $
Could not find valid boot record
Could not mount NFTL device
Could not find valid boot record
Could not mount NFTL device



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: fdisk problems

[David Woodhouse]

Please could you look for the find_boot_record() function at the beginning 
of drivers/mtd/nftlmount.c.

In the loop which says 'search for a valid boot record', inside the code 
which executes if the memcmp of DataOrgID with 'ANAND' is zero (line 77 of 
my version), can you first make it printk a message when, so you know it's 
actually _found_ the ANAND header, and then find each instance of 'goto 
ReplUnitTable' and make it print the reason if/when it triggers, rather 
than just doing so silently.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: fdisk problems

[Brian Michalk]

> my version), can you first make it printk a message when, so you 
> know it's 
> actually _found_ the ANAND header, and then find each instance of 'goto 
> ReplUnitTable' and make it print the reason if/when it triggers, rather 
> than just doing so silently.

Done

>Please define ECC_DEBUG at the beginning of doc2000.c

Done

Okay.  I'm recompiling.  I will report back after it's done.


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: fdisk problems

[Brian Michalk]

The source code changes:
nftlmount.c
...
if (memcmp(mh->DataOrgID, "ANAND", 6) == 0) {
	printk("memcmp found \"ANAND\"\n");
	/* first boot record */
...
if ((nftl->nb_boot_blocks + 2) >= nftl->nb_blocks) {
	printk("nb_boot_blocks+2 >= nb_blocks\n");
	goto ReplUnitTable; /* small consistency check */
}
...
if (nftl->numvunits > (nftl->nb_blocks - nftl->nb_boot_blocks - 2)) {
	printk("numvumits > nb_blocks-nb_boot_blocks-2\n");
	goto ReplUnitTable; /* small consistency check */
}
...
if (MTD_READECC(nftl->mtd, block * nftl->EraseSize +
		i + SECTORSIZE, SECTORSIZE,
		&retlen, buf, (char *)&oob) < 0) {
	printk("MTD_READECC(...) < 0\n");
	goto ReplUnitTable;
}

What dmesg said:
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
M-Systems DiskOnChip driver. (C) 1999 Machine Vision Holdings, Inc.
DiskOnChip 2000 found at address 0xE0000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC)
9 flash chips found. Total DiskOnChip size: 72 Mb
mtd: Giving out device 0 to DiskOnChip 2000
DiskOnChip 2000 found at address 0xE2000
Flash chip found: Manufacturer ID: EC, Chip ID: E6 (Samsung KM29U64000)
9 flash chips found. Total DiskOnChip size: 72 Mb
mtd: Giving out device 1 to DiskOnChip 2000
ftl_cs: FTL header not found.
ftl_cs: FTL header not found.
M-Systems NAND Flash Translation Layer driver. (C) 1999 MVHI
$Id: nftl.c,v 1.57 2000/12/01 17:51:54 dwmw2 Exp $
NFTL_notify_add for DiskOnChip 2000
mtd->read = c01ad26c, size = 75497472, erasesize = 8192
NFTL_setup
memcmp found "ANAND"
MTD_READECC(...) < 0
memcmp found "ANAND"
MTD_READECC(...) < 0
Could not find valid boot record
Could not mount NFTL device
NFTL_notify_add for DiskOnChip 2000
mtd->read = c01ad26c, size = 75497472, erasesize = 8192
NFTL_setup
memcmp found "ANAND"
MTD_READECC(...) < 0
memcmp found "ANAND"
MTD_READECC(...) < 0
Could not find valid boot record
Could not mount NFTL device



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: fdisk problems

[David Woodhouse]

On Thu, 25 Jan 2001,  Brian Michalk wrote:

> MTD_READECC(...) < 0

If you define ECC_DEBUG in doc2000.c, I think you'll find it's reporting
an ECC failure. Before I left work, I managed to reproduce this, as
M-Systems sent me some 72MiB units a couple of days ago. Unfortunately, I
don't know _why_ it's reporting the ECC failure.

For now, can you change the code so it ignores that and continues?

You don't have anything valuable on that DiskOnChip at the moment, do 
you?

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: fdisk problems

[Brian Michalk]

Hmmmm,
Now I'm getting an error at the bootprompt:
LILLILO may overwrite Extended BIOS data area.

Before I upgraded my slackware I didn't have this problem.  It'sobviously
the EBDA problem.  The funny thing is that the problem goes away if I
disable the DOC.

There is a patch in the archives.  Perhaps I'll try patching LILO.

> -----Original Message-----
> From: dwmw2@infradead.org [mailto:dwmw2@infradead.org]
> Sent: Thursday, January 25, 2001 2:57 PM
> To: Brian Michalk
> Cc: mtd@infradead.org
> Subject: RE: fdisk problems
>
>
> On Thu, 25 Jan 2001,  Brian Michalk wrote:
>
> > MTD_READECC(...) < 0
>
> If you define ECC_DEBUG in doc2000.c, I think you'll find it's reporting
> an ECC failure. Before I left work, I managed to reproduce this, as
> M-Systems sent me some 72MiB units a couple of days ago. Unfortunately, I
> don't know _why_ it's reporting the ECC failure.
>
> For now, can you change the code so it ignores that and continues?
>
> You don't have anything valuable on that DiskOnChip at the moment, do
> you?
>
> --
> dwmw2
>
>



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: fdisk problems

[Brian Michalk]

I am at a loss.
I can get my 8Mb DOCs to work, but not my 72Mb DOCs.

I have booted into DOS and:
dupdate /win=c800 /s:doc42.exb
dformat /win:c800 /s:doc42.exb

This all went without problems.

When I boot an MTD compiled kernel (no modules) I always get the ECC errors.
I went to my cabinet and pulled out a handfull of 72Mb DOCs, and they all
exhibit the same symptoms.

I recall that at some time in the past, we need needed to write either
zeroes, or FFs to the flash before using it.  Is this still required?
Is there a different .exb file I should be using?

> -----Original Message-----
> From: dwmw2@infradead.org [mailto:dwmw2@infradead.org]
> Sent: Thursday, January 25, 2001 2:57 PM
> To: Brian Michalk
> Cc: mtd@infradead.org
> Subject: RE: fdisk problems
>
>
> On Thu, 25 Jan 2001,  Brian Michalk wrote:
>
> > MTD_READECC(...) < 0
>
> If you define ECC_DEBUG in doc2000.c, I think you'll find it's reporting
> an ECC failure. Before I left work, I managed to reproduce this, as
> M-Systems sent me some 72MiB units a couple of days ago. Unfortunately, I
> don't know _why_ it's reporting the ECC failure.
>
> For now, can you change the code so it ignores that and continues?
>
> You don't have anything valuable on that DiskOnChip at the moment, do
> you?
>
> --
> dwmw2
>
>



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: fdisk problems

[David Woodhouse]

michalk@awpi.com said:
>  I recall that at some time in the past, we need needed to write
> either zeroes, or FFs to the flash before using it.  Is this still
> required? Is there a different .exb file I should be using? 

Nope. It looks like there's something 'different' about the ECC on the 
larger units. I'll have to poke at it and find out what.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: fdisk problems

[Brian Michalk]

You are right.  I dug through the documentation at M-systems and tried the
various firmware files.  None of them work.

After a week of poking around I have come to the conclusion that I am not
insane and that the 72Mb DOCs are different in some fashion.

Let me know if there is anything I can do to help.

 Brian Michalk  <http://www.awpi.com/michalk>
Life is what you make of it ... never wish you had done something.
Aviator, experimental aircraft builder, motorcyclist, SCUBA diver
musician, home-brewer, entrepreneur and SINGLE!


> -----Original Message-----
> From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
> Of David Woodhouse
> Sent: Sunday, January 28, 2001 7:20 AM
> To: Brian Michalk
> Cc: mtd@infradead.org
> Subject: Re: fdisk problems
>
>
>
> michalk@awpi.com said:
> >  I recall that at some time in the past, we need needed to write
> > either zeroes, or FFs to the flash before using it.  Is this still
> > required? Is there a different .exb file I should be using?
>
> Nope. It looks like there's something 'different' about the ECC on the
> larger units. I'll have to poke at it and find out what.
>
> --
> dwmw2
>
>
>
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
>



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: mtdblock module & I'm Back again

[David Woodhouse]

gschallert@dawning.com said:
>  2)  What does mtdblock.c actually do? If I load mtd.o, mapped.o, and
> mtdblock.o  what additional functionality do I need to program to get
> a minix file system on the flash chips?

You don't need 'mapped.o' which is going to go away fairly shortly.

You need to ensure that 'jedec.c' both works and supports the interleaved 
arrangement of your flash chips. 

Then you need to provide a 'map' driver through which it can access the 
chips. If the flash chips are linearly mapped into your physical address 
space, then physmem.c is a good place to start.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org