All of lore.kernel.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; 31+ 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] 31+ 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
                     ` (3 more replies)
  0 siblings, 4 replies; 31+ 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] 31+ messages in thread

* Re: HELP
  2001-06-07  9:35 ` HELP David Woodhouse
@ 2001-06-07  9:43   ` Abraham vd Merwe
  2001-06-07 14:30     ` HELP Nicolas Pitre
  2001-06-07  9:44   ` HELP David Woodhouse
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 31+ 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] 31+ 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  9:44   ` David Woodhouse
  2001-06-07  9:47     ` HELP Abraham vd Merwe
                       ` (2 more replies)
  2001-06-07  9:48   ` HELP David Woodhouse
  2001-06-07 14:23   ` HELP Nicolas Pitre
  3 siblings, 3 replies; 31+ 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] 31+ messages in thread

* Re: HELP
  2001-06-07  9:44   ` HELP David Woodhouse
@ 2001-06-07  9:47     ` Abraham vd Merwe
  2001-06-07 17:21     ` HELP Russ Dill
  2001-06-07 20:01     ` HELP David Woodhouse
  2 siblings, 0 replies; 31+ 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] 31+ 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  9:44   ` HELP David Woodhouse
@ 2001-06-07  9:48   ` David Woodhouse
  2001-06-07  9:51     ` HELP Abraham vd Merwe
  2001-06-07 10:16     ` HELP David Woodhouse
  2001-06-07 14:23   ` HELP Nicolas Pitre
  3 siblings, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ messages in thread

* Re: HELP
  2001-06-07  9:48   ` HELP David Woodhouse
  2001-06-07  9:51     ` HELP Abraham vd Merwe
@ 2001-06-07 10:16     ` David Woodhouse
  1 sibling, 0 replies; 31+ 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] 31+ messages in thread

* Re: HELP
  2001-06-07  9:35 ` HELP David Woodhouse
                     ` (2 preceding siblings ...)
  2001-06-07  9:48   ` HELP David Woodhouse
@ 2001-06-07 14:23   ` Nicolas Pitre
  3 siblings, 0 replies; 31+ 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] 31+ messages in thread

* Re: HELP
  2001-06-07  9:43   ` HELP Abraham vd Merwe
@ 2001-06-07 14:30     ` Nicolas Pitre
  0 siblings, 0 replies; 31+ 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] 31+ 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 17:21     ` Russ Dill
  2001-06-07 20:01     ` HELP David Woodhouse
  2 siblings, 0 replies; 31+ 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] 31+ 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 17:21     ` HELP Russ Dill
@ 2001-06-07 20:01     ` David Woodhouse
  2001-06-11 16:04       ` problem with zlib.o Xavier DEBREUIL
  2001-06-12  8:14       ` David Woodhouse
  2 siblings, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ messages in thread

* Re: problem with zlib.o
  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
  1 sibling, 1 reply; 31+ 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] 31+ 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
  2001-06-12 12:19           ` David Woodhouse
  0 siblings, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ messages in thread

* Re: unable to mount jffs2
  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
                               ` (2 more replies)
  1 sibling, 3 replies; 31+ 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] 31+ 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:35             ` David Woodhouse
  2001-06-12 12:36             ` unable to mount jffs2 Xavier DEBREUIL
  2 siblings, 0 replies; 31+ 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] 31+ 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:35             ` David Woodhouse
  2001-06-12 13:56               ` Xavier DEBREUIL
  2001-06-12 12:36             ` unable to mount jffs2 Xavier DEBREUIL
  2 siblings, 1 reply; 31+ 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] 31+ 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:35             ` David Woodhouse
@ 2001-06-12 12:36             ` Xavier DEBREUIL
  2 siblings, 0 replies; 31+ 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] 31+ 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; 31+ 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] 31+ 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
  2001-06-12 15:46                   ` David Woodhouse
  0 siblings, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ 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
  2001-06-12 16:26                     ` Xavier DEBREUIL
  2001-06-12 16:29                     ` David Woodhouse
  1 sibling, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ 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
  2001-06-12 16:38                       ` Xavier DEBREUIL
  2001-06-12 16:43                       ` David Woodhouse
  1 sibling, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ 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
  2001-06-12 17:21                         ` Xavier DEBREUIL
  2001-06-12 21:10                         ` David Woodhouse
  1 sibling, 2 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ 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
  1 sibling, 0 replies; 31+ 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] 31+ messages in thread

* RE: unable to modify jffs2
@ 2001-06-12 15:20 Frederic Giasson
  0 siblings, 0 replies; 31+ messages in thread
From: Frederic Giasson @ 2001-06-12 15:20 UTC (permalink / raw)
  To: 'Xavier DEBREUIL', linux-mtd

Are you sure your erase function ( at command set level ) works properly^

Frédéric Giasson





-----Original Message-----
From: Xavier DEBREUIL [mailto:xde@inventel.fr]
Sent: Tuesday, June 12, 2001 11:19 AM
To: linux-mtd@lists.infradead.org
Subject: unable to modify jffs2


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

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

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

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

Thread overview: 31+ 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 14:30     ` HELP Nicolas Pitre
2001-06-07  9:44   ` HELP David Woodhouse
2001-06-07  9:47     ` HELP Abraham vd Merwe
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: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-12 12:36             ` unable to mount jffs2 Xavier DEBREUIL
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 14:23   ` HELP Nicolas Pitre
2001-06-12 15:20 unable to modify jffs2 Frederic Giasson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.