NAND and JFFS2 supports in Linux 2.4

NAND and JFFS2 supports in Linux 2.4

[Laurent Lagrange]

Hello,

I work on a custom 82xx board with a NAND flash :
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V
8-bit)

I have to KEEP a Linux 2.4 and can't migrate to a Linux 2.6 for this board.

This type of NAND flash and JFFS2 work fine with a Linux 2.6 but with a
Linux 2.4,
this is a little tricky :
Linux 2.4.18 or 2.4.25 do not support this device,
Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
Linux 2.4.32 does not support this device anymore.

On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
supported.

Any help would be welcome
Thanks
Laurent

Re: NAND and JFFS2 supports in Linux 2.4

[Jaap-Jan Boor]

Laurent,

Take a look at the 2.4 http://www.denx.de kernel, it has NAND and jffs2
support.

Jaap-Jan

On 11-apr-2006, at 18:31, Laurent Lagrange wrote:

>
> Hello,
>
> I work on a custom 82xx board with a NAND flash :
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND  
> 128MiB 3,3V
> 8-bit)
>
> I have to KEEP a Linux 2.4 and can't migrate to a Linux 2.6 for  
> this board.
>
> This type of NAND flash and JFFS2 work fine with a Linux 2.6 but  
> with a
> Linux 2.4,
> this is a little tricky :
> Linux 2.4.18 or 2.4.25 do not support this device,
> Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
> Linux 2.4.32 does not support this device anymore.
>
> On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
> supported.
>
> Any help would be welcome
> Thanks
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> -- 
> This message has been scanned for viruses and is believed to be clean
>

____
J.G.J. Boor                       Anton Philipsweg 1
Software Engineer                 1223 KZ Hilversum
AimSys bv                         tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   jjboor at aimsys dot nl

Re: NAND and JFFS2 supports in Linux 2.4

[Josh Boyer]

On Tue, 2006-04-11 at 18:31 +0200, Laurent Lagrange wrote:
> Hello,
> 
> I work on a custom 82xx board with a NAND flash :
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V
> 8-bit)
> 
> I have to KEEP a Linux 2.4 and can't migrate to a Linux 2.6 for this board.
> 
> This type of NAND flash and JFFS2 work fine with a Linux 2.6 but with a
> Linux 2.4,
> this is a little tricky :
> Linux 2.4.18 or 2.4.25 do not support this device,

Those are entire too old.

> Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,

NAND + JFFS2 + 2.4 is not a supported combination.
 
> Linux 2.4.32 does not support this device anymore.

Odd.  Do you have a diff from .31 to .32?

> On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
> supported.

Well, 2.4 is supported but no new features go in that tree.  Including
NAND support in JFFS2.  If there is a bug in the 2.4 code that is
present in MTD/JFFS2 it can certainly still be fixed.

> 
> Any help would be welcome

You might try your luck with patching the latest 2.4 kernel with MTD
CVS.  But be warned that quite a few things have changed, so you'd have
to essentially backport.

And keep in mind that it's not supported.

josh

RE: NAND and JFFS2 supports in Linux 2.4

[Laurent Lagrange]

Hello

> -----Message d'origine-----
> De : Josh Boyer

> > Linux 2.4.18 or 2.4.25 do not support this device,
> Those are entire too old.
Except for some customers which must maintain kernels during many years :-)

> > Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
> NAND + JFFS2 + 2.4 is not a supported combination.
That's the problem i am facing with.

> > Linux 2.4.32 does not support this device anymore.
> Odd.  Do you have a diff from .31 to .32?
Not a diff but

1) in Linux 2.4.32, I have the following files :
Config.in        diskonchip.c  nand_bbt.c        rtc_from4.c  tx4925ndfmc.c
Makefile         edb7312.c     nand_ecc.c        s3c2410.c    tx4938ndfmc.c
Makefile.common  h1910.c       nand_ids.c        sharpsl.c*
au1550nd.c       nand.c        nandsim.c         spia.c
autcpu12.c       nand_base.c   ppchameleonevb.c  toto.c
$Id: nand_ids.c,v 1.12 2005/02/16 09:33:27 gleixner Exp $

2) in Linux 2.4.32, I just have the following files :
autcpu12.c  edb7312.c  nand.c      nand_ids.c
Config.in   Makefile   nand_ecc.c  spia.c
with a very old nand_ids.c.
$Id: nand_ids.c,v 1.1 2002/12/02 22:06:04 gleixner Exp $

> > On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
supported.
> Well, 2.4 is supported but no new features go in that tree.  Including
> NAND support in JFFS2.  If there is a bug in the 2.4 code that is
> present in MTD/JFFS2 it can certainly still be fixed.
OK

> > Any help would be welcome
> You might try your luck with patching the latest 2.4 kernel with MTD
> CVS.  But be warned that quite a few things have changed, so
> you'd have to essentially backport.
> And keep in mind that it's not supported.
Yes, I saw  that many things have changed and are not be easily backported.
I checked the MTD CVS. All that I found are in the Linux kernel 2.4.31 or
2.6.x.

> -----Message d'origine-----
> De : Jaap-Jan Boor
> Take a look at the 2.4 http://www.denx.de kernel, it has NAND
> and jffs2 support.
Thanks but, I retreived the same files than in the other kernels.


Thanks again for your ideas
I will see what I can do

Bye
Laurent

Re: NAND and JFFS2 supports in Linux 2.4

[Jörn Engel]

On Thu, 13 April 2006 16:49:35 +0200, Laurent Lagrange wrote:
> > -----Message d'origine-----
> > De : Josh Boyer
> 
> > > Linux 2.4.18 or 2.4.25 do not support this device,
> > Those are entire too old.
> Except for some customers which must maintain kernels during many years :-)
> 
> > > Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
> > NAND + JFFS2 + 2.4 is not a supported combination.
> That's the problem i am facing with.

Supporting an old system for years is one thing.  Adding new features
is a completely different beast.  Looks like you have to spend some
substantial time, just to get something running.  Are you sure this is
desired and preferred over a kernel upgrade?  Might be worth
rethinking.

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu

Linux kernel thread with Linux 2.6.x

[Laurent Lagrange]

Hello everybody,

I'm writing a custom network driver based on a MPC8260 FCC device for a
2.6.9 linux kernel.
In this driver, I need to use specific buffer allocation functions which use
down and up semaphore functions.

As the interrupt handler can't be scheduled, I have made a kernel thread
which waits forever on a semaphore.
This semaphore is set when a received packet interrupt occured. All that
mechanism works but the performances
are very poor.

Is there any solution to increase the kthread priority in the scheduler ?
Is there another solution than the semaphore to quickly wake up a kthread ?

Thanks a lot for your help.
Laurent

Re: Linux kernel thread with Linux 2.6.x

[Thiago Galesi]

>
> As the interrupt handler can't be scheduled, I have made a kernel thread
> which waits forever on a semaphore.
> This semaphore is set when a received packet interrupt occured.

You should look into tasklets for this. Not that your system is not
OK, but, as you said it, it's not fast enough.

Note that you still have some limitations using tasklets, but it's
more flexible than Interrupt handlers.

RE: Linux kernel thread with Linux 2.6.x

[Laurent Lagrange]

Hi,

Thanks for your answer, but a tasklet runs in interrupt context
(in_interrupt() != 0) so it doesn't support schedule() call
included in "down" semaphore function.

Any other idea ?

Laurent.

> -----Message d'origine-----
> De : Thiago Galesi [mailto:thiagogalesi@gmail.com]
> Envoyé : lun. 29 mai 2006 18:13
> À : Laurent Lagrange
> Cc : linuxppc-embedded@ozlabs.org
> Objet : Re: Linux kernel thread with Linux 2.6.x
>
>
> >
> > As the interrupt handler can't be scheduled, I have made a
> kernel thread
> > which waits forever on a semaphore.
> > This semaphore is set when a received packet interrupt occured.
>
> You should look into tasklets for this. Not that your system is not
> OK, but, as you said it, it's not fast enough.
>
> Note that you still have some limitations using tasklets, but it's
> more flexible than Interrupt handlers.
>
>

Re: Linux kernel thread with Linux 2.6.x

[Jörn Engel]

On Tue, 30 May 2006 11:46:09 +0200, Laurent Lagrange wrote:
> 
> Thanks for your answer, but a tasklet runs in interrupt context
> (in_interrupt() != 0) so it doesn't support schedule() call
> included in "down" semaphore function.

Do you have code you can show?

Jörn

-- 
Data expands to fill the space available for storage.
-- Parkinson's Law

Re: Linux kernel thread with Linux 2.6.x

[almoeli]

Hi,

do you have to use the semaphore or does a spinlock also meet your needs?
If you are in kernel 2.4 you can use one of the task_queues (e.g the
scheduler queue, timer and immediate queue also run at irq context) but
that won't have a better speed than your solution because it also gets
the processor when tasks are scheduled (all 10ms I think). In 2.6 it
would be the work_queue (schedule_work()).
So the best way is to use spinlocks and do the work in a tasklet at
interrupt context.

Oliver

Jörn Engel schrieb:
> On Tue, 30 May 2006 11:46:09 +0200, Laurent Lagrange wrote:
>> Thanks for your answer, but a tasklet runs in interrupt context
>> (in_interrupt() != 0) so it doesn't support schedule() call
>> included in "down" semaphore function.
> 
> Do you have code you can show?
> 
> Jörn
> 

Re: Linux kernel thread with Linux 2.6.x

[Andy Fleming]

Couldn't you use a work_queue?  For the PHY Layer, the MDIO  
transactions can't occur at interrupt time (they need to be  
interruptible), so the interrupt handler calls schedule_work() to get  
the interrupt handled.  I'm not sure how much faster it is (if at  
all), but it's another method, and sounds less complicated than  
waiting on a semaphore.

Of course, I would suggest trying to avoid the buffer allocation  
functions you are using, or defer the work using NAPI, but it's  
impossible for me to tell whether that's a reasonable solution for you.

On May 29, 2006, at 10:35, Laurent Lagrange wrote:

>
> Hello everybody,
>
> I'm writing a custom network driver based on a MPC8260 FCC device  
> for a
> 2.6.9 linux kernel.
> In this driver, I need to use specific buffer allocation functions  
> which use
> down and up semaphore functions.
>
> As the interrupt handler can't be scheduled, I have made a kernel  
> thread
> which waits forever on a semaphore.
> This semaphore is set when a received packet interrupt occured. All  
> that
> mechanism works but the performances
> are very poor.
>
> Is there any solution to increase the kthread priority in the  
> scheduler ?
> Is there another solution than the semaphore to quickly wake up a  
> kthread ?
>
> Thanks a lot for your help.
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded