CFI with 4 x8/x16 devices on a 32-bit bus

CFI with 4 x8/x16 devices on a 32-bit bus

[Brett Carswell]

Hi All,

I'm having problems getting MTD working on a RPXLite board. I'm not having
endian problems as have been discussed recently - that part seems OK. The
board has four AMD 29LV160 chips which are in x8 mode. These chips can also
be in x16 mode but aren't in this case. 

My first question is am I correct in expecting that I should see these chips
detected as 4 x8 Devices in 32-bit mode? I can get them working in this mode
only by shifting all the offset addresses in my mapping functions right by
one. However when I do this and write to the flash every second word is
skipped (not surprisingly).

It's as though I need to shift the addresses for the CFI commands only. I
looked in the archives from a couple of months ago an it seemed as though
the problem was fixed. Perhaps I'm missing a point somewhere.

Thanks in advance,
Brett Carswell

Nu-Lec Industries  (ACN 085 972 425)
35-37 South Street, Lytton, Brisbane, Qld, 4178, Australia
PO Box 761, Wynnum, Qld, 4178, Australia
Direct Dial Phone No:	+61 7 3249 5498
Switchboard Phone No:	+61 7 3249 5444
Facsimile No:		+61 7 3249 5888
Email Address:		BrettC@nulec.com.au
World Wide Web Site:	http://www.nulec.com.au




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

BrettC@nulec.com.au said:
>  The board has four AMD 29LV160 chips which are in x8 mode. These
> chips can also be in x16 mode but aren't in this case. 

> My first question is am I correct in expecting that I should see these
> chips detected as 4 x8 Devices in 32-bit mode? I can get them working
> in this mode only by shifting all the offset addresses in my mapping
> functions right by one.

Shouldn't that be 4 x16 devices in 8-bit mode? 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Brett Carswell]

> BrettC@nulec.com.au said:
> >  The board has four AMD 29LV160 chips which are in x8 mode. These
> > chips can also be in x16 mode but aren't in this case. 
> 
> > My first question is am I correct in expecting that I 
> should see these
> > chips detected as 4 x8 Devices in 32-bit mode? I can get 
> them working
> > in this mode only by shifting all the offset addresses in my mapping
> > functions right by one.
> 
> Shouldn't that be 4 x16 devices in 8-bit mode? 
> 

I think I wasn't clear enough or my understanding of MTD is totally broken
(which is possible). I'm referring to the output of the line:

	printk(KERN_INFO "%s: Found %d x%d devices at 0x%x in %d-bit
mode\n", map->name, 
	       cfi->interleave, cfi->device_type*8, base, map->buswidth*8);

I have four flash chips in parallel on a 32 bit bus so my impression is that
I have an interleave of 4, a device type of 1 (8 bits) and a buswidth of 4
(32bits). However, the CFI probe is detecting the flash chips as device type
2 (16bit). This is fine except when the second address for the write command
is generated as 0x1550  (0x2AA << 8) instead of 0x1554 (0x555 << 4). I'm
trying to work out whether the detection or the program address generation
is wrong or whether by interpretation of buswidth, interleave etc is wrong.

Brett


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

BrettC@nulec.com.au said:
> I have four flash chips in parallel on a 32 bit bus so my impression
> is that I have an interleave of 4, a device type of 1 (8 bits) and a
> buswidth of 4 (32bits). 

I believe that for 29LV160 chips, the device type should be X16, as that
determines the addresses to which the CFI commands must be sent, rather than
X8, which is merely the mode in which the chip happens to be configured at
the moment.

> However, the CFI probe is detecting the flash chips as device type 2
> (16bit). 

That's what I'd expect. They _are_ 16-bit devices, even though you're using 
them in 8-bit mode.

> This is fine except when the second address for the write
> command is generated as 0x1550  (0x2AA << 8) instead of 0x1554 (0x555
> << 4).

This stuff makes my head hurt :)

Thinks... Numbering CPU address lines by _byte_ addresses, A0 and A1 don't
exist. A2 is driving the 'A-1' line (aka D15 in word mode) of the flash
chip, presumably. A3 is driving the A0 line, etc. Right? Remembering that 
the flash chip address lines are numbered by word (16-bit) addresses.

So to put 0x555 on the real address lines of the chip, we need to put 
(0x555 << 3) == 0x2AA8 onto the CPU's address bus. And to put 0x2AA on the 
real address lines of the chip, we put (0x2AA << 3) == 0x1550 onto the 
CPU's address bus.

Ignoring the fact that you wrote '<<' when you meant '*', why do you think 
we should be using the address 0x1554 (== 0x555 << 3)? What am I missing 
this time? :)

0x1554 would be asserting the 'A-1' line of the flash chips. Why would you 
want to do that?

> I'm trying to work out whether the detection or the program
> address generation is wrong or whether by interpretation of buswidth,
> interleave etc is wrong.

The address generation seems right. What exactly is going wrong, and where?

To confirm:
 buswidth: obvious. (4 bytes)
 interleave: Number of devices accessible through a single bus-width access (4)
 device type: _Device_ type (2). You ignore the 'A-1' line because the magic
	addresses still need to be on the 'A0' line and above, so you still 
	have to do the multiplication by this number.

At one time, I was under the mistaken impression that 
buswidth == interleave * devtype. That's not necessarily true.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

dwmw2@infradead.org said:
>  Ignoring the fact that you wrote '<<' when you meant '*', why do you
> think  we should be using the address 0x1554 (== 0x555 << 3)? What am
> I missing  this time? :) 

er... 0x1554 == 0x555 << 2. But don't let details like that bother you :)

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Joakim Tjernlund]

Hi all

I have RPX CLLF (very similar to RPX Lite) with similar Flash setup as
below.
I have modified rpxlite.c so it will set up 5 partitions on that flash
and it appears to work, but when I do a cat /dev/mtd0 or cat /dev/mtdblock0
which is an erased partition I get the following pattern:
81ff81ff81ff81ff .....
for the whole partition instead of fffffffffffff ...

Any ideas?

 Jocke

-----Original Message-----
From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
Of David Woodhouse
Sent: Friday, April 06, 2001 15:46
To: Brett Carswell
Cc: 'mtd@infradead.org'
Subject: Re: CFI with 4 x8/x16 devices on a 32-bit bus



BrettC@nulec.com.au said:
> I have four flash chips in parallel on a 32 bit bus so my impression
> is that I have an interleave of 4, a device type of 1 (8 bits) and a
> buswidth of 4 (32bits).

I believe that for 29LV160 chips, the device type should be X16, as that
determines the addresses to which the CFI commands must be sent, rather than
X8, which is merely the mode in which the chip happens to be configured at
the moment.

> However, the CFI probe is detecting the flash chips as device type 2
> (16bit).

That's what I'd expect. They _are_ 16-bit devices, even though you're using
them in 8-bit mode.

> This is fine except when the second address for the write
> command is generated as 0x1550  (0x2AA << 8) instead of 0x1554 (0x555
> << 4).

This stuff makes my head hurt :)

Thinks... Numbering CPU address lines by _byte_ addresses, A0 and A1 don't
exist. A2 is driving the 'A-1' line (aka D15 in word mode) of the flash
chip, presumably. A3 is driving the A0 line, etc. Right? Remembering that
the flash chip address lines are numbered by word (16-bit) addresses.

So to put 0x555 on the real address lines of the chip, we need to put
(0x555 << 3) == 0x2AA8 onto the CPU's address bus. And to put 0x2AA on the
real address lines of the chip, we put (0x2AA << 3) == 0x1550 onto the
CPU's address bus.

Ignoring the fact that you wrote '<<' when you meant '*', why do you think
we should be using the address 0x1554 (== 0x555 << 3)? What am I missing
this time? :)

0x1554 would be asserting the 'A-1' line of the flash chips. Why would you
want to do that?

> I'm trying to work out whether the detection or the program
> address generation is wrong or whether by interpretation of buswidth,
> interleave etc is wrong.

The address generation seems right. What exactly is going wrong, and where?

To confirm:
 buswidth: obvious. (4 bytes)
 interleave: Number of devices accessible through a single bus-width access
(4)
 device type: _Device_ type (2). You ignore the 'A-1' line because the magic
	addresses still need to be on the 'A0' line and above, so you still
	have to do the multiplication by this number.

At one time, I was under the mistaken impression that
buswidth == interleave * devtype. That's not necessarily true.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Brett Carswell]

> BrettC@nulec.com.au said:
> > I have four flash chips in parallel on a 32 bit bus so my impression
> > is that I have an interleave of 4, a device type of 1 (8 bits) and a
> > buswidth of 4 (32bits). 
> 
[snipped]

> This stuff makes my head hurt :)
> 
> Thinks... Numbering CPU address lines by _byte_ addresses, A0 
> and A1 don't
> exist. A2 is driving the 'A-1' line (aka D15 in word mode) of 
> the flash
> chip, presumably. A3 is driving the A0 line, etc. Right? 
> Remembering that 
> the flash chip address lines are numbered by word (16-bit) addresses.
> 
> So to put 0x555 on the real address lines of the chip, we need to put 
> (0x555 << 3) == 0x2AA8 onto the CPU's address bus. And to put 
> 0x2AA on the 
> real address lines of the chip, we put (0x2AA << 3) == 0x1550 
> onto the 
> CPU's address bus.
> 
> Ignoring the fact that you wrote '<<' when you meant '*', why 
> do you think 
> we should be using the address 0x1554 (== 0x555 << 3)? What 
> am I missing 
> this time? :)
> 
> 0x1554 would be asserting the 'A-1' line of the flash chips. 
> Why would you 
> want to do that?
> 

My take on the datasheet is that when in byte mode, A-1 becomes the LSB of
the address.
The unlock 2 address in word mode is 0x2AA (8 bits set to 1) and byte mode
is 0x555 (9 bits set to 1). So in byte mode A-1 (the LSB on the device)
needs to be set and it can't possibly be by left shifting 0x2AA (which is
what the code does). I kludged up a solution that suited my needs by
changing lines in cfi_build_cmd_addr from

{
  return (cmd_ofs * type) * interleave;
}

to

{
  __u32 addr = (cmd_ofs * type) * interleave;

  if (interleave == 1)
    return addr;
  else
    return ((addr | (addr >> (interleave >> 1))) & 0xffffffff * interleave);
}

This ugly code fragment just propagates the alternating bit pattern through
to the LSB of the device. God only knows what else this will break but it
seems to have fixed the problem I had. I'm only hoping that I've fixed it by
working out what was wrong and not just stumbling across something that
happened to make it work.

> The address generation seems right. What exactly is going 
> wrong, and where?
> 
No writes or erases were working until I changed the code above.

> To confirm:
>  buswidth: obvious. (4 bytes)
>  interleave: Number of devices accessible through a single 
> bus-width access (4)
>  device type: _Device_ type (2). You ignore the 'A-1' line 
> because the magic
> 	addresses still need to be on the 'A0' line and above, 

This last point does not seem to be the case. The datasheet says :
Addresses are A19:A0 in word mode (BYTE# = V IH ), A19:A-1 in byte mode
(BYTE# = V IL ).
Not really much to be too confident about - but setting the LSB seems to be
the only difference between a non-working and a working system.

Thanks,
Brett


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Nicolas Pitre]

On Tue, 10 Apr 2001, Brett Carswell wrote:

> > To confirm:
> >  buswidth: obvious. (4 bytes)
> >  interleave: Number of devices accessible through a single
> > bus-width access (4)
> >  device type: _Device_ type (2). You ignore the 'A-1' line
> > because the magic
> > 	addresses still need to be on the 'A0' line and above,
>
> This last point does not seem to be the case. The datasheet says :
> Addresses are A19:A0 in word mode (BYTE# = V IH ), A19:A-1 in byte mode
> (BYTE# = V IL ).

At tis point it may all depend on how your hardware folks wired the chips...

> Not really much to be too confident about - but setting the LSB seems to be
> the only difference between a non-working and a working system.

To be sure, do a coherency test on your flash i.e. if you have 16MB then
generate 16MB of random data, write it to flash through MTD, read it back,
and compare.


Nicolas



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

BrettC@nulec.com.au said:
> My take on the datasheet is that when in byte mode, A-1 becomes the
> LSB of the address.

OK,... looking at the (AM29LV320D) datasheet again, I see that. 

> The unlock 2 address in word mode is 0x2AA (8 bits set to 1) and byte mode
> is 0x555 (9 bits set to 1).

Ah, yes - I see that too. I find it very concerning that the datasheet is 
clearer to me at 2:30 in the morning than at any other time. 

OK.... how about fixing it up in the probe code to appear as an 8-bit 
device, and setting the unlock[12] addresses accordingly?

If we detect it's a 16-bit device in 8-bit mode, do...

 cfi->device_type = 1;
 cfi->addr_unlock1 = 0xaaa;
 cfi->addr_unlock2 = 0x555;

Does that work?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

nico@cam.org said:
>  At tis point it may all depend on how your hardware folks wired the
> chips... 

Heh. Don't listen to the nasty man. He's been tainted by too much exposure 
to the evil monkeys who glued together some of the sicker ARM systems. 

Run away and hope you never have to experience it yourself. Keep a baseball 
bat by your side just in case your hardware designers try to do the same to 
you.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

dwmw2@infradead.org said:
>  If we detect it's a 16-bit device in 8-bit mode, do...
>  cfi->device_type = 1;
>  cfi->addr_unlock1 = 0xaaa;
>  cfi->addr_unlock2 = 0x555; 

Actually, it's probably best not to override the device_type, but to change 
the code to always use DEVICE_TYPE_X8 instead of cfi->device_type when 
doing the unlock cycles, and set addr_unlock[12] to the pre-shifted value 
when cfi->device_type != 1.



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Brett Carswell]

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

> dwmw2@infradead.org said:
> >  If we detect it's a 16-bit device in 8-bit mode, do...
> >  cfi->device_type = 1;
> >  cfi->addr_unlock1 = 0xaaa;
> >  cfi->addr_unlock2 = 0x555; 
> 
> Actually, it's probably best not to override the device_type, 
> but to change 
> the code to always use DEVICE_TYPE_X8 instead of 
> cfi->device_type when 
> doing the unlock cycles, and set addr_unlock[12] to the 
> pre-shifted value 
> when cfi->device_type != 1.
> 

OK - this seems to work well. I have attached a patch that does what I think
you are desscibing - for those who are interested.

Brett


[-- Attachment #2: patch-unlock --]
[-- Type: application/octet-stream, Size: 5024 bytes --]

Index: cfi_cmdset_0002.c
===================================================================
RCS file: /home/cvs/mtd/kernel/cfi_cmdset_0002.c,v
retrieving revision 1.42
diff -U2 -r1.42 cfi_cmdset_0002.c
--- cfi_cmdset_0002.c	2001/03/27 06:26:10	1.42
+++ cfi_cmdset_0002.c	2001/04/10 07:07:06
@@ -332,7 +332,7 @@
 	}
 	else {
-	        cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
-	        cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, cfi->device_type, NULL);
-	        cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	        cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	        cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	        cfi_send_gen_cmd(0xA0, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
 	}
 
@@ -427,7 +427,7 @@
 	
 	/* Go into unlock bypass mode */
-	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-	cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
 
 	/* We are now aligned, write as much as possible */
@@ -474,7 +474,7 @@
 			if (cfi->fast_prog){
 				/* Go into unlock bypass mode for next set of chips */
-				cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-				cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, cfi->device_type, NULL);
-				cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, cfi->device_type, NULL);
+				cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+				cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+				cfi_send_gen_cmd(0x20, cfi->addr_unlock1, chipstart, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
 			}
 		}
@@ -547,9 +547,9 @@
 	adr += chip->start;
 	ENABLE_VPP(map);
-	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
-	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, cfi->device_type, NULL);
-	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
-	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, cfi->device_type, NULL);
-	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, cfi->device_type, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
 	cfi_write(map, CMD(0x30), adr);
 	
Index: cfi_probe.c
===================================================================
RCS file: /home/cvs/mtd/kernel/cfi_probe.c,v
retrieving revision 1.48
diff -U2 -r1.48 cfi_probe.c
--- cfi_probe.c	2001/04/09 13:26:21	1.48
+++ cfi_probe.c	2001/04/10 07:07:09
@@ -122,7 +122,7 @@
 	case 1:
 		/* Autoselect */
-		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi->interleave, cfi->device_type, NULL);
-		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi->interleave, cfi->device_type, NULL);
-		cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi->interleave, cfi->device_type, NULL);
+		cfi_send_gen_cmd(0xaa, cfi->addr_unlock1, base, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0x55, cfi->addr_unlock2, base, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
+		cfi_send_gen_cmd(0x90, cfi->addr_unlock1, base, map, cfi->interleave, CFI_DEVICETYPE_X8, NULL);
 		break;
 	}
@@ -196,5 +196,15 @@
 	int index;
 	cfi->cfi_mode=0;	/* cfi mode */
-	cfi->addr_unlock1=0x555; cfi->addr_unlock2=0x2aa; 
+	
+	if (cfi->device_type == CFI_DEVICETYPE_X8)
+	{
+	  cfi->addr_unlock1=0x555; 
+	  cfi->addr_unlock2=0x2aa; 
+	}
+	else
+	{
+	  cfi->addr_unlock1=0xaaa; 
+	  cfi->addr_unlock2=0x555; 
+	}
 	index = cfi_probe_chip_1(map,base,chips,cfi);
 	if (index>=0) return index;

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Joakim Tjernlund]

Hi again :-)

I have testing a few combinations w.r.t number of partitions
and this is what I have discoved so far:

1) No partitions, just do add_device() for the whole flash - Works OK (cat
/dev/mtd0 returns fffffffff ...)
2) 1 small(size 0x40000, offset 0) partition - Works OK (cat /dev/mtd0
returns fffffffff ...)
3) 2 partitions( tried a few different sizes) - Not OK, here I get
81ff81ff81ff ... !

I have 4 amd flash chips(label printed on them is D323BD90VI)
which I think maps to the following spec:
http://www.amd.com/products/nvd/techdocs/23480.pdf

Apparently this is chip with 2 erase sectors sizes. I suspect the different
sector sizes
is the cause to my problems, but I cant figure out where the problem is. I
have
tried with&whithout virtual regions.

Any ideas?

Boot message regarding the flash:

  RPX Lite or CLLF flash device: 1000000 at ff000000
  RPX: Found 4 x16 devices at 0x0 in 32-bit mode
  Amd/Fujitsu Extended Query Table v1.2 at 0x0040
  number of CFI chips: 1
  0: offset=0x0,size=0x8000,blocks=8
  1: offset=0x40000,size=0x40000,blocks=63
  Created 1 virtual regions for partiton 0
  mtd: Giving out device 0 to RPX App 0xff000000
  Created 1 virtual regions for partiton 1
  mtd: Giving out device 1 to RPX App 0xff040000
  Created 1 virtual regions for partiton 2
  mtd: Giving out device 2 to RPX CLLF boot firmware
  Created 1 virtual regions for partiton 3
  mtd: Giving out device 3 to RPX  App 0xfff40000
  Created 1 virtual regions for partiton 4
  mtd: Giving out device 4 to RPX  Diag & Utils


Brett, I have included your changes in rpxlite.c, did not make a difference,
but at lest I
have a better chance to write to the flash once the problem above has been
solved. Thanks a lot!

    Joakim

-----Original Message-----
From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis.se]
Sent: Monday, April 09, 2001 18:25
To: 'mtd@infradead.org'
Subject: RE: CFI with 4 x8/x16 devices on a 32-bit bus


Hi all

I have RPX CLLF (very similar to RPX Lite) with similar Flash setup as
below.
I have modified rpxlite.c so it will set up 5 partitions on that flash
and it appears to work, but when I do a cat /dev/mtd0 or cat /dev/mtdblock0
which is an erased partition I get the following pattern:
81ff81ff81ff81ff .....
for the whole partition instead of fffffffffffff ...

Any ideas?

 Jocke

-----Original Message-----
From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
Of David Woodhouse
Sent: Friday, April 06, 2001 15:46
To: Brett Carswell
Cc: 'mtd@infradead.org'
Subject: Re: CFI with 4 x8/x16 devices on a 32-bit bus



BrettC@nulec.com.au said:
> I have four flash chips in parallel on a 32 bit bus so my impression
> is that I have an interleave of 4, a device type of 1 (8 bits) and a
> buswidth of 4 (32bits).

I believe that for 29LV160 chips, the device type should be X16, as that
determines the addresses to which the CFI commands must be sent, rather than
X8, which is merely the mode in which the chip happens to be configured at
the moment.

> However, the CFI probe is detecting the flash chips as device type 2
> (16bit).

That's what I'd expect. They _are_ 16-bit devices, even though you're using
them in 8-bit mode.

> This is fine except when the second address for the write
> command is generated as 0x1550  (0x2AA << 8) instead of 0x1554 (0x555
> << 4).

This stuff makes my head hurt :)

Thinks... Numbering CPU address lines by _byte_ addresses, A0 and A1 don't
exist. A2 is driving the 'A-1' line (aka D15 in word mode) of the flash
chip, presumably. A3 is driving the A0 line, etc. Right? Remembering that
the flash chip address lines are numbered by word (16-bit) addresses.

So to put 0x555 on the real address lines of the chip, we need to put
(0x555 << 3) == 0x2AA8 onto the CPU's address bus. And to put 0x2AA on the
real address lines of the chip, we put (0x2AA << 3) == 0x1550 onto the
CPU's address bus.

Ignoring the fact that you wrote '<<' when you meant '*', why do you think
we should be using the address 0x1554 (== 0x555 << 3)? What am I missing
this time? :)

0x1554 would be asserting the 'A-1' line of the flash chips. Why would you
want to do that?

> I'm trying to work out whether the detection or the program
> address generation is wrong or whether by interpretation of buswidth,
> interleave etc is wrong.

The address generation seems right. What exactly is going wrong, and where?

To confirm:
 buswidth: obvious. (4 bytes)
 interleave: Number of devices accessible through a single bus-width access
(4)
 device type: _Device_ type (2). You ignore the 'A-1' line because the magic
	addresses still need to be on the 'A0' line and above, so you still
	have to do the multiplication by this number.

At one time, I was under the mistaken impression that
buswidth == interleave * devtype. That's not necessarily true.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Kári Davíðsson]

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis.se]
> Sent: 11. apríl 2001 15:05
> To: mtd@infradead.org
> Subject: RE: CFI with 4 x8/x16 devices on a 32-bit bus 

<snip>
 
3) 2 partitions( tried a few different sizes) - Not OK, here I get
81ff81ff81ff ... !

You get this behaviour for both partitions? Also one that has all
sectors of the same size?

<snip>

> 
> Apparently this is chip with 2 erase sectors sizes. I suspect 
> the different
> sector sizes
> is the cause to my problems, but I cant figure out where the 
> problem is. I
> have
> tried with&whithout virtual regions.

Get it to work without the viertual regions. Then add the virtual
regions if you need them. Stricly speeking you anly need them if you
have a partition that you need to manage that crosses erase region
boundary. It is hightly experimental code
that has only be tested on my single 16bit wide Intel chip so it is
bound to fail
on more complex setups.

K.D.

<snip>


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Joakim Tjernlund]

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

Hi

I been all the time wrong! I just discovered that hexl-mode i emacs is
broken!
Emacs in hexl-mode displays 81ff81ff81ff ... and od -x says fffffff ...

Sorry about that.

While I am at it perhaps someone can enlighten me somewhat ...

I am a bit confused about how add_mtd_device() and add_mtd_partitions()
work.
Looking in nora.c it looks like you can partition a flash by doing 
a few calls to add_mtd_device() with different offsets, but if you can do
that with add_mtd_device(), what's the point with add_mtd_partitions()?

I am missing something here, can someone explain when and how you are
supposed to
use these two functions?

 Jocke



-----Original Message-----
From: owner-mtd@infradead.org [mailto:owner-mtd@infradead.org]On Behalf
Of Kári Davíðsson
Sent: Thursday, April 12, 2001 14:42
To: mtd@infradead.org
Subject: RE: CFI with 4 x8/x16 devices on a 32-bit bus 




> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis.se]
> Sent: 11. apríl 2001 15:05
> To: mtd@infradead.org
> Subject: RE: CFI with 4 x8/x16 devices on a 32-bit bus 

<snip>
 
3) 2 partitions( tried a few different sizes) - Not OK, here I get
81ff81ff81ff ... !

You get this behaviour for both partitions? Also one that has all
sectors of the same size?

<snip>

> 
> Apparently this is chip with 2 erase sectors sizes. I suspect 
> the different
> sector sizes
> is the cause to my problems, but I cant figure out where the 
> problem is. I
> have
> tried with&whithout virtual regions.

Get it to work without the viertual regions. Then add the virtual
regions if you need them. Stricly speeking you anly need them if you
have a partition that you need to manage that crosses erase region
boundary. It is hightly experimental code
that has only be tested on my single 16bit wide Intel chip so it is
bound to fail
on more complex setups.

K.D.

<snip>


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2676 bytes --]

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Kári Davíðsson]

Hi,

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@lumentis.se]
> Sent: 12. apríl 2001 13:53
> To: Kári Davíðsson; mtd@infradead.org
> Subject: RE: CFI with 4 x8/x16 devices on a 32-bit bus 
> 
> 
> Hi
> 
> I been all the time wrong! I just discovered that hexl-mode i 
> emacs is broken!
> Emacs in hexl-mode displays 81ff81ff81ff ... and od -x says 
> fffffff ...
> 
> Sorry about that.
> 
> While I am at it perhaps someone can enlighten me somewhat ...
> 
> I am a bit confused about how add_mtd_device() and 
> add_mtd_partitions() work.
> Looking in nora.c it looks like you can partition a flash by doing 
> a few calls to add_mtd_device() with different offsets, but 
> if you can do
> that with add_mtd_device(), what's the point with 
> add_mtd_partitions()?

To call a few calls to add_mtd_device() 8-)

> 
> I am missing something here, can someone explain when and how 
> you are supposed to
> use these two functions?

Well as you can see in add_mtd_partition() it is not a question of just
calling a couple of times to add_mtd_device(). You need set up the
correspding
device structeres etc, etc, add the virtual regions if you wan't to use
them etc,
etc....

I find it a good abstractation to add partitions to flash devices. After
you
add the partition you just access it like any other flash device, i.e.
you do not
have to know that you are accessing only part of a flash device
(partition) 
rather than the whole device it self. It is all abstracted for you and
makes the
world a much nicer place 8-).

To summary: It is a good way to convert a simple partition description
structures
into device description structures so that the rest of the code does not
have to
know the difference of devices and partitions.

K.D.

> 
>  Jocke


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I been all the time wrong! I just discovered that hexl-mode i emacs
> is broken! Emacs in hexl-mode displays 81ff81ff81ff ... and od -x says
> fffffff ... 

Heh. Naughty emacs. Is everything working now?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

BrettC@nulec.com.au said:
>  OK - this seems to work well. I have attached a patch that does what
> I think you are desscibing - for those who are interested. 

That is indeed what I was describing. Thanks - I've just committed a 
slightly modified version to CVS.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Joakim Tjernlund]

yeah, shame on emacs! :-)

It's working much better now. I have managed to create a JFFS2 FS on one
partition and copied
a few files to it. No problems so far. Now I trying to make that partition
my root FS, have not gotten
very far yet, but I will :-)

I still working my way through MTD and I have still much to learn ...
Hope you have the time to answer a question or two ...

We are doing our own custom board(PPC860) with 3 "banks" of Intel Flashes.
Each bank consists of 2 flashes in 16 bit mode, 2-chip interleave, 32-bit
data bus.
Now I want to make a partition that spans more than one flash bank(or at
least crosses
a bank boundary). Is that possible? Any special tricks or just do an
add_mtd_partition() call?

  Jocke

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
Woodhouse
Sent: Tuesday, April 17, 2001 15:58
To: joakim.tjernlund@lumentis.se
Cc: 'Kari Davmpsson'; mtd@infradead.org
Subject: Re: CFI with 4 x8/x16 devices on a 32-bit bus



joakim.tjernlund@lumentis.se said:
>  I been all the time wrong! I just discovered that hexl-mode i emacs
> is broken! Emacs in hexl-mode displays 81ff81ff81ff ... and od -x says
> fffffff ...

Heh. Naughty emacs. Is everything working now?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  We are doing our own custom board(PPC860) with 3 "banks" of Intel
> Flashes. Each bank consists of 2 flashes in 16 bit mode, 2-chip
> interleave, 32-bit data bus. Now I want to make a partition that spans
> more than one flash bank(or at least crosses a bank boundary). Is that
> possible? Any special tricks or just do an add_mtd_partition() call? 

Special tricks, if they're really in separate banks and you can't just use 
a single mapping driver which will detect all the flash in one go. The code 
can deal with aliases appearing between devices, but can't deal with empty 
space between them - although you could play tricks in the mapping driver 
to make that disappear.

What physical addresses are the flash chips mapped to?

If they have to be in separate mappings, you'll need to write wrapper 
functions similar to the ones in mtdpart.c, which munge the offset and pass 
through to the function in the appropriate MTD device.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Joakim Tjernlund]

Hi again

I can place them at any physical(almost) address since they are connected to
the
cpu's Chip Select logic. I figure I will place them somewhere high starting
at 0xf8000000.
I can also make the address space linear(no holes between the banks).

Now, can I just define WINDOW_ADDR 0xf8000000 and WINDOW_SIZE 0x8000000 and
specifiy my partitions without worrying about flash bank boundries? (In my
dreams or ...)

    Jocke
PS.
    I meant 4 flash banks below. Each bank is 32 MB

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
Woodhouse
Sent: Tuesday, April 17, 2001 17:23
To: joakim.tjernlund@lumentis.se
Cc: kd@flaga.is; mtd@infradead.org
Subject: Re: CFI with 4 x8/x16 devices on a 32-bit bus



joakim.tjernlund@lumentis.se said:
>  We are doing our own custom board(PPC860) with 3 "banks" of Intel
> Flashes. Each bank consists of 2 flashes in 16 bit mode, 2-chip
> interleave, 32-bit data bus. Now I want to make a partition that spans
> more than one flash bank(or at least crosses a bank boundary). Is that
> possible? Any special tricks or just do an add_mtd_partition() call?

Special tricks, if they're really in separate banks and you can't just use
a single mapping driver which will detect all the flash in one go. The code
can deal with aliases appearing between devices, but can't deal with empty
space between them - although you could play tricks in the mapping driver
to make that disappear.

What physical addresses are the flash chips mapped to?

If they have to be in separate mappings, you'll need to write wrapper
functions similar to the ones in mtdpart.c, which munge the offset and pass
through to the function in the appropriate MTD device.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: CFI with 4 x8/x16 devices on a 32-bit bus

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  I can place them at any physical(almost) address since they are
> connected to the cpu's Chip Select logic. I figure I will place them
> somewhere high starting at 0xf8000000. I can also make the address
> space linear(no holes between the banks).

> Now, can I just define WINDOW_ADDR 0xf8000000 and WINDOW_SIZE
> 0x8000000 and specifiy my partitions without worrying about flash bank
> boundries? (In my dreams or ...) 

That should work.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: CFI with 4 x8/x16 devices on a 32-bit bus

[Joakim Tjernlund]

Great!!

Wish I had the board here so I could bore you with even more questions :-)
But I will have to wait several weeks ...

    Jocke

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@redhat.com]On Behalf Of David
Woodhouse
Sent: Tuesday, April 17, 2001 17:53
To: joakim.tjernlund@lumentis.se
Cc: kd@flaga.is; mtd@infradead.org
Subject: Re: CFI with 4 x8/x16 devices on a 32-bit bus 



joakim.tjernlund@lumentis.se said:
>  I can place them at any physical(almost) address since they are
> connected to the cpu's Chip Select logic. I figure I will place them
> somewhere high starting at 0xf8000000. I can also make the address
> space linear(no holes between the banks).

> Now, can I just define WINDOW_ADDR 0xf8000000 and WINDOW_SIZE
> 0x8000000 and specifiy my partitions without worrying about flash bank
> boundries? (In my dreams or ...) 

That should work.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org