Re: DiskOnChip 2000 and CVS Drivers

On Thu, 2003-07-31 at 18:32, Philippe wrote:
> Now I want to use two partitions (there is a similar post but it's
> pretty old and there were no real answer) :
>  - 2Mb (NFTL/EXT2) kernel + initrd.gz (RO)
>  - 30Mb (JFFS/JFFS2) config files, log files etc... (RW)

There _is_ no real answer at the moment. We're working on it though.

The new DiskOnChip translation layer, INFTL, does contain a kind of
partitioning scheme of its own, which makes this kind of thing easier. I
think if we declare a 'binary partition' we should be able to use JFFS2
on it -- we're _supposed_ to have magic stuff in the spare area of each
block but we should be able to omit that since nothing will be actually
checking for it.

So I think what we need to do is make the DiskOnChip/INFTL code register
multiple partitions as separate MTD devices, according to what it finds
in the INFTL media header. 

M-Systems recommend that we use the original (non-partition-capable)
NFTL on the older devices, just as their tools do. I suppose if you're
using JFFS2 then compatibility with the status quo isn't really a
priority for you, so that's not an issue. It may affect the bootstrap
using their BIOS though -- I'm not sure. You may need to use Grub, which
doesn't yet have INFTL support; only NFTL.

> I read (the last two weeks) that setting up JFFS2 on DOC is tricky. 
> I saw several posts (from 2001) with patches to build a
> FAKE_PARTITION_SYSTEM. I wasn't able to set it up with my 2.4.20
> kernel and MTD stuff.

kernel oops due to aligment error in cmdlinepart.c

Greetings,

I've been using the latest MTD CVS (+/- a few days) on an ARM Integrator/CM920T
running linux-2.4.20'ish and have found that cmdlinepart.c has a struct alignment
problem which causes a kernel oops. The attached patch fixes the alignment problem
for me (YMMV : ). I've successfully tested this on an ARM Integrator/CM920T, ADS
Graphics Client Plus and TI Innovator/OMAP1510, FWIW. : )

--
Regards,
George

Index: drivers/mtd/cmdlinepart.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/cmdlinepart.c,v
retrieving revision 1.10
diff -u -r1.10 cmdlinepart.c
--- drivers/mtd/cmdlinepart.c	29 May 2003 09:25:22 -0000	1.10
+++ drivers/mtd/cmdlinepart.c	31 Jul 2003 23:48:20 -0000
 <at>  <at>  -241,6 +241,7  <at>  <at> 
 				&num_parts,	/* out: number of parts */
 				0,		/* first partition */
 				(unsigned char**)&this_mtd, /* out: extra mem */
+				__alignof__(*this_mtd) - 1 +
 				mtd_id_len + 1 + sizeof(*this_mtd));
 		if(!parts)
 		{
 <at>  <at>  -252,7 +253,21  <at>  <at> 

Re: kernel oops due to aligment error in cmdlinepart.c

On Fri, 2003-08-01 at 01:02, George G. Davis wrote:
> Greetings,
> 
> I've been using the latest MTD CVS (+/- a few days) on an ARM
> Integrator/CM920T running linux-2.4.20'ish and have found that
> cmdlinepart.c has a struct alignment problem which causes a kernel
> oops. The attached patch fixes the alignment problem

No Likee. Linux requires that you fix up misaligned loads and stores.
Therefore, explicit working around alignment 'breakage' isn't permitted.
I've added it before and been told to remove it.

IF your hardware _cannot_ do this, and I know some ARM7 uCLinux systems
really can't, then you need to deal with it properly in 2.5 -- talk to
DaveM and Linus about it. 

Alternatively, in this case you could probably just refactor the code to
allocate the idents separately or at least arrange its storage so that
the aligned bits are first, like I think the RedBoot code does.

--

-- 
dwmw2

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

RE : DiskOnChip 2000 and CVS Drivers

Hi,

> I merged some of that code already; all that remains is the fake
> partitioning, and that should be fairly easy to patch in by hand if
you

I checked it today, as you told me I merged the FAKE_PART_CODE.
Everything seems OK (no compilation troubles etc...)

I'll test it next week. If Everything works as expected, i'll send a
diff against [kernel 2.4.20 + cvs / mtd patch]

> want it -- what did you try and in what way did you fail? That's your
> best option for the moment -- use nftl_format with an NFTL size as you
> desire, and hack the doc2000.c code to register a second partition on
> which you use JFFS2.

Well I had troubles using NFTL, let me explain :

I made two partition :
 - 1 - Boot : grub stuff + kernel + initrd + software
 - 2 - Conf/Save : every file wich may be used by my application

Everything was fine except two things :

a) when I turned off the machine -- when I launch the shutdown (via the
app), I do "sync", "umount" and then shutdown -h now -- Nothing was
saved on the DOC (I do not understand because when I use the same kernel
/ stuff on  my hard drive or on a CF/ide, everything is allright)

Re: RE : DiskOnChip 2000 and CVS Drivers

On Fri, 2003-08-01 at 17:02, Philippe wrote:
> I checked it today, as you told me I merged the FAKE_PART_CODE.
> Everything seems OK (no compilation troubles etc...)

OK.

> I'll test it next week. If Everything works as expected, i'll send a
> diff against [kernel 2.4.20 + cvs / mtd patch]

OK, thanks. I probably won't merge it as-is, but it will be useful for
others in the meantime.
> a) when I turned off the machine -- when I launch the shutdown (via the
> app), I do "sync", "umount" and then shutdown -h now -- Nothing was
> saved on the DOC 

Hmmm. That sounds like a problem with the NFTL code. Were there any
error messages at the time this happened?

> b) the sync process is very long (about 30sec)

Some of that could possibly be avoided. See if it still happens with the
current CVS code.

--

-- 
dwmw2

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

Re: hardcoded maximum number of CFI chips - continued

On Thu, 24 July 2003 18:28:31 +0200, andrzej.mialkowski <at> inetia.pl wrote:
> 
> [a lot of code and explanations]

Sorry for the long lag.  Exam period has come up again, the most
irrational timeof the year for me.  But I'm finally reading your code.

Thanks! :)

Jörn

--

-- 
Premature optimization is the root of all evil.
-- Donald Knuth

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

compiling latest CVS

I got the latest CVS to build, but with a few issues.

patches/patchin.sh ran successfully.  Upon building my kernel
modules I got an error in nand.c that 'i' was undeclared.  So in
mtd/drivers/nand/nand.c, line 936 add 'i' to the int declaration.

Now cross-compiling the kernel and modules worked fine.

I sym-linked mtd/util into the kernel source base as instructed
in the README.  Building failed complaining about something in
crc32.h and I realized that it wasn't finding linux/types.h.
I needed to include the linux kernel include directory to get
past this.  Then it failed trying to find zlib.h.  Added that
then it failed to find libz.so.  

The above can all be done without modifying files:

make CROSS=i386-linux- CFLAGS='-I/path/to/kernel/linux-2.4.21/include
-I/path/to/zlib-1.4.1' \
LDFLAGS=-L/path/to/zlib/lib

and everything cross-compiled to my target system.  Was pointing to
the kernel/include directory bad?

-tim

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

RE: compiling latest CVS

oops - that path to 'zlib-1.4.1' should read 'zlib-1.1.4' - hopefully
you got the point.

-tim

> -----Original Message-----
> From: linux-mtd-bounces <at> lists.infradead.org 
> [mailto:linux-mtd-bounces <at> lists.infradead.org] On Behalf Of Tim Drury
> Sent: Friday, August 01, 2003 6:08 PM
> To: linux-mtd <at> lists.infradead.org
> Subject: compiling latest CVS
> 
> 
> 
> I got the latest CVS to build, but with a few issues.
> 
> patches/patchin.sh ran successfully.  Upon building my kernel 
> modules I got an error in nand.c that 'i' was undeclared.  So 
> in mtd/drivers/nand/nand.c, line 936 add 'i' to the int declaration.
> 
> Now cross-compiling the kernel and modules worked fine.
> 
> I sym-linked mtd/util into the kernel source base as 
> instructed in the README.  Building failed complaining about 
> something in crc32.h and I realized that it wasn't finding 
> linux/types.h. I needed to include the linux kernel include 
> directory to get past this.  Then it failed trying to find 
> zlib.h.  Added that then it failed to find libz.so.  
> 

zlib patch doesn't take?

I'm trying to patch my already heavily-patched linux-2.4.18 to use the
mtd snapshot from what looks like May.  After running

  ./patchin.sh -j -c /home/build/linux

and starting a kernel compile (using gcc-3.3) I get the following
error.  Any suggestions?

...snipped from make
output:
/home/dave/C/perforce/source/deschutes/buildroot-M14.0-X225/build_mipsel/staging_dir/bin/mipsel-uclibc-gcc
-I /home/build/linux/include/asm/gcc -D__KERNEL__ -I/home/build/linux/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G
0 -mno-abicalls -fno-pic -mips2 -Wa,--trap -pipe  -DLINUX_RAM_START=0x80100000 
-DKBUILD_BASENAME=zlib  -DEXPORT_SYMTAB -c zlib.c
zlib.c:72: error: `deflate' undeclared here (not in a function)
zlib.c:72: error: initializer element is not constant
zlib.c:72: error: (near initialization for `__ksymtab_deflate.value')
zlib.c:73: error: `deflateInit_' undeclared here (not in a function)
zlib.c:73: error: initializer element is not constant
zlib.c:73: error: (near initialization for `__ksymtab_deflateInit_.value')
zlib.c:74: error: `deflateInit2_' undeclared here (not in a function)
zlib.c:74: error: initializer element is not constant
zlib.c:74: error: (near initialization for `__ksymtab_deflateInit2_.value')
zlib.c:75: error: `deflateEnd' undeclared here (not in a function)
zlib.c:75: error: initializer element is not constant
zlib.c:75: error: (near initialization for `__ksymtab_deflateEnd.value')
zlib.c:76: error: `deflateSetDictionary' undeclared here (not in a function)
zlib.c:76: error: initializer element is not constant
zlib.c:76: error: (near initialization for `__ksymtab_deflateSetDictionary.value')

Re: zlib patch doesn't take?

On Monday 04 August 2003 03:26, David Wuertele wrote:
> I'm trying to patch my already heavily-patched linux-2.4.18 to use the
> mtd snapshot from what looks like May.  After running
>
>   ./patchin.sh -j -c /home/build/linux
>
> and starting a kernel compile (using gcc-3.3) I get the following
> error.  Any suggestions?

zlib.h is obviously not updated.

Can you provide the output of ./patchin.sh ?

--

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

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