chip drivers

chip drivers

[Jonas Holmberg]

I need to use different flash chips (AMD compatible, mixed CFI and
non-CFI, mixed geometry etc) at the same time :). I think I will need to
change the cfi drivers and the cfi- and jedec-probe to accomplish this. 

I'm not going to try to use different chips in interleave (the code for
that would probably be unreadable, and who needs it?).

Are there other cases I ought to handle as well? Would anyone object if
I replace the cfi_probe and jedec_probe with one unified flash_probe?

I'll do some thinking and testing and come up with a more detailed plan
before I start doing any serious damag^H^H^H^H^Hcoding.

/Jonas

Re: chip drivers

[David Woodhouse]

jonas.holmberg@axis.com said:
> I need to use different flash chips (AMD compatible, mixed CFI and
> non-CFI, mixed geometry etc) at the same time :). I think I will need
> to change the cfi drivers and the cfi- and jedec-probe to accomplish
> this.  

Why do you think this? They should be fine. Just set up as many map 
structures as you require and call the appropriate probe functions.

--
dwmw2

Re: chip drivers

[Jonas Holmberg]

On Fri, 2002-02-01 at 14:34, David Woodhouse wrote:
> 
> jonas.holmberg@axis.com said:
> > I need to use different flash chips (AMD compatible, mixed CFI and
> > non-CFI, mixed geometry etc) at the same time :). I think I will need
> > to change the cfi drivers and the cfi- and jedec-probe to accomplish
> > this.  
> 
> Why do you think this? They should be fine. Just set up as many map 
> structures as you require and call the appropriate probe functions.

Do you mean using two map structures (one for each probe) and just let
the cfi_probe fill out one of them and jedec_probe the other? Because I
don't think that will work without complex code that calls the probes
over and over again.

/Jonas

Re: chip drivers

[David Woodhouse]

jonas.holmberg@axis.com said:
>  Do you mean using two map structures (one for each probe) and just
> let the cfi_probe fill out one of them and jedec_probe the other?

Yes.

> Because I don't think that will work without complex code that calls
> the probes over and over again.

Look at drivers/mtd/maps/ocelot.c. It has two map structures and calls two 
probe functions. 


--
dwmw2

Re: chip drivers

[Jonas Holmberg]

> > Because I don't think that will work without complex code that calls
> > the probes over and over again.
> 
> Look at drivers/mtd/maps/ocelot.c. It has two map structures and calls two 
> probe functions. 

But how would I be able to detect all chips if I had a configuration
like this:

0x00000000 - 0x003FFFFF 4MiB CFI chip
0x00400000 - 0x005FFFFF 2MiB jedec only chip
0x00600000 - 0x009FFFFF 4MiB CFI chip

I could call the cfi-probe first and it would find the first chip but it
would try to find the next chip at 0x00400000 and that's not a CFI chip
so it would continue to look at 0x00800000 and miss the chip at
0x00600000. And I would have to make the jedec_probe start looking at
0x00400000 because it wouldn't find any chip at 0x00000000.

Let's say that all chips above are 2MiB instead so that the can be
detected by the probes. Would it be possible to make a partition that is
located both in a CFI and in a non-CFI chip?
 
Can the cfi-driver really handle chips of different sizes and/or
eraseregion-layouts?

I noticed that the jedec_probe only accepts identical chips (IDs) and it
thinks that it has found a new chip if my window is bigger than all my
chips together (I'll have to fix that).

/Jonas (slightly confused)

Re: chip drivers

[David Woodhouse]

jonas.holmberg@axis.com said:
>  But how would I be able to detect all chips if I had a configuration
> like this:

> 0x00000000 - 0x003FFFFF 4MiB CFI chip
> 0x00400000 - 0x005FFFFF 2MiB jedec only chip
> 0x00600000 - 0x009FFFFF 4MiB CFI chip

You'd need three maps, three probe calls. Although I suppose you could have 
a single map driver for the first and last chips where the access calls do 
something like:
	return *(volatile __u32 *) (addr + (addr>0x400000?0x200000:0));

You probably don't want that though. Register them as three separate chips 
and then use the partition code that's been fixed to let you combine ranges 
of separate devices into one 'partition' rather than just split devices up.


--
dwmw2

Re: chip drivers

[Jonas Holmberg]

> Register them as three separate chips 
> and then use the partition code that's been fixed to let you combine ranges 
> of separate devices into one 'partition' rather than just split devices up.

I haven't got past the probing part yet. I'm trying to use cfi_probe and
jedec_probe to find all chips in a really big window. So when the
cfi_probe or the jedec_probe has found something I make a copy of the
map it used and increase map_priv_1 (used by the read and write
callbacks as in physmap.c) in the new map. The new map is then used for
the next probe.

The problem is that I cannot determine if a previous probe found any
alias or not. I must not probe where an alias has been found by a
previous probe since the next probe will think it is a new chip and not
recognize it as an alias (sinze it will think that it found the chip at
location zero). And I must continue probing until the end of the window.

Do I have to change the interface of the probe functions (I need the
address of the last found alias without "manually" looking for aliases
like the probe functions do)?

/Jonas

Re: chip drivers

[Jonas Holmberg]

> Do I have to change the interface of the probe functions (I need the
> address of the last found alias without "manually" looking for aliases
> like the probe functions do)?

I'm giving up on making the ultimate super-mega-grand-flash-probe-de-lux
that only needs one map and a window size to magically find all chips
within that window. The more I try the more problems I find.

I will just do cfi_probe and jedec_probe on the two chip selects (two
maps) on the hardware I use (ETRAX 100LX) and assume that noone mounts
different chips on the same map (it requires external hardware to mount
more than one chip on each chip select anyway). That will cover all
existing hardware configurations that I know of. The code will be
hardware-specific so I will not make it a part of MTD (I'll just put it
in our linux/arch/cris/axisflashmap.c when I'm done).

/Jonas

Re: chip drivers

[Jonas Holmberg]

> > 0x00000000 - 0x003FFFFF 4MiB CFI chip
> > 0x00400000 - 0x005FFFFF 2MiB jedec only chip
> > 0x00600000 - 0x009FFFFF 4MiB CFI chip
> 
> You'd need three maps, three probe calls. Although I suppose you could have 
> a single map driver for the first and last chips where the access calls do 
> something like:
> 	return *(volatile __u32 *) (addr + (addr>0x400000?0x200000:0));
> 
> You probably don't want that though. Register them as three separate chips 
> and then use the partition code that's been fixed to let you combine ranges 
> of separate devices into one 'partition' rather than just split devices up.

Can you explain that a bit further? I can't figure out how use
add_mtd_partitions (current CVS) when I want to make a partition that
starts in one map and ends in another. Since the map is an argument to
app_mtd_partitions I must make two calls to add_mtd_partitions, right?
But how do I make add_mtd_partitions merge the start of the device (in
the endo of the first map) with the end of the device (in the beginning
of the other map)?

/Jonas

Re: chip drivers

[David Woodhouse]

On 6 Feb 2002, Jonas Holmberg wrote:

> Can you explain that a bit further? I can't figure out how use
> add_mtd_partitions (current CVS) when I want to make a partition that
> starts in one map and ends in another. 

It's not in CVS. There were patches on the mailing list. You need to 
either use those, or write your own indirection routines to do what you 
require, in place of the existing mtdpart methods.

-- 
dwmw2

Re: chip drivers

[Jonas Holmberg]

On Wed, 2002-02-06 at 15:43, David Woodhouse wrote:
> On 6 Feb 2002, Jonas Holmberg wrote:
> 
> > Do you mean Jörn Engels patches
> > (http://wh.fh-wedel.de/~joern/software/kernel/)? Are they expected to be
> > committed to the MTD CVS soon?
> 
> Yes - I believe they contain support for this. I'm intending to merge them 
> as soon as I've finished all the destabilising stuff in JFFS2 (eCos 
> support, NAND flash support) and when I stop ignoring Linus' 2.5 kernel.
> 
> At that point I'll look at merging Jörn's patches into a 2.5 branch, which
> should be usable in 2.4 but won't be submitted to Marcelo.

I need a solution that will work in 2.4. It sounds like I shouldn't rely
on Jörn's patches working in 2.4.

What really annoys me is that even though different probe funcions will
find two different chips, the same driver will still be used
(cfi_cmdset_0002 in my case) for both chips. So if I could merge the two
mtd_info structs (and everything they point to, like eraseregions and
flchip structs) the result ought to allow me to create devices that
start in one chip and end in the other using the partition code in
current CVS.

This can be done in two ways at least: an ugly merge-function (kind of a
+ operator for mtd_infos), or make the probe functions check the
map->fldrv_priv and use an existing mtd_info before creating a new one.
I prefer the latter. I think it would work if I add an offset field to
map_info that can be used for the second probe (added to all offsets in
eraseregions and flchips for the second probe). The only problem would
be the chipshift field in cfi_private (I think) and it could be removed
and replaced by the start (offset) field in flchip where used.

The second probe with the same map would, of course, have to fail if
there were a mismatch in interleave, device_type etc.

I would like to get your opinion on this. Would it have any chance of
ending up in 2.4 if it works?

/Jonas