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

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

What about a search engine ?

[DELANNEAU Alain]

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


Hi mtd hackers
I'm a newcomer to mtd and jffs, and I'm impressed
by the quantity and quality of the subjects treated here !
I've been browsing this mail archive for some days
"by hand", but it's so huge now ...
Wouldn't it be a good idea to set up a search engine ?

Nice work anyway


[-- Attachment #2: Carte pour delanneau --]
[-- Type: text/x-vcard, Size: 385 bytes --]

begin:vcard 
n:DELANNEAU;Alain
tel;fax:01 41 87 74 27
tel;work:01 41 87 70 79
x-mozilla-html:FALSE
org:CS TELECOM;Basic software / System
version:2.1
email;internet:alain.delanneau@cstelecom.com
title:Software development engineer
adr;quoted-printable:;;4-16, Avenue du G=E9n=E9ral Leclerc=0D=0ABP 74;Fontenay-Aux-Roses;;92260;FRANCE
x-mozilla-cpt:;-24128
fn:Alain DELANNEAU
end:vcard

Re: What about a search engine ?

[David Woodhouse]

alain.delanneau@cstelecom.com said:
> Wouldn't it be a good idea to set up a search engine ? 

http://www.linux-mtd.infradead.org/list-archive/mtd-2001q1/8.html

:)

--
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