Large flash concatenation

Large flash concatenation

[Andy Hawkins]

Hi,

I'm trying to add support to the kernel for concatenating a number of
large flash devices (1Gb Samsung K9F1G08).

I've added the following line to nand_ids.c:

	{"NAND 1GiB 3,3V", 0xf1, 30, 0x4000, 0},

and the devices are correctly detected (I've also written the required
code in drivers/mtd/nand), showing a size of 0x40000000 for each device.
However, when I concatenate 15 of these devices, I end up with a
partition of size 0xc000000. I assume that this is because the total
size is stored in 32 bits, and as such is overflowing.

I want to be able to use these multiple chips as a single flash
filesystem (probably JFFS2).

Can anyone help as to how I can do this?

Many thanks.

Andy

Re: Large flash concatenation

[Thomas Gleixner]

On Friday 28 May 2004 11:41, Andy Hawkins wrote:
> Hi,
>
> I'm trying to add support to the kernel for concatenating a number of
> large flash devices (1Gb Samsung K9F1G08).
>
> I've added the following line to nand_ids.c:
>
> 	{"NAND 1GiB 3,3V", 0xf1, 30, 0x4000, 0},
>
> and the devices are correctly detected (I've also written the required
> code in drivers/mtd/nand), showing a size of 0x40000000 for each device.

The device size is not 1GiB in words: One GigaByte.
The device size for chips with the id code 0xf1 is
1 GigaBit which is 128 MegaByte

The erasesize is wrong, as it is 64KiB and not 16KiB, but see below (1.)

> However, when I concatenate 15 of these devices, I end up with a
> partition of size 0xc000000. I assume that this is because the total
> size is stored in 32 bits, and as such is overflowing.

15 * 128 Megabyte =  2013265920 Bytes = 0x78000000
which fits into 32 bit

1. Please use the latest NAND code, as the support for the larger devices is 
already there and the old code does not handle the large page devices.
We have actually problems with CVS access (is IPV6 only). I can provide a 
current snapshot on request.

2. The nand driver itself can handle multiple chips now. The scan function
supports multiple chip detection. Do not use the concat function for this 
purpose. The chips are provided as one big device to the MTD layer if you do 
not use partitions.

> I want to be able to use these multiple chips as a single flash
> filesystem (probably JFFS2).

It might turn out that JFFS2 is not the first choice for this concatenated 
device size, but it should work. Maybe YAFFS2 would be more suitable. It's 
not released yet AFAIK, but it should be available soon. 

You can join #mtd on irc.freenode.net if you want.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large flash concatenation

[David Woodhouse]

On Fri, 2004-05-28 at 10:41 +0100, Andy Hawkins wrote:
> Hi,
> 
> I'm trying to add support to the kernel for concatenating a number of
> large flash devices (1Gb Samsung K9F1G08).
> 
> I've added the following line to nand_ids.c:
> 
> 	{"NAND 1GiB 3,3V", 0xf1, 30, 0x4000, 0},

Er, that part is 1Gib, not 1GiB. 1Gib is 128MiB.

> I want to be able to use these multiple chips as a single flash
> filesystem (probably JFFS2).

That's a lot of flash -- JFFS2 doesn't scale too well at the moment.

To make JFFS2 work better, we need to reduce the memory usage -- partly
by reducing the size of some structures (we can drop totlen from the
jffs2_raw_node_ref with a bit of effort), and partly by reducing the
_number_ of such structures -- perhaps we should increase the maximum
data payload on a single node from 4KiB to 16KiB or more -- thereby
reducing the number of nodes a lot.

We also really need to do checkpointing to reduce mount time.

It would be interesting to try JFFS2 -- but I suspect you may do better
with YAFFS2 at the moment.

-- 
dwmw2

Re: Large flash concatenation

[Andy Hawkins]

Hi,

Thanks to both Thomas and David for replying.

On Fri, 2004-05-28 at 11:27, Thomas Gleixner wrote:
> 1. Please use the latest NAND code, as the support for the larger devices is 
> already there and the old code does not handle the large page devices.
> We have actually problems with CVS access (is IPV6 only). I can provide a 
> current snapshot on request.

I'm now doing that. I've downloaded the latest snapshot
(mtd-snapshot-20040527.tar.bz2) and am trying to get it to compile now.

> 2. The nand driver itself can handle multiple chips now. The scan function
> supports multiple chip detection. Do not use the concat function for this 
> purpose. The chips are provided as one big device to the MTD layer if you do 
> not use partitions.

How do I do this? Each chip appears at a separate address (we've used
the lower 6 bits of the address lines to decode the chip selects for
each chip). At the moment, I'm looping over all the possible addresses
calling 'nand_scan' at each address. Is this this correct way to do
this?

> It might turn out that JFFS2 is not the first choice for this concatenated 
> device size, but it should work. Maybe YAFFS2 would be more suitable. It's 
> not released yet AFAIK, but it should be available soon. 

We haven't made a final choice of filesystem as of yet, I just want to
get the devices up and running so that I can write / read them (to prove
our hardware design is correct).

> You can join #mtd on irc.freenode.net if you want.

That might be a good idea. Thanks for letting me know about that.

Andy

Re: Large flash concatenation

[Thomas Gleixner]

On Friday 28 May 2004 12:42, Andy Hawkins wrote:
> Hi,
>
> Thanks to both Thomas and David for replying.
>
> On Fri, 2004-05-28 at 11:27, Thomas Gleixner wrote:
> > 1. Please use the latest NAND code, as the support for the larger devices
> > is already there and the old code does not handle the large page devices.
> > We have actually problems with CVS access (is IPV6 only). I can provide a
> > current snapshot on request.
>
> I'm now doing that. I've downloaded the latest snapshot
> (mtd-snapshot-20040527.tar.bz2) and am trying to get it to compile now.

The snapshot is outdated due to the same reason. I'm building one and putting 
it somewhere for download.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large flash concatenation

[Andy Hawkins]

On Fri, 2004-05-28 at 11:44, Thomas Gleixner wrote:
> The snapshot is outdated due to the same reason. I'm building one and putting 
> it somewhere for download.

Excellent, I'll hold off until your one is ready then.

Many thanks.

Andy

Re: Large flash concatenation

[Thomas Gleixner]

On Friday 28 May 2004 12:58, Andy Hawkins wrote:
> On Fri, 2004-05-28 at 11:44, Thomas Gleixner wrote:
> > The snapshot is outdated due to the same reason. I'm building one and
> > putting it somewhere for download.
>
> Excellent, I'll hold off until your one is ready then.

http://www.linutronix.de/data/mtd-20040528-tglx-1.tar.bz2

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large flash concatenation

[Thomas Gleixner]

On Friday 28 May 2004 12:42, Andy Hawkins wrote:
> Hi,
>
> > 2. The nand driver itself can handle multiple chips now. The scan
> > function supports multiple chip detection. Do not use the concat function
> > for this purpose. The chips are provided as one big device to the MTD
> > layer if you do not use partitions.
>
> How do I do this? Each chip appears at a separate address (we've used
> the lower 6 bits of the address lines to decode the chip selects for
> each chip). At the moment, I'm looping over all the possible addresses
> calling 'nand_scan' at each address. Is this this correct way to do
> this?

nand_scan now takes a parameter maxchips. This tells nand_scan to scan for up 
to maxchips chips.

The selection is simple. Only one chip can be selected at a time. 
All you have to do is write your own select_chip function and set the function 
pointer in the nand chip structure to this function before calling nand_scan

the function gets the chipnr (0 - maxchip-1) which should be selected or -1 to 
deselect.
Inside this function you simply modify the IO_ADDR_R and IO_ADDR_W fields of 
the nand structure so the appropriate chip gets selected.

-- 
Thomas
________________________________________________________________________
Steve Ballmer quotes the statistic that IT pros spend 70 percent of their 
time managing existing systems. That couldn’t have anything to do with 
the fact that 99 percent of these systems run Windows, could it?
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: Large flash concatenation

[David Woodhouse]

On Fri, 2004-05-28 at 12:44 +0200, Thomas Gleixner wrote:
> The snapshot is outdated due to the same reason. I'm building one and putting 
> it somewhere for download.

The snapshots stopped working because CVS doesn't handle pserver on
IPv6. Anonymous CVS access is now done over SSH:

	export CVS_RSH=`which ssh`
	cvs -d :ext:anoncvs@cvs.infradead.org:/home/cvs co mtd

The snapshots should be up to date again starting from tonight's.

-- 
dwmw2