* 128MB DOC 2000 not working (possible bug)
From: Adam Lee @ 2002-11-19 15:17 UTC (permalink / raw)
To: linux-mtd list; +Cc: alee
Hi,
We just upgrade a 96 MB DOC 2000 to 128 MB DOC 2000 but the 128MB chip is
not functioning. I compiled the driver into the kernel, and it worked with
the 96 MB. In kernel boot up, the 128MB DOC2000 is recognized as DOC
Millennium. The kernel boot up message is as followed:
.
.
Using configured DiskOnChip probe address 0xd0000
DiskOnChip Millennium found at address 0xD0000
_DoC_WaitReady called for out-of-line wait
_DoC_WaitReady called for out-of-line wait
_DoC_WaitReady called for out-of-line wait
.
.
No flash chips recognised.
NFTL driver: nftlcore.c $Revision: 1.87 $, nftlmount.c $Revision: 1.30 $
.
.
After boot, /proc/mtd is empty.
The part number for the 128 MB DOC 2000 is
MD2202-D128-V3-X
23205010089 5.1
And we are using RedHat dist. kernel version 2.4.18-3
Thank you,
Adam
^ permalink raw reply
* BUSINESS RELATIONSHIP
From: Dennis Dozie @ 2002-11-11 14:43 UTC (permalink / raw)
To: ddozie
ATTN:DIRECTOR/CEO
Sir,
This contact is tantamount to an unflinching desire to establish a long mutual
business relationship based on trust and mutual understanding.
I am Mr.Dennis Dozie ,the payment Co-Ordinator of ECO INTERNATIONAL BANK
PLC(Lagos-Nigeria).During the course of investigation it was found that the sum
of
US$12.5M (Twelve Million Five Hundred Thousand US Dollars) has been lying
dormant in a suspense account of our bank.
The said amount after due investigation belongs to a Foreigner, Late ENG.ANDREW
WILSON who was an Oil merchant/contractor with the Federal Government of
Nigeria and he was our valued customer but unfortunately the dastardly act of
the terrorists september 11th 2001 on the WTC(NEW YORK) building brought his
transaction to a halt.It is quite amazing that nobody has serviced the account
or shown up for his money since after his death till date.Although,several
efforts have been made by the bank to get in touch with his next of kin or any
of his relations, but all to no avail (he had no wife or children).
It is on this note some top officials of ECO INTERNATIONAL BANK PLC,who are
fully aware of the incident resolved and asked me to find and negotiate with
trust worthy foreigner who will be willing to assist us ,and act as next of kin
to the Late ENG.ANDREW WILSON.
Going by the policy in our country as against civil servants operating foreign
account or even to have that kind of huge amount in our local accounts,I
solicit for your assistance in transferring this money into your foreign
account for personal investment purpose. Having found out that your city are
known for business acumen and trustworthiness in business dealings.
Because of this I have to solicit for your assistance and understanding,with an
unflinching faith that you will not betray me in this business.This is the
reason why I am asking for your assistance to enable me invest the fund in
your city,settle down with my family and also have you as my mentor.
If you can handle the transfer for our joint benefit please get back to me so
we can discuss,as what is required now is either for us to have you as his
next of kin or to transfer the money in your name.
I want you to understand that this transaction must be kept in utmost
confidentiality and secrecy because the bank here might claim the fund if they
got to know
^ permalink raw reply
* (no subject)
From: Wauviel @ 2002-11-15 20:58 UTC (permalink / raw)
To: linux-mtd-cvs
Offshore Suppliers Directory (http://www.OffshoreSuppliersDirectory.com) has just gotten better!
You know Offshore Suppliers Directory as the world's first published guide to offshore software development, services, and product suppliers. However, did you know it's a growing online B2B, buyer / supplier exchange as well?
New features for BUYERS:
* RFPs and Projects: You can post your RFPs to all suppliers or you can select just the suppliers you want to invite after a search.
* Offshore Resource Management System (ORMS): Nobody knows your requirements better than you. Search for the right suppliers and invite them to respond to your RFP / Project all within ORMS!
* Search Utilities: Perform basic and complex searches for offshore suppliers (both companies and independent contractors) at our unique ORMS.
* Purchase your advance copy of the Offshore Suppliers Directory at a 30% discount! Limited Time Offer!
New features for SUPPLIERS:
* Basic listings are FREE! More comprehensive listings are available for purchase. Note: Buyers will search for suppliers by business and technology capabilities. These fields are ONLY available with a paid listing. If you want buyers to find you and invite you to bid on their RFP then upgrade to a 1-page or 2-page listing today.
* Our rates have been reduced! A 1-page listing is now only $75.00 (was $125.00) and a 2-page listing is now only $125.00 (was 200.00)!
* Support for Independent Offshore Contractors. Sometimes buyers just need one or two resources to support a project and now finding those individuals is simple. It's like having Monster.com but for the offshore market! Make sure buyers find you! The cost is only $19.95 per year (that's only $0.05 per day!).
* List your offshore company! Your company information will be available to buyers around the world in both the printed directory and the online searches.
* We're sending FREE copies of the Offshore Suppliers Directory to key individuals at Fortune 500 companies! Make sure you have as much information as possible in the printed guide by purchasing a 1-page or 2-page listing so they choose your company as the right providers of services to meet their needs! If you're not in the printed guide or online directory how can they select you?
* With our Offshore Resource Management System (ORMS) you don't have to register for RFPs, the system takes care of that automatically for you when you register as a Supplier or Independent Contractor!
See us at the following sites!:
National Association of Software and Service Companies (NASSCOM): www.nasscom.org
Outsourcing Russia - All about IT Outsourcing to Russia: www.outsourcing-russia.com
Software Ireland - Ireland's leading FREE portal to the IT industry: www.softwareireland.com
To Your Success,
Offshore Suppliers Directory
http://www.OffshoreSuppliersDirectory.com
YOUR NAME WAS SELECTED AS A PERSON OR ORGANIZATION INVOLVED WITH TECHNOLOGY.
WE APOLOGIZE IF THIS EMAIL IS NOT APPLICABLE TO YOU.
THIS IS A ONE TIME SUBMISSION.
YOU DO NOT NEED TO SUBMIT A REMOVAL REQUEST.
^ permalink raw reply
* Re: cmdline.c file name collision
From: Frank Neuber @ 2002-11-15 10:34 UTC (permalink / raw)
To: rkaiser; +Cc: linux-mtd
In-Reply-To: <200211150849.gAF8nVs02462@dagobert.svc.sysgo.de>
On Fri, Nov 15, 2002 at 10:56:44AM +0100, Robert Kaiser wrote:
> Am Donnerstag, 14. November 2002 23:39 schrieb Hicks, Jamey:
> > I've renamed my copy to
> > cmdlinepart.c in the handhelds.org CVS repository, but I have not done so
> > on the MTD repository. If no one objects, I will add cmdlinepart.c and
> > remove cmdline.c in the infradead cvs.
>
> Why not mtdcmdline.c ? I think it is more important to have the name indicate
> the subsystem this file belongs to. The fact that it deals with partitions is
> IMHO of minor importance (and might even change in the future).
Yes I agree with you. I use the mtdcmdline.c also to pass the physical map_info.
Frank
--
Dipl.-Ing. Elektrotechnik convergence / HW
Frank Neuber Rosenthalerstr.51 / 10178 Berlin
Email: neuber@convergence.de Phone: +49(0)30-72 62 06 76
WWW: www.convergence.de Fax: +49(0)30-72 62 06 55
^ permalink raw reply
* RE: Support for command set 0003 not present
From: Gettert, Wolfram @ 2002-11-15 10:11 UTC (permalink / raw)
To: linux-mtd
Hallo,
since I use the kernel 2.2.18 I had to apply the inter_module_register
patch.
Now everthing is Ok.
Wolfram
> -----Original Message-----
> From: J B [mailto:mad_flasher@hotmail.com]
> Sent: Donnerstag, 14. November 2002 17:41
> To: Wolfram.Gettert@fci.com; linux-mtd@lists.infradead.org
> Subject: Re: Support for command set 0003 not present
>
>
> >From: "Gettert, Wolfram" <Wolfram.Gettert@fci.com>
> >
> >Support for command set 0003 not present
> >gen_probe: No supported vendor command set found
>
> Is CONFIG_MTD_INTELEXT defined? That could be the problem...
>
> >The macro P_ID_INTEL_STD is defined. Do I have overseen to
> load a module or
> >is this command set not yet implemented. Is somebody working
> >on this or do I have to it on my own?
>
> A chip with command set 0x0003 should work. That command set looks
> like it is supported by cfi_cmdset_0001.c
>
> Josh
>
> _________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
^ permalink raw reply
* Re: cmdline.c file name collision
From: Robert Kaiser @ 2002-11-15 9:56 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <D99C1FB421989A40818B6370E3187094040A3ABD@tayexc19.americas.cpqcorp.net>
Am Donnerstag, 14. November 2002 23:39 schrieb Hicks, Jamey:
> I've renamed my copy to
> cmdlinepart.c in the handhelds.org CVS repository, but I have not done so
> on the MTD repository. If no one objects, I will add cmdlinepart.c and
> remove cmdline.c in the infradead cvs.
Why not mtdcmdline.c ? I think it is more important to have the name indicate
the subsystem this file belongs to. The fact that it deals with partitions is
IMHO of minor importance (and might even change in the future).
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: cmdline.c file name collision
From: Hicks, Jamey @ 2002-11-14 22:39 UTC (permalink / raw)
To: Scott Anderson; +Cc: linux-mtd
I think we should change the filename to avoid the collision in 2.4.x kernels. I do not think we should do surgery on the CVS repository even though that means the file history gets split. I've renamed my copy to cmdlinepart.c in the handhelds.org CVS repository, but I have not done so on the MTD repository. If no one objects, I will add cmdlinepart.c and remove cmdline.c in the infradead cvs.
Jamey
> -----Original Message-----
> From: Scott Anderson [mailto:scott_anderson@mvista.com]
> Sent: Wednesday, November 13, 2002 2:32 PM
> To: Hicks, Jamey
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: cmdline.c file name collision
>
>
> "Hicks, Jamey" wrote:
> > hmm. My first thought was to rename drivers/mtd/cmdline.c to
> > drivers/mtd/mtdcmdline.c or drivers/mtd/cmdlinepart.c.
>
> That sounds reasonable. Does someone that has direct access
> to the CVS
> repository want to move the files around in the repository
> (so we don't
> lose history) or should I just submit a patch that removes
> the file and
> adds the file back with a different name?
>
> > Actually, that was my second thought. My first thought was
> to wonder
> > why CONFIG_MODVERSIONS flattens the kernel source file namespace.
> > I just turned on CONFIG_MODVERSIONS to build an ipaq
> kernel, and I find
> > I also have a name conflict on arch/arm/mach-sa1100/pm.c
> and kernel/pm.c.
>
> I've been told third hand or so that it is a "known
> limitation" in 2.4.
> I just looked in 2.5, and this limitation has been eliminated
> (there is
> a hierarchy of files under include/linux/modules that parallels the
> source hierarchy).
>
> With that new found information, I guess a new question comes up: does
> working around the 2.4 limitation warrant the rename when the
> limitation
> is removed in 2.5?
>
> Scott Anderson
> scott_anderson@mvista.com MontaVista Software Inc.
> (408)328-9214 1237 East Arques Ave.
> http://www.mvista.com Sunnyvale, CA 94085
>
^ permalink raw reply
* Re: Support for command set 0003 not present
From: J B @ 2002-11-14 16:40 UTC (permalink / raw)
To: Wolfram.Gettert, linux-mtd
>From: "Gettert, Wolfram" <Wolfram.Gettert@fci.com>
>
>Support for command set 0003 not present
>gen_probe: No supported vendor command set found
Is CONFIG_MTD_INTELEXT defined? That could be the problem...
>The macro P_ID_INTEL_STD is defined. Do I have overseen to load a module or
>is this command set not yet implemented. Is somebody working
>on this or do I have to it on my own?
A chip with command set 0x0003 should work. That command set looks
like it is supported by cfi_cmdset_0001.c
Josh
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Support for command set 0003 not present
From: Gettert, Wolfram @ 2002-11-14 14:38 UTC (permalink / raw)
To: linux-mtd
Hallo,
I have added the device data for a new device in jedec_probe.c and get this
message:
Support for command set 0003 not present
gen_probe: No supported vendor command set found
The macro P_ID_INTEL_STD is defined. Do I have overseen to load a module or
is this
command set not yet implemented. Is somebody working on this or do I have to
it on my own?
I will do it if it's necessary.
Wolfram
--
Wolfram Gettert
Software Engineer
Force Computers GmbH
- A Solectron Company -
Lilienthalstr. 15
D-85579 Neubiberg/München
Wolfram.Gettert_at_fci.com
www.forcecomputers.com
^ permalink raw reply
* Re: help about jffs2 write problem.
From: nbhorse @ 2002-11-14 0:45 UTC (permalink / raw)
To: nbhorse; +Cc: linux-mtd@lists.infradead.org
Hello nbhorse!
I download new mtd and include source code from http://lists.infradead.org,fix my old kernel,ererything is ok
---------2002-11-13 11:42:00 nbhorse wrote:-------
>Hello everyone,
> I have a problem with the mtd and jffs2.when I ported a linux kernel(2.4.18 rmk7)to my arm 7212 board(samsung k9f560 32m nandflash),and my partition for nand mtd driver like this:
>
>const static struct mtd_partition partition_info[] = {
> { name: "kernel",
> offset: 0,
> size: 1*1024*1024},
> { name: "blank",
> offset: 1*1024*1024,
> size: 1*1024*1024},
> { name: "file system 1",
> offset: 2*1024*1024,
> size: 4*1024*1024},
> { name: "SamSung flash partition 1",
> offset: 6*1024*1024,
> size: 2*1024*1024},
> { name: "SamSung flash partition 2",
> offset: 8*1024*1024,
> size: 24*1024*1024 }
>};
> and i want to mount partition 1(blank) with jffs2.
> I have a problem:
> I use "eraseall /dev/mtd1"(c 90 2) to erase the mtdblock1,and i "mount -t jffs2 /dev/mtdblock1 /flash","copy /bin/busybox /flash",it display following error message:
>
> ARGH. About to write node to 0x000f8760 on flash, but there's data already there:
>0x000f8760: 57 a6 fb 05 76 e3 29 d7 fe f0 78 b7 ce 0f b8 c6
> .....
>then i run"/flash/busybox",error is:
>
>Node CRC b04df10c != calculated CRC 49b35642 for node at 00020760
>Node CRC b04df10c != calculated CRC 49b35642 for node at 00020760
>
>I'm sure that partition 1（"blank") is be erased.
>
>if i use ext2 filesystem,everything is ok.
>
>Any help would be appreciated
>
>
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
-------------------------------------------------
Best regards,
nbhorse
nbhorse@163.com
2002-11-14
^ permalink raw reply
* Re: cmdline.c file name collision
From: Scott Anderson @ 2002-11-13 19:31 UTC (permalink / raw)
To: Hicks, Jamey; +Cc: linux-mtd
In-Reply-To: <D99C1FB421989A40818B6370E3187094040A3AB6@tayexc19.americas.cpqcorp.net>
"Hicks, Jamey" wrote:
> hmm. My first thought was to rename drivers/mtd/cmdline.c to
> drivers/mtd/mtdcmdline.c or drivers/mtd/cmdlinepart.c.
That sounds reasonable. Does someone that has direct access to the CVS
repository want to move the files around in the repository (so we don't
lose history) or should I just submit a patch that removes the file and
adds the file back with a different name?
> Actually, that was my second thought. My first thought was to wonder
> why CONFIG_MODVERSIONS flattens the kernel source file namespace.
> I just turned on CONFIG_MODVERSIONS to build an ipaq kernel, and I find
> I also have a name conflict on arch/arm/mach-sa1100/pm.c and kernel/pm.c.
I've been told third hand or so that it is a "known limitation" in 2.4.
I just looked in 2.5, and this limitation has been eliminated (there is
a hierarchy of files under include/linux/modules that parallels the
source hierarchy).
With that new found information, I guess a new question comes up: does
working around the 2.4 limitation warrant the rename when the limitation
is removed in 2.5?
Scott Anderson
scott_anderson@mvista.com MontaVista Software Inc.
(408)328-9214 1237 East Arques Ave.
http://www.mvista.com Sunnyvale, CA 94085
^ permalink raw reply
* RE: cmdline.c file name collision
From: Hicks, Jamey @ 2002-11-13 15:25 UTC (permalink / raw)
To: Scott Anderson, linux-mtd
> -----Original Message-----
> From: Scott Anderson [mailto:scott_anderson@mvista.com]
> Sent: Tuesday, November 12, 2002 12:47 PM
> To: linux-mtd@lists.infradead.org
> Subject: cmdline.c file name collision
>
>
> Hi all,
>
> I recently noticed that when CONFIG_MODVERSIONS is turned on, both
> drivers/mtd/cmdline.c and lib/cmdline.c are trying to store their
> symbol versions in include/linux/modules/cmdline.ver in a 2.4 kernel
> tree. Only one of them "wins" leaving the versioned symbols of the
> other undefined. It seems to me that drivers/mtd/cmdline.c should
> probably be renamed to avoid the conflict. Thoughts?
>
hmm. My first thought was to rename drivers/mtd/cmdline.c to drivers/mtd/mtdcmdline.c or drivers/mtd/cmdlinepart.c.
Actually, that was my second thought. My first thought was to wonder why CONFIG_MODVERSIONS flattens the kernel source file namespace. I just turned on CONFIG_MODVERSIONS to build an ipaq kernel, and I find I also have a name conflict on arch/arm/mach-sa1100/pm.c and kernel/pm.c.
Jamey
^ permalink raw reply
* RE: Problem writing to flash with writeb()
From: Gettert, Wolfram @ 2002-11-13 8:12 UTC (permalink / raw)
To: 'linux-mtd@lists.infradead.org'
Thanks for the hint.
I was really blind.
Wolfram
> -----Original Message-----
> From: J B [mailto:mad_flasher@hotmail.com]
> Sent: Dienstag, 12. November 2002 20:02
> To: Wolfram.Gettert@fci.com; linux-mtd@lists.infradead.org
> Subject: Re: Problem writing to flash with writeb()
>
>
>
> > physmap_map.map_priv_1 = (unsigned
> >long)ioremap_nocache(WINDOW_ADDR,WINDOW_SIZE);
> >
> > ...
> >
> > //Read Manufacturer and Device code
> > physmap_write8(&physmap_map,0x90,physmap_map.map_priv_1);
>
> Are you sure you want to pass physmap_map.map_priv_1 as the
> address? That
> would imply that the address you are writing 0x90 to is (2 *
> physmap_map.map_priv_1) because physmap_writeX will add
> map->map_priv_1 to
> whatever address you pass it. If that is bigger than
> WINDOW_SIZE, I don't
> think the command will actually reach the flash chip because
> the address
> isn't mapped to a flash chip. I am assuming you are using a
> cfi compliant
> flash chip and 0x90 is putting it into "Read Identifier
> Codes". Try using 0
> for the address instead, which is what you did below.
>
> >If I do it like this:
> >
> > p = physmap_map.map_priv_1;
> > p[0] = 0x90;
>
> Looks like this is the equivalent of:
> physmap_write8(&physmap_map,0x90,0);
>
>
> I could be very wrong however. I still consider myself a
> newbie, so sorry
> if this doesn't make any sense. Hope it helps though.
>
>
> Josh
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
^ permalink raw reply
* help about jffs2 write problem.
From: nbhorse @ 2002-11-13 3:42 UTC (permalink / raw)
To: linux-mtd@lists.infradead.org
Hello everyone,
I have a problem with the mtd and jffs2.when I ported a linux kernel(2.4.18 rmk7)to my arm 7212 board(samsung k9f560 32m nandflash),and my partition for nand mtd driver like this:
const static struct mtd_partition partition_info[] = {
{ name: "kernel",
offset: 0,
size: 1*1024*1024},
{ name: "blank",
offset: 1*1024*1024,
size: 1*1024*1024},
{ name: "file system 1",
offset: 2*1024*1024,
size: 4*1024*1024},
{ name: "SamSung flash partition 1",
offset: 6*1024*1024,
size: 2*1024*1024},
{ name: "SamSung flash partition 2",
offset: 8*1024*1024,
size: 24*1024*1024 }
};
and i want to mount partition 1(blank) with jffs2.
I have a problem:
I use "eraseall /dev/mtd1"(c 90 2) to erase the mtdblock1,and i "mount -t jffs2 /dev/mtdblock1 /flash","copy /bin/busybox /flash",it display following error message:
ARGH. About to write node to 0x000f8760 on flash, but there's data already there:
0x000f8760: 57 a6 fb 05 76 e3 29 d7 fe f0 78 b7 ce 0f b8 c6
.....
then i run"/flash/busybox",error is:
Node CRC b04df10c != calculated CRC 49b35642 for node at 00020760
Node CRC b04df10c != calculated CRC 49b35642 for node at 00020760
I'm sure that partition 1（"blank") is be erased.
if i use ext2 filesystem,everything is ok.
Any help would be appreciated
^ permalink raw reply
* Re: Problem writing to flash with writeb()
From: David Woodhouse @ 2002-11-12 19:26 UTC (permalink / raw)
To: J B; +Cc: Wolfram.Gettert, linux-mtd
In-Reply-To: <F132Y30kkZIhTrBoe2U00000281@hotmail.com>
mad_flasher@hotmail.com said:
> Looks like this is the equivalent of: physmap_write8(&physmap_map,0x90
> ,0);
It does. Show disassembly of each version.
--
dwmw2
^ permalink raw reply
* Re: Problem writing to flash with writeb()
From: J B @ 2002-11-12 19:02 UTC (permalink / raw)
To: Wolfram.Gettert, linux-mtd
> physmap_map.map_priv_1 = (unsigned
>long)ioremap_nocache(WINDOW_ADDR,WINDOW_SIZE);
>
> ...
>
> //Read Manufacturer and Device code
> physmap_write8(&physmap_map,0x90,physmap_map.map_priv_1);
Are you sure you want to pass physmap_map.map_priv_1 as the address? That
would imply that the address you are writing 0x90 to is (2 *
physmap_map.map_priv_1) because physmap_writeX will add map->map_priv_1 to
whatever address you pass it. If that is bigger than WINDOW_SIZE, I don't
think the command will actually reach the flash chip because the address
isn't mapped to a flash chip. I am assuming you are using a cfi compliant
flash chip and 0x90 is putting it into "Read Identifier Codes". Try using 0
for the address instead, which is what you did below.
>If I do it like this:
>
> p = physmap_map.map_priv_1;
> p[0] = 0x90;
Looks like this is the equivalent of:
physmap_write8(&physmap_map,0x90,0);
I could be very wrong however. I still consider myself a newbie, so sorry
if this doesn't make any sense. Hope it helps though.
Josh
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* cmdline.c file name collision
From: Scott Anderson @ 2002-11-12 17:46 UTC (permalink / raw)
To: linux-mtd
Hi all,
I recently noticed that when CONFIG_MODVERSIONS is turned on, both
drivers/mtd/cmdline.c and lib/cmdline.c are trying to store their
symbol versions in include/linux/modules/cmdline.ver in a 2.4 kernel
tree. Only one of them "wins" leaving the versioned symbols of the
other undefined. It seems to me that drivers/mtd/cmdline.c should
probably be renamed to avoid the conflict. Thoughts?
Scott Anderson
scott_anderson@mvista.com MontaVista Software Inc.
(408)328-9214 1237 East Arques Ave.
http://www.mvista.com Sunnyvale, CA 94085
^ permalink raw reply
* Re: mirroring in JFFS2
From: Jörn Engel @ 2002-11-12 17:27 UTC (permalink / raw)
To: David Woodhouse; +Cc: Alan Cox, Miraj Mohamed, jffs-dev, linux-mtd
In-Reply-To: <6310.1037120842@passion.cambridge.redhat.com>
On Tue, 12 November 2002 17:07:22 +0000, David Woodhouse wrote:
>
> But it's not too bad -- you GC on _both_ media till you have enough space
> on them both for the write you want to do, then you allow the allocation
> call to return, do the write to both media and return. Some detail in
> sorting out the case where a page write crosses an eraseblock boundary and
> ends up split into two on one or both media, but that's not really too hard
> conceptually -- I suspect it'd make an ugly mess of the code though.
I wonder if it would make sense to expand the erase marker a bit in
this case. For two devices, the erase marker on each device holds the
number of the corresponding block on the other. This would allow you
to prioritize bad block recovery, once you find one.
This is quite a special case, though. More devices and the procedure
is pointless. Different device types and the procedure is not
possible.
Jörn
--
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)
^ permalink raw reply
* Re: mirroring in JFFS2
From: Jörn Engel @ 2002-11-12 17:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: Miraj Mohamed, jffs-dev, linux-mtd
In-Reply-To: <449.1037117917@passion.cambridge.redhat.com>
On Tue, 12 November 2002 16:18:37 +0000, David Woodhouse wrote:
>
> RAID is done at the wrong layer. The file system knows stuff about the
> contents of the media which a block device driver cannot possibly know. So
> you end up having a RAID rebuild take ages to reconstruct parts of the disc
> which the file system _knows_ are currently unused, etc.
This is an implementation problem, the RAID driver could as well
reconstruct on the fly and give pending requests priority. No need to
duplicate the code in all the filesystems.
> Getting back to JFFS2, the same applies -- if you have a bad block in one
> of your flash chips, what do you do about it? Refrain from using the
> equivalent block in the other chip? Have some kind of block remapper
> underneath JFFS2, which keeps a whole lot of address information which is
> in fact entirely superfluous to the file system?
The bad block point does make sense. Hard disks usually work
completely or fail completely. Point taken.
> I think it does want to be done in the file system, or possibly even in a
> layer _above_ the individual file system, which duplicates writes to two or
> more underlying file systems of a mountpoint, and do whatever's deemed
> appropriate for reads. Doing it in the individual file system is probably
> easier, if less interesting :)
RAID over filesystems would be fun, for sure. But in this case, you
have me convinced, jffs2 is the best place to put it into.
Jörn
--
Geld macht nicht glücklich.
Glück macht nicht satt.
^ permalink raw reply
* Re: mirroring in JFFS2
From: David Woodhouse @ 2002-11-12 17:07 UTC (permalink / raw)
To: Alan Cox; +Cc: Jörn Engel, Miraj Mohamed, jffs-dev, linux-mtd
In-Reply-To: <1037121749.8746.67.camel@irongate.swansea.linux.org.uk>
alan@lxorguk.ukuu.org.uk said:
> The fs doesnt know enough about the block I/O layer to do that
Certainly it doesn't when it's all hidden by RAID. It's feasible that it
_could_ though. It looked like the nwfs code did something like this -- you
told the file system explicitly about all the individual block devices it
was supposed to be using. I never did investigate it much though.
To be honest, in a lot of cases I'd settle for a way for a file system to
tell the block device 'this sector is now unused'. Not so much for RAID but
for the "block-based file system on flash translation layer" case.
> A dupfs layer is probably quite doable too yes.
There are a few interesting cases about what you do when you get write
errors (or -ENOSPC) after your write already succeeded to the other device,
but yeah -- it shouldn't be too horrible.
> However for JFFS2 surely all you actually want to do is write each log
> entry including its ID number to both journals. When you hit a bad block
> you can play back that bit of the journal from the other flash and then
> mark it bad.
Yep, that basically works.
> The only fun case is working out the size of your journal since its
> effectively the smaller of two journals can shrink online.
Well that bit is quite fun already :)
But it's not too bad -- you GC on _both_ media till you have enough space
on them both for the write you want to do, then you allow the allocation
call to return, do the write to both media and return. Some detail in
sorting out the case where a page write crosses an eraseblock boundary and
ends up split into two on one or both media, but that's not really too hard
conceptually -- I suspect it'd make an ugly mess of the code though.
--
dwmw2
^ permalink raw reply
* Re: mirroring in JFFS2
From: Alan Cox @ 2002-11-12 17:22 UTC (permalink / raw)
To: David Woodhouse; +Cc: Jörn Engel, Miraj Mohamed, jffs-dev, linux-mtd
In-Reply-To: <449.1037117917@passion.cambridge.redhat.com>
On Tue, 2002-11-12 at 16:18, David Woodhouse wrote:
> RAID is done at the wrong layer. The file system knows stuff about the
> contents of the media which a block device driver cannot possibly know. So
And vice versa. Its not quite as simple as it looks. For flash I think
you are right.
> you end up having a RAID rebuild take ages to reconstruct parts of the disc
> which the file system _knows_ are currently unused, etc.
>
> You can have journalled RAID to help alleviate this problem -- or you could
> just let the file system do it because that already has a journal anyway.
The fs doesnt know enough about the block I/O layer to do that
> I think it does want to be done in the file system, or possibly even in a
> layer _above_ the individual file system, which duplicates writes to two or
> more underlying file systems of a mountpoint, and do whatever's deemed
> appropriate for reads. Doing it in the individual file system is probably
> easier, if less interesting :)
A dupfs layer is probably quite doable too yes. However for JFFS2 surely
all you actually want to do is write each log entry including its ID
number to both journals. When you hit a bad block you can play back that
bit of the journal from the other flash and then mark it bad. The only
fun case is working out the size of your journal since its effectively
the smaller of two journals can shrink online.
^ permalink raw reply
* Re: mirroring in JFFS2
From: David Woodhouse @ 2002-11-12 16:18 UTC (permalink / raw)
To: Jörn Engel; +Cc: Miraj Mohamed, jffs-dev, linux-mtd
In-Reply-To: <20021112160843.GE5031@wohnheim.fh-wedel.de>
joern@wohnheim.fh-wedel.de said:
> Are you trying to put the mirroring stuff into jffs2?
> In the hard disk world, people use md for this, which uses two devices
> and returns one. The filesystem does not need to worry about anything.
RAID is done at the wrong layer. The file system knows stuff about the
contents of the media which a block device driver cannot possibly know. So
you end up having a RAID rebuild take ages to reconstruct parts of the disc
which the file system _knows_ are currently unused, etc.
You can have journalled RAID to help alleviate this problem -- or you could
just let the file system do it because that already has a journal anyway.
So, for example, you scribble it to your journal, then to both your mirrors,
and mark the journal transaction complete only when it's hit both discs.
Getting back to JFFS2, the same applies -- if you have a bad block in one
of your flash chips, what do you do about it? Refrain from using the
equivalent block in the other chip? Have some kind of block remapper
underneath JFFS2, which keeps a whole lot of address information which is
in fact entirely superfluous to the file system?
I think it does want to be done in the file system, or possibly even in a
layer _above_ the individual file system, which duplicates writes to two or
more underlying file systems of a mountpoint, and do whatever's deemed
appropriate for reads. Doing it in the individual file system is probably
easier, if less interesting :)
--
dwmw2
^ permalink raw reply
* Problem writing to flash with writeb()
From: Gettert, Wolfram @ 2002-11-12 16:18 UTC (permalink / raw)
To: 'linux-mtd@lists.infradead.org'
Hallo,
I try to identify my flash with manufacturer id and device id.
Because I am using the 2.2.18 kernel and I want to be portable I
use the physmap_read/writeX() functions. They are defined as followed.
void physmap_writeX(struct map_info *map, __u8 d, unsigned long adr)
{
__raw_writeX(d, map->map_priv_1 + adr);
mb();
}
In the 2.2.18 __rawreadb is not defined so I have done this.
#define __raw_readX readX
#define __raw_writeX writeX
Now I want to identify the flash doing this
volatile char *p;
u32 manufacturer, device;
physmap_map.map_priv_1 = (unsigned long)ioremap_nocache(WINDOW_ADDR,
WINDOW_SIZE);
...
//Read Manufacturer and Device code
physmap_write8(&physmap_map,0x90,physmap_map.map_priv_1);
manufacturer = physmap_read8(&physmap_map,0);
device = physmap_read8(&physmap_map,2);
printk("Manufacturer Code: 0x%x\n",manufacturer);
printk("Device Code: 0x%x\n",device);
The result in log is:
Manufacturer Code: 0xff
Device Code: 0xff
If I do it like this:
p = physmap_map.map_priv_1;
p[0] = 0x90;
printk("Manufacturer Code: 0x%x\n",p[0]);
printk("Device Code: 0x%x\n",p[2]);
The result in log is:
Manufacturer Code: 0xffffff98
Device Code: 0xffffff9c
That's what I expect. *p needs to declared as volatile to let this work.
But I want to use readb ... Any ideas?
Thanks
Wolfram
--
Wolfram Gettert
Software Engineer
Force Computers GmbH
- A Solectron Company -
Lilienthalstr. 15
D-85579 Neubiberg/München
Wolfram.Gettert_at_fci.com
www.forcecomputers.com
^ permalink raw reply
* Re: mirroring in JFFS2
From: Jörn Engel @ 2002-11-12 16:08 UTC (permalink / raw)
To: Miraj Mohamed; +Cc: jffs-dev, linux-mtd
In-Reply-To: <3DD0D966.E6D877EC@procsys.com>
On Tue, 12 November 2002 16:05:18 +0530, Miraj Mohamed wrote:
>
> Our system needs error detection and recovery of data on Flash.
> We selected Jffs2 which has in built CRC. And planning to modify
> Jffs2 code for mirroring. This means...each write and erase will be
> duplicated
> on mirror partition . While reading if a CRC error is detected,
> the mirror data will be read.
>
> Can any one say if this implementation is ok (or is
> possible)?
> Have anyone implemented a similar system before? Any other way to attain
> redundancy?
Are you trying to put the mirroring stuff into jffs2?
In the hard disk world, people use md for this, which uses two devices
and returns one. The filesystem does not need to worry about anything.
Writing an mtd driver in that fashion should be pretty easy. Robert
Kaiser has done something similar already, have a look at the concat
layer.
Jörn
--
Data expands to fill the space available for storage.
-- Parkinson's Law
^ permalink raw reply
* Re: [PATCH] Add a map_sram driver to drivers/chips/
From: Jörn Engel @ 2002-11-12 16:02 UTC (permalink / raw)
To: Ian Campbell; +Cc: Linux MTD Mailing List
In-Reply-To: <1037099125.26491.81.camel@LinuxDev>
On Tue, 12 November 2002 11:05:25 +0000, Ian Campbell wrote:
>
> The attached patch adds "map_sram" as a second chip driver in
> drivers/mtd/chips/map_ram.c. The two are basically identical apart from
> the use of the MTD_VOLATILE flag.
Slightly OT.
Have you tried the slram driver? I have always used that one to access
plain old memory and was very happy. And now you make me wonder, if
there is another way that might even be better.
Jörn
--
A victorious army first wins and then seeks battle.
-- Sun Tzu
^ 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