* please unsubscribe me
From: yiftachf @ 2002-11-10 7:46 UTC (permalink / raw)
To: linux-mtd
^ permalink raw reply
* Re: Q on MTD support for NOR flash
From: Jörn Engel @ 2002-11-09 20:57 UTC (permalink / raw)
To: Kevin Kaichuan He; +Cc: linux-mtd
In-Reply-To: <20021109203650.72416.qmail@web14809.mail.yahoo.com>
On Sat, 9 November 2002 12:36:50 -0800, Kevin Kaichuan He wrote:
>
> We are considering to use NOR flash in a embedded linux
> system. But it seems that NAND flash support was mentioned
> a lot in MTD instead of NOR flash. I'm wondering if there
> is intensive NOR flash support in MTD, specifically if
> AMD's boot sector NOR flash
> (AM29LV800B,http://www.amd.com/us-en/FlashMemory/ProductInformation/0,,37_1447_1623_1468%5E1532,00.html)
> is supported.
Yupp.
Nand flash support is not too old and thus is getting a lot more
development now. Nor, in almost all cases, simply works.
> Also can we partition the AM29LV800B into multiple partitions and
> mount different filesystem on it (e.g. JFFS on RW partiton and Cramfs
> on RO partition) ?
Yupp.
> How about the boot sector of NOR flash, is it supported too ?
Kinda. If you have to access the small fragments seperately, you might
run into problems. But that is usually only done from a bootloader,
not from linux.
For all practical purposes, yupp.
Jörn
--
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike
^ permalink raw reply
* Q on MTD support for NOR flash
From: Kevin Kaichuan He @ 2002-11-09 20:36 UTC (permalink / raw)
To: linux-mtd
Hello,
We are considering to use NOR flash in a embedded linux
system. But it seems that NAND flash support was mentioned
a lot in MTD instead of NOR flash. I'm wondering if there
is intensive NOR flash support in MTD, specifically if
AMD's boot sector NOR flash
(AM29LV800B,http://www.amd.com/us-en/FlashMemory/ProductInformation/0,,37_1447_1623_1468%5E1532,00.html)
is supported.
Also can we partition the AM29LV800B into multiple partitions and
mount different filesystem on it (e.g. JFFS on RW partiton and Cramfs
on RO partition) ? How about the boot sector of NOR flash, is it supported
too ?
Thank you very much for your time!
Kevin
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
^ permalink raw reply
* Re: Compact Flash Reliability Embeded System
From: Robert Kaiser @ 2002-11-09 18:57 UTC (permalink / raw)
To: Jörn Engel; +Cc: Asier Santamaria, linux-mtd
In-Reply-To: <20021109155706.GA18502@wohnheim.fh-wedel.de>
On Sat, 9 Nov 2002, Jörn Engel wrote:
> On Fri, 8 November 2002 19:47:21 +0100, Asier Santamaria wrote:
> >
> > I've read something about the Compact Flash reliability problems on an
> > embedded system. I'm developing an embedded system running Linux and I was
> > thinking to use a Compact Flash as storage drive. But I read that Compact
> > Flash is not the most reliable storage system, that you can have problems
> > during the power failure or bad shutting down of the system (usual on an
> > embedded system), that the CF can death.
> > Anyone has more information about that?
>
> Try http://www.linux-mtd.infradead.org/tech/nand.html
>
Hmm, not sure this helps, since the OP asked about Compact Flashes.
Technically, CF devices behave exactly like IDE disks and that is how
Linux deals with them. Therefore, CF's have nothing to do with MTD and
thus they are not really on topic here.
FWIW, I have seen credible reports from people on various mailing lists
saying that they had CFs break after a loss of power, when a write access
was in progress. However, I have yet to see an official statement from a
CF manufacturer about this. BTW, (true) IDE disks may also break if you
remove power while a write is in progress.
Rob
----------------------------------------------------------------
Robert Kaiser email: rkaiser@sysgo.de
SYSGO AG
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
^ permalink raw reply
* Re: Compact Flash Reliability Embeded System
From: Jörn Engel @ 2002-11-09 15:57 UTC (permalink / raw)
To: Asier Santamaria; +Cc: linux-mtd
In-Reply-To: <001901c28757$46ffd0f0$adef99c1@ordenadorcasa>
On Fri, 8 November 2002 19:47:21 +0100, Asier Santamaria wrote:
>
> I've read something about the Compact Flash reliability problems on an
> embedded system. I'm developing an embedded system running Linux and I was
> thinking to use a Compact Flash as storage drive. But I read that Compact
> Flash is not the most reliable storage system, that you can have problems
> during the power failure or bad shutting down of the system (usual on an
> embedded system), that the CF can death.
> Anyone has more information about that?
Try http://www.linux-mtd.infradead.org/tech/nand.html
Jörn
--
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike
^ permalink raw reply
* Compile error
From: Indy500 @ 2002-11-09 0:24 UTC (permalink / raw)
To: linux-mtd
Hi
I try to compile the CVS Tree 21.10 and above with linuxkernel 2.4.19
but there is always a compile error on File mtdpart.c
mtdpart.c: In function `part_unpoint':
mtdpart.c:76: too many arguments to function
mtdpart.c: In function `add_mtd_partitions':
mtdpart.c:331: warning: assignment from incompatible pointer type
make[4]: *** [mtdpart.o] Fehler 1
any Ideas?
^ permalink raw reply
* mtd based file system for Sega Dreamcast
From: adr @ 2002-11-08 20:24 UTC (permalink / raw)
To: linux-mtd
There is now a working (read-only at present) file system for the Sega
Dreamcast "Visual Memory Unit". This is obviously of novelty value only if
you don't have a Dreamcast, but if you want to see it have a look at the
LinuxDC website (follow the SF project page link): http://linuxdc.org
Adrian
^ permalink raw reply
* Compact Flash Reliability Embeded System
From: Asier Santamaria @ 2002-11-08 18:47 UTC (permalink / raw)
To: linux-mtd
Hi,
I've read something about the Compact Flash reliability problems on an
embedded system. I'm developing an embedded system running Linux and I was
thinking to use a Compact Flash as storage drive. But I read that Compact
Flash is not the most reliable storage system, that you can have problems
during the power failure or bad shutting down of the system (usual on an
embedded system), that the CF can death.
Anyone has more information about that?
Thanks,
Asier
^ permalink raw reply
* cfi_cmdset_0002.c (HZ/1000) question
From: Vladimir Doukhanine @ 2002-11-08 17:41 UTC (permalink / raw)
To: dwmw2; +Cc: linux-mtd
Hi David,
I'm just wondering if this line makes any sence:
./drivers/mtd/chips/cfi_cmdset_0002.c:511: timeo = jiffies +
(HZ/1000); /* setting timeout to 1ms for now */
Thanks,
Vlad
^ permalink raw reply
* 16bit NAND flash support
From: Taeil Um @ 2002-11-08 6:49 UTC (permalink / raw)
To: linux-mtd
Hi All !
i have tried to support Samsung 16bit NAND flash (K9F2816U0C).
So, i made drivers/mtd/nand/nand16.c.
But, i didn't succeed.
Please, inform or send me a nand16.c .
And, do you know which part should be changed for supporting jffs2.
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: Jörn Engel @ 2002-11-07 16:00 UTC (permalink / raw)
To: David Woodhouse; +Cc: Brian J. Murrell, linux-mtd
In-Reply-To: <17545.1036684691@passion.cambridge.redhat.com>
On Thu, 7 November 2002 15:58:11 +0000, David Woodhouse wrote:
>
> Ignore that. Look at 2.5 Kconfig. I'm not interested in improving the 2.4
> version.
True. uml won't go into 2.4 anyway.
Jörn
--
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: David Woodhouse @ 2002-11-07 15:58 UTC (permalink / raw)
To: Jörn Engel; +Cc: Brian J. Murrell, linux-mtd
In-Reply-To: <20021107155433.GD31118@wohnheim.fh-wedel.de>
joern@wohnheim.fh-wedel.de said:
> How could this be done in an elegant manner? I fear something like if
> [ "$CONFIG_THISMAP" = "y" -o
> "$CONFIG_THATMAP" = "y" -o
> ...
> "$CONFIG_LASTMAP" = "y" ]
Ignore that. Look at 2.5 Kconfig. I'm not interested in improving the 2.4
version.
--
dwmw2
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: Jörn Engel @ 2002-11-07 15:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: Brian J. Murrell, linux-mtd
In-Reply-To: <15366.1036683254@passion.cambridge.redhat.com>
On Thu, 7 November 2002 15:34:14 +0000, David Woodhouse wrote:
>> Shouldn't the current mapping drivers be disabled as well, unless we
>> are dealing with hardware or mmapping host memory?
>
> Yeah. Aren't most of them arch-specific already though?
Correct. Physmap depends on gen_probe, which itself would depend on
any mapping driver. This cyclic dependency should go away, I guess,
but the idea is really nice.
>>> A better plan would be to allow the chip configuration to be enabled iff
>>> there is at least one mapping driver enabled.
How could this be done in an elegant manner? I fear something like
if [ "$CONFIG_THISMAP" = "y" -o
"$CONFIG_THATMAP" = "y" -o
...
"$CONFIG_LASTMAP" = "y" ]
Jörn
--
Do not stop an army on its way home.
-- Sun Tzu
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: David Woodhouse @ 2002-11-07 15:34 UTC (permalink / raw)
To: Jörn Engel; +Cc: Brian J. Murrell, linux-mtd
In-Reply-To: <20021107153336.GB31118@wohnheim.fh-wedel.de>
joern@wohnheim.fh-wedel.de said:
> Shouldn't the current mapping drivers be disabled as well, unless we
> are dealing with hardware or mmapping host memory?
Yeah. Aren't most of them arch-specific already though?
--
dwmw2
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: Jörn Engel @ 2002-11-07 15:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: Brian J. Murrell, linux-mtd
In-Reply-To: <7374.1036677634@passion.cambridge.redhat.com>
On Thu, 7 November 2002 14:00:34 +0000, David Woodhouse wrote:
>
> A better plan would be to allow the chip configuration to be enabled iff
> there is at least one mapping driver enabled.
Shouldn't the current mapping drivers be disabled as well, unless we
are dealing with hardware or mmapping host memory?
Jörn
--
It's just what we asked for, but not what we want!
-- anonymous
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: Jörn Engel @ 2002-11-07 15:21 UTC (permalink / raw)
To: Brian J. Murrell, linux-mtd
In-Reply-To: <20021107135052.GA13914@pc.ilinx>
On Thu, 7 November 2002 08:50:53 -0500, Brian J. Murrell wrote:
> On Thu, Nov 07, 2002 at 08:00:36AM +0000, David Woodhouse wrote:
> >
> > What happens when someone makes a mapping driver for UML which mmaps part
> > of /dev/kmem from the host?
>
> I hope I am understanding the question/scenario you are proposing, but
> the answer seems to simple, so I am sure I am missing something.
Yupp. The actual NOR chip is connected to the memory bus and can be
accessed by reading/writing to some memory addresses. /dev/kmem gives
you access to all physical memory, so any user space program with
permissions to write /dev/kmem could act as a device driver.
This userspace program is uml. It maps host memory to uml memory and
can use all the hardware device drivers that were useless until then.
I hope, I didn't miss too much, David. Hit me, I can take it. :-)
Jörn
--
Fantasy is more important than knowlegde. Knowlegde is limited,
while fantasy embraces the whole world.
-- Albert Einstein
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: David Woodhouse @ 2002-11-07 14:00 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: linux-mtd
In-Reply-To: <20021107135052.GA13914@pc.ilinx>
e88cd5ffd87e620fdc30b3e6db510d03@interlinx.bc.ca said:
> I hope I am understanding the question/scenario you are proposing,
> but the answer seems to simple, so I am sure I am missing something.
> When/if someone makes that UML mapping driver, it would have it's
<PEDANT>
YM "its"
</PEDANT>
(Sorry, customers being bloody stupid at me today and I have to be nasty to
_someone_ or my brain will explode :)
> CONFIG_MTD_UML (or whatever they will call it) outside of the
> CONFIG_MEMORY bus protected portions of the MTD Config.in files.
But the options for the _chips_ it's able to find in that mapping are
disabled because CONFIG_MEMORY_BUS is turned off.
A better plan would be to allow the chip configuration to be enabled iff
there is at least one mapping driver enabled.
--
dwmw2
^ permalink raw reply
* Re: MTD Config.in items not escaped by bus availability
From: Brian J. Murrell @ 2002-11-07 13:50 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <6557.1036656036@passion.cambridge.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
On Thu, Nov 07, 2002 at 08:00:36AM +0000, David Woodhouse wrote:
>
> What happens when someone makes a mapping driver for UML which mmaps part
> of /dev/kmem from the host?
I hope I am understanding the question/scenario you are proposing, but
the answer seems to simple, so I am sure I am missing something.
When/if someone makes that UML mapping driver, it would have it's
CONFIG_MTD_UML (or whatever they will call it) outside of the
CONFIG_MEMORY bus protected portions of the MTD Config.in files.
b.
--
Brian J. Murrell
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GRUB on DoC Millennium/2000 - Instructions (Revised) problem
From: Mark Meade @ 2002-11-07 13:05 UTC (permalink / raw)
To: eylon eyal, linux-mtd
In-Reply-To: <200211071020.16625.ayalon@tadlys.com>
eylon eyal wrote:
> 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?
This patch has not been uploaded to the MTD cvs yet. I apologize -- I will
try to get to that soon.
The 10-08 grub patch is currently available in two places:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=505&group_id=68
http://lists.infradead.org/pipermail/linux-mtd/2002-October/006150.html
Please let us know how things go. Any feedback on the patch and/or the
instructions is welcome.
Thanks,
Mark
^ permalink raw reply
* Re: Building mkfs.jffs2
From: Darren Freeman @ 2002-11-07 22:49 UTC (permalink / raw)
To: Linux MTD List
In-Reply-To: <1036570803.16096.98.camel@dirac.home>
I have an update to the previous posting...
On Wed, 2002-11-06 at 08:20, Darren Freeman wrote:
> 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.
OK I found the source of my problem here. Yes, the old mkfs.jffs2 was
doing that but the new binary I grabbed (I think) off RedHat's site
actually works. But the symptoms were lots of errors and a screwed
filesystem as before so I thought it was the same problem.
The actual problem is that somehow the system, booted by RedBoot, is
locking the flash over the partition of interest. I have to do a "fis
unlock" command to unlock the partition before booting Linux, then the
filesystem recovers and is read/write. Which is a relief but
*really*weird* =)
Oh and the target kernel is 2.4.19-rmk1 (woops)
> 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.
Yeah I tried and tried and tried some more. Still gave up.
> 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!
Well I don't need it anymore but some ideas would still be appreciated
=)
> Have fun,
> Darren Freeman
What he said =)
^ permalink raw reply
* Unable to handle kernel NULL pointer dereference at virtual address 0000000c
From: nur @ 2002-11-07 12:13 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <20021104171339.GB13152@wohnheim.fh-wedel.de>
1. During boot, I faced this problem right after DiskOnChip Millennium is
recognized
Is this a kernel bug or mtd drivers cause it?
I searched through google to find something and there were several messages
without any solution.
One of them was, David Woodhouse's mtdblock.c correction. As I have newer
version of it, there is no use to test.
2. Is it ok if I compile kernel with DiskOnChip Millennium support for a
system having DiskOnChip Millennium Module?
Thanks, regards
Nur.
^ permalink raw reply
* Re: NAND flash of EDB7312
From: Marius Groeger @ 2002-11-07 12:58 UTC (permalink / raw)
To: Taeil Um; +Cc: linux-mtd list
In-Reply-To: <BDEDIOGGNJEEPBHLJLFGOEGJCDAA.tium@palmpalm.com>
On Tue, 5 Nov 2002, Taeil Um wrote:
> So, Did anybody succeed to use NAND flash on EDB7312 board ?
> if somebody succeed, Could you inform me the value of MEMCFG1?
It worked ok for me using ARMboot (armboot.sf.net) and Elinos, which
uses the driver checked in on Infradead. As for MEMCFG1, see
armboot/board/ep7312/memsetup.S:
...
memcfg1_val: .long 0x1f101710
...
Regards,
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
^ permalink raw reply
* Re: seeking help on JFFS2
From: David Woodhouse @ 2002-11-07 8:49 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linux-mtd
In-Reply-To: <IGEFJKJNHJDCBKALBJLLOELLFHAA.joakim.tjernlund@lumentis.se>
joakim.tjernlund@lumentis.se said:
> Why does JEDEC end up in cfi_cmdset_0001.c?
CFI only defines how you _probe_ chips. The actual Intel command set is the
same as it's always been, likewise the AMD one. This is why jedec_probe
passes control to the CFI drivers and all the other chip drivers are
deprecated.
> If it should end up in cfi_cmdset_0001.c, why does it not set cmdset_priv?
IIRC because cmdset_priv is just a copy of the extended CFI table from the
chip, which we don't have in the case of a non-CFI chip. It's that which
holds the details of whether we can do erase suspend, etc.
Perhaps the table in jedec_probe should also contain a 'fake' extended CFI
table. More sensibly, perhaps we should have a structure in the cmdset_priv
with just the flags we care about, and at probe time either parse the
extended CFI table or copy those flags from the jedec_probe table.
For now, we just assume jedec-probed chips have none of the extended
features.
--
dwmw2
^ permalink raw reply
* RE: seeking help on JFFS2
From: Joakim Tjernlund @ 2002-11-07 8:28 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
In-Reply-To: <4556.1036599271@passion.cambridge.redhat.com>
David
Why does JEDEC end up in cfi_cmdset_0001.c?
If it should end up in cfi_cmdset_0001.c, why does it not set cmdset_priv?
Jocke
>
>
> 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
>
^ permalink raw reply
* 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
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