* DiskOnChip 2000 128Mb problem
@ 2003-05-07 20:37 Matthew Dharm
2003-05-08 6:17 ` David Woodhouse
0 siblings, 1 reply; 20+ messages in thread
From: Matthew Dharm @ 2003-05-07 20:37 UTC (permalink / raw)
To: linux-mtd
I'm porting Linux to our embedded PPC platform. We have a DoC 2000
(apparently known as "Millenium") on the board, and I'm having
problems getting the driver working. I'm hoping someone here can
help... I think the issue is that the driver doesn't support this
part, tho it should (are we really the first to try this?).
We're using kernel 2.4.17, upgraded with MTD from CVS as of today.
Our DoC is 128MB in size and operates at 3.3 V.
Here's our story: The main DoC driver detects the device, but is
unable to identify any flash devices. At boot time, it shows:
Using configured DiskOnChip probe address 0x70400000
DiskOnChip Millennium found at address 0x70400000
No flash chips recognised.
NFTL driver: nftlcore.c $Revision: 1.88 $, nftlmount.c $Revision: 1.31
$
And /proc/mtd shows no entries. If I switch to the Millenium-only
driver, (config change and edit docprobe.c), we get:
Using configured DiskOnChip probe address 0x70400000
DiskOnChip Millennium found at address 0x70400000
Flash chip found: Manufacturer ID: EC, Chip ID: 76 (Samsung:NAND 64MB
3,3V)
1 flash chips found. Total DiskOnChip size: 64 MiB
mtd: Giving out device 0 to DiskOnChip Millennium
NFTL driver: nftlcore.c $Revision: 1.88 $, nftlmount.c $Revision: 1.31
$
NFTL_notify_add for DiskOnChip Millennium
mtd->read = c00cd470, size = 67108864, erasesize = 8192
NFTL_setup
Could not find valid boot record
Could not mount NFTL device
And, in /proc/mtd:
# cat /proc/mtd
dev: size erasesize name
mtd0: 04000000 00002000 "DiskOnChip Millennium"
Which is interesting, because it is exactly half the correct size. A
quick check through the source code shows that MAX_CHIPS_MIL is set to
1, and there is a FIXME in doc2001.c "to deal with multi-flash on
multi-Millenium case more carefully". If I change the definition of
MAX_CHIPS_MIL to 4, we get:
Using configured DiskOnChip probe address 0x70400000
DiskOnChip Millennium found at address 0x70400000
Flash chip found: Manufacturer ID: EC, Chip ID: 76 (Samsung:NAND 64MB
3,3V)
Flash chip found: Manufacturer ID: EC, Chip ID: 76 (Samsung:NAND 64MB
3,3V)
2 flash chips found. Total DiskOnChip size: 128 MiB
mtd: Giving out device 0 to DiskOnChip Millennium
NFTL driver: nftlcore.c $Revision: 1.88 $, nftlmount.c $Revision: 1.31
$
NFTL_notify_add for DiskOnChip Millennium
mtd->read = c00cd450, size = 134217728, erasesize = 8192
NFTL_setup
Could not find valid boot record
Could not mount NFTL device
# cat /proc/mtd
dev: size erasesize name
mtd0: 08000000 00002000 "DiskOnChip Millennium"
So it looks like the driver can probe and see the multiple flash chips
present, but can't seem to actually do anything with them. I didn't
really expect that change to make it work, but it does show that I
have the right amount of flash in the part
Of course, now you ask if the chip is formatted. I believe it is, as
the part was tested under VxWorks and data was actually written to it.
My understanding is that the format is supposed to be compatible....
I've tried nftldump, but it doesn't seem to generate any output.
nftl_format just gives a large number of errors as it tries to format
the part.
Does anyone have any ideas on where to go from here? Perhaps someone
can explain what the FIXME means (if applicable)
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DiskOnChip 2000 128Mb problem
2003-05-07 20:37 DiskOnChip 2000 128Mb problem Matthew Dharm
@ 2003-05-08 6:17 ` David Woodhouse
2003-05-08 18:04 ` Matthew Dharm
0 siblings, 1 reply; 20+ messages in thread
From: David Woodhouse @ 2003-05-08 6:17 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
On Wed, 2003-05-07 at 21:37, Matthew Dharm wrote:
> I'm porting Linux to our embedded PPC platform. We have a DoC 2000
> (apparently known as "Millenium") on the board,
The DiskOnChip 2000 and DiskOnChip Millennium are separate beasts.
Remember the new Millennium didn't start till 2001 :)
You had a DiskOnChip 2000 on the Ocelots, and it's been working fine --
looks like you really do have a Millennium on the new board though.
Incidentally, why are you using these expensive parts and not just
putting raw flash on there?
> and I'm having problems getting the driver working. I'm hoping
> someone here can help... I think the issue is that the driver doesn't
> support this part, tho it should (are we really the first to try
> this?).
>
> We're using kernel 2.4.17, upgraded with MTD from CVS as of today.
> Our DoC is 128MB in size and operates at 3.3 V.
>
> Here's our story: The main DoC driver detects the device, but is
> unable to identify any flash devices. At boot time, it shows:
>
> Using configured DiskOnChip probe address 0x70400000
> DiskOnChip Millennium found at address 0x70400000
> No flash chips recognised.
Odd. There shouldn't really be much difference in behaviour between the
2000 and the 2001 drivers. They diverged for a while, then we merged
them. Some tracing and debugging ought to show what the merged driver is
doing differently (and, I assume, wrong).
<...>
> Which is interesting, because it is exactly half the correct size. A
> quick check through the source code shows that MAX_CHIPS_MIL is set to
> 1, and there is a FIXME in doc2001.c "to deal with multi-flash on
> multi-Millenium case more carefully". If I change the definition of
> MAX_CHIPS_MIL to 4, we get:
>
> Using configured DiskOnChip probe address 0x70400000
> DiskOnChip Millennium found at address 0x70400000
> Flash chip found: Manufacturer ID: EC, Chip ID: 76 (Samsung:NAND 64MB 3,3V)
> Flash chip found: Manufacturer ID: EC, Chip ID: 76 (Samsung:NAND 64MB 3,3V)
> 2 flash chips found. Total DiskOnChip size: 128 MiB
> mtd: Giving out device 0 to DiskOnChip Millennium
That looks basically correct now.
> NFTL driver: nftlcore.c $Revision: 1.88 $, nftlmount.c $Revision: 1.31$
> NFTL_notify_add for DiskOnChip Millennium
> mtd->read = c00cd450, size = 134217728, erasesize = 8192
> NFTL_setup
> Could not find valid boot record
> Could not mount NFTL device
At this point, it failed to find the NFTL format on the DiskOnChip. If
the kernel code fails, then 'nftldump' will too. Try 'nanddump' which
should just dump the contents of the raw flash. Look through it for a
block starting 'ANAND' and/or send me a copy.
We used to have endianness bugs in the NFTL code, but they were fixed
when I was playing with the Ocelot. I don't think there have been
changes since then, so it should still be fine.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-08 6:17 ` David Woodhouse
@ 2003-05-08 18:04 ` Matthew Dharm
2003-05-09 14:25 ` David Woodhouse
0 siblings, 1 reply; 20+ messages in thread
From: Matthew Dharm @ 2003-05-08 18:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
> On Wed, 2003-05-07 at 21:37, Matthew Dharm wrote:
> > I'm porting Linux to our embedded PPC platform. We have
> a DoC 2000
> > (apparently known as "Millenium") on the board,
>
> The DiskOnChip 2000 and DiskOnChip Millennium are separate beasts.
> Remember the new Millennium didn't start till 2001 :)
>
> You had a DiskOnChip 2000 on the Ocelots, and it's been
> working fine --
> looks like you really do have a Millennium on the new board though.
Well, now we may have found part of the problem -- the label on the
chip says "DiskOnChip 2000" with a part number of MD2202-D128-V3
So is that a 2000 or Millennium? If it's really a 2000, then the
driver is detecting it incorrectly.
> > and I'm having problems getting the driver working. I'm hoping
> > someone here can help... I think the issue is that the
> driver doesn't
> > support this part, tho it should (are we really the first to try
> > this?).
> >
> > We're using kernel 2.4.17, upgraded with MTD from CVS as of today.
> > Our DoC is 128MB in size and operates at 3.3 V.
> >
> > Here's our story: The main DoC driver detects the device, but is
> > unable to identify any flash devices. At boot time, it shows:
> >
> > Using configured DiskOnChip probe address 0x70400000
> > DiskOnChip Millennium found at address 0x70400000
> > No flash chips recognised.
>
> Odd. There shouldn't really be much difference in behaviour
> between the
> 2000 and the 2001 drivers. They diverged for a while, then we merged
> them. Some tracing and debugging ought to show what the
> merged driver is
> doing differently (and, I assume, wrong).
>
> <...>
>
> > Which is interesting, because it is exactly half the
> correct size. A
> > quick check through the source code shows that
> MAX_CHIPS_MIL is set to
> > 1, and there is a FIXME in doc2001.c "to deal with multi-flash on
> > multi-Millenium case more carefully". If I change the
> definition of
> > MAX_CHIPS_MIL to 4, we get:
> >
> > Using configured DiskOnChip probe address 0x70400000
> > DiskOnChip Millennium found at address 0x70400000
> > Flash chip found: Manufacturer ID: EC, Chip ID: 76
> (Samsung:NAND 64MB 3,3V)
> > Flash chip found: Manufacturer ID: EC, Chip ID: 76
> (Samsung:NAND 64MB 3,3V)
> > 2 flash chips found. Total DiskOnChip size: 128 MiB
> > mtd: Giving out device 0 to DiskOnChip Millennium
>
> That looks basically correct now.
Well, that's worth something, I guess.
> > NFTL driver: nftlcore.c $Revision: 1.88 $, nftlmount.c
> $Revision: 1.31$
> > NFTL_notify_add for DiskOnChip Millennium
> > mtd->read = c00cd450, size = 134217728, erasesize = 8192
> > NFTL_setup
> > Could not find valid boot record
> > Could not mount NFTL device
>
> At this point, it failed to find the NFTL format on the
> DiskOnChip. If
> the kernel code fails, then 'nftldump' will too. Try
> 'nanddump' which
> should just dump the contents of the raw flash. Look
> through it for a
> block starting 'ANAND' and/or send me a copy.
I presume nanddump works on the /dev/mtd0 node?
Matt
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-08 18:04 ` Matthew Dharm
@ 2003-05-09 14:25 ` David Woodhouse
2003-05-09 14:35 ` David Woodhouse
0 siblings, 1 reply; 20+ messages in thread
From: David Woodhouse @ 2003-05-09 14:25 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
On Thu, 2003-05-08 at 19:04, Matthew Dharm wrote:
> Well, now we may have found part of the problem -- the label on the
> chip says "DiskOnChip 2000" with a part number of MD2202-D128-V3
>
> So is that a 2000 or Millennium? If it's really a 2000, then the
> driver is detecting it incorrectly.
It's probably a Millennium.
> I presume nanddump works on the /dev/mtd0 node?
Yes.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 14:25 ` David Woodhouse
@ 2003-05-09 14:35 ` David Woodhouse
2003-05-09 16:40 ` Matthew Dharm
2003-05-31 13:08 ` David Woodhouse
0 siblings, 2 replies; 20+ messages in thread
From: David Woodhouse @ 2003-05-09 14:35 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
On Fri, 2003-05-09 at 15:25, David Woodhouse wrote:
> On Thu, 2003-05-08 at 19:04, Matthew Dharm wrote:
> > Well, now we may have found part of the problem -- the label on the
> > chip says "DiskOnChip 2000" with a part number of MD2202-D128-V3
> >
> > So is that a 2000 or Millennium? If it's really a 2000, then the
> > driver is detecting it incorrectly.
>
> It's probably a Millennium.
I lied. That's a DiskOnChip 2000 part number, I think. Check bus width,
timing, etc. for the chip select you've attached it to. I know PMON used
to set it up wrong for the Ocelot, we fix it up manually in Linux.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 14:35 ` David Woodhouse
@ 2003-05-09 16:40 ` Matthew Dharm
2003-05-09 16:48 ` David Woodhouse
2003-05-31 13:08 ` David Woodhouse
1 sibling, 1 reply; 20+ messages in thread
From: Matthew Dharm @ 2003-05-09 16:40 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
Is it normal for a DoC 2000 to be detected as a Millenium?
I've already checked the bus width and timing.
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Friday, May 09, 2003 7:35 AM
> To: Matthew Dharm
> Cc: linux-mtd@lists.infradead.org
> Subject: RE: DiskOnChip 2000 128Mb problem
>
>
> On Fri, 2003-05-09 at 15:25, David Woodhouse wrote:
> > On Thu, 2003-05-08 at 19:04, Matthew Dharm wrote:
> > > Well, now we may have found part of the problem -- the
> label on the
> > > chip says "DiskOnChip 2000" with a part number of MD2202-D128-V3
> > >
> > > So is that a 2000 or Millennium? If it's really a
> 2000, then the
> > > driver is detecting it incorrectly.
> >
> > It's probably a Millennium.
>
> I lied. That's a DiskOnChip 2000 part number, I think.
> Check bus width,
> timing, etc. for the chip select you've attached it to. I
> know PMON used
> to set it up wrong for the Ocelot, we fix it up manually in Linux.
>
> --
> dwmw2
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 16:40 ` Matthew Dharm
@ 2003-05-09 16:48 ` David Woodhouse
2003-05-09 16:58 ` Matthew Dharm
0 siblings, 1 reply; 20+ messages in thread
From: David Woodhouse @ 2003-05-09 16:48 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> Is it normal for a DoC 2000 to be detected as a Millenium?
No, but it's not normal for its contents to be read back as 0x01 0x02
0x03 etc. either: )
> I've already checked the bus width and timing.
And it's definitely not set to 16-bit? -ECONFUSED.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 16:48 ` David Woodhouse
@ 2003-05-09 16:58 ` Matthew Dharm
2003-05-09 20:23 ` Edward A. Hildum
0 siblings, 1 reply; 20+ messages in thread
From: Matthew Dharm @ 2003-05-09 16:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Friday, May 09, 2003 9:48 AM
> To: Matthew Dharm
> Cc: linux-mtd@lists.infradead.org
> Subject: RE: DiskOnChip 2000 128Mb problem
>
>
> On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> > Is it normal for a DoC 2000 to be detected as a Millenium?
>
> No, but it's not normal for its contents to be read back as
> 0x01 0x02
> 0x03 etc. either: )
Okay, so we're all on the same page.
> > I've already checked the bus width and timing.
>
> And it's definitely not set to 16-bit? -ECONFUSED.
No kidding. I'm hoping the docs will have something useful, and I'm
about to pull out the bus analyizer.
Matt
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 16:58 ` Matthew Dharm
@ 2003-05-09 20:23 ` Edward A. Hildum
2003-05-09 20:29 ` Matthew Dharm
0 siblings, 1 reply; 20+ messages in thread
From: Edward A. Hildum @ 2003-05-09 20:23 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
I had a similar experience using a DOC 2000 TSOP 256M part. Its chip ID is
0x30, which is right for a Millenium part, even though it has a DOC 2000
part number. The part also has an IPL which can be updated like Millenium
parts.
Ted Hildum
At 09:58 AM 5/9/2003 -0700, you wrote:
> > -----Original Message-----
> > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > Sent: Friday, May 09, 2003 9:48 AM
> > To: Matthew Dharm
> > Cc: linux-mtd@lists.infradead.org
> > Subject: RE: DiskOnChip 2000 128Mb problem
> >
> >
> > On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> > > Is it normal for a DoC 2000 to be detected as a Millenium?
> >
> > No, but it's not normal for its contents to be read back as
> > 0x01 0x02
> > 0x03 etc. either: )
>
>Okay, so we're all on the same page.
>
> > > I've already checked the bus width and timing.
> >
> > And it's definitely not set to 16-bit? -ECONFUSED.
>
>No kidding. I'm hoping the docs will have something useful, and I'm
>about to pull out the bus analyizer.
>
>
>Matt
>
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 20:23 ` Edward A. Hildum
@ 2003-05-09 20:29 ` Matthew Dharm
2003-05-12 20:42 ` Edward A. Hildum
0 siblings, 1 reply; 20+ messages in thread
From: Matthew Dharm @ 2003-05-09 20:29 UTC (permalink / raw)
To: Edward A. Hildum; +Cc: linux-mtd
Did the Linux drivers work for you?
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: Edward A. Hildum [mailto:ehildum@mail.arc.nasa.gov]
> Sent: Friday, May 09, 2003 1:24 PM
> To: Matthew Dharm
> Cc: linux-mtd@lists.infradead.org
> Subject: RE: DiskOnChip 2000 128Mb problem
>
>
> I had a similar experience using a DOC 2000 TSOP 256M part.
> Its chip ID is
> 0x30, which is right for a Millenium part, even though it
> has a DOC 2000
> part number. The part also has an IPL which can be updated
> like Millenium
> parts.
>
> Ted Hildum
>
> At 09:58 AM 5/9/2003 -0700, you wrote:
> > > -----Original Message-----
> > > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > > Sent: Friday, May 09, 2003 9:48 AM
> > > To: Matthew Dharm
> > > Cc: linux-mtd@lists.infradead.org
> > > Subject: RE: DiskOnChip 2000 128Mb problem
> > >
> > >
> > > On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> > > > Is it normal for a DoC 2000 to be detected as a Millenium?
> > >
> > > No, but it's not normal for its contents to be read back as
> > > 0x01 0x02
> > > 0x03 etc. either: )
> >
> >Okay, so we're all on the same page.
> >
> > > > I've already checked the bus width and timing.
> > >
> > > And it's definitely not set to 16-bit? -ECONFUSED.
> >
> >No kidding. I'm hoping the docs will have something
> useful, and I'm
> >about to pull out the bus analyizer.
> >
> >
> >Matt
> >
> >
> >______________________________________________________
> >Linux MTD discussion mailing list
> >http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 20:29 ` Matthew Dharm
@ 2003-05-12 20:42 ` Edward A. Hildum
2003-05-13 1:42 ` Matthew Dharm
0 siblings, 1 reply; 20+ messages in thread
From: Edward A. Hildum @ 2003-05-12 20:42 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
They didn't, but I didn't try the Millenium-only driver. After fooling
around with GRUB, trying to get it working with the DOC, I punted and went
with the M-Systems proprietary driver. This solves my problem for
now. Maybe I'll try again later when I've got some progress on other
fronts to show.
Ted
At 01:29 PM 5/9/2003 -0700, you wrote:
>Did the Linux drivers work for you?
>
>Matt
>
>--
>Matthew D. Dharm Senior Software Designer
>Momentum Computer Inc. 1815 Aston Ave. Suite 107
>(760) 431-8663 X-115 Carlsbad, CA 92008-7310
>Momentum Works For You www.momenco.com
>
> > -----Original Message-----
> > From: Edward A. Hildum [mailto:ehildum@mail.arc.nasa.gov]
> > Sent: Friday, May 09, 2003 1:24 PM
> > To: Matthew Dharm
> > Cc: linux-mtd@lists.infradead.org
> > Subject: RE: DiskOnChip 2000 128Mb problem
> >
> >
> > I had a similar experience using a DOC 2000 TSOP 256M part.
> > Its chip ID is
> > 0x30, which is right for a Millenium part, even though it
> > has a DOC 2000
> > part number. The part also has an IPL which can be updated
> > like Millenium
> > parts.
> >
> > Ted Hildum
> >
> > At 09:58 AM 5/9/2003 -0700, you wrote:
> > > > -----Original Message-----
> > > > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > > > Sent: Friday, May 09, 2003 9:48 AM
> > > > To: Matthew Dharm
> > > > Cc: linux-mtd@lists.infradead.org
> > > > Subject: RE: DiskOnChip 2000 128Mb problem
> > > >
> > > >
> > > > On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> > > > > Is it normal for a DoC 2000 to be detected as a Millenium?
> > > >
> > > > No, but it's not normal for its contents to be read back as
> > > > 0x01 0x02
> > > > 0x03 etc. either: )
> > >
> > >Okay, so we're all on the same page.
> > >
> > > > > I've already checked the bus width and timing.
> > > >
> > > > And it's definitely not set to 16-bit? -ECONFUSED.
> > >
> > >No kidding. I'm hoping the docs will have something
> > useful, and I'm
> > >about to pull out the bus analyizer.
> > >
> > >
> > >Matt
> > >
> > >
> > >______________________________________________________
> > >Linux MTD discussion mailing list
> > >http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-12 20:42 ` Edward A. Hildum
@ 2003-05-13 1:42 ` Matthew Dharm
2003-05-13 7:40 ` David Woodhouse
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Matthew Dharm @ 2003-05-13 1:42 UTC (permalink / raw)
To: Edward A. Hildum; +Cc: linux-mtd
Well, I found at least one part of the problem.
The Linux driver doc2001.c assumes that addresses (in DoC_Address) are
23 bits max. On some parts, the max is 31, so an extra write of the
address component is needed.
Given that modification (and changing calls to DoC_Address to use 4
bytes instead of 3 -- one of the parameters is how many to use), I now
have data coming from nanddump. I'm sending that to David only for
now -- it's 800K compressed.
What's interesting here is that there is definately data there. I can
even see readable text strings, and the filename of the VxWorks image
that was loaded onto this particular unit. But, the string "ANAND" is
somewhat rare -- the string "BNAND" is significantly more common.
I'm starting to wonder if M-Systems has changed their on-chip data
format from NFTL to something else....
Edward, have you ever tried the nanddump utility?
Unfortunately for me, the proprietary driver is x86-only, and I'm on a
PPC platform.
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: Edward A. Hildum [mailto:ehildum@mail.arc.nasa.gov]
> Sent: Monday, May 12, 2003 1:43 PM
> To: Matthew Dharm
> Cc: linux-mtd@lists.infradead.org
> Subject: RE: DiskOnChip 2000 128Mb problem
>
>
> They didn't, but I didn't try the Millenium-only driver.
> After fooling
> around with GRUB, trying to get it working with the DOC, I
> punted and went
> with the M-Systems proprietary driver. This solves my problem for
> now. Maybe I'll try again later when I've got some
> progress on other
> fronts to show.
>
> Ted
>
> At 01:29 PM 5/9/2003 -0700, you wrote:
> >Did the Linux drivers work for you?
> >
> >Matt
> >
> >--
> >Matthew D. Dharm Senior
> Software Designer
> >Momentum Computer Inc. 1815 Aston
> Ave. Suite 107
> >(760) 431-8663 X-115 Carlsbad, CA 92008-7310
> >Momentum Works For You www.momenco.com
> >
> > > -----Original Message-----
> > > From: Edward A. Hildum [mailto:ehildum@mail.arc.nasa.gov]
> > > Sent: Friday, May 09, 2003 1:24 PM
> > > To: Matthew Dharm
> > > Cc: linux-mtd@lists.infradead.org
> > > Subject: RE: DiskOnChip 2000 128Mb problem
> > >
> > >
> > > I had a similar experience using a DOC 2000 TSOP 256M part.
> > > Its chip ID is
> > > 0x30, which is right for a Millenium part, even though it
> > > has a DOC 2000
> > > part number. The part also has an IPL which can be updated
> > > like Millenium
> > > parts.
> > >
> > > Ted Hildum
> > >
> > > At 09:58 AM 5/9/2003 -0700, you wrote:
> > > > > -----Original Message-----
> > > > > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > > > > Sent: Friday, May 09, 2003 9:48 AM
> > > > > To: Matthew Dharm
> > > > > Cc: linux-mtd@lists.infradead.org
> > > > > Subject: RE: DiskOnChip 2000 128Mb problem
> > > > >
> > > > >
> > > > > On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> > > > > > Is it normal for a DoC 2000 to be detected as a Millenium?
> > > > >
> > > > > No, but it's not normal for its contents to be read back as
> > > > > 0x01 0x02
> > > > > 0x03 etc. either: )
> > > >
> > > >Okay, so we're all on the same page.
> > > >
> > > > > > I've already checked the bus width and timing.
> > > > >
> > > > > And it's definitely not set to 16-bit? -ECONFUSED.
> > > >
> > > >No kidding. I'm hoping the docs will have something
> > > useful, and I'm
> > > >about to pull out the bus analyizer.
> > > >
> > > >
> > > >Matt
> > > >
> > > >
> > > >______________________________________________________
> > > >Linux MTD discussion mailing list
> > > >http://lists.infradead.org/mailman/listinfo/linux-mtd/
> > >
>
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: DiskOnChip 2000 128Mb problem
2003-05-13 1:42 ` Matthew Dharm
@ 2003-05-13 7:40 ` David Woodhouse
2003-05-13 8:03 ` Daniel Toussaint
2003-05-13 18:34 ` Matthew Dharm
2003-05-13 8:22 ` David Woodhouse
2003-05-13 17:09 ` Edward A. Hildum
2 siblings, 2 replies; 20+ messages in thread
From: David Woodhouse @ 2003-05-13 7:40 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
On Tue, 2003-05-13 at 02:42, Matthew Dharm wrote:
> Well, I found at least one part of the problem.
>
> The Linux driver doc2001.c assumes that addresses (in DoC_Address) are
> 23 bits max. On some parts, the max is 31, so an extra write of the
> address component is needed.
Interesting. If we make this change, does it still work with the older
units?
> ... the string "ANAND" is
> somewhat rare -- the string "BNAND" is significantly more common.
>
> I'm starting to wonder if M-Systems has changed their on-chip data
> format from NFTL to something else....
Definitely looks that way. Some reverse-engineering (or hopefully
perhaps assistance from M-Systems) is required. A lot of the format
looks the same as 'normal' NFTL; it may just be the MediaHeader block
which has changed.
Alternatively, given that it's just a bunch of NAND flash chips, we
could fix up the incompatibility between the DiskOnChip driver and the
normal NAND drivers, then you could use JFFS2 or YAFFS on it. Real file
systems directly on the flash make a whole lot more sense than this
pretending-to-be-a-block-device nonsense anyway.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DiskOnChip 2000 128Mb problem
2003-05-13 7:40 ` David Woodhouse
@ 2003-05-13 8:03 ` Daniel Toussaint
2003-05-13 16:22 ` David Woodhouse
2003-05-13 18:34 ` Matthew Dharm
1 sibling, 1 reply; 20+ messages in thread
From: Daniel Toussaint @ 2003-05-13 8:03 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
David Woodhouse wrote:
>On Tue, 2003-05-13 at 02:42, Matthew Dharm wrote:
>
>
>>Well, I found at least one part of the problem.
>>
>>The Linux driver doc2001.c assumes that addresses (in DoC_Address) are
>>23 bits max. On some parts, the max is 31, so an extra write of the
>>address component is needed.
>>
>>
>
>Interesting. If we make this change, does it still work with the older
>units?
>
>
>
>> ... the string "ANAND" is
>>somewhat rare -- the string "BNAND" is significantly more common.
>>
>>I'm starting to wonder if M-Systems has changed their on-chip data
>>format from NFTL to something else....
>>
>>
>
>Definitely looks that way. Some reverse-engineering (or hopefully
>perhaps assistance from M-Systems) is required. A lot of the format
>looks the same as 'normal' NFTL; it may just be the MediaHeader block
>which has changed.
>
>Alternatively, given that it's just a bunch of NAND flash chips, we
>could fix up the incompatibility between the DiskOnChip driver and the
>normal NAND drivers, then you could use JFFS2 or YAFFS on it. Real file
>systems directly on the flash make a whole lot more sense than this
>pretending-to-be-a-block-device nonsense anyway
>
>
David, other MTD guru's ,
Interesting. My company wants to deploy the DiskOnChip millenium PLUS as
a new standard for our x86 embedded pc product line. (so far we were
using DIP sockets with a doc2000/mil as an option) . Our other option is
to just use raw memory chips of some kind -but then we leave the wince
and other embedded os users with more difficulties.
We had the local m-systems representatives over , and I can tell you
that their attitude towards the Linux open source (mtd) drivers for
their products was close to hostile. Also, they don't even want to
comment on some issue's (for example jffs2 on DiskOnChip).
I work in support, and whenever a customer has problems with M-systems
binary drivers/ lilo install / license questions - I teach them how to
use the linux mtd utilities(+grub) and this always solves all problems.
For the millenium plus however the only way to go is to use the
m-systems binary driver. A while back I saw that www.snapgear.com
announced they had spend several months in developing open source (mtd
based drivers & the new INFTL layer) for the millenium plus - but
nothing has been released yet I - probably licensing/nda issue's.
To get back to the point: Being able to use the raw nand chips in Doc
devices and put jffs2/yaffs on it would be the greatest thing ever.
My question is , following guidelines in the nand documentation on how
to write a "mapping driver for your board" is it theoretically possible
to get it to work? I am not an mtd guru - but given enough time , and
studying the current Doc code ,myself, or someone else might get it to
work some day?
Or is there just no way to make it work due to lack of
information/licensing issue's ?? Also, of course the company I work for
can sign an nda with m-systems - but this is no use to since we also
just want to provide open source code to our customers to develop with -
we don't make end user products.
(Sorry for the long story , ...)
Greetings,
Daniel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DiskOnChip 2000 128Mb problem
2003-05-13 8:03 ` Daniel Toussaint
@ 2003-05-13 16:22 ` David Woodhouse
0 siblings, 0 replies; 20+ messages in thread
From: David Woodhouse @ 2003-05-13 16:22 UTC (permalink / raw)
To: Daniel Toussaint; +Cc: linux-mtd
On Tue, 2003-05-13 at 09:03, Daniel Toussaint wrote:
> Interesting. My company wants to deploy the DiskOnChip millenium PLUS as
> a new standard for our x86 embedded pc product line. (so far we were
> using DIP sockets with a doc2000/mil as an option) . Our other option is
> to just use raw memory chips of some kind -but then we leave the wince
> and other embedded os users with more difficulties.
YAFFS already runs on WinCE. JFFS2 already runs on eCos. Both are easily
portable.
> Also, they don't even want to comment on some issue's (for example
> jffs2 on DiskOnChip).
Put yourself in their shoes -- they're selling you hardware at premium
prices because you get it with their 'translation layer' software to
make it pretend to be a block device, on which you use a 'traditional'
journalling file system.
Now ask them about using a file system designed specifically to be used
directly on flash chips, and what do you _think_ they're going to say?
:)
> I work in support, and whenever a customer has problems with M-systems
> binary drivers/ lilo install / license questions - I teach them how to
> use the linux mtd utilities(+grub) and this always solves all problems.
:)
> For the millenium plus however the only way to go is to use the
> m-systems binary driver. A while back I saw that www.snapgear.com
> announced they had spend several months in developing open source (mtd
> based drivers & the new INFTL layer) for the millenium plus - but
> nothing has been released yet I - probably licensing/nda issue's.
Until such time as that code is released, the advice remains: avoid this
hardware like the plague. Do not design it into new boards, do not
purchase it to plug into older socketed designs. Use real flash instead.
> To get back to the point: Being able to use the raw nand chips in Doc
> devices and put jffs2/yaffs on it would be the greatest thing ever.
> My question is , following guidelines in the nand documentation on how
> to write a "mapping driver for your board" is it theoretically possible
> to get it to work? I am not an mtd guru - but given enough time , and
> studying the current Doc code ,myself, or someone else might get it to
> work some day?
> Or is there just no way to make it work due to lack of
> information/licensing issue's ??
It can work. The only reason the DiskOnChip drivers don't use the
generic NAND code is because they predate it by about three years. It
shouldn't be hard to convert them -- and in fact you may not even need
to convert them to use the generic NAND code, but just make them agree
about the ECC API.
It's probably a few weeks' work, and if you don't want to, or can't do
it yourself, then there are probably quite a few people out there who'd
be willing to quote you for it.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-13 7:40 ` David Woodhouse
2003-05-13 8:03 ` Daniel Toussaint
@ 2003-05-13 18:34 ` Matthew Dharm
1 sibling, 0 replies; 20+ messages in thread
From: Matthew Dharm @ 2003-05-13 18:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Tuesday, May 13, 2003 12:40 AM
> To: Matthew Dharm
> Cc: Edward A. Hildum; linux-mtd@lists.infradead.org
> Subject: RE: DiskOnChip 2000 128Mb problem
>
>
> On Tue, 2003-05-13 at 02:42, Matthew Dharm wrote:
> > Well, I found at least one part of the problem.
> >
> > The Linux driver doc2001.c assumes that addresses (in
> DoC_Address) are
> > 23 bits max. On some parts, the max is 31, so an extra
> write of the
> > address component is needed.
>
> Interesting. If we make this change, does it still work
> with the older
> units?
Doubtful. The doc2000 'integrated' code actually has a system for
marking certain parts as needed 3 or 4 bytes of address, depending on
the part ID. I can't use that code, since it can't ID my parts (and I
haven't figured out why).
Matt
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-13 1:42 ` Matthew Dharm
2003-05-13 7:40 ` David Woodhouse
@ 2003-05-13 8:22 ` David Woodhouse
2003-05-13 17:09 ` Edward A. Hildum
2 siblings, 0 replies; 20+ messages in thread
From: David Woodhouse @ 2003-05-13 8:22 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
On Tue, 2003-05-13 at 02:42, Matthew Dharm wrote:
> I'm starting to wonder if M-Systems has changed their on-chip data
> format from NFTL to something else....
You could also try just running nftl_format on it and reverting to the
old NFTL format, given that you don't seem to have any bad blocks
marked.
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-13 1:42 ` Matthew Dharm
2003-05-13 7:40 ` David Woodhouse
2003-05-13 8:22 ` David Woodhouse
@ 2003-05-13 17:09 ` Edward A. Hildum
2 siblings, 0 replies; 20+ messages in thread
From: Edward A. Hildum @ 2003-05-13 17:09 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
Haven't tried nanddump.
Ted
At 06:42 PM 5/12/2003 -0700, you wrote:
>Well, I found at least one part of the problem.
>
>The Linux driver doc2001.c assumes that addresses (in DoC_Address) are
>23 bits max. On some parts, the max is 31, so an extra write of the
>address component is needed.
>
>Given that modification (and changing calls to DoC_Address to use 4
>bytes instead of 3 -- one of the parameters is how many to use), I now
>have data coming from nanddump. I'm sending that to David only for
>now -- it's 800K compressed.
>
>What's interesting here is that there is definately data there. I can
>even see readable text strings, and the filename of the VxWorks image
>that was loaded onto this particular unit. But, the string "ANAND" is
>somewhat rare -- the string "BNAND" is significantly more common.
>
>I'm starting to wonder if M-Systems has changed their on-chip data
>format from NFTL to something else....
>
>Edward, have you ever tried the nanddump utility?
>
>Unfortunately for me, the proprietary driver is x86-only, and I'm on a
>PPC platform.
>
>Matt
>
>--
>Matthew D. Dharm Senior Software Designer
>Momentum Computer Inc. 1815 Aston Ave. Suite 107
>(760) 431-8663 X-115 Carlsbad, CA 92008-7310
>Momentum Works For You www.momenco.com
>
> > -----Original Message-----
> > From: Edward A. Hildum [mailto:ehildum@mail.arc.nasa.gov]
> > Sent: Monday, May 12, 2003 1:43 PM
> > To: Matthew Dharm
> > Cc: linux-mtd@lists.infradead.org
> > Subject: RE: DiskOnChip 2000 128Mb problem
> >
> >
> > They didn't, but I didn't try the Millenium-only driver.
> > After fooling
> > around with GRUB, trying to get it working with the DOC, I
> > punted and went
> > with the M-Systems proprietary driver. This solves my problem for
> > now. Maybe I'll try again later when I've got some
> > progress on other
> > fronts to show.
> >
> > Ted
> >
> > At 01:29 PM 5/9/2003 -0700, you wrote:
> > >Did the Linux drivers work for you?
> > >
> > >Matt
> > >
> > >--
> > >Matthew D. Dharm Senior
> > Software Designer
> > >Momentum Computer Inc. 1815 Aston
> > Ave. Suite 107
> > >(760) 431-8663 X-115 Carlsbad, CA 92008-7310
> > >Momentum Works For You www.momenco.com
> > >
> > > > -----Original Message-----
> > > > From: Edward A. Hildum [mailto:ehildum@mail.arc.nasa.gov]
> > > > Sent: Friday, May 09, 2003 1:24 PM
> > > > To: Matthew Dharm
> > > > Cc: linux-mtd@lists.infradead.org
> > > > Subject: RE: DiskOnChip 2000 128Mb problem
> > > >
> > > >
> > > > I had a similar experience using a DOC 2000 TSOP 256M part.
> > > > Its chip ID is
> > > > 0x30, which is right for a Millenium part, even though it
> > > > has a DOC 2000
> > > > part number. The part also has an IPL which can be updated
> > > > like Millenium
> > > > parts.
> > > >
> > > > Ted Hildum
> > > >
> > > > At 09:58 AM 5/9/2003 -0700, you wrote:
> > > > > > -----Original Message-----
> > > > > > From: David Woodhouse [mailto:dwmw2@infradead.org]
> > > > > > Sent: Friday, May 09, 2003 9:48 AM
> > > > > > To: Matthew Dharm
> > > > > > Cc: linux-mtd@lists.infradead.org
> > > > > > Subject: RE: DiskOnChip 2000 128Mb problem
> > > > > >
> > > > > >
> > > > > > On Fri, 2003-05-09 at 17:40, Matthew Dharm wrote:
> > > > > > > Is it normal for a DoC 2000 to be detected as a Millenium?
> > > > > >
> > > > > > No, but it's not normal for its contents to be read back as
> > > > > > 0x01 0x02
> > > > > > 0x03 etc. either: )
> > > > >
> > > > >Okay, so we're all on the same page.
> > > > >
> > > > > > > I've already checked the bus width and timing.
> > > > > >
> > > > > > And it's definitely not set to 16-bit? -ECONFUSED.
> > > > >
> > > > >No kidding. I'm hoping the docs will have something
> > > > useful, and I'm
> > > > >about to pull out the bus analyizer.
> > > > >
> > > > >
> > > > >Matt
> > > > >
> > > > >
> > > > >______________________________________________________
> > > > >Linux MTD discussion mailing list
> > > > >http://lists.infradead.org/mailman/listinfo/linux-mtd/
> > > >
> >
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-09 14:35 ` David Woodhouse
2003-05-09 16:40 ` Matthew Dharm
@ 2003-05-31 13:08 ` David Woodhouse
2003-05-31 13:19 ` David Woodhouse
1 sibling, 1 reply; 20+ messages in thread
From: David Woodhouse @ 2003-05-31 13:08 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mtd
Normally I just bounce broken mail to the list but I'll make an
exception and forward this one...
--
dwmw2
-----Forwarded Message-----
From: Zachi Friedman <zachi.friedman@m-sys.com>
To: linux-mtd@lists.infradead.org
Subject: RE: DiskOnChip 2000 128Mb problem
Date: Fri, 30 May 2003 10:53:06 -0700
Here is the deal:
Newer (and higher capacity) DiskOnChip 2000 devices have a new ASIC
controller. This ASIC controller has the chip ID of 0x30 (instead of 0x20).
I guess that is the reason the MTD driver identifies the 128MB as a
Millennium...
Also, to solve the confusion here once and for all: Millennium comes _ONLY_
8MB. There never was, and never will be a Millennium is different capacity!
There is the Millennium Plus (comes in 16MB, 32MB and 64MB), but its chip
IDs are 0x40 and 0x41.
So, once you have chip ID of 0x30, how can you tell whether it's a
Millennium or the newer DiskOnChip 2000? You have to read chip ID 4 times.
If the 4th read is NOT 0x30 - it's a new DiskOnChip 2000 !
Also, these new DiskOnChip 2000 SHOULD be used with INFTL. The reason being
these newer devices use newer NAND flash that have a lower PPP (of 3). NFTL
needs PPP=5 (at least the original M-systems' implementation does). If MTD
group's implementation of NFTL needs PPP>3 or if low-level format
compatibility with M-Systems is important enough, then INFTL is the way to
go with those devices!
Regarding the INFTL - since SnapGear has released the 1st implementation a
week ago, I guess it can be used as the basis for the supporting these
devices as well :)
Good luck,
Zachi.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DiskOnChip 2000 128Mb problem
2003-05-31 13:08 ` David Woodhouse
@ 2003-05-31 13:19 ` David Woodhouse
0 siblings, 0 replies; 20+ messages in thread
From: David Woodhouse @ 2003-05-31 13:19 UTC (permalink / raw)
To: Zachi Friedman; +Cc: linux-mtd
Zachi Friedman <zachi.friedman@m-sys.com> writes:
> So, once you have chip ID of 0x30, how can you tell whether it's a
> Millennium or the newer DiskOnChip 2000? You have to read chip ID 4
> times. If the 4th read is NOT 0x30 - it's a new DiskOnChip 2000 !
Thanks for the information. You say it has a new ASIC -- other than the
ChipID, in what other ways does it behave like a Millennium rather than
a DiskOnChip 2000?
It looks like it was passing the Millennium version of the 'toggle'
test, where we read the ECCConf register, rather than the DiskOnChip
2000 version where we read the 2k_ECCStatus register.
What are the contents of the fourth read supposed to be? 0x20 as we'd
expect from a DiskOnChip 2000? Should we just read the ChipID four times
and discard the first three, or do something like...
--- docprobe.c 23 May 2003 11:29:34 -0000 1.36
+++ docprobe.c 31 May 2003 13:18:37 -0000
@@ -137,19 +137,31 @@ static inline int __init doccheck(unsign
ChipID = ReadDOC(window, ChipID);
switch (ChipID) {
case DOC_ChipID_Doc2k:
+ really2k:
/* Check the TOGGLE bit in the ECC register */
tmp = ReadDOC(window, 2k_ECCStatus) & DOC_TOGGLE_BIT;
tmpb = ReadDOC(window, 2k_ECCStatus) & DOC_TOGGLE_BIT;
tmpc = ReadDOC(window, 2k_ECCStatus) & DOC_TOGGLE_BIT;
if (tmp != tmpb && tmp == tmpc)
return ChipID;
break;
case DOC_ChipID_DocMil:
+ /* If we read the ID four times and it changes, then
+ it wasn't really a Millennium; it was a newer
+ DiskOnChip 2000. Pass me the baseball bat. */
+ ChipID = ReadDOC(window, ChipID);
+ ChipID = ReadDOC(window, ChipID);
+ ChipID = ReadDOC(window, ChipID);
+ if (ChipID != DOC_ChipID_DocMil) {
+ printk(KERN_DEBUG "New DiskOnChip 2000 with bizarre ChipID detected. %02x on fourth read.\n", ChipID);
+ goto really2k;
+ }
+
/* Check the TOGGLE bit in the ECC register */
tmp = ReadDOC(window, ECCConf) & DOC_TOGGLE_BIT;
tmpb = ReadDOC(window, ECCConf) & DOC_TOGGLE_BIT;
tmpc = ReadDOC(window, ECCConf) & DOC_TOGGLE_BIT;
if (tmp != tmpb && tmp == tmpc)
--
dwmw2
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-05-31 13:18 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-07 20:37 DiskOnChip 2000 128Mb problem Matthew Dharm
2003-05-08 6:17 ` David Woodhouse
2003-05-08 18:04 ` Matthew Dharm
2003-05-09 14:25 ` David Woodhouse
2003-05-09 14:35 ` David Woodhouse
2003-05-09 16:40 ` Matthew Dharm
2003-05-09 16:48 ` David Woodhouse
2003-05-09 16:58 ` Matthew Dharm
2003-05-09 20:23 ` Edward A. Hildum
2003-05-09 20:29 ` Matthew Dharm
2003-05-12 20:42 ` Edward A. Hildum
2003-05-13 1:42 ` Matthew Dharm
2003-05-13 7:40 ` David Woodhouse
2003-05-13 8:03 ` Daniel Toussaint
2003-05-13 16:22 ` David Woodhouse
2003-05-13 18:34 ` Matthew Dharm
2003-05-13 8:22 ` David Woodhouse
2003-05-13 17:09 ` Edward A. Hildum
2003-05-31 13:08 ` David Woodhouse
2003-05-31 13:19 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox