* GRUB on DoC Millennium/2000 - Instructions (Revised) problem
From: eylon eyal @ 2002-11-07 10:20 UTC (permalink / raw)
To: linux-mtd
I've read the last paper about how to use grub with doc 2000
http://lists.infradead.org/pipermail/linux-mtd/2002-October/006166.html
i downloaded the last mtd sources from the cvs as following
cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs login
(password = anoncvs)
cvs -z3 -d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd
and i downloaded the last grub source from cvs
now the instractions says that i need to patch the grub sources as follow
patch -p0 -i grub-2002-10-08-doc.patch
i understand that this patch should be under directory /usr/src/mtd/patches/
but the last patch i find there is grub-2002-07-29-doc.patch
were can i get the correct patch? or is it ok to use this patch?
thanks alot ayalon
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: David Woodhouse @ 2002-11-07 8:00 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: linux-mtd
In-Reply-To: <20021106204530.GE12743@pc.ilinx>
f327b61d4f54c7b54025800b32e2ac7c@interlinx.bc.ca said:
> You are absolutely right! That is what I get for patching my vendor's
> kernel-source rather than working with a virgin kernel.org tree. Find
> attached a new patch, covering all 16 architectures. I don't know
> what some of them are (i.e. "sh, "cris") but I am assuming they are
> all hardware an all have memory busses.
What happens when someone makes a mapping driver for UML which mmaps part
of /dev/kmem from the host?
--
dwmw2
^ permalink raw reply
* [slightly OT] "SPIA" = ?
From: Jeffrey Lim @ 2002-11-07 6:21 UTC (permalink / raw)
To: linux-mtd
Hi, was just wondering what "spia" stands for. I've inherited code that
seems to be based on spia.c, but try as i might, i cant seem to locate
much information about this elusive "spia", except that it's some sort of
a board (from /usr/src/linux/drivers/mtd/nand/spia.c).
If anybody has any pointers to any extra info, I would appreciate it.
Thanks
-jf
--
"It's an extraordinary world!" - jfsworld <at> fastmail.fm
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: Brian J. Murrell @ 2002-11-06 20:45 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <20021104171339.GB13152@wohnheim.fh-wedel.de>
[-- Attachment #1.1: Type: text/plain, Size: 769 bytes --]
On Mon, Nov 04, 2002 at 06:13:39PM +0100, Jörn Engel wrote:
>
> That is five architectures out of of sixteen. You might argue that
> s390 does not need mtd (which I'm not even sure about), but arm is
> definitely missing and surely some more.
You are absolutely right! That is what I get for patching my vendor's
kernel-source rather than working with a virgin kernel.org tree. Find
attached a new patch, covering all 16 architectures. I don't know
what some of them are (i.e. "sh, "cris") but I am assuming they are
all hardware an all have memory busses.
> Can you add the other architectures or explain for each missing one,
> why this was not necessary? Maybe I am just stupid.
Nope, just me being stupid. :-)
b.
--
Brian J. Murrell
[-- Attachment #1.2: this.diff --]
[-- Type: text/plain, Size: 15654 bytes --]
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/alpha/defconfig linux-2.4.19-memory_bus/arch/alpha/defconfig
--- linux-2.4.19/arch/alpha/defconfig 2002-11-06 13:19:24.000000000 -0500
+++ linux-2.4.19-memory_bus/arch/alpha/defconfig 2002-11-06 13:20:26.000000000 -0500
@@ -51,6 +51,7 @@
# CONFIG_ALPHA_TAKARA is not set
# CONFIG_ALPHA_TITAN is not set
# CONFIG_ALPHA_WILDFIRE is not set
+CONFIG_MEMORY_BUS=y
CONFIG_ISA=y
CONFIG_EISA=y
# CONFIG_SBUS is not set
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/arm/defconfig linux-2.4.19-memory_bus/arch/arm/defconfig
--- linux-2.4.19/arch/arm/defconfig 2001-05-19 20:43:05.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/arm/defconfig 2002-11-06 13:20:34.000000000 -0500
@@ -71,6 +71,7 @@
# CONFIG_ANGELBOOT is not set
CONFIG_PCI_INTEGRATOR=y
CONFIG_PCI=y
+CONFIG_MEMORY_BUS=y
# CONFIG_ISA is not set
# CONFIG_ISA_DMA is not set
CONFIG_PCI_NAMES=y
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/cris/defconfig linux-2.4.19-memory_bus/arch/cris/defconfig
--- linux-2.4.19/arch/cris/defconfig 2002-08-02 20:39:42.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/cris/defconfig 2002-11-06 13:21:41.000000000 -0500
@@ -95,6 +95,7 @@
# CONFIG_ETRAX_IDE is not set
CONFIG_ETRAX_AXISFLASHMAP=y
CONFIG_ETRAX_PTABLE_SECTOR=65536
+CONFIG_MEMORY_BUS=y
CONFIG_MTD=y
CONFIG_MTD_CFI=y
# CONFIG_MTD_CFI_INTELEXT is not set
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/i386/defconfig linux-2.4.19-memory_bus/arch/i386/defconfig
--- linux-2.4.19/arch/i386/defconfig 2002-08-02 20:39:42.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/i386/defconfig 2002-11-06 13:21:50.000000000 -0500
@@ -71,6 +71,7 @@
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/ia64/defconfig linux-2.4.19-memory_bus/arch/ia64/defconfig
--- linux-2.4.19/arch/ia64/defconfig 2002-08-02 20:39:42.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/ia64/defconfig 2002-11-06 13:21:53.000000000 -0500
@@ -65,6 +65,7 @@
# CONFIG_ACPI_EC is not set
# CONFIG_ACPI_CMBATT is not set
# CONFIG_ACPI_THERMAL is not set
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
CONFIG_PCI_NAMES=y
# CONFIG_HOTPLUG is not set
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/m68k/defconfig linux-2.4.19-memory_bus/arch/m68k/defconfig
--- linux-2.4.19/arch/m68k/defconfig 2000-06-19 15:56:08.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/m68k/defconfig 2002-11-06 13:22:02.000000000 -0500
@@ -24,6 +24,7 @@
# CONFIG_SUN3X is not set
# CONFIG_SUN3 is not set
# CONFIG_Q40 is not set
+CONFIG_MEMORY_BUS=y
#
# Processor type
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/mips/defconfig linux-2.4.19-memory_bus/arch/mips/defconfig
--- linux-2.4.19/arch/mips/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/mips/defconfig 2002-11-06 13:22:12.000000000 -0500
@@ -90,6 +90,7 @@
CONFIG_FORWARD_KEYBOARD=y
# CONFIG_ARC_CONSOLE is not set
CONFIG_NET=y
+CONFIG_MEMORY_BUS=y
# CONFIG_PCI is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/mips64/defconfig linux-2.4.19-memory_bus/arch/mips64/defconfig
--- linux-2.4.19/arch/mips64/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/mips64/defconfig 2002-11-06 13:22:08.000000000 -0500
@@ -35,6 +35,7 @@
CONFIG_BOOT_ELF64=y
CONFIG_ARC64=y
CONFIG_MAPPED_PCI_IO=y
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
CONFIG_QL_ISP_A64=y
CONFIG_L1_CACHE_SHIFT=7
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/parisc/defconfig linux-2.4.19-memory_bus/arch/parisc/defconfig
--- linux-2.4.19/arch/parisc/defconfig 2000-12-05 15:29:39.000000000 -0500
+++ linux-2.4.19-memory_bus/arch/parisc/defconfig 2002-11-06 13:22:20.000000000 -0500
@@ -17,6 +17,7 @@
CONFIG_GSC=y
CONFIG_IOMMU_CCIO=y
CONFIG_GSC_LASI=y
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
CONFIG_GSC_DINO=y
CONFIG_PCI_LBA=y
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/ppc/defconfig linux-2.4.19-memory_bus/arch/ppc/defconfig
--- linux-2.4.19/arch/ppc/defconfig 2002-02-25 14:37:55.000000000 -0500
+++ linux-2.4.19-memory_bus/arch/ppc/defconfig 2002-11-06 13:22:27.000000000 -0500
@@ -47,6 +47,7 @@
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/ppc64/defconfig linux-2.4.19-memory_bus/arch/ppc64/defconfig
--- linux-2.4.19/arch/ppc64/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/ppc64/defconfig 2002-11-06 13:22:24.000000000 -0500
@@ -40,6 +40,7 @@
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
# CONFIG_EISA is not set
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/s390/defconfig linux-2.4.19-memory_bus/arch/s390/defconfig
--- linux-2.4.19/arch/s390/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/s390/defconfig 2002-11-06 13:22:38.000000000 -0500
@@ -9,6 +9,7 @@
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_GENERIC_BUST_SPINLOCK is not set
CONFIG_ARCH_S390=y
+CONFIG_MEMORY_BUS=y
#
# Code maturity level options
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/s390x/defconfig linux-2.4.19-memory_bus/arch/s390x/defconfig
--- linux-2.4.19/arch/s390x/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/s390x/defconfig 2002-11-06 13:22:43.000000000 -0500
@@ -9,6 +9,7 @@
# CONFIG_GENERIC_BUST_SPINLOCK is not set
CONFIG_ARCH_S390=y
CONFIG_ARCH_S390X=y
+CONFIG_MEMORY_BUS=y
#
# Code maturity level options
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/sh/defconfig linux-2.4.19-memory_bus/arch/sh/defconfig
--- linux-2.4.19/arch/sh/defconfig 2001-10-15 16:36:48.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/sh/defconfig 2002-11-06 13:23:12.000000000 -0500
@@ -49,6 +49,7 @@
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
+CONFIG_MEMORY_BUS=y
#
# Parallel port support
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/sparc/defconfig linux-2.4.19-memory_bus/arch/sparc/defconfig
--- linux-2.4.19/arch/sparc/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/sparc/defconfig 2002-11-06 13:23:19.000000000 -0500
@@ -43,6 +43,7 @@
CONFIG_SUN_PM=y
# CONFIG_SUN4 is not set
# CONFIG_PCI is not set
+CONFIG_MEMORY_BUS=y
CONFIG_SUN_OPENPROMFS=m
CONFIG_NET=y
CONFIG_SYSVIPC=y
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/arch/sparc64/defconfig linux-2.4.19-memory_bus/arch/sparc64/defconfig
--- linux-2.4.19/arch/sparc64/defconfig 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.19-memory_bus/arch/sparc64/defconfig 2002-11-06 13:23:15.000000000 -0500
@@ -42,6 +42,7 @@
CONFIG_SUN_CONSOLE=y
CONFIG_SUN_AUXIO=y
CONFIG_SUN_IO=y
+CONFIG_MEMORY_BUS=y
CONFIG_PCI=y
CONFIG_RTC=y
# CONFIG_PCI_NAMES is not set
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/drivers/mtd/chips/Config.in linux-2.4.19-memory_bus/drivers/mtd/chips/Config.in
--- linux-2.4.19/drivers/mtd/chips/Config.in 2001-10-04 18:13:18.000000000 -0400
+++ linux-2.4.19-memory_bus/drivers/mtd/chips/Config.in 2002-11-06 13:27:39.000000000 -0500
@@ -6,52 +6,53 @@
comment 'RAM/ROM/Flash chip drivers'
-dep_tristate ' Detect flash chips by Common Flash Interface (CFI) probe' CONFIG_MTD_CFI $CONFIG_MTD
-#dep_tristate ' Detect non-CFI Intel-compatible flash chips' CONFIG_MTD_INTELPROBE $CONFIG_MTD
-dep_tristate ' Detect non-CFI AMD/JEDEC-compatible flash chips' CONFIG_MTD_JEDECPROBE $CONFIG_MTD
-
-if [ "$CONFIG_MTD_CFI" = "y" -o "$CONFIG_MTD_INTELPROBE" = "y" -o "$CONFIG_MTD_JEDECPROBE" = "y" ]; then
- define_bool CONFIG_MTD_GEN_PROBE y
-else
- if [ "$CONFIG_MTD_CFI" = "m" -o "$CONFIG_MTD_INTELPROBE" = "m" -o "$CONFIG_MTD_JEDECPROBE" = "m" ]; then
- define_bool CONFIG_MTD_GEN_PROBE m
+if [ "$CONFIG_MEMORY_BUS" = "y" ]; then
+ dep_tristate ' Detect flash chips by Common Flash Interface (CFI) probe' CONFIG_MTD_CFI $CONFIG_MTD
+ #dep_tristate ' Detect non-CFI Intel-compatible flash chips' CONFIG_MTD_INTELPROBE $CONFIG_MTD
+ dep_tristate ' Detect non-CFI AMD/JEDEC-compatible flash chips' CONFIG_MTD_JEDECPROBE $CONFIG_MTD
+
+ if [ "$CONFIG_MTD_CFI" = "y" -o "$CONFIG_MTD_INTELPROBE" = "y" -o "$CONFIG_MTD_JEDECPROBE" = "y" ]; then
+ define_bool CONFIG_MTD_GEN_PROBE y
else
- define_bool CONFIG_MTD_GEN_PROBE n
+ if [ "$CONFIG_MTD_CFI" = "m" -o "$CONFIG_MTD_INTELPROBE" = "m" -o "$CONFIG_MTD_JEDECPROBE" = "m" ]; then
+ define_bool CONFIG_MTD_GEN_PROBE m
+ else
+ define_bool CONFIG_MTD_GEN_PROBE n
+ fi
fi
-fi
-if [ "$CONFIG_MTD_GEN_PROBE" = "y" -o "$CONFIG_MTD_GEN_PROBE" = "m" ]; then
- bool ' Flash chip driver advanced configuration options' CONFIG_MTD_CFI_ADV_OPTIONS
- if [ "$CONFIG_MTD_CFI_ADV_OPTIONS" = "y" ]; then
- choice 'Flash cmd/query data swapping' \
- "NO CONFIG_MTD_CFI_NOSWAP \
- BIG_ENDIAN_BYTE CONFIG_MTD_CFI_BE_BYTE_SWAP \
- LITTLE_ENDIAN_BYTE CONFIG_MTD_CFI_LE_BYTE_SWAP" NO
- bool ' Specific CFI Flash geometry selection' CONFIG_MTD_CFI_GEOMETRY
- if [ "$CONFIG_MTD_CFI_GEOMETRY" = "y" ]; then
- bool ' Support 8-bit buswidth' CONFIG_MTD_CFI_B1
- bool ' Support 16-bit buswidth' CONFIG_MTD_CFI_B2
- bool ' Support 32-bit buswidth' CONFIG_MTD_CFI_B4
- if [ "$CONFIG_MTD_CFI_B1" = "y" ]; then
- define_bool CONFIG_MTD_CFI_I1 y
- else
- bool ' Support 1-chip flash interleave' CONFIG_MTD_CFI_I1
- fi
- bool ' Support 2-chip flash interleave' CONFIG_MTD_CFI_I2
- bool ' Support 4-chip flash interleave' CONFIG_MTD_CFI_I4
+ if [ "$CONFIG_MTD_GEN_PROBE" = "y" -o "$CONFIG_MTD_GEN_PROBE" = "m" ]; then
+ bool ' Flash chip driver advanced configuration options' CONFIG_MTD_CFI_ADV_OPTIONS
+ if [ "$CONFIG_MTD_CFI_ADV_OPTIONS" = "y" ]; then
+ choice 'Flash cmd/query data swapping' \
+ "NO CONFIG_MTD_CFI_NOSWAP \
+ BIG_ENDIAN_BYTE CONFIG_MTD_CFI_BE_BYTE_SWAP \
+ LITTLE_ENDIAN_BYTE CONFIG_MTD_CFI_LE_BYTE_SWAP" NO
+ bool ' Specific CFI Flash geometry selection' CONFIG_MTD_CFI_GEOMETRY
+ if [ "$CONFIG_MTD_CFI_GEOMETRY" = "y" ]; then
+ bool ' Support 8-bit buswidth' CONFIG_MTD_CFI_B1
+ bool ' Support 16-bit buswidth' CONFIG_MTD_CFI_B2
+ bool ' Support 32-bit buswidth' CONFIG_MTD_CFI_B4
+ if [ "$CONFIG_MTD_CFI_B1" = "y" ]; then
+ define_bool CONFIG_MTD_CFI_I1 y
+ else
+ bool ' Support 1-chip flash interleave' CONFIG_MTD_CFI_I1
+ fi
+ bool ' Support 2-chip flash interleave' CONFIG_MTD_CFI_I2
+ bool ' Support 4-chip flash interleave' CONFIG_MTD_CFI_I4
+ fi
fi
- fi
-fi
-dep_tristate ' Support for Intel/Sharp flash chips' CONFIG_MTD_CFI_INTELEXT $CONFIG_MTD_GEN_PROBE
-dep_tristate ' Support for AMD/Fujitsu flash chips' CONFIG_MTD_CFI_AMDSTD $CONFIG_MTD_GEN_PROBE
-
-dep_tristate ' Support for RAM chips in bus mapping' CONFIG_MTD_RAM $CONFIG_MTD
-dep_tristate ' Support for ROM chips in bus mapping' CONFIG_MTD_ROM $CONFIG_MTD
-dep_tristate ' Support for absent chips in bus mapping' CONFIG_MTD_ABSENT $CONFIG_MTD
-
-bool ' Older (theoretically obsoleted now) drivers for non-CFI chips' CONFIG_MTD_OBSOLETE_CHIPS
-dep_tristate ' AMD compatible flash chip support (non-CFI)' CONFIG_MTD_AMDSTD $CONFIG_MTD $CONFIG_MTD_OBSOLETE_CHIPS
-dep_tristate ' pre-CFI Sharp chip support' CONFIG_MTD_SHARP $CONFIG_MTD $CONFIG_MTD_OBSOLETE_CHIPS
-dep_tristate ' JEDEC device support' CONFIG_MTD_JEDEC $CONFIG_MTD $CONFIG_MTD_OBSOLETE_CHIPS
+ fi
+ dep_tristate ' Support for Intel/Sharp flash chips' CONFIG_MTD_CFI_INTELEXT $CONFIG_MTD_GEN_PROBE
+ dep_tristate ' Support for AMD/Fujitsu flash chips' CONFIG_MTD_CFI_AMDSTD $CONFIG_MTD_GEN_PROBE
+ dep_tristate ' Support for RAM chips in bus mapping' CONFIG_MTD_RAM $CONFIG_MTD
+ dep_tristate ' Support for ROM chips in bus mapping' CONFIG_MTD_ROM $CONFIG_MTD
+ dep_tristate ' Support for absent chips in bus mapping' CONFIG_MTD_ABSENT $CONFIG_MTD
+
+ bool ' Older (theoretically obsoleted now) drivers for non-CFI chips' CONFIG_MTD_OBSOLETE_CHIPS
+ dep_tristate ' AMD compatible flash chip support (non-CFI)' CONFIG_MTD_AMDSTD $CONFIG_MTD $CONFIG_MTD_OBSOLETE_CHIPS
+ dep_tristate ' pre-CFI Sharp chip support' CONFIG_MTD_SHARP $CONFIG_MTD $CONFIG_MTD_OBSOLETE_CHIPS
+ dep_tristate ' JEDEC device support' CONFIG_MTD_JEDEC $CONFIG_MTD $CONFIG_MTD_OBSOLETE_CHIPS
+fi
endmenu
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/drivers/mtd/devices/Config.in linux-2.4.19-memory_bus/drivers/mtd/devices/Config.in
--- linux-2.4.19/drivers/mtd/devices/Config.in 2001-10-04 18:13:18.000000000 -0400
+++ linux-2.4.19-memory_bus/drivers/mtd/devices/Config.in 2002-11-06 13:27:39.000000000 -0500
@@ -10,7 +10,7 @@
bool ' PMC551 256M DRAM Bugfix' CONFIG_MTD_PMC551_BUGFIX
bool ' PMC551 Debugging' CONFIG_MTD_PMC551_DEBUG
fi
-dep_tristate ' Uncached system RAM' CONFIG_MTD_SLRAM $CONFIG_MTD
+dep_tristate ' Uncached system RAM' CONFIG_MTD_SLRAM $CONFIG_MTD "$CONFIG_MEMORY_BUS"
if [ "$CONFIG_SA1100_LART" = "y" ]; then
dep_tristate ' 28F160xx flash driver for LART' CONFIG_MTD_LART $CONFIG_MTD
fi
@@ -24,7 +24,8 @@
fi
dep_tristate ' MTD emulation using block device' CONFIG_MTD_BLKMTD $CONFIG_MTD
-comment 'Disk-On-Chip Device Drivers'
+if [ "$CONFIG_MEMORY_BUS" = "y" ]; then
+ comment 'Disk-On-Chip Device Drivers'
dep_tristate ' M-Systems Disk-On-Chip 1000' CONFIG_MTD_DOC1000 $CONFIG_MTD
dep_tristate ' M-Systems Disk-On-Chip 2000 and Millennium' CONFIG_MTD_DOC2000 $CONFIG_MTD
dep_tristate ' M-Systems Disk-On-Chip Millennium-only alternative driver (see help)' CONFIG_MTD_DOC2001 $CONFIG_MTD
@@ -50,6 +51,7 @@
bool ' Probe for 0x55 0xAA BIOS Extension Signature' CONFIG_MTD_DOCPROBE_55AA
fi
fi
+fi
endmenu
diff --exclude '*.swp' --exclude '*.orig' --exclude '*~' -Nur linux-2.4.19/drivers/mtd/nand/Config.in linux-2.4.19-memory_bus/drivers/mtd/nand/Config.in
--- linux-2.4.19/drivers/mtd/nand/Config.in 2001-10-04 18:13:18.000000000 -0400
+++ linux-2.4.19-memory_bus/drivers/mtd/nand/Config.in 2002-11-06 13:27:40.000000000 -0500
@@ -6,7 +6,7 @@
comment 'NAND Flash Device Drivers'
-dep_tristate ' NAND Device Support' CONFIG_MTD_NAND $CONFIG_MTD
+dep_tristate ' NAND Device Support' CONFIG_MTD_NAND $CONFIG_MTD "$CONFIG_MEMORY_BUS"
if [ "$CONFIG_MTD_NAND" = "y" -o "$CONFIG_MTD_NAND" = "m" ]; then
bool ' Enable ECC correction algorithm' CONFIG_MTD_NAND_ECC
bool ' Verify NAND page writes' CONFIG_MTD_NAND_VERIFY_WRITE
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: seeking help on JFFS2
From: Junping Zhang @ 2002-11-06 18:26 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
Thanks a lot. That one-line change worked, now under my cp/rm stress test,
JFFS2 doesn't
crash anymore, but I still crashed finally when I overflowed the file
system. My boss just asked
me to work on something else first, when I come back, I will generate the
dump for the new
oops.
Also, shouldn't unpoint() in mtd.h take four params? and MTD_UNPOINT() macro
doesn't seem
to be used by anyone.
Thanks everyone
- Junping
> -----Original Message-----
> From: David Woodhouse [SMTP:dwmw2@infradead.org]
> Sent: Wednesday, November 06, 2002 11:15 AM
> To: Junping Zhang
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: seeking help on JFFS2
>
>
> JZhang@erinc.com said:
> > 0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
> > 473 if (!(((struct
> cfi_pri_intelext*)cfi->cmdset_priv)->FeatureSupport & 2))
>
> Why didn't you say so before? :)
>
> cvs up
>
>
> --
> dwmw2
>
^ permalink raw reply
* Re: seeking help on JFFS2
From: David Woodhouse @ 2002-11-06 16:14 UTC (permalink / raw)
To: Junping Zhang; +Cc: linux-mtd
In-Reply-To: <F4608F665DF5D311B231009027B70F700131E269@MAIL>
JZhang@erinc.com said:
> 0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
> 473 if (!(((struct cfi_pri_intelext*)cfi->cmdset_priv)->FeatureSupport & 2))
Why didn't you say so before? :)
cvs up
--
dwmw2
^ permalink raw reply
* RE: seeking help on JFFS2
From: Junping Zhang @ 2002-11-06 16:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
David,
I changed mtd.h to make unpoint take four params, it doesn't seem to
have any effect.
So here is what I have:
linux-2.4.19 + shared-zlib patch + mtd-20021022 snapshot, but I
used the original
patchin.sh, so JFFS2 in 2.4.19 is used.
It always crashed at the same point in kernel.
Here is the oops, ksymoops result and the source lines.
Thanks a lot -- Junping
This is the oops message
========================
Oops: kernel access of bad area, sig: 11
NIP: C00E0008 XER: 00000000 LR: C00DFFB4 SP: C3E0DCC0 REGS: c3e0dc10 TRAP:
0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000005, DSISR: 20000000
TASK = c3e0c000[32] 'cp' Last syscall: 4
last math c3e0c000 last altivec 00000000
GPR00: C00E0004 C3E0DCC0 C3E0C000 80808080 C3F88560 C3F885E0 C3E0DCD4
00000010
GPR08: C3E0DDB0 00000000 00000000 00000010 00000000 10055EF0 00000000
C3ACFEC0
GPR16: C3E0DEBC C01CE670 C01CE670 00001000 C3E0DDB0 00000010 00000000
C3F885E0
GPR24: 0012E1D8 80808080 00005DDA 00000000 0012E1D8 C3F8861C C3F88560
00000010
Call backtrace:
C0013610 C00DDD38 C00E22B8 C00A62CC C00A6484 C00A2378 C002A024
C00375A4 C0005BBC FFFFFFFF 0FF2463C 0FF253A0 0FF1A1B0 1002FB8C
1002F874 1002F6A0 100056C4 1002F2C8 1002EF18 0FECEF70 00000000
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 180 seconds..
This is the oops through ksymoops
(on my mount nfs. MTD & JFFS2 are compiled in, so no modules)
=============================================================
# ./ksymoops -v ./vmlinux -m ./System.map oops.now
ksymoops 2.4.1 on ppc 2.4.19. Options used
-v ./vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.19/ (default)
-m ./System.map (specified)
/usr/bin/nm: not found
Error (pclose_local): read_nm_symbols pclose failed 0xff00
Warning (read_vmlinux): no kernel symbols in vmlinux, is ./vmlinux a valid
vmlinux file?
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod
file?
Warning (compare_maps): mismatch on symbol xchg_u32 , ksyms_base says
c000d300, System.map says c0008yOops: kernel access of bad area, sig: 11
NIP: C00E0008 XER: 00000000 LR: C00DFFB4 SP: C3E0DCC0 REGS: c3e0dc10 TRAP:
0300 Not tainted
Using defaults from ksymoops -t elf32-powerpc -a powerpc:common
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c3e0c000[32] 'cp' Last syscall: 4
last math c3e0c000 last altivec 00000000
GPR00: C00E0004 C3E0DCC0 C3E0C000 80808080 C3F88560 C3F885E0 C3E0DCD4
00000010
GPR08: C3E0DDB0 00000000 00000000 00000010 00000000 10055EF0 00000000
C3ACFEC0
GPR16: C3E0DEBC C01CE670 C01CE670 00001000 C3E0DDB0 00000010 00000000
C3F885E0
GPR24: 0012E1D8 80808080 00005DDA 00000000 0012E1D8 C3F8861C C3F88560
00000010
Call backtrace:
C0013610 C00DDD38 C00E22B8 C00A62CC C00A6484 C00A2378 C002A024
C00375A4 C0005BBC FFFFFFFF 0FF2463C 0FF253A0 0FF1A1B0 1002FB8C
1002F874 1002F6A0 100056C4 1002F2C8 1002EF18 0FECEF70 00000000
Kernel panic: Aiee, killing interrupt handler!
Warning (Oops_read): Code line not seen, dumping what data is available
>>NIP; c00e0008 <do_read_onechip+b8/4ec> <=====
Trace; c0013610 <call_console_drivers+a0/168>
Trace; c00ddd38 <cfi_intelext_read+b4/100>
Trace; c00e22b8 <part_read+68/a0>
Trace; c00a62cc <writecheck+34/12c>
Trace; c00a6484 <jffs2_write_dnode+c0/2b4>
Trace; c00a2378 <jffs2_commit_write+364/614>
Trace; c002a024 <generic_file_write+49c/7ac>
Trace; c00375a4 <sys_write+bc/150>
Trace; c0005bbc <ret_from_syscall_1+0/b4>
Trace; ffffffff <END_OF_CODE+3fe0f237/????>
Trace; 0ff2463c Before first symbol
Trace; 0ff253a0 Before first symbol
Trace; 0ff1a1b0 Before first symbol
Trace; 1002fb8c Before first symbol
Trace; 1002f874 Before first symbol
Trace; 1002f6a0 Before first symbol
Trace; 100056c4 Before first symbol
Trace; 1002f2c8 Before first symbol
Trace; 1002ef18 Before first symbol
Trace; 0fecef70 Before first symbol
Trace; 00000000 Before first symbol
4 warnings and 1 error issued. Results may not be reliable.
This is the source positions for the oops (for the last four)
=============================================================
I don't know how call_console_drivers got in the trace ...
(gdb) l *0xc00e0008
0xc00e0008 is in do_read_onechip (cfi_cmdset_0001.c:473).
468 /* Check that the chip's ready to talk to us.
469 * If it's in FL_ERASING state, suspend it and make it talk now.
470 */
471 switch (chip->state) {
472 case FL_ERASING:
473 if (!(((struct cfi_pri_intelext
*)cfi->cmdset_priv)->FeatureSupport & 2))
474 goto sleep; /* We don't support erase suspend */
475
476 cfi_write (map, CMD(0xb0), cmd_addr);
477 /* If the flash has finished erasing, then 'erase suspend'
(gdb) l *0xc0013610
0xc0013610 is in call_console_drivers (printk.c:379).
374 start_print = cur_index;
375 break;
376 }
377 }
378 }
379 _call_console_drivers(start_print, end, msg_level);
380 }
381
382 static void emit_log_char(char c)
383 {
(gdb) l *0xc00ddd38
0xc00ddd38 is in cfi_intelext_read (cfi_cmdset_0001.c:607).
602 if ((len + ofs -1) >> cfi->chipshift)
603 thislen = (1<<cfi->chipshift) - ofs;
604 else
605 thislen = len;
606
607 ret = do_read_onechip(map, &cfi->chips[chipnum], ofs, thislen,
buf);
608 if (ret)
609 break;
610
611 *retlen += thislen;
(gdb) l *0xc00e22b8
0xc00e22b8 is in part_read (mtdpart.c:57).
52 struct mtd_part *part = PART(mtd);
53 if (from >= mtd->size)
54 len = 0;
55 else if (from + len > mtd->size)
56 len = mtd->size - from;
57 return part->master->read (part->master, from + part->offset,
58 len, retlen, buf);
59 }
60
61 static int part_point (struct mtd_info *mtd, loff_t from, size_t len,
(gdb)
> -----Original Message-----
> From: David Woodhouse [SMTP:dwmw2@infradead.org]
> Sent: Tuesday, November 05, 2002 4:37 PM
> To: Junping Zhang
> Subject: Re: seeking help on JFFS2
>
>
> JZhang@erinc.com said:
> > Here is the oops message through ksymoops:
>
> Can you show the whole oops, preferably also using gdb to identify the
> precise line of code.
>
> --
> dwmw2
>
^ permalink raw reply
* RE: MTD newbie wants programming a 28F800 with a 2.2.18 kernel
From: Jeffrey Lim @ 2002-11-06 15:56 UTC (permalink / raw)
To: Gettert, Wolfram; +Cc: linux-mtd
On Wed, 6 Nov 2002 13:56:46 +0100, "Gettert, Wolfram"
<Wolfram.Gettert@fci.com> said:
>
> Do you try to tell me not to use the patch but getting the most recent
> MTD
> code from 2.5.x and get it running under 2.2.18?
> Perhaps it's just the easiest way? Of course I get the best MTD code.
>
>
> Wolfram
>
yes - why not? The CVS code is for the most part the best code to get,
since any corrections for any earlier code will be incorporated here.
Unless you're sure that you have something already working, or that the
CVS has a problem, you should always consider taking a look at the CVS...
-jf
> > -----Original Message-----
> > From: Jörn Engel [mailto:joern@wohnheim.fh-wedel.de]
> > Sent: Mittwoch, 6. November 2002 10:27
> > To: Gettert, Wolfram
> > Cc: 'linux-mtd@lists.infradead.org'
> > Subject: Re: MTD newbie wants programming a 28F800 with a
> > 2.2.18 kernel
> >
> > On Wed, 6 November 2002 09:25:25 +0100, Gettert, Wolfram wrote:
> > > I am completely new to MTD. My job is to program a 28F800
> > boot block flash
> > > running a 2.2.18 kernel.
> > > ...
> >
> > As always, bugging the company to finally upgrade to a recent kernel
> > is a good thing, although unrealistic. :-)
> >
> > Most of the mtd code in cvs should be running on any kernel from 2.2.0
> > up to 2.5.current. David has done an excellent job there. So you
> > should take a peek into cvs, whenever you have a problem.
> >
> > Apart from that, try to cut down on the number of #ifdefs, consider
> > sending a patch to David and good luck!
> >
> > Jörn
> >
> > --
> > Everything should be made as simple as possible, but not simpler.
> > -- Albert Einstein
> >
--
"It's an extraordinary world!" - jfsworld <at> fastmail.fm
^ permalink raw reply
* Re: cfi_cmdset_0020.c
From: Jörn Engel @ 2002-11-06 15:46 UTC (permalink / raw)
To: J B; +Cc: linux-mtd
In-Reply-To: <F147brL1SCeX8KShPdH00000308@hotmail.com>
On Wed, 6 November 2002 09:03:03 -0600, J B wrote:
[one big block without structure, oh well] ;-)
The M58LW064A chips has two sizes that might be confused but are
orthogonal in semantics:
- Buffer size. When writing to flash, data is copied into a write
buffer and then written to flash by the chip itself.
- Page size. The ecc checksum is written to flash itself. This is done
for one page (8 bytes) at a time. Due to ecc, it can only be written
once before deleting the erase block again.
Writing it again would cause some some ecc bits to switch from 0 to
1, impossible for flash.
> I have a couple of questions reguarding the patch you released a while
> ago to support the M58LW064A STMicro flash chip. I noticed that you set
> the eccsize in the mtd_info structure to 8, and in your patch for jffs2,
> you used this as the size of the wbuf for writes in nor_wbuf.c. Isn't this
> value really the minimum buffer size for the flash chip?
This is the page size. In effect, it also is the minimum buffer size,
yes. And it is the granularity that ecc checksums are calculated from.
> If so, since your
> patch for jffs2 is based on NAND chips, wouldn't it make more sense to use
> the oobblock variable in the mtd_info structure to represent the size of
> the buffer?
Maybe, but you have to try really hard convincing me. You can view the
checksum as oob data, but there is no way to take a look at the data
or even change it. For NAND, as I understand it, the oob data is used
to store data in, the erasemarkers e.g.
And, the eccsize variable appeared to be unused. David didn't object,
so in effect I defined eccsize to be pagesize for NOR flashes. :-)
> There could be other reasons you used eccsize that I am
> missing and if so please forgive my ignorance ;). Also, is there a reason
> you decided to use the minimum buffer size for the wbuf?
The write buffer is a Bad Thing (tm). Try writing to flash, cut the
power, reboot and look at the messages. The last chunk of data will be
missing in 7 out of 8 cases.
The smaller the write buffer is, the better. Zero would be perfect,
but the chip does not allow us to go below 8.
> According to the
> datasheet for those chips, the buffer can hold up to 32 bytes. Wouldn't
> using the maximum buffer available make things more efficient?
32 bytes are used for writing (at least I think so, should check it
again). The write buffer is a different beast, it is the amount of
data that is held back and not written, in case your write doesn't end
on a page boundary.
The ecc chips take some time before you really understand what they
are doing. And the data cheet is not as clear, as it could be. But I
hope, this explains the most important bits to you.
Jörn
--
Fantasy is more important than knowlegde. Knowlegde is limited,
while fantasy embraces the whole world.
-- Albert Einstein
^ permalink raw reply
* Re: MTD newbie wants programming a 28F800 with a 2.2.18 kernel
From: Jörn Engel @ 2002-11-06 15:23 UTC (permalink / raw)
To: Gettert, Wolfram; +Cc: 'linux-mtd@lists.infradead.org'
In-Reply-To: <9CFB9DA5261CD611A29B00508B789048380A49@ex-deu-munich02.force.de>
On Wed, 6 November 2002 13:56:46 +0100, Gettert, Wolfram wrote:
>
> Do you try to tell me not to use the patch but getting the most recent MTD
> code from 2.5.x and get it running under 2.2.18?
> Perhaps it's just the easiest way? Of course I get the best MTD code.
The patch was mtd-patch-2.2.18-20001218-2230GMT, right?
^^^^^^^^
Dezember 2000 sound a bit old. You can of course use it, but I would
either look for a newer patch or create one myself, yes.
You also might want to look through the mailing list archive a bit.
2.2.x questions are rare but they do happen from time to time. And the
archive has more knowledge than I do. :-)
Jörn
--
"Security vulnerabilities are here to stay."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
^ permalink raw reply
* cfi_cmdset_0020.c
From: J B @ 2002-11-06 15:03 UTC (permalink / raw)
To: joern; +Cc: linux-mtd
Jörn,
I have a couple of questions reguarding the patch you released a while
ago to support the M58LW064A STMicro flash chip. I noticed that you set the
eccsize in the mtd_info structure to 8, and in your patch for jffs2, you
used this as the size of the wbuf for writes in nor_wbuf.c. Isn't this
value really the minimum buffer size for the flash chip? If so, since your
patch for jffs2 is based on NAND chips, wouldn't it make more sense to use
the oobblock variable in the mtd_info structure to represent the size of the
buffer? There could be other reasons you used eccsize that I am missing and
if so please forgive my ignorance ;). Also, is there a reason you decided
to use the minimum buffer size for the wbuf? According to the datasheet for
those chips, the buffer can hold up to 32 bytes. Wouldn't using the maximum
buffer available make things more efficient?
Thanks,
J
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
^ permalink raw reply
* RE: seeking help on JFFS2
From: Junping Zhang @ 2002-11-06 13:13 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd
I specified CONFIG_MTD_CFI_INTELEXT only. Here is that section in .config
-----------------------------------------------------------
# CONFIG_MTD_CFI is not set
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
# CONFIG_MTD_CFI_B1 is not set
# CONFIG_MTD_CFI_B2 is not set
CONFIG_MTD_CFI_B4=y
# CONFIG_MTD_CFI_B8 is not set
# CONFIG_MTD_CFI_I1 is not set
# CONFIG_MTD_CFI_I2 is not set
CONFIG_MTD_CFI_I4=y
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
# CONFIG_MTD_RAM is not set
CONFIG_MTD_ROM=y
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
--------------------------------------
Since in xconfig, it has Intel/Sharp in the option together and my chips
have Sharp printed on it, I guess
it's right. Also, I referenced the .config file from Christian, who made
JFFS2 work for 2.4.4 (from denx) and
some older version of mtd, so I think the setup is ok.
Before I chase the source of the crashed trace, I want to look at something
I had to change to make it
compile, now seems to co-relate with my crash. I had to change mtdpart.c's
part_unpoint() to make
unpoint() only pass two parameters because mtd_info structure dictates it,
but in cfi_cmdset_0001.c,
the do_unpoint, which has four params, is assigned to unpoint func ptr
(warning in compile). It looks wrong
to me, and all those files are sym-linked from mtd-20021022 snapshot, can
you guys verify it's really
an inconsistancy, not my mistake?
When I stress test JFFS2 subsystem from 2.4.19 kernel, it seems to me it
always crashs at the beginning
of the 2nd cycle. I have a 7M JFFS2, and I copy 3M stuff on it, remove it,
and do it again, it always fails at
the 4th time, which, onsidering zlib compression on binary files, seems to
be the next cycle.
I will later provide the oops with the source lines.
Thanks a lot
- Junping
> -----Original Message-----
> From: Jörn Engel [SMTP:joern@wohnheim.fh-wedel.de]
> Sent: Tuesday, November 05, 2002 4:09 PM
> To: Junping Zhang
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: seeking help on JFFS2
>
> On Tue, 5 November 2002 14:56:56 -0500, Junping Zhang wrote:
> >
> > I just tested 2.4.19 with shared-zlib patch, same behavior. I could
> use
> > the JFFS2 system,
> > but it will eventually crash after a while.
> >
> > The flash chip is original from Motorola: 8M, 80 pin SIMM, SM73228. I
> > used Christian's
> > map file. Since JFFS works on it without any problem, should I safely
> assume
> > the MTD layer
> > is correct?
>
> Ok, glancing at the spec, it said something about being compatible to
> Am29F040 chips, which use the amd command set. And looking back at the
> trace, we see
> Trace; c00df668 <cfi_intelext_read+b4/100>
> ^^^^^
> This is strange.
>
> Have you configured only CONFIG_MTD_CFI_AMDSTD, only
> CONFIG_MTD_CFI_INTELEXT or both?
>
> Jörn
>
> --
> The competent programmer is fully aware of the strictly limited size of
> his own skull; therefore he approaches the programming task in full
> humility, and among other things he avoids clever tricks like the plague.
> -- Edsger W. Dijkstra
^ permalink raw reply
* RE: MTD newbie wants programming a 28F800 with a 2.2.18 kernel
From: Gettert, Wolfram @ 2002-11-06 12:56 UTC (permalink / raw)
To: 'linux-mtd@lists.infradead.org'
> -----Original Message-----
> From: Jörn Engel [mailto:joern@wohnheim.fh-wedel.de]
> Sent: Mittwoch, 6. November 2002 10:27
> To: Gettert, Wolfram
> Cc: 'linux-mtd@lists.infradead.org'
> Subject: Re: MTD newbie wants programming a 28F800 with a
> 2.2.18 kernel
>
>
> On Wed, 6 November 2002 09:25:25 +0100, Gettert, Wolfram wrote:
> > I am completely new to MTD. My job is to program a 28F800
> boot block flash
> > running a 2.2.18 kernel.
> > I am using this patch mtd-patch-2.2.18-20001218-2230GMT.
> Since there is no
> > support for the 28F800 because it has CUI not CFI I need
> to write the
> > driver for the CUI. I found the lart-driver (lart.c) in the
> 2.5.x sources
> > which can manage a 28F160 (which is compatible to 28F800).
> >
> > Do you know of any implementation of the lart-driver on a
> 2.2.x kernel?
> > Since the mtd_info structure has changed extensively from
> the 2.2.18-patch
> > to 2.5.x there is a lot of work to-do.
>
> As always, bugging the company to finally upgrade to a recent kernel
> is a good thing, although unrealistic. :-)
>
> Most of the mtd code in cvs should be running on any kernel from 2.2.0
> up to 2.5.current. David has done an excellent job there. So you
> should take a peek into cvs, whenever you have a problem.
>
> Apart from that, try to cut down on the number of #ifdefs, consider
> sending a patch to David and good luck!
>
> Jörn
>
> --
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
Do you try to tell me not to use the patch but getting the most recent MTD
code from 2.5.x and get it running under 2.2.18?
Perhaps it's just the easiest way? Of course I get the best MTD code.
Wolfram
^ permalink raw reply
* jffs2 root file system erased during boot
From: David @ Netvision @ 2002-11-06 11:48 UTC (permalink / raw)
To: linux-mtd
Hi All,
I am trying to bring up arm linux-2.5.30-rmk1-pxa1.
I Mapped jffs2 root file system (bootstrap.jffs2 Downloaded from
familiar project) as mtdblock2 and defined that
this is the root file system.
The boot fails because the kernel can't find init, and the kernel
erasing the entire file system.
Any idea what may cause this?
The console output is bellow.
/*******************************************************************************\
Linux version 2.5.30-rmk1-pxa1 (root@TESTLIN) (gcc version 3.2) #40 Mon
Sep 30 13:27:50 IDT 2002
CPU: Intel XScale-PXA250 revision 3
CPU: D undefined 5 cache
CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Machine: Intel DBPXA250 Development Platform
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,38400n8 root=/dev/mtdblock2
Calibrating delay loop... 99.12 BogoMIPS
Memory: 16MB = 16MB total
Memory: 14596KB available (1317K code, 218K data, 56K init)
Security Scaffold v1.0.0 initialized
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec: init pool 0, 1 entries, 12 bytes
biovec: init pool 1, 4 entries, 48 bytes
biovec: init pool 2, 16 entries, 192 bytes
biovec: init pool 3, 64 entries, 768 bytes
biovec: init pool 4, 128 entries, 1536 bytes
biovec: init pool 5, 256 entries, 3072 bytes
Journalled Block Device driver loaded
JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc.
Capability LSM initialized
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
ttyS0 at (irq = 14) is a PXA
pty: 256 Unix98 ptys configured
block: 32 slots per queue, batch=8
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Probing Lubbock flash at physical address 0x00000000
Using static partition definition
Creating 4 MTD partitions on "Lubbock flash":
0x00000000-0x00100000 : "ArmBoot"
mtd: Giving out device 0 to ArmBoot
0x00100000-0x00200000 : "Kernel Image"
mtd: Giving out device 1 to Kernel Image
0x00200000-0x01000000 : "Root Filesystem"
mtd: Giving out device 2 to Root Filesystem
0x01000000-0x01200000 : "Other Filesystem"
mtd: Giving out device 3 to Other Filesystem
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
mtdblock_open
ok
mtdblock: read on "Root Filesystem" at 0x400, size 0x400
mtdblock_release
ok
mtdblock_open
ok
mtdblock: read on "Root Filesystem" at 0x400, size 0x400
mtdblock_release
ok
mtdblock_open
ok
VFS: Mounted root (jffs filesystem) readonly.
Freeing init memory: 56K
Warning: unable to open an initial console.
Kernel panic: No init found. Try passing init= option to kernel.
/**********************************************************************\
Thanks,
David
^ permalink raw reply
* Re: MTD newbie wants programming a 28F800 with a 2.2.18 kernel
From: Jörn Engel @ 2002-11-06 9:26 UTC (permalink / raw)
To: Gettert, Wolfram; +Cc: 'linux-mtd@lists.infradead.org'
In-Reply-To: <9CFB9DA5261CD611A29B00508B789048380A47@ex-deu-munich02.force.de>
On Wed, 6 November 2002 09:25:25 +0100, Gettert, Wolfram wrote:
> I am completely new to MTD. My job is to program a 28F800 boot block flash
> running a 2.2.18 kernel.
> I am using this patch mtd-patch-2.2.18-20001218-2230GMT. Since there is no
> support for the 28F800 because it has CUI not CFI I need to write the
> driver for the CUI. I found the lart-driver (lart.c) in the 2.5.x sources
> which can manage a 28F160 (which is compatible to 28F800).
>
> Do you know of any implementation of the lart-driver on a 2.2.x kernel?
> Since the mtd_info structure has changed extensively from the 2.2.18-patch
> to 2.5.x there is a lot of work to-do.
As always, bugging the company to finally upgrade to a recent kernel
is a good thing, although unrealistic. :-)
Most of the mtd code in cvs should be running on any kernel from 2.2.0
up to 2.5.current. David has done an excellent job there. So you
should take a peek into cvs, whenever you have a problem.
Apart from that, try to cut down on the number of #ifdefs, consider
sending a patch to David and good luck!
Jörn
--
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
^ permalink raw reply
* Re: [PATCH] patches/patchin.sh (was Re: MTD CVS: missing JFFS2?)
From: Jeffrey Lim @ 2002-11-06 8:40 UTC (permalink / raw)
To: Dave; +Cc: linux-mtd list, jfsworld
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
Sorry there - here's the missing patch (attached)
-jf
On Wed, 6 Nov 2002 02:09:32 UT, "Jeffrey Lim" <jfsworld@fastmail.fm>
said:
> Hi David,
>
> referencing the email below, this is a simple patch to patches/patchin.sh
> (dated in the CVS Wed Apr 25 12:10:23 2001) to "patch in" the jffs2 code
> as well. Currently patchin.sh only patches in the latest mtd code, and
> jffs, but not jffs*2*)
>
> Would you mind looking over the diff to see if i missed out anything that
> should be patched in as well?
> Thanks.
>
> -jf
>
> On Tue, 5 Nov 2002 20:27:22 +0100, "Jörn Engel"
> <joern@wohnheim.fh-wedel.de> said:
> > On Tue, 5 November 2002 17:21:24 +0000, Jeffrey Lim wrote:
> > >
> > > I assume David Woodhouse is the person to whom i should submit the patch
> > > to patchin.sh to? (oh boy).
> >
> > Correct. It would be nice, if you cc'd the mailinglist as well.
> >
> > > I'll have a patch ready first thing i get to work later.
> >
> > Cool!
> >
> > Jörn
> >
> > --
> > ticks = jiffies;
> > while (ticks == jiffies);
> > ticks = jiffies;
> > -- /usr/src/linux/init/main.c
> >
>
>
> --
> "It's an extraordinary world!" - jfsworld <at> fastmail.fm
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
"It's an extraordinary world!" - jfsworld <at> fastmail.fm
[-- Attachment #2: patchin.sh.diff --]
[-- Type: application/unknown, Size: 219 bytes --]
^ permalink raw reply
* MTD newbie wants programming a 28F800 with a 2.2.18 kernel
From: Gettert, Wolfram @ 2002-11-06 8:25 UTC (permalink / raw)
To: 'linux-mtd@lists.infradead.org'
Hallo
I am completely new to MTD. My job is to program a 28F800 boot block flash
running a 2.2.18 kernel.
I am using this patch mtd-patch-2.2.18-20001218-2230GMT. Since there is no
support for the 28F800 because it has CUI not CFI I need to write the
driver for the CUI. I found the lart-driver (lart.c) in the 2.5.x sources
which can manage a 28F160 (which is compatible to 28F800).
Do you know of any implementation of the lart-driver on a 2.2.x kernel?
Since the mtd_info structure has changed extensively from the 2.2.18-patch
to 2.5.x there is a lot of work to-do.
THX
Wolfram
--
Wolfram Gettert
Software Engineer
Force Computers GmbH
- A Solectron Company -
Lilienthalstr. 15
D-85579 Neubiberg/München
email: Wolfram.Gettert@fci.com
www.forcecomputers.com
^ permalink raw reply
* Re: [PATCH] patches/patchin.sh (was Re: MTD CVS: missing JFFS2?)
From: Jeffrey Lim @ 2002-11-06 2:30 UTC (permalink / raw)
To: Dave; +Cc: linux-mtd list
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
Sorry - i must have forgotten to attach the patch.
-jf
On Wed, 6 Nov 2002 02:09:32 UT, "Jeffrey Lim" <jfsworld@fastmail.fm>
said:
> Hi David,
>
> referencing the email below, this is a simple patch to patches/patchin.sh
> (dated in the CVS Wed Apr 25 12:10:23 2001) to "patch in" the jffs2 code
> as well. Currently patchin.sh only patches in the latest mtd code, and
> jffs, but not jffs*2*)
>
> Would you mind looking over the diff to see if i missed out anything that
> should be patched in as well?
> Thanks.
>
> -jf
>
> On Tue, 5 Nov 2002 20:27:22 +0100, "Jörn Engel"
> <joern@wohnheim.fh-wedel.de> said:
> > On Tue, 5 November 2002 17:21:24 +0000, Jeffrey Lim wrote:
> > >
> > > I assume David Woodhouse is the person to whom i should submit the patch
> > > to patchin.sh to? (oh boy).
> >
> > Correct. It would be nice, if you cc'd the mailinglist as well.
> >
> > > I'll have a patch ready first thing i get to work later.
> >
> > Cool!
> >
> > Jörn
> >
> > --
> > ticks = jiffies;
> > while (ticks == jiffies);
> > ticks = jiffies;
> > -- /usr/src/linux/init/main.c
> >
>
>
> --
> "It's an extraordinary world!" - jfsworld <at> fastmail.fm
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
"It's an extraordinary world!" - jfsworld <at> fastmail.fm
[-- Attachment #2: patchin.sh.diff --]
[-- Type: application/unknown, Size: 219 bytes --]
^ permalink raw reply
* [PATCH] patches/patchin.sh (was Re: MTD CVS: missing JFFS2?)
From: Jeffrey Lim @ 2002-11-06 2:09 UTC (permalink / raw)
To: Dave; +Cc: linux-mtd list
Hi David,
referencing the email below, this is a simple patch to patches/patchin.sh
(dated in the CVS Wed Apr 25 12:10:23 2001) to "patch in" the jffs2 code
as well. Currently patchin.sh only patches in the latest mtd code, and
jffs, but not jffs*2*)
Would you mind looking over the diff to see if i missed out anything that
should be patched in as well?
Thanks.
-jf
On Tue, 5 Nov 2002 20:27:22 +0100, "Jörn Engel"
<joern@wohnheim.fh-wedel.de> said:
> On Tue, 5 November 2002 17:21:24 +0000, Jeffrey Lim wrote:
> >
> > I assume David Woodhouse is the person to whom i should submit the patch
> > to patchin.sh to? (oh boy).
>
> Correct. It would be nice, if you cc'd the mailinglist as well.
>
> > I'll have a patch ready first thing i get to work later.
>
> Cool!
>
> Jörn
>
> --
> ticks = jiffies;
> while (ticks == jiffies);
> ticks = jiffies;
> -- /usr/src/linux/init/main.c
>
--
"It's an extraordinary world!" - jfsworld <at> fastmail.fm
^ permalink raw reply
* Building mkfs.jffs2
From: Darren Freeman @ 2002-11-06 8:20 UTC (permalink / raw)
To: Linux MTD List; +Cc: Greg Knowles
Dear list,
I am trying to build the latest version of mkfs.jffs2 on either of two
PCs running RedHat 7.2 and Mandrake 9.0 respectively.
The problem with the binary mkfs.jffs2 that I have right now is that I
upgraded from a really really old kernel on the target (around 2.4.2) up
to 2.4.20-rmk1 and according to the kernel at boot time, JFFS2 has
changed enough to cause problems.
The symptoms are that I can flash an image and use it for a little
while, but after a small amount of writing (change text files etc.) the
filesystem just screws up and becomes 100% full. From that point onwards
the target is screwed, and only NFS has saved me. Unfortunately with a
broken root filesystem I can't get too much done =)
The RedHat host is running the stock kernel, 2.4.2, and I've configured
the kernel for JFFS2 but not recompiled it. The Mandrake box is running
2.4.20 recompiled to my liking.
The target is an EPXA10 development board, with cpu=ARM922T,
kernel=2.4.19-rmk1 patched for the board.
I simply can't get mtd/utils to build on either host. I don't want a
cross-compiled binary, just something to use on the host. I have tried
using ./configure --with-kernel= pointing to the host kernel or target
but no success. I guess the target kernel is the correct one to use
here.
My latest problem is that mkfs.jffs2.c uses jint16_t which is not found
when grepping through my kernel source but is in mtd. So I have to do
--with-kernel=/path/mtd but finally I get the error:
compr_zlib.c:15:2: #error "The userspace support got too messy and was
removed. Update your mkfs.jffs2"
Followed by tons of garbage.
Any ideas? Or somebody willing to give me a binary of mkfs.jffs2 for
i386 -> ARM9 ? I would greatly appreciate it!
Have fun,
Darren Freeman
^ permalink raw reply
* Re: seeking help on JFFS2
From: Jörn Engel @ 2002-11-05 21:08 UTC (permalink / raw)
To: Junping Zhang; +Cc: linux-mtd
In-Reply-To: <F4608F665DF5D311B231009027B70F700131DF9D@MAIL>
On Tue, 5 November 2002 14:56:56 -0500, Junping Zhang wrote:
>
> I just tested 2.4.19 with shared-zlib patch, same behavior. I could use
> the JFFS2 system,
> but it will eventually crash after a while.
>
> The flash chip is original from Motorola: 8M, 80 pin SIMM, SM73228. I
> used Christian's
> map file. Since JFFS works on it without any problem, should I safely assume
> the MTD layer
> is correct?
Ok, glancing at the spec, it said something about being compatible to
Am29F040 chips, which use the amd command set. And looking back at the
trace, we see
Trace; c00df668 <cfi_intelext_read+b4/100>
^^^^^
This is strange.
Have you configured only CONFIG_MTD_CFI_AMDSTD, only
CONFIG_MTD_CFI_INTELEXT or both?
Jörn
--
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague.
-- Edsger W. Dijkstra
^ permalink raw reply
* RE: seeking help on JFFS2
From: Junping Zhang @ 2002-11-05 19:56 UTC (permalink / raw)
To: Jörn Engel, Junping Zhang; +Cc: linux-mtd
Jörn,
I just tested 2.4.19 with shared-zlib patch, same behavior. I could use
the JFFS2 system,
but it will eventually crash after a while.
The flash chip is original from Motorola: 8M, 80 pin SIMM, SM73228. I
used Christian's
map file. Since JFFS works on it without any problem, should I safely assume
the MTD layer
is correct?
I appreciate your thought, but my company won't let me give people
direct access. I will
check out the latest MTD from cvs tonight and give it a try tomorrow.
Thanks
- Junping
> -----Original Message-----
> From: Jörn Engel [SMTP:joern@wohnheim.fh-wedel.de]
> Sent: Tuesday, November 05, 2002 2:31 PM
> To: Junping Zhang
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: seeking help on JFFS2
>
> On Tue, 5 November 2002 12:39:31 -0500, Junping Zhang wrote:
> > Yes, the minor number is 2, and I checked mkfs.jffs2 source, hex is ok.
> I
> > also tried with
> > the method you mentioned, the crashed happened right away.
>
> Ok.
>
> > I just tried using the stock JFFS2 in 2.4.18 kernel. It actually got me
> > further than JFFS2
> > in my mtd-20021022 snapshot, I could use either image or direct mount to
> > create JFFS2,
> > but it still crashed under stress test. On the other hand, JFFS works
> quite
> > well.
>
> Ok.
>
> > Does stock 2.4.19 have a stable JFFS2 without patch? I downloaded a
> > shared-zlib patch
> > for 2.4.19-pre10 but am not sure it will fix my JFFS2 problem.
>
> 2.4.19 should have a stable jffs2, as should 2.4.18. You can try
> 2.4.19, but I don't expect any better behaviour.
>
> What flashes do you exactly use? And can you provide ssh login to the
> development host?
>
> Jörn
>
> --
> If you're willing to restrict the flexibility of your approach,
> you can almost always do something better.
> -- John Carmack
^ permalink raw reply
* Re: seeking help on JFFS2
From: Jörn Engel @ 2002-11-05 19:32 UTC (permalink / raw)
To: Jeffrey Lim; +Cc: Junping Zhang, linux-mtd
In-Reply-To: <20021105171709.3BC642FD77@server4.fastmail.fm>
On Tue, 5 November 2002 17:17:12 +0000, Jeffrey Lim wrote:
> I believe there shouldnt be a problem with passing hex to it - the code
> uses strtol() to recognize both decimal and hex.
Makes sense. Hm. I wonder what has hit me back then. Strange.
Jörn
--
A surrounded army must be given a way out.
-- Sun Tzu
^ permalink raw reply
* Re: seeking help on JFFS2
From: Jörn Engel @ 2002-11-05 19:31 UTC (permalink / raw)
To: Junping Zhang; +Cc: linux-mtd
In-Reply-To: <F4608F665DF5D311B231009027B70F700131DEB6@MAIL>
On Tue, 5 November 2002 12:39:31 -0500, Junping Zhang wrote:
> Yes, the minor number is 2, and I checked mkfs.jffs2 source, hex is ok. I
> also tried with
> the method you mentioned, the crashed happened right away.
Ok.
> I just tried using the stock JFFS2 in 2.4.18 kernel. It actually got me
> further than JFFS2
> in my mtd-20021022 snapshot, I could use either image or direct mount to
> create JFFS2,
> but it still crashed under stress test. On the other hand, JFFS works quite
> well.
Ok.
> Does stock 2.4.19 have a stable JFFS2 without patch? I downloaded a
> shared-zlib patch
> for 2.4.19-pre10 but am not sure it will fix my JFFS2 problem.
2.4.19 should have a stable jffs2, as should 2.4.18. You can try
2.4.19, but I don't expect any better behaviour.
What flashes do you exactly use? And can you provide ssh login to the
development host?
Jörn
--
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
^ permalink raw reply
* Re: MTD CVS: missing JFFS2?
From: Jörn Engel @ 2002-11-05 19:27 UTC (permalink / raw)
To: Jeffrey Lim; +Cc: linux-mtd list
In-Reply-To: <20021105172124.324302FD78@server4.fastmail.fm>
On Tue, 5 November 2002 17:21:24 +0000, Jeffrey Lim wrote:
>
> I assume David Woodhouse is the person to whom i should submit the patch
> to patchin.sh to? (oh boy).
Correct. It would be nice, if you cc'd the mailinglist as well.
> I'll have a patch ready first thing i get to work later.
Cool!
Jörn
--
ticks = jiffies;
while (ticks == jiffies);
ticks = jiffies;
-- /usr/src/linux/init/main.c
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox