* 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
2001-06-07 14:23 ` HELP Nicolas Pitre
0 siblings, 2 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 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; 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: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; 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 9:48 ` HELP David Woodhouse
2001-06-07 17:21 ` HELP Russ Dill
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: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; 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: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; 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 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; 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
0 siblings, 1 reply; 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-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; 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
0 siblings, 1 reply; 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
0 siblings, 1 reply; 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 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; 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:36 ` Xavier DEBREUIL
1 sibling, 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:36 ` Xavier DEBREUIL
2001-06-12 12:35 ` David Woodhouse
1 sibling, 1 reply; 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:36 ` Xavier DEBREUIL
@ 2001-06-12 12:35 ` David Woodhouse
2001-06-12 13:56 ` Xavier DEBREUIL
0 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: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
0 siblings, 1 reply; 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
0 siblings, 1 reply; 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:31 ` Martin Gadbois
@ 2001-06-12 15:46 ` David Woodhouse
2001-06-12 16:26 ` Xavier DEBREUIL
0 siblings, 1 reply; 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
0 siblings, 1 reply; 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 16:26 ` Xavier DEBREUIL
@ 2001-06-12 16:29 ` David Woodhouse
2001-06-12 16:38 ` Xavier DEBREUIL
0 siblings, 1 reply; 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
0 siblings, 1 reply; 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:38 ` Xavier DEBREUIL
@ 2001-06-12 16:43 ` David Woodhouse
2001-06-12 17:21 ` Xavier DEBREUIL
0 siblings, 1 reply; 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
0 siblings, 1 reply; 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 17:21 ` Xavier DEBREUIL
@ 2001-06-12 21:10 ` David Woodhouse
0 siblings, 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: 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; 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:35 ` HELP David Woodhouse
2001-06-07 9:43 ` HELP Abraham vd Merwe
@ 2001-06-07 14:23 ` Nicolas Pitre
1 sibling, 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: 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 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
-- strict thread matches above, loose matches on Subject: below --
2001-06-12 15:20 unable to modify jffs2 Frederic Giasson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox