public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* HELP
@ 2001-06-07  9:04 Abraham vd Merwe
  2001-06-07  9:35 ` HELP David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Abraham vd Merwe @ 2001-06-07  9:04 UTC (permalink / raw)
  To: MTD for Linux

[-- Attachment #1: Type: text/plain, Size: 7661 bytes --]

Hi!

I'm busy debugging my chip driver for 28Fxx... chips in LART and I got this
problem with one of my tests:

------------< snip <------< snip <------< snip <------------
root@tinystor:~# ./mtd_debug write 2 6 /dev/zero
MTD_open
MTD_write
flash_write(to = 0x00000002, len = 6)
write_dword(): 0x00000000 <- 0x0000ffff
mtd_debug: Unaligned memory access at pc=0xca005644, lr=0xc001dc08 (bad
address=0xc0135d82, cod)
Internal error: alignment exception: 0
CPU: 0
pc : [<ca005644>]    lr : [<c001dc08>]
sp : c9635f10  ip : c9635f54  fp : c9635f44
r10: c0135d82  r9 : 00000000  r8 : 00000004
r7 : c0135d82  r6 : 00000002  r5 : 00000004  r4 : 00000000
r3 : 00000002  r2 : 00000004  r1 : ca005adc  r0 : ca005ac0
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C075117F  Table: C075117F  DAC: 00000015
Process mtd_debug (pid: 273, stackpage=c9635000)
Code: e59f10c0 e1a02008 (e49a3004) e2455004 eb00020f
Stack:
c9635f00: c001dc08 ca005644 20000013 ffffffff  00000002 00000000 0000ffff
00000006
c9635f20: c0135d80 00000000 00000006 c00116e0  c011bec0 0200d800 c9635f80
c9635f48
c9635f40: ca002648 ca0054b0 c9635f54 c0135d80  00000000 00000002 c00116c0
ffffffea
c9635f60: 00000000 00000006 0200d800 00000004  bfffff30 c9635fac c9635f84
c003f48c
c9635f80: ca0024e4 c00180bc c003ee5c 0200d800  0200d810 20000010 00000002
c0012804
c9635fa0: 00000000 c9635fb0 c0012680 c003f3bc  0200d800 c0018690 00000003
0200d800
c9635fc0: 00000006 ffffffff 0200d800 0200d810  00000006 00000002 00000003
400fe248
c9635fe0: bfffff30 bffffdcc 400abaa0 bffffda8  02000b48 400abaa4 20000010
00000003
Backtrace:
Function entered at [<ca0054a4>] from [<ca002648>]
Function entered at [<ca0024d8>] from [<c003f48c>]
Function entered at [<c003f3b0>] from [<c0012680>]
 r8 = C0012804  r7 = 00000002  r6 = 20000010  r5 = 0200D810
 r4 = 0200D800
Segmentation fault
root@tinystor:~#
------------< snip <------< snip <------< snip <------------

All that the test program in this case is doing is writing 6 bytes starting
at offset 2 in /dev/mtd0 to /dev/mtd0 (damn, this sounds confusing). Here is
the test procedure:

------------< snip <------< snip <------< snip <------------
void file_to_flash (int fd,u_int32_t offset,u_int32_t len,const char
*filename)
{
   u_int8_t *buf;
   FILE *fp;
   int err;
   if (offset != lseek (fd,offset,SEEK_SET))
     {
        perror ("lseek()");
        return;
     }
   if ((buf = (u_int8_t *) malloc (len * sizeof (u_int8_t))) == NULL)
     {
        perror ("malloc()");
        return;
     }
   if ((fp = fopen (filename,"r")) == NULL)
     {
        perror ("fopen()");
        free (buf);
        return;
     }
   if (fread (buf,len,1,fp) != 1 || ferror (fp))
     {
        perror ("fread()");
        free (buf);
        fclose (fp);
        return;
     }
   err = write (fd,buf,len);
   if (err < 0)
     {
        perror ("write()");
        free (buf);
        fclose (fp);
        return;
     }
   free (buf);
   fclose (fp);
   printf ("Copied %d bytes from %s to address 0x%.8x in
flash\n",len,filename,offset);
}
------------< snip <------< snip <------< snip <------------

Above function is called with an open file descriptor to /dev/mtd0, offset =
2, len = 6, and the source file is /dev/zero

As you can see from the fault that occurred, above function obviously
reached the write(), so I doubt there's anything wrong with the function
above (after I can't see anything that might be unaligned in there)

Now the chip driver which is used by /dev/mtd0 is a dummy driver which fakes
the write and just shows you what it would do (hence the write_dword():
0x00000000 <- 0x0000ffff)

Below is the relevant module code:

------------< snip <------< snip <------< snip <------------
static int flash_write (struct mtd_info *mtd,loff_t to,size_t len,size_t
*retlen,const u_char *buf)
{
   __u8 tmp[4];
   int i,n;

#ifdef LART_DEBUG
   printk (KERN_DEBUG "%s(to = 0x%.8x, len = %d)\n",__FUNCTION__,(__u32)
to,len);
#endif

   *retlen = 0;

   /* sanity checks */
   if (!len) return (0);
   if (to + len > mtd->size) return (-EINVAL);

   /* first, we write a 0xFF.... padded byte until we reach a dword boundary
*/
   if (to & (BUSWIDTH - 1))
     {
        __u32 aligned = to & ~(BUSWIDTH - 1);
        int gap = to - aligned;

        i = n = 0;

        while (gap--) tmp[i++] = 0xFF;
        while (len && i < BUSWIDTH) tmp[i++] = buf[n++], len--;
        while (i < BUSWIDTH) tmp[i++] = 0xFF;

        if (!write_dword (aligned,*((__u32 *) tmp))) return (-EIO);

        to += n;
        buf += n;
        *retlen += n;
     }

   /* now we write dwords until we reach a non-dword boundary */
   while (len >= BUSWIDTH)
     {
        if (!write_dword (to,*((__u32 *) buf))) return (-EIO);

        to += BUSWIDTH;
        buf += BUSWIDTH;
        *retlen += BUSWIDTH;
        len -= BUSWIDTH;
     }

   /* top up the last unaligned bytes, padded with 0xFF.... */
   if (len & (BUSWIDTH - 1))
     {
        i = n = 0;

        while (len--) tmp[i++] = buf[n++];
        while (i < BUSWIDTH) tmp[i++] = 0xFF;

        if (!write_dword (to,*((__u32 *) tmp))) return (-EIO);

        *retlen += n;
     }

   return (0);
}

static inline int write_dword (__u32 offset,__u32 x)
{
#ifndef LART_DEBUG
   __u32 status;

   /* setup writing */
   write32 (data_to_flash (PGM_SETUP),offset);

   /* write the data */
   write32 (x,offset);

   /* wait for the write to finish */
   do
     {
        write32 (data_to_flash (STATUS_READ),offset);
        status = flash_to_data (read32 (offset));
     }
   while ((~status & STATUS_BUSY) != 0);

   /* put the flash back into command mode */
   write32 (data_to_flash (READ_ARRAY),offset);

   /* was the write successfull? */
   if ((status & STATUS_PGM_ERR) || read32 (x) != x)
     {
        printk (KERN_WARNING "%s: write error at address
0x%.8x.\n",module_name,offset);
        return (0);
     }
#else
   printk (KERN_DEBUG "%s(): 0x%.8x <- 0x%.8x\n",__FUNCTION__,offset,x);
#endif

   return (1);
}
------------< snip <------< snip <------< snip <------------

LART_DEBUG is of course defined. As you can see from the output, the first
if() was executed successfully and then it crashed in the while loop (at
offset 2, there's a padded word and a dword that needs to be written. The
dword get's caught be the while loop).

What I don't get is why I get an "Unaligned memory access" since all the
data I'm using should be aligned correctly by the compiler. Also a similar
test that tests the dword while loop works perfectly:

------------< snip <------< snip <------< snip <------------
root@tinystor:~# ./mtd_debug write 4 6 /dev/zero
MTD_open
MTD_write
flash_write(to = 0x00000004, len = 6)
write_dword(): 0x00000004 <- 0x00000000
write_dword(): 0x00000008 <- 0xffff0000
Copied 6 MTD_close
bytes from /dev/zero to address 0x00000004 in flash
root@tinystor:~#
------------< snip <------< snip <------< snip <------------

Any help would really be appreciated.

-- 

Regards
 Abraham

Love is never asking why?

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:04 HELP Abraham vd Merwe
@ 2001-06-07  9:35 ` David Woodhouse
  2001-06-07  9:43   ` HELP Abraham vd Merwe
  2001-06-07 14:23   ` HELP Nicolas Pitre
  0 siblings, 2 replies; 30+ messages in thread
From: David Woodhouse @ 2001-06-07  9:35 UTC (permalink / raw)
  To: Abraham vd Merwe; +Cc: MTD for Linux

abraham@2d3d.co.za said:
> mtd_debug: Unaligned memory access at pc=0xca005644, lr=0xc001dc08
> (bad address=0xc0135d82, cod) Internal error: alignment exception: 0

Enable CONFIG_ALIGNMENT_TRAP.

2.4.4-rmk1 or later will force you to do this before you can enable
CONFIG_MTD.

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:35 ` HELP David Woodhouse
@ 2001-06-07  9:43   ` Abraham vd Merwe
  2001-06-07  9:44     ` HELP David Woodhouse
  2001-06-07 14:30     ` HELP Nicolas Pitre
  2001-06-07 14:23   ` HELP Nicolas Pitre
  1 sibling, 2 replies; 30+ messages in thread
From: Abraham vd Merwe @ 2001-06-07  9:43 UTC (permalink / raw)
  To: David Woodhouse; +Cc: MTD for Linux

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

Hi David!

> abraham@2d3d.co.za said:
> > mtd_debug: Unaligned memory access at pc=0xca005644, lr=0xc001dc08
> > (bad address=0xc0135d82, cod) Internal error: alignment exception: 0
> 
> Enable CONFIG_ALIGNMENT_TRAP.
> 
> 2.4.4-rmk1 or later will force you to do this before you can enable
> CONFIG_MTD.

why is this necessary though? The kernel docs make it pretty clear that
enabling that causes severe performance penalties which I wanted to avoid.

-- 

Regards
 Abraham

Everybody is somebody else's weirdo.
		-- Dykstra

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:43   ` HELP Abraham vd Merwe
@ 2001-06-07  9:44     ` David Woodhouse
  2001-06-07  9:47       ` HELP Abraham vd Merwe
                         ` (2 more replies)
  2001-06-07 14:30     ` HELP Nicolas Pitre
  1 sibling, 3 replies; 30+ messages in thread
From: David Woodhouse @ 2001-06-07  9:44 UTC (permalink / raw)
  To: Abraham vd Merwe; +Cc: MTD for Linux

abraham@2d3d.co.za said:
>  why is this necessary though? The kernel docs make it pretty clear
> that enabling that causes severe performance penalties which I wanted
> to avoid. 

Then fix the kernel docs. :)

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:44     ` HELP David Woodhouse
@ 2001-06-07  9:47       ` Abraham vd Merwe
  2001-06-07  9:48       ` HELP David Woodhouse
  2001-06-07 17:21       ` HELP Russ Dill
  2 siblings, 0 replies; 30+ messages in thread
From: Abraham vd Merwe @ 2001-06-07  9:47 UTC (permalink / raw)
  To: David Woodhouse; +Cc: MTD for Linux

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

Hi David!

> abraham@2d3d.co.za said:
> >  why is this necessary though? The kernel docs make it pretty clear
> > that enabling that causes severe performance penalties which I wanted
> > to avoid. 
> 
> Then fix the kernel docs. :)

Hiehiehie.

-- 

Regards
 Abraham

Power corrupts.  And atomic power corrupts atomically.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:44     ` HELP David Woodhouse
  2001-06-07  9:47       ` HELP Abraham vd Merwe
@ 2001-06-07  9:48       ` David Woodhouse
  2001-06-07  9:51         ` HELP Abraham vd Merwe
  2001-06-07 17:21       ` HELP Russ Dill
  2 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-07  9:48 UTC (permalink / raw)
  To: Abraham vd Merwe, MTD for Linux

Seriously, though - if you're doing a driver which is only going to be used
on ARM hardware you may consider using get_unaligned(). Do read the archives
from when we did this for the CFI drivers and subsequently took it out again
though.

I think that might actually have been on the ipaq list. 

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:48       ` HELP David Woodhouse
@ 2001-06-07  9:51         ` Abraham vd Merwe
  2001-06-07 10:16           ` HELP David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Abraham vd Merwe @ 2001-06-07  9:51 UTC (permalink / raw)
  To: David Woodhouse; +Cc: MTD for Linux

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hi David!

> Seriously, though - if you're doing a driver which is only going to be used
> on ARM hardware you may consider using get_unaligned(). Do read the archives
> from when we did this for the CFI drivers and subsequently took it out again
> though.

why did you take it out?

> I think that might actually have been on the ipaq list. 

that helps :P

-- 

Regards
 Abraham

Don't vote -- it only encourages them!

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:51         ` HELP Abraham vd Merwe
@ 2001-06-07 10:16           ` David Woodhouse
  0 siblings, 0 replies; 30+ messages in thread
From: David Woodhouse @ 2001-06-07 10:16 UTC (permalink / raw)
  To: Abraham vd Merwe; +Cc: MTD for Linux


abraham@2d3d.co.za said:
> 
> I think that might actually have been on the ipaq list. 
> that helps :P 

http://www.handhelds.org/pipermail/ipaq/2001-March/004805.html

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:35 ` HELP David Woodhouse
  2001-06-07  9:43   ` HELP Abraham vd Merwe
@ 2001-06-07 14:23   ` Nicolas Pitre
  1 sibling, 0 replies; 30+ messages in thread
From: Nicolas Pitre @ 2001-06-07 14:23 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Abraham vd Merwe, MTD for Linux


On Thu, 7 Jun 2001, David Woodhouse wrote:

>
> abraham@2d3d.co.za said:
> > mtd_debug: Unaligned memory access at pc=0xca005644, lr=0xc001dc08
> > (bad address=0xc0135d82, cod) Internal error: alignment exception: 0
>
> Enable CONFIG_ALIGNMENT_TRAP.
>
> 2.4.4-rmk1 or later will force you to do this before you can enable
> CONFIG_MTD.

2.4.5-rmk*-np* and later kernels unconditionally enable
CONFIG_ALIGNMENT_TRAP for SA1100 architectures without asking you.


Nicolas

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:43   ` HELP Abraham vd Merwe
  2001-06-07  9:44     ` HELP David Woodhouse
@ 2001-06-07 14:30     ` Nicolas Pitre
  1 sibling, 0 replies; 30+ messages in thread
From: Nicolas Pitre @ 2001-06-07 14:30 UTC (permalink / raw)
  To: Abraham vd Merwe; +Cc: David Woodhouse, MTD for Linux


On Thu, 7 Jun 2001, Abraham vd Merwe wrote:

> Hi David!
>
> > abraham@2d3d.co.za said:
> > > mtd_debug: Unaligned memory access at pc=0xca005644, lr=0xc001dc08
> > > (bad address=0xc0135d82, cod) Internal error: alignment exception: 0
> >
> > Enable CONFIG_ALIGNMENT_TRAP.
> >
> > 2.4.4-rmk1 or later will force you to do this before you can enable
> > CONFIG_MTD.
>
> why is this necessary though? The kernel docs make it pretty clear that
> enabling that causes severe performance penalties which I wanted to avoid.

More precisely, _relying_ on it for unaligned access _only_ causes severe
performance penalties.  If you know in advance at compile time that you're
going to make unaligned access to memory then just wrap those with the
get_unaligned()/put_unaligned() macros.  The alignment trap will emulate
unaligned access at run time, with a performance penalty of course, but
still it will work for the rare and unpredictable cases where it might
happen.


Nicolas

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07  9:44     ` HELP David Woodhouse
  2001-06-07  9:47       ` HELP Abraham vd Merwe
  2001-06-07  9:48       ` HELP David Woodhouse
@ 2001-06-07 17:21       ` Russ Dill
  2001-06-07 20:01         ` HELP David Woodhouse
  2 siblings, 1 reply; 30+ messages in thread
From: Russ Dill @ 2001-06-07 17:21 UTC (permalink / raw)
  To: MTD for Linux

On 07 Jun 2001 10:44:12 +0100, David Woodhouse wrote:
> 
> abraham@2d3d.co.za said:
> >  why is this necessary though? The kernel docs make it pretty clear
> > that enabling that causes severe performance penalties which I wanted
> > to avoid. 
> 
> Then fix the kernel docs. :)

I already tried feeding rmk such a patch. The unaligned handly only
impacts performance when there is an unaligned read. So for you, its
good you now know and are working around this. However, some drivers
*cough*jffs2*cough* will make unaligned reads from time to time, but
only rarely. In this case, the handler speeds things up by doing the
access, instead of producing an oops.

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: HELP
  2001-06-07 17:21       ` HELP Russ Dill
@ 2001-06-07 20:01         ` David Woodhouse
  2001-06-11 16:04           ` problem with zlib.o Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-07 20:01 UTC (permalink / raw)
  To: Russ Dill; +Cc: MTD for Linux

Russ.Dill@asu.edu said:
> . However, some drivers *cough*jffs2*cough* will make unaligned reads
> from time to time, but only rarely. In this case, the handler speeds
> things up by doing the access, instead of producing an oops. 

Actually JFFS2 does it quite a lot. I added a byte to the dirent structure 
which means the names get unaligned.

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* problem with zlib.o
  2001-06-07 20:01         ` HELP David Woodhouse
@ 2001-06-11 16:04           ` Xavier DEBREUIL
  2001-06-12  8:14             ` David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-11 16:04 UTC (permalink / raw)
  Cc: linux-mtd

Hello,
I have some problems with linking the mtd stuff with a 2.4.2 kernel on
ARM.
I got many of the followings :

drivers/net/net.o: In function `deflate':
drivers/net/net.o(.text+0x8b38): multiple definition of `deflate'
fs/fs.o(.text+0x63db0):/home/xde/arm_linux/linux_2.4/linux-2.4.2/linux/fs/jffs2/zlib.c:
first defined here
drivers/net/net.o: In function `_tr_flush_block':
drivers/net/net.o(.text+0xba9c): multiple definition of
`_tr_flush_block'
fs/fs.o(.text+0x66d14):/home/xde/arm_linux/linux_2.4/linux-2.4.2/linux/fs/jffs2/zlib.c:
first defined here

what I did is removing from jffs2/Makefile zlib.o in COMPR_OBJS...
and linking is then ok...

Is it a good work around ?

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: problem with zlib.o
  2001-06-11 16:04           ` problem with zlib.o Xavier DEBREUIL
@ 2001-06-12  8:14             ` David Woodhouse
  2001-06-12  9:19               ` problem with util Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-12  8:14 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: linux-mtd

xde@inventel.fr said:
>  what I did is removing from jffs2/Makefile zlib.o in COMPR_OBJS...
> and linking is then ok...

> Is it a good work around ?

JFFS2 uses exactly the same zlib.c as the one in drivers/net - so yes, if 
you're compiling in the latter then you can omit the JFFS2 one. 

In 2.5 we need to sort out zlib properly so it can be shared sanely.


--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* problem with util
  2001-06-12  8:14             ` David Woodhouse
@ 2001-06-12  9:19               ` Xavier DEBREUIL
  2001-06-12 11:36                 ` unable to mount jffs2 Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12  9:19 UTC (permalink / raw)
  Cc: linux-mtd

Hello,
I compiled util for ARM and my computer(INTEL) ;

Is zlib-1.1.3 the right version to link with (ARM) ?
I was compelled to replace every memset calls by loops since __memzero
is not recognized in my system (ARM and INTEL) !!! Known problem ? Any
work around ?

And for my system (INTEL), I add a path to 2.4.2 headers since my system
is 2.2.18...

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* unable to mount jffs2
  2001-06-12  9:19               ` problem with util Xavier DEBREUIL
@ 2001-06-12 11:36                 ` Xavier DEBREUIL
  2001-06-12 12:19                   ` David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 11:36 UTC (permalink / raw)
  To: linux-mtd

I am using mtd-snapshot-20010610

I have made a jffs2 file on my computer ;
loaded it via ftp onto my arm board ;
erased the mtd1 partition : eraseall /dev/mtd1
copy the file in it : cp -a jffs2 /dev/mtd1

tried to mount it :
mount -t jffs2 /dev/mtdblock1 /mnt/jffs2/jffs2_1

and then the system stopped on the following :

/mnt/ramdisk/rd1 # mount -t jffs2 /dev/mtdblock1 /mnt/jffs2/jffs2_1
mtdblock_open
ok
jffs2_scan_empty(): Empty block at 0x0000fffc ends at 0x00010000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0002fffc ends at 0x00030000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0004fffc ends at 0x00050000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0006fffc ends at 0x00070000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x000afffc ends at 0x000b0000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x000efffc ends at 0x000f0000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0010fffc ends at 0x00110000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0012fffc ends at 0x00130000 (with
0xe0021985)! Marking dirty
jffs2_scan_empty(): Empty block at 0x0014fffc ends at 0x00150000 (with
0xe0021985)! Marking dirty


Any help is welcomed.

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to mount jffs2
  2001-06-12 11:36                 ` unable to mount jffs2 Xavier DEBREUIL
@ 2001-06-12 12:19                   ` David Woodhouse
  2001-06-12 12:30                     ` Xavier DEBREUIL
  2001-06-12 12:36                     ` Xavier DEBREUIL
  0 siblings, 2 replies; 30+ messages in thread
From: David Woodhouse @ 2001-06-12 12:19 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: linux-mtd


xde@inventel.fr said:
> jffs2_scan_empty(): Empty block at 0x0000fffc ends at 0x00010000 (with
> 0xe0021985)! Marking dirty

Those are harmless messages telling you that you passed an incorrect '-e' 
option (or no '-e' option) to mkfs.jffs2.

They have no bearing on the failure to mount. What else happened?

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to mount jffs2
  2001-06-12 12:19                   ` David Woodhouse
@ 2001-06-12 12:30                     ` Xavier DEBREUIL
  2001-06-12 12:36                     ` Xavier DEBREUIL
  1 sibling, 0 replies; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 12:30 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

David Woodhouse wrote:
> 
> xde@inventel.fr said:
> > jffs2_scan_empty(): Empty block at 0x0000fffc ends at 0x00010000 (with
> > 0xe0021985)! Marking dirty
> 
> Those are harmless messages telling you that you passed an incorrect '-e'
> option (or no '-e' option) to mkfs.jffs2.
> 
> They have no bearing on the failure to mount. What else happened?
> 
> --
> dwmw2

that is the problem, nothing else happens and I am compelled to reboot...

Xavier (going to see the ftp transfer !!!)

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to mount jffs2
  2001-06-12 12:36                     ` Xavier DEBREUIL
@ 2001-06-12 12:35                       ` David Woodhouse
  2001-06-12 13:56                         ` Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-12 12:35 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: linux-mtd

xde@inventel.fr said:
>  yes, no '-e' option since I want to use the default 64KiB as
> indicated in the help ; is it optional or not ? if not, I will notify
> it in the future.

It's optional. You don't _need_ to specify it if your erase size is larger 
than 64KiB. Yours appears to be 128KiB.




--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to mount jffs2
  2001-06-12 12:19                   ` David Woodhouse
  2001-06-12 12:30                     ` Xavier DEBREUIL
@ 2001-06-12 12:36                     ` Xavier DEBREUIL
  2001-06-12 12:35                       ` David Woodhouse
  1 sibling, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 12:36 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

David Woodhouse wrote:
> 
> xde@inventel.fr said:
> > jffs2_scan_empty(): Empty block at 0x0000fffc ends at 0x00010000 (with
> > 0xe0021985)! Marking dirty
> 
> Those are harmless messages telling you that you passed an incorrect '-e'
> option (or no '-e' option) to mkfs.jffs2.

yes, no '-e' option since I want to use the default 64KiB as indicated in the
help ;
is it optional or not ?
if not, I will notify it in the future.

Xavier

> 
> They have no bearing on the failure to mount. What else happened?
> 
> --
> dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to mount jffs2
  2001-06-12 12:35                       ` David Woodhouse
@ 2001-06-12 13:56                         ` Xavier DEBREUIL
  2001-06-12 15:19                           ` unable to modify jffs2 Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 13:56 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

David Woodhouse wrote:
> 
> xde@inventel.fr said:
> >  yes, no '-e' option since I want to use the default 64KiB as
> > indicated in the help ; is it optional or not ? if not, I will notify
> > it in the future.
> 
> It's optional. You don't _need_ to specify it if your erase size is larger
> than 64KiB. Yours appears to be 128KiB.

Oooops... Sorry, of course, I have two flash in parallel so 2 sectors of
64kbytes means 128kbytes.

for the ftp point of view, I was using ncftp which seems to not work properly on
my system...
netkit-ftp is ok and I can mount the jffs2 now.

Xavier

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

^ permalink raw reply	[flat|nested] 30+ messages in thread

* unable to modify jffs2
  2001-06-12 13:56                         ` Xavier DEBREUIL
@ 2001-06-12 15:19                           ` Xavier DEBREUIL
  2001-06-12 15:31                             ` Martin Gadbois
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 15:19 UTC (permalink / raw)
  To: linux-mtd

I have managed to mount the jffs2 ;
however, it seems that I cannot erase anything or write anything on it

/mnt/jffs2/jffs2_1/bin # df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/ram0                 3963      2997       966  76% /
/dev/ram1                 2011        13      1998   1% /mnt/ramdisk/rd1
/dev/mtdblock1            2048      2048         0 100%
/mnt/jffs2/jffs2_1

/mnt/jffs2/jffs2_1/bin # mount 
/dev/ram0 on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw)
/dev/ram1 on /mnt/ramdisk/rd1 type ext2 (rw)
/dev/mtdblock1 on /mnt/jffs2/jffs2_1 type jffs2 (rw)

I can list, chroot and execute things on the filesystem but no
erasure...
Is there an option I've missed ?

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 15:19                           ` unable to modify jffs2 Xavier DEBREUIL
@ 2001-06-12 15:31                             ` Martin Gadbois
  2001-06-12 15:46                               ` David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Martin Gadbois @ 2001-06-12 15:31 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: linux-mtd

Xavier DEBREUIL wrote:

> I have managed to mount the jffs2 ;
> however, it seems that I cannot erase anything or write anything on it
>
> /mnt/jffs2/jffs2_1/bin # df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/ram0                 3963      2997       966  76% /
> /dev/ram1                 2011        13      1998   1% /mnt/ramdisk/rd1
> /dev/mtdblock1            2048      2048         0 100%
> /mnt/jffs2/jffs2_1
>
> /mnt/jffs2/jffs2_1/bin # mount
> /dev/ram0 on / type ext2 (rw)
> none on /proc type proc (rw)
> none on /dev/pts type devpts (rw)
> /dev/ram1 on /mnt/ramdisk/rd1 type ext2 (rw)
> /dev/mtdblock1 on /mnt/jffs2/jffs2_1 type jffs2 (rw)
>
> I can list, chroot and execute things on the filesystem but no
> erasure...
> Is there an option I've missed ?
>
> Xavier

Your df command says that the filesystem is full to capacity... how many
files do you have in there? What is the result of the du command on /mnt?

--
Martin Gadbois
S/W designer
Colubris Networks (http://www.colubris.com)

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 15:31                             ` Martin Gadbois
@ 2001-06-12 15:46                               ` David Woodhouse
  2001-06-12 16:26                                 ` Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-12 15:46 UTC (permalink / raw)
  To: Martin Gadbois; +Cc: Xavier DEBREUIL, linux-mtd

martin.gadbois@colubris.com said:
>  Your df command says that the filesystem is full to capacity... how
> many files do you have in there? What is the result of the du command
> on /mnt? 

Compile with CONFIG_JFFS2_FS_DEBUG=1. Run 'dmesg'. What does it say?


--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 15:46                               ` David Woodhouse
@ 2001-06-12 16:26                                 ` Xavier DEBREUIL
  2001-06-12 16:29                                   ` David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 16:26 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Martin Gadbois, linux-mtd

David Woodhouse a écrit :
> 
> martin.gadbois@colubris.com said:
> >  Your df command says that the filesystem is full to capacity... how
> > many files do you have in there? What is the result of the du command
> > on /mnt?
> 
> Compile with CONFIG_JFFS2_FS_DEBUG=1. Run 'dmesg'. What does it say?
> 
> --
> dwmw2

I just try to erase the link lib in the following directory

/mnt/jffs2/jffs2_1/usr/arm/arm-linux # rm lib


dmesg returns :

jffs2_reserve_space(): Requested 0x2c bytes
jffs2_reserve_space(): alloc sem got
Short on space, but total dirty size 0x0000002c < sector size
0x00020000, so -ENOSPC


the jffs2 fs is mounted rw :

/mnt/jffs2/jffs2_1/usr/arm/arm-linux # mount
/dev/ram0 on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw)
/dev/ram1 on /mnt/ramdisk/rd1 type ext2 (rw)
/dev/mtdblock1 on /mnt/jffs2/jffs2_1 type jffs2 (rw)


but something is strange since df indicates that there is no space left
on that fs ; but the file I have written on my 2Meg partition was only
1.5Meg
/mnt/jffs2/jffs2_1/usr/arm/arm-linux # df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/ram0                 3963      2997       966  76% /
/dev/mtdblock1            2048      2048         0 100%
/mnt/jffs2/jffs2_1
/dev/ram1                 2011        13      1998   1% /mnt/ramdisk/rd1

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 16:26                                 ` Xavier DEBREUIL
@ 2001-06-12 16:29                                   ` David Woodhouse
  2001-06-12 16:38                                     ` Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-12 16:29 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: Martin Gadbois, linux-mtd

xde@inventel.fr said:
>  jffs2_reserve_space(): Requested 0x2c bytes
>  jffs2_reserve_space(): alloc sem got 
> Short on space, but total dirty size 0x0000002c < sector size 0x00020000, so -ENOSPC 

Looks like your filesystem is too full. You need at least 5 erase blocks 
free. How big was the jffs2 image you put on it?

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 16:29                                   ` David Woodhouse
@ 2001-06-12 16:38                                     ` Xavier DEBREUIL
  2001-06-12 16:43                                       ` David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 16:38 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Martin Gadbois, linux-mtd

David Woodhouse a écrit :
> 
> xde@inventel.fr said:
> >  jffs2_reserve_space(): Requested 0x2c bytes
> >  jffs2_reserve_space(): alloc sem got
> > Short on space, but total dirty size 0x0000002c < sector size 0x00020000, so -ENOSPC
> 
> Looks like your filesystem is too full. You need at least 5 erase blocks
> free. How big was the jffs2 image you put on it?
> 
> --
> dwmw2

In my last email :

  but something is strange since df indicates that there is no space
left
  on that fs ; but the file I have written on my 2Meg partition was only
  1.5Meg
  /mnt/jffs2/jffs2_1/usr/arm/arm-linux # df
  Filesystem           1k-blocks      Used Available Use% Mounted on
  /dev/ram0                 3963      2997       966  76% /
  /dev/mtdblock1            2048      2048         0 100%
  /mnt/jffs2/jffs2_1
  /dev/ram1                 2011        13      1998   1%
/mnt/ramdisk/rd1


So if you say that it needs at least 5 free blocks, it means that I need
5 blocks of 128KB, so at least 650KB free!!!
Is it necessary ?

In fact if this is true, a 2MB partition is to short...

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 16:38                                     ` Xavier DEBREUIL
@ 2001-06-12 16:43                                       ` David Woodhouse
  2001-06-12 17:21                                         ` Xavier DEBREUIL
  0 siblings, 1 reply; 30+ messages in thread
From: David Woodhouse @ 2001-06-12 16:43 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: Martin Gadbois, linux-mtd

xde@inventel.fr said:
> the file I have written on my 2Meg partition was only 1.5Meg

Sorry, I missed that. Too big.

> So if you say that it needs at least 5 free blocks, it means that I
> need 5 blocks of 128KB, so at least 650KB free!!! Is it necessary ?

> In fact if this is true, a 2MB partition is to short... 

At the moment, yes. JFFS2 requires a _lot_ of slack space. Actually it's
probably safe to cut that down to three. Nobody's yet proved that though -
YMMV. Eventually I intend to cut it down to one or two and prove that it's
safe. 


--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 16:43                                       ` David Woodhouse
@ 2001-06-12 17:21                                         ` Xavier DEBREUIL
  2001-06-12 21:10                                           ` David Woodhouse
  0 siblings, 1 reply; 30+ messages in thread
From: Xavier DEBREUIL @ 2001-06-12 17:21 UTC (permalink / raw)
  To: David Woodhouse; +Cc: Martin Gadbois, linux-mtd

David Woodhouse a écrit :
> 
> xde@inventel.fr said:
> > the file I have written on my 2Meg partition was only 1.5Meg
> 
> Sorry, I missed that. Too big.
> 
> > So if you say that it needs at least 5 free blocks, it means that I
> > need 5 blocks of 128KB, so at least 650KB free!!! Is it necessary ?
> 
> > In fact if this is true, a 2MB partition is to short...
> 
> At the moment, yes. JFFS2 requires a _lot_ of slack space. Actually it's
> probably safe to cut that down to three. Nobody's yet proved that though -
> YMMV. Eventually I intend to cut it down to one or two and prove that it's
> safe.
> 
> --
> dwmw2

It seems to work with a 4MB partition.

So, is it possible to define the size of a block inferior to the size of
the erase block ?
For example, erase size is 128KB and block size is 64KB.

Xavier

^ permalink raw reply	[flat|nested] 30+ messages in thread

* Re: unable to modify jffs2
  2001-06-12 17:21                                         ` Xavier DEBREUIL
@ 2001-06-12 21:10                                           ` David Woodhouse
  0 siblings, 0 replies; 30+ messages in thread
From: David Woodhouse @ 2001-06-12 21:10 UTC (permalink / raw)
  To: Xavier DEBREUIL; +Cc: Martin Gadbois, linux-mtd

xde@inventel.fr said:
>  So, is it possible to define the size of a block inferior to the size
> of the erase block ? For example, erase size is 128KB and block size
> is 64KB. 

Absolutely not possible. You cannot erase only a 64KiB region - you _must_ 
erase 128KiB at a time.

Cutting down JFFS2's requirements is possible. It's just a matter of time. 
I'm happy to give you pointers, or it's on my TODO list for attention in 
my Copious Spare Time (tm).

Or talk to my pimp.

--
dwmw2

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2001-06-12 21:07 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-06-07  9:04 HELP Abraham vd Merwe
2001-06-07  9:35 ` HELP David Woodhouse
2001-06-07  9:43   ` HELP Abraham vd Merwe
2001-06-07  9:44     ` HELP David Woodhouse
2001-06-07  9:47       ` HELP Abraham vd Merwe
2001-06-07  9:48       ` HELP David Woodhouse
2001-06-07  9:51         ` HELP Abraham vd Merwe
2001-06-07 10:16           ` HELP David Woodhouse
2001-06-07 17:21       ` HELP Russ Dill
2001-06-07 20:01         ` HELP David Woodhouse
2001-06-11 16:04           ` problem with zlib.o Xavier DEBREUIL
2001-06-12  8:14             ` David Woodhouse
2001-06-12  9:19               ` problem with util Xavier DEBREUIL
2001-06-12 11:36                 ` unable to mount jffs2 Xavier DEBREUIL
2001-06-12 12:19                   ` David Woodhouse
2001-06-12 12:30                     ` Xavier DEBREUIL
2001-06-12 12:36                     ` Xavier DEBREUIL
2001-06-12 12:35                       ` David Woodhouse
2001-06-12 13:56                         ` Xavier DEBREUIL
2001-06-12 15:19                           ` unable to modify jffs2 Xavier DEBREUIL
2001-06-12 15:31                             ` Martin Gadbois
2001-06-12 15:46                               ` David Woodhouse
2001-06-12 16:26                                 ` Xavier DEBREUIL
2001-06-12 16:29                                   ` David Woodhouse
2001-06-12 16:38                                     ` Xavier DEBREUIL
2001-06-12 16:43                                       ` David Woodhouse
2001-06-12 17:21                                         ` Xavier DEBREUIL
2001-06-12 21:10                                           ` David Woodhouse
2001-06-07 14:30     ` HELP Nicolas Pitre
2001-06-07 14:23   ` HELP Nicolas Pitre

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox