* Which filesystem can live on one flash sector? @ 2002-12-10 6:02 fred 2002-12-10 7:46 ` Jörn Engel 2002-12-10 17:28 ` Russ Dill 0 siblings, 2 replies; 11+ messages in thread From: fred @ 2002-12-10 6:02 UTC (permalink / raw) To: linuxppc-embedded, linux-mtd Hi, I am using CRAMFS plus RAMFS on my board. And there is only one sector left for saving configuration data. Can I put a file system, e.g. JFFS, on it? BR, Fred ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Which filesystem can live on one flash sector? 2002-12-10 6:02 Which filesystem can live on one flash sector? fred @ 2002-12-10 7:46 ` Jörn Engel 2002-12-10 17:28 ` Russ Dill 1 sibling, 0 replies; 11+ messages in thread From: Jörn Engel @ 2002-12-10 7:46 UTC (permalink / raw) To: fred; +Cc: linuxppc-embedded, linux-mtd On Tue, 10 December 2002 14:02:05 +0800, fred wrote: > > I am using CRAMFS plus RAMFS on my board. > And there is only one sector left for saving configuration data. > Can I put a file system, e.g. JFFS, on it? You can use ext2 or minix. The just ain't no journaling with only one erase block, so forget about jffs[12], ext3 and so on. Jörn -- My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. -- Edsger W. Dijkstra ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Which filesystem can live on one flash sector? 2002-12-10 6:02 Which filesystem can live on one flash sector? fred 2002-12-10 7:46 ` Jörn Engel @ 2002-12-10 17:28 ` Russ Dill 2002-12-10 23:29 ` NAND and concat Christian Gan 1 sibling, 1 reply; 11+ messages in thread From: Russ Dill @ 2002-12-10 17:28 UTC (permalink / raw) To: fred; +Cc: linuxppc-embedded, linux-mtd On Mon, 2002-12-09 at 23:02, fred wrote: > Hi, > > I am using CRAMFS plus RAMFS on my board. > And there is only one sector left for saving configuration data. > Can I put a file system, e.g. JFFS, on it? I'd make another block free and then do some sort of journalling from userspace (each data block has a header with crc, size, header crc, and revision). If you flash it boot block flash, the boot block may be the place to find a couple small free sectors. ^ permalink raw reply [flat|nested] 11+ messages in thread
* NAND and concat 2002-12-10 17:28 ` Russ Dill @ 2002-12-10 23:29 ` Christian Gan 2002-12-10 23:58 ` Charles Manning 2002-12-11 12:46 ` Robert Kaiser 0 siblings, 2 replies; 11+ messages in thread From: Christian Gan @ 2002-12-10 23:29 UTC (permalink / raw) To: linux-mtd, yaffs list Quick, but possibly loaded question: Is anyone working on concat for NAND flashes? I looked though and realised that there is no functionality at the moment for NAND (i.e. no support for read/write oob etc). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: NAND and concat 2002-12-10 23:29 ` NAND and concat Christian Gan @ 2002-12-10 23:58 ` Charles Manning 2002-12-11 15:58 ` Christian Gan 2002-12-11 12:46 ` Robert Kaiser 1 sibling, 1 reply; 11+ messages in thread From: Charles Manning @ 2002-12-10 23:58 UTC (permalink / raw) To: Christian Gan, linux-mtd, yaffs list I'm not sure I understand what you mean by concat for NAND. Do you mean being able to read/write directly to the char device? Certainly handling OOB and pages makes things a bit different. Someone wrote a nand dumper which maybe does what you want (or can be persuaded :-). The yaffs format tool uses the char interface. It needs to expand to load up a mkyaffsimage image into flash. -- CHarles ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: NAND and concat 2002-12-10 23:58 ` Charles Manning @ 2002-12-11 15:58 ` Christian Gan 0 siblings, 0 replies; 11+ messages in thread From: Christian Gan @ 2002-12-11 15:58 UTC (permalink / raw) To: linux-mtd, yaffs list Sorry Charles, I think the title should have been "NAND and mtdconcat". :) > -----Original Message----- > From: linux-mtd-admin@lists.infradead.org > [mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Charles Manning > Sent: Tuesday, December 10, 2002 5:58 PM > To: Christian Gan; linux-mtd@lists.infradead.org; yaffs list > Subject: Re: NAND and concat > > > I'm not sure I understand what you mean by concat for NAND. Do > you mean being > able to read/write directly to the char device? > > Certainly handling OOB and pages makes things a bit different. > Someone wrote > a nand dumper which maybe does what you want (or can be persuaded > :-). The > yaffs format tool uses the char interface. It needs to expand to > load up a > mkyaffsimage image into flash. > > -- CHarles > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: NAND and concat 2002-12-10 23:29 ` NAND and concat Christian Gan 2002-12-10 23:58 ` Charles Manning @ 2002-12-11 12:46 ` Robert Kaiser 2002-12-11 15:57 ` Christian Gan 2003-03-05 19:21 ` [PATCH] NAND and mtdconcat Christian Gan 1 sibling, 2 replies; 11+ messages in thread From: Robert Kaiser @ 2002-12-11 12:46 UTC (permalink / raw) To: Christian Gan, linux-mtd, yaffs list Am Mittwoch, 11. Dezember 2002 00:29 schrieb Christian Gan: > Is anyone working on concat for NAND flashes? Probably not. > I looked though and realised > that there is no functionality at the moment for NAND (i.e. no support for > read/write oob etc). I must admit that I knew nothing about NAND flashes when I wrote the concat stuff (and this hasn't improved much in the meantime) :-(. OTOH, all the concat stuff does is to redirect calls to the hardware drivers, so, except for the maintaining of OOB data, what NAND specific functionality would be needed ? 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 [flat|nested] 11+ messages in thread
* RE: NAND and concat 2002-12-11 12:46 ` Robert Kaiser @ 2002-12-11 15:57 ` Christian Gan 2003-03-05 19:21 ` [PATCH] NAND and mtdconcat Christian Gan 1 sibling, 0 replies; 11+ messages in thread From: Christian Gan @ 2002-12-11 15:57 UTC (permalink / raw) To: rkaiser, linux-mtd, yaffs list I haven't really given it much thought either, but off the top of my head: 1. read_ecc and write_ecc 2. read_oob and write_oob But really, I think this may be OK to do. Since I need something like this for my project anyways I can give it a shot and test. Everything else should be useable as is. If anyone can think of anything I should watch out for, advice would be great. > -----Original Message----- > From: linux-mtd-admin@lists.infradead.org > [mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Robert Kaiser > Sent: Wednesday, December 11, 2002 6:47 AM > To: Christian Gan; linux-mtd@lists.infradead.org; yaffs list > Subject: Re: NAND and concat > > > Am Mittwoch, 11. Dezember 2002 00:29 schrieb Christian Gan: > > Is anyone working on concat for NAND flashes? > > Probably not. > > > I looked though and realised > > that there is no functionality at the moment for NAND (i.e. no > support for > > read/write oob etc). > > I must admit that I knew nothing about NAND flashes when I wrote > the concat > stuff (and this hasn't improved much in the meantime) :-(. > > OTOH, all the concat stuff does is to redirect calls to the > hardware drivers, > so, except for the maintaining of OOB data, what NAND specific > functionality > would be needed ? > > 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 > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] NAND and mtdconcat 2002-12-11 12:46 ` Robert Kaiser 2002-12-11 15:57 ` Christian Gan @ 2003-03-05 19:21 ` Christian Gan 2003-03-06 12:10 ` Robert Kaiser 1 sibling, 1 reply; 11+ messages in thread From: Christian Gan @ 2003-03-05 19:21 UTC (permalink / raw) To: linux-mtd This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C2E31A.116CC0F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello all, Attached is a patch for mtdconcat.c that supports NAND functions for the oob. I've tested it on my own bench and it seems to work great on two 64MB NANDs concatenated into one MTD. Robert, since you were the original author of this file, can you verify it for me? Thanks! ------=_NextPart_000_0132_01C2E31A.116CC0F0 Content-Type: application/octet-stream; name="mtdconcat.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mtdconcat.diff" Index: mtdconcat.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /home/cvs/mtd/drivers/mtd/mtdconcat.c,v=0A= retrieving revision 1.3=0A= diff -u -r1.3 mtdconcat.c=0A= --- mtdconcat.c 21 May 2002 21:04:25 -0000 1.3=0A= +++ mtdconcat.c 5 Mar 2003 19:13:45 -0000=0A= @@ -52,6 +52,8 @@=0A= size_t *retlen, u_char *buf)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size, retsize;=0A= int err =3D -EINVAL;=0A= int i;=0A= =0A= @@ -59,20 +61,21 @@=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= - size_t size, retsize;=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= + retsize =3D 0;=0A= =0A= if (from >=3D subdev->size)=0A= - {=0A= + { /* Not destined for this subdev */=0A= size =3D 0;=0A= from -=3D subdev->size;=0A= }=0A= else=0A= {=0A= if (from + len > subdev->size)=0A= - size =3D subdev->size - from;=0A= + size =3D subdev->size - from; /* First part goes into this subdev */=0A= else=0A= - size =3D len;=0A= + size =3D len; /* Entire transaction goes into this subdev */=0A= =0A= err =3D subdev->read(subdev, from, size, &retsize, buf);=0A= =0A= @@ -96,6 +99,8 @@=0A= size_t *retlen, const u_char *buf)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size, retsize;=0A= int err =3D -EINVAL;=0A= int i;=0A= =0A= @@ -106,8 +111,9 @@=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= - size_t size, retsize;=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= + retsize =3D 0;=0A= =0A= if (to >=3D subdev->size)=0A= {=0A= @@ -142,6 +148,226 @@=0A= return err;=0A= }=0A= =0A= +static int concat_read_ecc (struct mtd_info *mtd, loff_t from, size_t = len,=0A= + size_t *retlen, u_char *buf, u_char *eccbuf, int oobsel)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size, retsize;=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= + retsize =3D 0;=0A= +=0A= + if (from >=3D subdev->size)=0A= + { /* Not destined for this subdev */=0A= + size =3D 0;=0A= + from -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (from + len > subdev->size)=0A= + size =3D subdev->size - from; /* First part goes into this subdev */=0A= + else=0A= + size =3D len; /* Entire transaction goes into this subdev */=0A= + =0A= + if (subdev->read_ecc)=0A= + err =3D subdev->read_ecc(subdev, from, size, &retsize, buf, = eccbuf, oobsel);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + if (eccbuf)=0A= + {=0A= + eccbuf +=3D subdev->oobsize;=0A= + /* in nand.c at least, eccbufs are tagged with 2 = (int)eccstatus',=0A= + we must account for these */=0A= + eccbuf +=3D 2 * (sizeof(int)); =0A= + }=0A= + from =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +static int concat_write_ecc (struct mtd_info *mtd, loff_t to, size_t = len,=0A= + size_t *retlen, const u_char *buf, u_char *eccbuf, int = oobsel)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size, retsize;=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + if (!(mtd->flags & MTD_WRITEABLE))=0A= + return -EROFS;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= + retsize =3D 0;=0A= +=0A= + if (to >=3D subdev->size)=0A= + {=0A= + size =3D 0;=0A= + to -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (to + len > subdev->size)=0A= + size =3D subdev->size - to;=0A= + else=0A= + size =3D len;=0A= +=0A= + if (!(subdev->flags & MTD_WRITEABLE))=0A= + err =3D -EROFS;=0A= + else if (subdev->write_ecc)=0A= + err =3D subdev->write_ecc(subdev, to, size, &retsize, buf, eccbuf, = oobsel);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + if (eccbuf)=0A= + eccbuf +=3D subdev->oobsize;=0A= + to =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +static int concat_read_oob (struct mtd_info *mtd, loff_t from, size_t = len,=0A= + size_t *retlen, u_char *buf)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size, retsize;=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= + retsize =3D 0;=0A= +=0A= + if (from >=3D subdev->size)=0A= + { /* Not destined for this subdev */=0A= + size =3D 0;=0A= + from -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (from + len > subdev->size)=0A= + size =3D subdev->size - from; /* First part goes into this subdev */=0A= + else=0A= + size =3D len; /* Entire transaction goes into this subdev */=0A= + =0A= + if (subdev->read_oob)=0A= + err =3D subdev->read_oob(subdev, from, size, &retsize, buf);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + from =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +static int concat_write_oob (struct mtd_info *mtd, loff_t to, size_t = len, =0A= + size_t *retlen, const u_char *buf)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size, retsize;=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + if (!(mtd->flags & MTD_WRITEABLE))=0A= + return -EROFS;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= + retsize =3D 0;=0A= +=0A= + if (to >=3D subdev->size)=0A= + {=0A= + size =3D 0;=0A= + to -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (to + len > subdev->size)=0A= + size =3D subdev->size - to;=0A= + else=0A= + size =3D len;=0A= +=0A= + if (!(subdev->flags & MTD_WRITEABLE))=0A= + err =3D -EROFS;=0A= + else if (subdev->write_oob)=0A= + err =3D subdev->write_oob(subdev, to, size, &retsize, buf);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + to =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +=0A= static void concat_erase_callback (struct erase_info *instr)=0A= {=0A= wake_up((wait_queue_head_t *)instr->priv);=0A= @@ -316,6 +542,8 @@=0A= static int concat_lock (struct mtd_info *mtd, loff_t ofs, size_t len)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size;=0A= int i, err =3D -EINVAL;=0A= =0A= if ((len + ofs) > mtd->size) =0A= @@ -323,8 +551,8 @@=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= - size_t size;=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= =0A= if (ofs >=3D subdev->size)=0A= {=0A= @@ -357,6 +585,8 @@=0A= static int concat_unlock (struct mtd_info *mtd, loff_t ofs, size_t len)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL;=0A= + size_t size;=0A= int i, err =3D 0;=0A= =0A= if ((len + ofs) > mtd->size) =0A= @@ -364,8 +594,8 @@=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= - size_t size;=0A= + subdev =3D concat->subdev[i];=0A= + size =3D 0;=0A= =0A= if (ofs >=3D subdev->size)=0A= {=0A= @@ -398,11 +628,12 @@=0A= static void concat_sync(struct mtd_info *mtd)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL; =0A= int i;=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= + subdev =3D concat->subdev[i];=0A= subdev->sync(subdev);=0A= }=0A= }=0A= @@ -410,11 +641,12 @@=0A= static int concat_suspend(struct mtd_info *mtd)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL; =0A= int i, rc =3D 0;=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= + subdev =3D concat->subdev[i];=0A= if((rc =3D subdev->suspend(subdev)) < 0)=0A= return rc;=0A= }=0A= @@ -424,11 +656,12 @@=0A= static void concat_resume(struct mtd_info *mtd)=0A= {=0A= struct mtd_concat *concat =3D CONCAT(mtd);=0A= + struct mtd_info *subdev =3D NULL; =0A= int i;=0A= =0A= for(i =3D 0; i < concat->num_subdev; i++)=0A= {=0A= - struct mtd_info *subdev =3D concat->subdev[i];=0A= + subdev =3D concat->subdev[i]; =0A= subdev->resume(subdev);=0A= }=0A= }=0A= @@ -526,9 +759,13 @@=0A= * because they are messy to implement and they are not=0A= * used to a great extent anyway.=0A= */=0A= - concat->mtd.erase =3D concat_erase;=0A= - concat->mtd.read =3D concat_read;=0A= - concat->mtd.write =3D concat_write;=0A= + concat->mtd.erase =3D concat_erase;=0A= + concat->mtd.read =3D concat_read; =0A= + concat->mtd.write =3D concat_write;=0A= + concat->mtd.read_ecc =3D concat_read_ecc; =0A= + concat->mtd.write_ecc =3D concat_write_ecc;=0A= + concat->mtd.read_oob =3D concat_read_oob; =0A= + concat->mtd.write_oob =3D concat_write_oob;=0A= concat->mtd.sync =3D concat_sync;=0A= concat->mtd.lock =3D concat_lock;=0A= concat->mtd.unlock =3D concat_unlock;=0A= ------=_NextPart_000_0132_01C2E31A.116CC0F0-- ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] NAND and mtdconcat 2003-03-05 19:21 ` [PATCH] NAND and mtdconcat Christian Gan @ 2003-03-06 12:10 ` Robert Kaiser 2003-03-06 23:10 ` Christian Gan 0 siblings, 1 reply; 11+ messages in thread From: Robert Kaiser @ 2003-03-06 12:10 UTC (permalink / raw) To: linux-mtd Christian, Am Mittwoch, 5. M?rz 2003 20:21 schrieb Christian Gan: > Hello all, > > Attached is a patch for mtdconcat.c that supports NAND functions for the > oob. I've tested it on my own bench and it seems to work great on two 64MB > NANDs concatenated into one MTD. > > Robert, since you were the original author of this file, can you verify it > for me? Looks OK to me. I can't test it right now as I don't have any suitable HW available, but I'll take your word that it works ;-) One question though, you made changes like this: @@ -410,11 +641,12 @@ static int concat_suspend(struct mtd_info *mtd) { struct mtd_concat *concat = CONCAT(mtd); + struct mtd_info *subdev = NULL; int i, rc = 0; for(i = 0; i < concat->num_subdev; i++) { - struct mtd_info *subdev = concat->subdev[i]; + subdev = concat->subdev[i]; if((rc = subdev->suspend(subdev)) < 0) return rc; } @@ -424,11 +656,12 @@ all over the place. Why? This might generate slightly more code and be slower (not that it would be noticeable though). Other than that, I have no objections. 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 [flat|nested] 11+ messages in thread
* [PATCH] NAND and mtdconcat 2003-03-06 12:10 ` Robert Kaiser @ 2003-03-06 23:10 ` Christian Gan 0 siblings, 0 replies; 11+ messages in thread From: Christian Gan @ 2003-03-06 23:10 UTC (permalink / raw) To: linux-mtd This is a multi-part message in MIME format. ------=_NextPart_000_015B_01C2E403.4B14E2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hey all, Updated patch included with Robert's suggestions. I agree that either style is a non-factor in performance, so I might as well use the original style because it's cleaner. Thanks! Christian > -----Original Message----- > From: linux-mtd-admin at lists.infradead.org > [mailto:linux-mtd-admin at lists.infradead.org]On Behalf Of Robert Kaiser > Sent: Thursday, March 06, 2003 6:10 AM > To: Christian Gan; rkaiser at sysgo.de; linux-mtd at lists.infradead.org; > yaffs list > Subject: Re: [PATCH] NAND and mtdconcat > > > Christian, > > > Am Mittwoch, 5. M?rz 2003 20:21 schrieb Christian Gan: > > Hello all, > > > > Attached is a patch for mtdconcat.c that supports NAND functions for the > > oob. I've tested it on my own bench and it seems to work great > on two 64MB > > NANDs concatenated into one MTD. > > > > Robert, since you were the original author of this file, can > you verify it > > for me? > > Looks OK to me. I can't test it right now as I don't have any suitable HW > available, but I'll take your word that it works ;-) > > One question though, you made changes like this: > > > @@ -410,11 +641,12 @@ > static int concat_suspend(struct mtd_info *mtd) > { > struct mtd_concat *concat = CONCAT(mtd); > + struct mtd_info *subdev = NULL; > int i, rc = 0; > > for(i = 0; i < concat->num_subdev; i++) > { > - struct mtd_info *subdev = concat->subdev[i]; > + subdev = concat->subdev[i]; > if((rc = subdev->suspend(subdev)) < 0) > return rc; > } > @@ -424,11 +656,12 @@ > > all over the place. Why? This might generate slightly more code > and be slower > (not that it would be noticeable though). > > Other than that, I have no objections. > > Rob > > > ---------------------------------------------------------------- > Robert Kaiser email: rkaiser at sysgo.de > SYSGO AG > Am Pfaffenstein 14 phone: (49) 6136 9948-762 > D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > ------=_NextPart_000_015B_01C2E403.4B14E2D0 Content-Type: application/octet-stream; name="mtdconcat.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mtdconcat.diff" Index: mtdconcat.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /home/cvs/mtd/drivers/mtd/mtdconcat.c,v=0A= retrieving revision 1.3=0A= diff -u -r1.3 mtdconcat.c=0A= --- mtdconcat.c 21 May 2002 21:04:25 -0000 1.3=0A= +++ mtdconcat.c 6 Mar 2003 19:50:31 -0000=0A= @@ -63,16 +63,16 @@=0A= size_t size, retsize;=0A= =0A= if (from >=3D subdev->size)=0A= - {=0A= + { /* Not destined for this subdev */=0A= size =3D 0;=0A= from -=3D subdev->size;=0A= }=0A= else=0A= {=0A= if (from + len > subdev->size)=0A= - size =3D subdev->size - from;=0A= + size =3D subdev->size - from; /* First part goes into this subdev */=0A= else=0A= - size =3D len;=0A= + size =3D len; /* Entire transaction goes into this subdev */=0A= =0A= err =3D subdev->read(subdev, from, size, &retsize, buf);=0A= =0A= @@ -142,6 +142,214 @@=0A= return err;=0A= }=0A= =0A= +static int concat_read_ecc (struct mtd_info *mtd, loff_t from, size_t = len,=0A= + size_t *retlen, u_char *buf, u_char *eccbuf, int oobsel)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + struct mtd_info *subdev =3D concat->subdev[i];=0A= + size_t size, retsize;=0A= + =0A= + if (from >=3D subdev->size)=0A= + { /* Not destined for this subdev */=0A= + size =3D 0;=0A= + from -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (from + len > subdev->size)=0A= + size =3D subdev->size - from; /* First part goes into this subdev */=0A= + else=0A= + size =3D len; /* Entire transaction goes into this subdev */=0A= + =0A= + if (subdev->read_ecc)=0A= + err =3D subdev->read_ecc(subdev, from, size, &retsize, buf, = eccbuf, oobsel);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + if (eccbuf)=0A= + {=0A= + eccbuf +=3D subdev->oobsize;=0A= + /* in nand.c at least, eccbufs are tagged with 2 = (int)eccstatus',=0A= + we must account for these */=0A= + eccbuf +=3D 2 * (sizeof(int)); =0A= + }=0A= + from =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +static int concat_write_ecc (struct mtd_info *mtd, loff_t to, size_t = len,=0A= + size_t *retlen, const u_char *buf, u_char *eccbuf, int = oobsel)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + if (!(mtd->flags & MTD_WRITEABLE))=0A= + return -EROFS;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + struct mtd_info *subdev =3D concat->subdev[i];=0A= + size_t size, retsize;=0A= + =0A= + if (to >=3D subdev->size)=0A= + {=0A= + size =3D 0;=0A= + to -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (to + len > subdev->size)=0A= + size =3D subdev->size - to;=0A= + else=0A= + size =3D len;=0A= +=0A= + if (!(subdev->flags & MTD_WRITEABLE))=0A= + err =3D -EROFS;=0A= + else if (subdev->write_ecc)=0A= + err =3D subdev->write_ecc(subdev, to, size, &retsize, buf, eccbuf, = oobsel);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + if (eccbuf)=0A= + eccbuf +=3D subdev->oobsize;=0A= + to =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +static int concat_read_oob (struct mtd_info *mtd, loff_t from, size_t = len,=0A= + size_t *retlen, u_char *buf)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + struct mtd_info *subdev =3D concat->subdev[i];=0A= + size_t size, retsize;=0A= + =0A= + if (from >=3D subdev->size)=0A= + { /* Not destined for this subdev */=0A= + size =3D 0;=0A= + from -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (from + len > subdev->size)=0A= + size =3D subdev->size - from; /* First part goes into this subdev */=0A= + else=0A= + size =3D len; /* Entire transaction goes into this subdev */=0A= + =0A= + if (subdev->read_oob)=0A= + err =3D subdev->read_oob(subdev, from, size, &retsize, buf);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + from =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +static int concat_write_oob (struct mtd_info *mtd, loff_t to, size_t = len, =0A= + size_t *retlen, const u_char *buf)=0A= +{=0A= + struct mtd_concat *concat =3D CONCAT(mtd);=0A= + int err =3D -EINVAL;=0A= + int i;=0A= +=0A= + if (!(mtd->flags & MTD_WRITEABLE))=0A= + return -EROFS;=0A= +=0A= + *retlen =3D 0;=0A= +=0A= + for(i =3D 0; i < concat->num_subdev; i++)=0A= + {=0A= + struct mtd_info *subdev =3D concat->subdev[i];=0A= + size_t size, retsize;=0A= + =0A= + if (to >=3D subdev->size)=0A= + {=0A= + size =3D 0;=0A= + to -=3D subdev->size;=0A= + }=0A= + else=0A= + {=0A= + if (to + len > subdev->size)=0A= + size =3D subdev->size - to;=0A= + else=0A= + size =3D len;=0A= +=0A= + if (!(subdev->flags & MTD_WRITEABLE))=0A= + err =3D -EROFS;=0A= + else if (subdev->write_oob)=0A= + err =3D subdev->write_oob(subdev, to, size, &retsize, buf);=0A= + else=0A= + err =3D -EINVAL;=0A= +=0A= + if(err)=0A= + break;=0A= +=0A= + *retlen +=3D retsize;=0A= + len -=3D size;=0A= + if(len =3D=3D 0)=0A= + break;=0A= +=0A= + err =3D -EINVAL;=0A= + buf +=3D size;=0A= + to =3D 0;=0A= + }=0A= + }=0A= + return err;=0A= +}=0A= +=0A= +=0A= static void concat_erase_callback (struct erase_info *instr)=0A= {=0A= wake_up((wait_queue_head_t *)instr->priv);=0A= @@ -526,9 +734,13 @@=0A= * because they are messy to implement and they are not=0A= * used to a great extent anyway.=0A= */=0A= - concat->mtd.erase =3D concat_erase;=0A= - concat->mtd.read =3D concat_read;=0A= - concat->mtd.write =3D concat_write;=0A= + concat->mtd.erase =3D concat_erase;=0A= + concat->mtd.read =3D concat_read; =0A= + concat->mtd.write =3D concat_write;=0A= + concat->mtd.read_ecc =3D concat_read_ecc; =0A= + concat->mtd.write_ecc =3D concat_write_ecc;=0A= + concat->mtd.read_oob =3D concat_read_oob; =0A= + concat->mtd.write_oob =3D concat_write_oob;=0A= concat->mtd.sync =3D concat_sync;=0A= concat->mtd.lock =3D concat_lock;=0A= concat->mtd.unlock =3D concat_unlock;=0A= ------=_NextPart_000_015B_01C2E403.4B14E2D0-- ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-03-06 23:10 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-12-10 6:02 Which filesystem can live on one flash sector? fred 2002-12-10 7:46 ` Jörn Engel 2002-12-10 17:28 ` Russ Dill 2002-12-10 23:29 ` NAND and concat Christian Gan 2002-12-10 23:58 ` Charles Manning 2002-12-11 15:58 ` Christian Gan 2002-12-11 12:46 ` Robert Kaiser 2002-12-11 15:57 ` Christian Gan 2003-03-05 19:21 ` [PATCH] NAND and mtdconcat Christian Gan 2003-03-06 12:10 ` Robert Kaiser 2003-03-06 23:10 ` Christian Gan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox