RE: 16 NANDS

RE: 16 NANDS

[Marc Neiger]

Hi Thomas,

> I have the framework ready to support different buswidths. 

It's dangerous talking to you, guys, one gets easily caught in the maelstrom
;-)

I'll gladly put my share back into the GPLd world, however my timeframe for
the current project is very tight; everything, board, embedded linux and
application should be working in less than 2 months.....
Moreover, although I, and my colleagues, are experienced programmers, both
in embedded and win32, I booted my first Linux about 6 weeks ago....

The project shall be using a customly developped board using AMD Alchemy
AU1000 (MIPS4Kc) processor. The board is planned to support both 8 and
16bits NAND flash, an EPLD shall, among other task, take care of data bus
bits reordering (8 and 16 bits NANDS are pin out compatible except for the
bit order). After reading some msg on this list, we already doubt about the
ease of mounting a root JFFS2 filesystem.


I'll have a look at the framework, then if I have some "time" and I feel
comfortable with your code, I'll try to finish it, and we'll test it on our
first board version. Otherwise, and it seems more likely, after the project
is delivered and we have some experience on Linux, including kernel
development since we are to write a driver for this very specific hardware,
I'll get more seriously hands on the code but without having a very short
deadline in front of me.
I already do much non computer related volunteer work and can not afford to
take on my "free" time anymore.

Cheers,
Marc Neiger

Re: 16 NANDS

[Thomas Gleixner]

On Wednesday 08 January 2003 22:23, Marc Neiger wrote:
> Hi Thomas,
>
> > I have the framework ready to support different buswidths.
>
> It's dangerous talking to you, guys, one gets easily caught in the
> maelstrom ;-)
>
> I'll gladly put my share back into the GPLd world, however my timeframe for
> the current project is very tight; everything, board, embedded linux and
> application should be working in less than 2 months.....
> Moreover, although I, and my colleagues, are experienced programmers, both
> in embedded and win32, I booted my first Linux about 6 weeks ago....
>
> The project shall be using a customly developped board using AMD Alchemy
> AU1000 (MIPS4Kc) processor. The board is planned to support both 8 and
> 16bits NAND flash, an EPLD shall, among other task, take care of data bus
> bits reordering (8 and 16 bits NANDS are pin out compatible except for the
> bit order). After reading some msg on this list, we already doubt about the
> ease of mounting a root JFFS2 filesystem.
It's really no big deal to mount a root fs with JFFS2 on NAND FLASH (8 bit 
buswidth). It works right out of the box, if you take the preliminaries into 
concern (see http://www.linux-mtd.infradead.org/tech/nand.html)
It is used in production systems.

> I'll have a look at the framework, then if I have some "time" and I feel
> comfortable with your code, I'll try to finish it, and we'll test it on our
> first board version. Otherwise, and it seems more likely, after the project
> is delivered and we have some experience on Linux, including kernel
> development since we are to write a driver for this very specific hardware,
> I'll get more seriously hands on the code but without having a very short
> deadline in front of me.
If your deadline is so tight and your capacities are so restricted, you could 
consider to sponsor one of the volunteer experts. This would speed up 
development rapidly. :)

> I already do much non computer related volunteer work and can not afford to
> take on my "free" time anymore.
See above. :)

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

RE: 16 NANDS

[Marc Neiger]

Hi Charles,

Of course you properly understood I forgot to type "16bits wide".

I was thinking about products such as Samsung K9F5616U0B wich is a 256Mbit
NAND flash. Page size is 512 + 16 OOB bytes. So the problem is just
regarding the data transfer width as the page size are the same as the
already supported chips/architectures. Moreover it is quite complicated as
the commands and addresses are still transfered as 8 bits, only data are
transfered as 16bits.

However, as a newcomer in the embbeded linux world, and although I feel like
it should be quite simple, I don't feel like doing the software modification
myself...

Cheers,
Marc Neiger



> -----Message d'origine-----
> De : Charles Manning [mailto:manningc2@actrix.gen.nz]
> Envoyé : lundi 6 janvier 2003 22:15
> À : m.neiger@synergie-inf.com; 'linux-mtd@lists.infradead.org'
> Objet : Re: 16 NANDS
> 
> 
> By this I expect you mean the NAND chips with a 16-bit wide interface.
> 
> There are really two sub-issues:
> * Hook-up to the chips themselves (ie. doing x16 instead of 
> x8 trasfers).
> * The 16-bit wide chips have larger pages and blocks (2kB 
> pages, 128kB 
> blocks) than the previous generation stuff. This needs to be 
> handled too at 
> both the mtd and file system level. I believe (but don't 
> quote me) that JFFS2 
> will work as it is now. YAFFS is currently undergoing 
> extensions/mods to 
> support the larger pages/blocks.
> 
> -- Charles
> 
> 
> On Fri, 03 Jan 2003 23:27, Marc Neiger wrote:
> > Hi,
> >
> > what are the current status/plan regarding the use of 16 NAND Flash,
> > including with JFFS2
> >
> > Cheers and happy new year,
> > Marc Neiger
> >
> > Marc Neiger
> >
> >
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: 16 NANDS

[Charles Manning]

I believe Thomas has this on his TBD list, but - like everyone - he is rather 
busy so it might take a while before this comes to the top of his priority 
list. 

Hey why not give it a shot? One way to get experience is to just jump in 
(especially on something like this which looks relatively simple). There are 
many nice people in mtd land who will provide support.

-- CHarles


On Tue, 07 Jan 2003 11:42, Marc Neiger wrote:
> Hi Charles,
>
> Of course you properly understood I forgot to type "16bits wide".
>
> I was thinking about products such as Samsung K9F5616U0B wich is a 256Mbit
> NAND flash. Page size is 512 + 16 OOB bytes. So the problem is just
> regarding the data transfer width as the page size are the same as the
> already supported chips/architectures. Moreover it is quite complicated as
> the commands and addresses are still transfered as 8 bits, only data are
> transfered as 16bits.
>
> However, as a newcomer in the embbeded linux world, and although I feel
> like it should be quite simple, I don't feel like doing the software
> modification myself...
>
> Cheers,
> Marc Neiger
>
> > -----Message d'origine-----
> > De : Charles Manning [mailto:manningc2@actrix.gen.nz]
> > Envoyé : lundi 6 janvier 2003 22:15
> > À : m.neiger@synergie-inf.com; 'linux-mtd@lists.infradead.org'
> > Objet : Re: 16 NANDS
> >
> >
> > By this I expect you mean the NAND chips with a 16-bit wide interface.
> >
> > There are really two sub-issues:
> > * Hook-up to the chips themselves (ie. doing x16 instead of
> > x8 trasfers).
> > * The 16-bit wide chips have larger pages and blocks (2kB
> > pages, 128kB
> > blocks) than the previous generation stuff. This needs to be
> > handled too at
> > both the mtd and file system level. I believe (but don't
> > quote me) that JFFS2
> > will work as it is now. YAFFS is currently undergoing
> > extensions/mods to
> > support the larger pages/blocks.
> >
> > -- Charles
> >
> > On Fri, 03 Jan 2003 23:27, Marc Neiger wrote:
> > > Hi,
> > >
> > > what are the current status/plan regarding the use of 16 NAND Flash,
> > > including with JFFS2
> > >
> > > Cheers and happy new year,
> > > Marc Neiger
> > >
> > > Marc Neiger
> > >
> > >
> > >
> > > ______________________________________________________
> > > Linux MTD discussion mailing list
> > > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: 16 NANDS

[Thomas Gleixner]

On Tuesday 07 January 2003 00:03, Charles Manning wrote:
> I believe Thomas has this on his TBD list, but - like everyone - he is
> rather busy so it might take a while before this comes to the top of his
> priority list.
True :)
> Hey why not give it a shot? One way to get experience is to just jump in
> (especially on something like this which looks relatively simple). There
> are many nice people in mtd land who will provide support.
I have the framework ready to support different buswidths. This means there 
will be a bunch of function pointers, which have to be set correctly. The 
functions are not that different, but it's better to have a little duplicated 
code instead of if (buswitdh == x) then else.... crap.
If you're interested, I can provide you with my modified codebase. Give me 
time until weekend to polish it a little bit and write some lines, what to do 
where. You're heartly welcome in the club of volunteers :)

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: 16 NANDS

[David Woodhouse]

tglx@linutronix.de said:
>  The  functions are not that different, but it's better to have a
> little duplicated  code instead of if (buswitdh == x) then else....
> crap.

Bear in mind that if/then/else crap can be hidden inside #defines fairly 
effectively, and optimises away perfectly in the case where you compile for 
only one buswidth -- unlike out-of-line function calls. 

What Nico did with cfi_read() et al is worth considering.

--
dwmw2

Re: 16 NANDS

[Thomas Gleixner]

On Wednesday 08 January 2003 09:14, David Woodhouse wrote:
> tglx@linutronix.de said:
> >  The  functions are not that different, but it's better to have a
> > little duplicated  code instead of if (buswitdh == x) then else....
> > crap.
>
> Bear in mind that if/then/else crap can be hidden inside #defines fairly
> effectively, and optimises away perfectly in the case where you compile for
> only one buswidth -- unlike out-of-line function calls.
>
> What Nico did with cfi_read() et al is worth considering.
I have the option already built in to compile for one buswidth only, but if 
you want to compile it for 8/16/32 3 different functions give you more code, 
but also more speed and more flexibility for code maintainence

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

16 NANDS

[Marc Neiger]

Hi,
 
what are the current status/plan regarding the use of 16 NAND Flash,
including with JFFS2
 
Cheers and happy new year,
Marc Neiger

Marc Neiger
 

Re: 16 NANDS

[Charles Manning]

By this I expect you mean the NAND chips with a 16-bit wide interface.

There are really two sub-issues:
* Hook-up to the chips themselves (ie. doing x16 instead of x8 trasfers).
* The 16-bit wide chips have larger pages and blocks (2kB pages, 128kB 
blocks) than the previous generation stuff. This needs to be handled too at 
both the mtd and file system level. I believe (but don't quote me) that JFFS2 
will work as it is now. YAFFS is currently undergoing extensions/mods to 
support the larger pages/blocks.

-- Charles


On Fri, 03 Jan 2003 23:27, Marc Neiger wrote:
> Hi,
>
> what are the current status/plan regarding the use of 16 NAND Flash,
> including with JFFS2
>
> Cheers and happy new year,
> Marc Neiger
>
> Marc Neiger
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/