MD2202-D384 DoC with MTD

MD2202-D384 DoC with MTD

[Lindstrom James-A19027]

I'm trying to get my MD2202-D384 up and running with the diskonchip.c driver.  I'm starting with kernel linux-2.4.18-rmk7-pxa3-cerf3 then patching in mtd-snapshot-2005-03-04.  I did quite a bit of work hacking things to make them happy.  The kernel boots, however, the DoC is not detecting properly.  When I look in nandids.c, though, I don't even see an option for the 384 mb variety of DoC.  Am I missing something?

Here is my boot-up output (re-typed, forgive me):

DiskOnChip found at 0x10000000
NAND device: Manufacturer 0xec, Chip ID 0x79 (Samsung NAND 128MiB 3,3V 8-bit)
3 NAND chips detected
Bad block table not found for chip 0
Bad block table not found for chip 0
nand_read_ecc: from = 0x00000000, len = 512
nand_read_ecc: from = 0x00004000, len = 512
nand_read_ecc: from = 0x00008000, len = 512
nand_read_ecc: from = 0x0000c000, len = 512
nand_read_ecc: failed ECC read, page 0x000000c0 on chip 0
ECC error scanning DOC at 0xc000
DiskOnChip BNAND Media Header not found

Thanks,

jbl

Re: MD2202-D384 DoC with MTD

[Andre]

Lindstrom James-A19027 wrote:
> I'm trying to get my MD2202-D384 up and running with the diskonchip.c
> driver.  I'm starting with kernel linux-2.4.18-rmk7-pxa3-cerf3 then
> patching in mtd-snapshot-2005-03-04.  I did quite a bit of work
> hacking things to make them happy.  The kernel boots, however, the
> DoC is not detecting properly.  When I look in nandids.c, though, I
> don't even see an option for the 384 mb variety of DoC.  Am I missing
> something?

I have the exact same device, although my kernel is 2.6.11 with snapshot
20050612. No special hacks were needed in my case since I am not booting
from the diskonchip yet.

Here are the kernel config flags I used related to MTD:
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
CONFIG_FTL=m
# CONFIG_NFTL is not set
CONFIG_INFTL=m

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_RAMTD is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
# CONFIG_MTD_NAND_NANDSIM is not set

you then load the driver with:
modprobe -a diskonchip
modprobe -a inftl

After this I received some kernel messages from INFTL but I was able to
mount it ok. However, upon subsequent boot, my diskonchip stopped working. I
doubt that it had anything to do with mtd because when I ran the diskonchip
utilities from m-sys, it reported that it couldn't find the bad block table
anymore. According to the diskonchip data sheet, this table is supposedly in
a protected area.
Please see my posting titled 'kernel messages from INFTL'. I am still
waiting to hear from mtd folks what could have happened since the mount
operation should not actually do anything to the media in my opinion.

cheers,
Andre