Bad blocks

Bad blocks

[Kalev Lember]

Hi,

I am going to use DOC Millennium Plus and I do not want to use M-Systems 
propietary kernel modules.
Having read the mailing list archives I have some questions.  Does current 
INFTL code support bad block handling? Without that I would say it is 
virtually useless. Am I correct?

-- 
Best regards,
Kalev Lember

Re: Bad blocks

[David Woodhouse]

On Thu, 2004-04-01 at 17:06 +0300, Kalev Lember wrote:
> Hi,
> 
> I am going to use DOC Millennium Plus and I do not want to use M-Systems 
> propietary kernel modules.
> Having read the mailing list archives I have some questions.  Does current 
> INFTL code support bad block handling? Without that I would say it is 
> virtually useless. Am I correct?

It doesn't, and you're probably correct, yes.

This is fairly high up on my TODO list but keeps getting preempted by
RealWork(tm). Are you volunteering? It shouldn't be too hard.

-- 
dwmw2

patch for AMD am29dl800b

[David Updegraff]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hi.

I have a gadget with this amd chip on it.  Whose id and layout dfn. is 
not in the jedec_probe tables.  Unfortuanately, they have _SIX_ (6) 
erase regions.  Anyone know of a reason expanding the regions[] array to 
6 is a bad idea?  Or why dealing with this chip in general is a bad idea?

-dbu.

[-- Attachment #2: am29dl800b.patch --]
[-- Type: text/x-patch, Size: 1651 bytes --]

--- drivers/mtd/chips/jedec_probe.c.orig	2004-04-01 17:27:18.267578712 -0600
+++ drivers/mtd/chips/jedec_probe.c	2004-04-01 17:59:06.562473792 -0600
@@ -38,6 +38,9 @@
 
 
 /* AMD */
+#define AM29DL800BB	0x22C8
+#define AM29DL800BT	0x224A
+
 #define AM29F800BB	0x2258
 #define AM29F800BT	0x22D6
 #define AM29LV400BB	0x22BA
@@ -222,7 +225,7 @@
 	const int NumEraseRegions;
 	const int CmdSet;
 	const __u8 uaddr[4];		/* unlock addrs for 8, 16, 32, 64 */
-	const ulong regions[4];
+	const ulong regions[6];
 };
 
 #define ERASEINFO(size,blocks) (size<<8)|(blocks-1)
@@ -342,6 +345,45 @@
 			ERASEINFO(0x10000,15),
 		}
 	}, {
+/* add DL */
+		.mfr_id		= MANUFACTURER_AMD,
+		.dev_id		= AM29DL800BB,
+		.name		= "AMD AM29DL800BB",
+		.uaddr		= {
+			[0] = MTD_UADDR_0x0AAA_0x0555,  /* x8 */
+			[1] = MTD_UADDR_0x0555_0x02AA,  /* x16 */
+		},
+		.DevSize	= SIZE_1MiB,
+		.CmdSet		= P_ID_AMD_STD,
+		.NumEraseRegions= 6,
+		.regions	= {
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x02000,4),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x10000,14)
+		}
+	}, {
+		.mfr_id		= MANUFACTURER_AMD,
+		.dev_id		= AM29DL800BT,
+		.name		= "AMD AM29DL800BT",
+		.uaddr		= {
+			[0] = MTD_UADDR_0x0AAA_0x0555,  /* x8 */
+			[1] = MTD_UADDR_0x0555_0x02AA,  /* x16 */
+		},
+		.DevSize	= SIZE_1MiB,
+		.CmdSet		= P_ID_AMD_STD,
+		.NumEraseRegions= 6,
+		.regions	= {
+			ERASEINFO(0x10000,14),
+			ERASEINFO(0x04000,1),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x02000,4),
+			ERASEINFO(0x08000,1),
+			ERASEINFO(0x04000,1)
+		}
+	}, {
 		.mfr_id		= MANUFACTURER_AMD,
 		.dev_id		= AM29F800BB,
 		.name		= "AMD AM29F800BB",

Re: patch for AMD am29dl800b

[David Woodhouse]

Please don't reply to unrelated threads. This isn't about bad blocks and
doesn't live with the message to which you replied.

On Thu, 2004-04-01 at 18:01 -0600, David Updegraff wrote:
> Hi.
> 
> I have a gadget with this amd chip on it.  Whose id and layout dfn. is 
> not in the jedec_probe tables.  Unfortuanately, they have _SIX_ (6) 
> erase regions.  Anyone know of a reason expanding the regions[] array to 
> 6 is a bad idea?  Or why dealing with this chip in general is a bad idea?

Hmmm. And this chip really doesn't do CFI?

I wonder how much space we take up with this table, and if we should put
the regions outside the table rather than inline ("ulong *regions").
> 
> ______________________________________________________________________
-- 
dwmw2

Re: patch for AMD am29dl800b

[David Updegraff]

> Please don't reply to unrelated threads. This isn't about bad blocks and
> doesn't live with the message to which you replied.

Whoops.. me aculpa.

> 
> On Thu, 2004-04-01 at 18:01 -0600, David Updegraff wrote:
> 
>>Hi.
>>
>>I have a gadget with this amd chip on it.  Whose id and layout dfn. is 
>>not in the jedec_probe tables.  Unfortuanately, they have _SIX_ (6) 
>>erase regions.  Anyone know of a reason expanding the regions[] array to 
>>6 is a bad idea?  Or why dealing with this chip in general is a bad idea?
> 
> 
> Hmmm. And this chip really doesn't do CFI?

My attempts at that failed; and their PDF only says 'JEDEC compatible'.

> I wonder how much space we take up with this table, and if we should put
> the regions outside the table rather than inline ("ulong *regions").

.. or invent a command-line syntax; since in embedded situations one 
usually knows what one is looking for.. or has that alredy been 
discussed and discarded?

-dbu.

Re: patch for AMD am29dl800b

[David Woodhouse]

On Fri, 2004-04-02 at 07:30 -0600, David Updegraff wrote:
> > Hmmm. And this chip really doesn't do CFI?
> 
> My attempts at that failed; and their PDF only says 'JEDEC compatible'.

OK.

> > I wonder how much space we take up with this table, and if we should put
> > the regions outside the table rather than inline ("ulong *regions").
> 
> .. or invent a command-line syntax; since in embedded situations one 
> usually knows what one is looking for.. or has that alredy been 
> discussed and discarded?

You assume far too much competence on the part of the people who would
be expected to provide such arguments. You _can_ write a map driver
which bypasses the probe and set up the appropriate command set
directly, I think. There's not really much need to -- if you're _that_
concerned about bloat you won't be using Linux in the first place.

I've committed your patch; thanks.

-- 
dwmw2

Re: Bad blocks

[Greg Ungerer]

David Woodhouse wrote:
> On Thu, 2004-04-01 at 17:06 +0300, Kalev Lember wrote:
>>I am going to use DOC Millennium Plus and I do not want to use M-Systems 
>>propietary kernel modules.
>>Having read the mailing list archives I have some questions.  Does current 
>>INFTL code support bad block handling? Without that I would say it is 
>>virtually useless. Am I correct?
> 
> 
> It doesn't, and you're probably correct, yes.
> 
> This is fairly high up on my TODO list but keeps getting preempted by
> RealWork(tm). Are you volunteering? It shouldn't be too hard.

Yeah, high on my todo list as well. But I am not going to
get to it any time soon. It should be quite simple to do.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: Bad blocks

[Kalev Lember]

On Thu, 1 Apr 2004, David Woodhouse wrote:
> On Thu, 2004-04-01 at 17:06 +0300, Kalev Lember wrote:
> > INFTL code support bad block handling? Without that I would say it is 
> 
> This is fairly high up on my TODO list but keeps getting preempted by
> RealWork(tm). Are you volunteering? It shouldn't be too hard.

No, I could not do it because I do not have a developing platform, I have 
only access to some devices that have DoC soldered on their mainboards. 
They can boot only from DoC, currently using M-Systems driver and linux. 
If I were to make one unbootable the would have to reflash it in the 
manufacturers plant. Sorry.

-- 
Kalev Lember