RE: MTD/mtdblock.c uclinux 2.0.38?

RE: MTD/mtdblock.c uclinux 2.0.38?

[Mike Voytovich]

Hello,

I see this was posted less than a week ago...

Are you now able to build the latest MTD/JFFS2 CVS with uClinux 2.0.38?  I
would also like to get this code working with 2.0.38, although I'm first
trying with a clean 2.0.38 kernel (then will try with uClinux).

I tried the suggested workarounds below, but still have some problems, which
I'm not sure how to resolve.  Perhaps you have resolved them already.  If
not, I am willing to work on this and add a kernel patch to the mtd CVS, if
I can have a little help...

Thanks,
-mike

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Wednesday, July 11, 2001 3:29 PM
To: Steve Kranz
Cc: linux-mtd@lists.infradead.org
Subject: Re: MTD/mtdblock.c uclinux 2.0.38? 



skranz@ridgerun.com said:
> MTD depends on these headers which don't exist within the uclinux
> tree.

Touch them. We can sort out the missing stuff later. You might want slab.h 
to include malloc.h instead of just being empty.


> include/linux/mtd/map.h line 65, generates error: "field `list' has
> incomplete type"

Copy include/linux/list.h from a later kernel.


skranz@ridgerun.com said:
> statements __MOD_INC_USE_COUNT() and __MOD_DEC_USE_COUNT() found in
> various locations with the MTD tree generate these compile errors:
> "structure has no member named `uc'" "structure has no member named
> `flags'" 

Fix the definitions in include/linux/mtd/compatmac.h to match the kernel 
you're using.


--
dwmw2



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: MTD/mtdblock.c uclinux 2.0.38?

[David Woodhouse]

mvoytovich@coactive.com said:
> Are you now able to build the latest MTD/JFFS2 CVS with uClinux
> 2.0.38?  I would also like to get this code working with 2.0.38,
> although I'm first trying with a clean 2.0.38 kernel (then will try
> with uClinux).

I don't even have a 2.0 kernel in the building.

> I tried the suggested workarounds below, but still have some problems,
> which I'm not sure how to resolve. 

Show me.

--
dwmw2

RE: MTD/mtdblock.c uclinux 2.0.38?

[Mike Voytovich]

>Wouldn't it be easier to forward-port uCLinux to 2.4? Didn't someone
>already do that, in fact?

Yes, there is a uClinux 2.4.x port.  However, there are some issues with
that port; for example, I'm not sure if MMU-less ARM support is complete.
It definitely is complete for 2.0.x.  And, there's the size issue...


>Just provide internally to the JFFS2 code sufficient dcache stuff
>for it to work. Pretend dentries are JFFS2-internal data structures. 

Cool, that seems like good advice - perhaps we'll try that.  Thanks for the
feedback.

Regards,
-mike


-----Original Message-----
From: David Woodhouse
To: Mike Voytovich
Cc: Steve Kranz; linux-mtd@lists.infradead.org
Sent: 7/17/01 11:16 PM
Subject: Re: MTD/mtdblock.c uclinux 2.0.38? 


mvoytovich@coactive.com said:
> One big issue is that JFFS2 seems to rely on the dirent cache, which
> isn't present in the 2.0.x kernel.  So, I suppose that would have to
> be backported from 2.2.x (if that's even a reasonable task).  

Wouldn't it be easier to forward-port uCLinux to 2.4? Didn't someone 
already do that, in fact?

> I don't know what other kernel dependencies (besides dirent cache)
> there are for JFFS2...  I wonder if anyone has been successful in
> getting JFFS2 working with 2.0.x??  Any feedback would be
> appreciated...

JFFS1 will be easier. JFFS2 is possible but may be a lot of work. The
dcache
thing should be the biggest problem - and that's possible to work
around. I 
wouldn't backport the whole of the dcache thing to 2.0 - that would
involve 
completely rewriting the VFS. Just provide internally to the JFFS2 code 
sufficient dcache stuff for it to work. Pretend dentries are
JFFS2-internal 
data structures. 

--
dwmw2

RE: MTD/mtdblock.c uclinux 2.0.38?

[Mike Voytovich]

One big issue is that JFFS2 seems to rely on the dirent cache, which isn't
present in the 2.0.x kernel.  So, I suppose that would have to be backported
from 2.2.x (if that's even a reasonable task).  

I don't know what other kernel dependencies (besides dirent cache) there are
for JFFS2...  I wonder if anyone has been successful in getting JFFS2
working with 2.0.x??  Any feedback would be appreciated...

thanks,
-mike

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org]
Sent: Tuesday, July 17, 2001 12:07 AM
To: Mike Voytovich
Cc: Steve Kranz; linux-mtd@lists.infradead.org
Subject: Re: MTD/mtdblock.c uclinux 2.0.38? 



mvoytovich@coactive.com said:
> Are you now able to build the latest MTD/JFFS2 CVS with uClinux
> 2.0.38?  I would also like to get this code working with 2.0.38,
> although I'm first trying with a clean 2.0.38 kernel (then will try
> with uClinux).

I don't even have a 2.0 kernel in the building.

> I tried the suggested workarounds below, but still have some problems,
> which I'm not sure how to resolve. 

Show me.

--
dwmw2

Re: MTD/mtdblock.c uclinux 2.0.38?

[David Woodhouse]

mvoytovich@coactive.com said:
> One big issue is that JFFS2 seems to rely on the dirent cache, which
> isn't present in the 2.0.x kernel.  So, I suppose that would have to
> be backported from 2.2.x (if that's even a reasonable task).  

Wouldn't it be easier to forward-port uCLinux to 2.4? Didn't someone 
already do that, in fact?

> I don't know what other kernel dependencies (besides dirent cache)
> there are for JFFS2...  I wonder if anyone has been successful in
> getting JFFS2 working with 2.0.x??  Any feedback would be
> appreciated...

JFFS1 will be easier. JFFS2 is possible but may be a lot of work. The dcache
thing should be the biggest problem - and that's possible to work around. I 
wouldn't backport the whole of the dcache thing to 2.0 - that would involve 
completely rewriting the VFS. Just provide internally to the JFFS2 code 
sufficient dcache stuff for it to work. Pretend dentries are JFFS2-internal 
data structures. 

--
dwmw2

MTD/mtdblock.c uclinux 2.0.38?

[Steve Kranz]

1.
Anybody know if instruction exist for installing MTD and nftl
into an uclinux 2.0.38 tree?

2.
I'm interested in getting the SmartMedia slot of this arm7 board
working for both read and write -- and I'd like the SmartMedia
card to be readable/writable by a Windows machine too. Am I
correct that this interoperability constraint will prevent me from
using JFFS? I'm assuming that a vfat fs with MTD/nftl will do the
trick for me. Yes, no?

3.
I've been glancing at MTD code and didn't think I saw any logic
to deal with the bad (unusable) blocks of a NAND flash device.
Did I just miss it?

Thanks,
Steve Kranz
skranz@ridgerun.com

Re: MTD/mtdblock.c uclinux 2.0.38?

[David Woodhouse]

skranz@ridgerun.com said:
> 1. Anybody know if instruction exist for installing MTD and nftl into
> an uclinux 2.0.38 tree?

Should work. Probably doesn't. Give me individual instances of places I 
broke the 2.0 compile, preferably with patches, and we'll deal with it.

> 2. I'm interested in getting the SmartMedia slot of this arm7 board
> working for both read and write -- and I'd like the SmartMedia card to
> be readable/writable by a Windows machine too. Am I correct that this
> interoperability constraint will prevent me from using JFFS? I'm
> assuming that a vfat fs with MTD/nftl will do the trick for me. Yes,
> no?

You need to implement the SmartMedia translation layer format. It looks like
there's enough information on the Samsung web site to do that.

> 3. I've been glancing at MTD code and didn't think I saw any logic to
> deal with the bad (unusable) blocks of a NAND flash device. Did I just
> miss it? 

Done in the SmartMedia translation layer, not in the underlying device 
driver.

--
dwmw2

Re: MTD/mtdblock.c uclinux 2.0.38?

[Steve Kranz]

> uclinux 2.0.38 & MTD?
> Should work. Probably doesn't. Give me individual
> instances of places I broke the 2.0 compile, preferably
> with patches, and we'll deal with it.

Shown below are the problems I encountered when
attempting to build the latest MTD tree for uclinux
2.0.38. For the moment I have suspended efforts to get
this working under 2.0.38 and would be very interested
if someone could provide a MTD version or patch that
will work with that kernel. If so, please let me
know. Thank you!  :-)

Steve Kranz
skranz@ridgerun.com

---------------------------
My choosen config settings:
---------------------------
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_CHAR=y
CONFIG_NFTL=y
CONFIG_NFTL_RW=y
CONFIG_MTD_NAND=y

----------------
Missing Headers:
----------------
MTD depends on these headers which don't exist
within the uclinux tree.
linux/slab.h
linux/spinlock.h
linux/kmod.h

---------------
Other Problems:
---------------
include/linux/mtd/map.h line 65, generates error:
"field `list' has incomplete type"

Attempts to compile the MTD
statements __MOD_INC_USE_COUNT() and __MOD_DEC_USE_COUNT()
found in various locations with the MTD tree
generate these compile errors:
"structure has no member named `uc'"
"structure has no member named `flags'"

--------------
Version Notes:
--------------
I downloaded via cvs.infradead.org on
July 9, 2001. I placed it into my 2.0.38
uclinux tree and then applied the MTD
supplied patch mtd-uClinux-2.0.38.1pre7.patch.


-----------

David Woodhouse wrote:

> skranz@ridgerun.com said:
> > 1. Anybody know if instruction exist for installing MTD and nftl into
> > an uclinux 2.0.38 tree?
>
> Should work. Probably doesn't. Give me individual instances of places I
> broke the 2.0 compile, preferably with patches, and we'll deal with it.
>
> > 2. I'm interested in getting the SmartMedia slot of this arm7 board
> > working for both read and write -- and I'd like the SmartMedia card to
> > be readable/writable by a Windows machine too. Am I correct that this
> > interoperability constraint will prevent me from using JFFS? I'm
> > assuming that a vfat fs with MTD/nftl will do the trick for me. Yes,
> > no?
>
> You need to implement the SmartMedia translation layer format. It looks like
> there's enough information on the Samsung web site to do that.
>
> > 3. I've been glancing at MTD code and didn't think I saw any logic to
> > deal with the bad (unusable) blocks of a NAND flash device. Did I just
> > miss it?
>
> Done in the SmartMedia translation layer, not in the underlying device
> driver.
>
> --
> dwmw2
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: MTD/mtdblock.c uclinux 2.0.38?

[Herman Oosthuysen]

Hmm, I found the same problems, so I bought a copy of Intel's VFM for $99 to
use instead.  It took 3 weeks to get the source code from Intel, but I now
finally have it.  It is only for use with Intel chips, though it is royalty
free.

----- Original Message -----
From: Steve Kranz <skranz@ridgerun.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: <linux-mtd@lists.infradead.org>; <skranz@ridgerun.com>
Sent: Wednesday, July 11, 2001 1:30 PM
Subject: Re: MTD/mtdblock.c uclinux 2.0.38?


> > uclinux 2.0.38 & MTD?
> > Should work. Probably doesn't. Give me individual
> > instances of places I broke the 2.0 compile, preferably
> > with patches, and we'll deal with it.
>
> Shown below are the problems I encountered when
> attempting to build the latest MTD tree for uclinux
> 2.0.38. For the moment I have suspended efforts to get
> this working under 2.0.38 and would be very interested
> if someone could provide a MTD version or patch that
> will work with that kernel. If so, please let me
> know. Thank you!  :-)
>
> Steve Kranz
> skranz@ridgerun.com
>
> ---------------------------
> My choosen config settings:
> ---------------------------
> CONFIG_MTD=y
> CONFIG_MTD_DEBUG=y
> CONFIG_MTD_DEBUG_VERBOSE=3
> CONFIG_MTD_CHAR=y
> CONFIG_NFTL=y
> CONFIG_NFTL_RW=y
> CONFIG_MTD_NAND=y
>
> ----------------
> Missing Headers:
> ----------------
> MTD depends on these headers which don't exist
> within the uclinux tree.
> linux/slab.h
> linux/spinlock.h
> linux/kmod.h
>
> ---------------
> Other Problems:
> ---------------
> include/linux/mtd/map.h line 65, generates error:
> "field `list' has incomplete type"
>
> Attempts to compile the MTD
> statements __MOD_INC_USE_COUNT() and __MOD_DEC_USE_COUNT()
> found in various locations with the MTD tree
> generate these compile errors:
> "structure has no member named `uc'"
> "structure has no member named `flags'"
>
> --------------
> Version Notes:
> --------------
> I downloaded via cvs.infradead.org on
> July 9, 2001. I placed it into my 2.0.38
> uclinux tree and then applied the MTD
> supplied patch mtd-uClinux-2.0.38.1pre7.patch.
>
>
> -----------
>
> David Woodhouse wrote:
>
> > skranz@ridgerun.com said:
> > > 1. Anybody know if instruction exist for installing MTD and nftl into
> > > an uclinux 2.0.38 tree?
> >
> > Should work. Probably doesn't. Give me individual instances of places I
> > broke the 2.0 compile, preferably with patches, and we'll deal with it.
> >
> > > 2. I'm interested in getting the SmartMedia slot of this arm7 board
> > > working for both read and write -- and I'd like the SmartMedia card to
> > > be readable/writable by a Windows machine too. Am I correct that this
> > > interoperability constraint will prevent me from using JFFS? I'm
> > > assuming that a vfat fs with MTD/nftl will do the trick for me. Yes,
> > > no?
> >
> > You need to implement the SmartMedia translation layer format. It looks
like
> > there's enough information on the Samsung web site to do that.
> >
> > > 3. I've been glancing at MTD code and didn't think I saw any logic to
> > > deal with the bad (unusable) blocks of a NAND flash device. Did I just
> > > miss it?
> >
> > Done in the SmartMedia translation layer, not in the underlying device
> > driver.
> >
> > --
> > dwmw2
> >
> > ______________________________________________________
> > 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: MTD/mtdblock.c uclinux 2.0.38?

[David Woodhouse]

skranz@ridgerun.com said:
> MTD depends on these headers which don't exist within the uclinux
> tree.

Touch them. We can sort out the missing stuff later. You might want slab.h 
to include malloc.h instead of just being empty.


> include/linux/mtd/map.h line 65, generates error: "field `list' has
> incomplete type"

Copy include/linux/list.h from a later kernel.


skranz@ridgerun.com said:
> statements __MOD_INC_USE_COUNT() and __MOD_DEC_USE_COUNT() found in
> various locations with the MTD tree generate these compile errors:
> "structure has no member named `uc'" "structure has no member named
> `flags'" 

Fix the definitions in include/linux/mtd/compatmac.h to match the kernel 
you're using.


--
dwmw2