* 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: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
* 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
* [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