JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow :(

JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow :(

[Wojciech Kromer]

I have JFFS2 on my 8MBFujitsu Flash Chip connected to MPC850 (50Mhz).
I've decided to have root file system on that flash, but it boots
extremly slow.
It takes about 5 minutes. With compressed initial ram disk on flash it
takes less
than 30s.

Q1 Why?
Q2 I work on mtd-snapshot-20010628.tar.bz2. Are there any speed changes
in furthere releases?


--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow :(

[Russ Dill]

On 28 Aug 2001 13:59:37 +0200, Wojciech Kromer wrote:
> I have JFFS2 on my 8MBFujitsu Flash Chip connected to MPC850 (50Mhz).
> I've decided to have root file system on that flash, but it boots
> extremly slow.
> It takes about 5 minutes. With compressed initial ram disk on flash it
> takes less
> than 30s.
> 
> Q1 Why?
> Q2 I work on mtd-snapshot-20010628.tar.bz2. Are there any speed changes
> in furthere releases?
> 

It will take longer than a ramdisk because of the way jffs2 works, but
it looks like you might not be setting your flash timings

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow :(

[Wojciech Kromer]

>
> It will take longer than a ramdisk because of the way jffs2 works, but
> it looks like you might not be setting your flash timings

Do You mean 'wait wtates' on MPC chip-select configuration?
Or trere are some time settings in MTD?

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow :(

[Russ Dill]

On 29 Aug 2001 08:07:57 +0200, Wojciech Kromer wrote:
> 
> 
> >
> > It will take longer than a ramdisk because of the way jffs2 works, but
> > it looks like you might not be setting your flash timings
> 
> Do You mean 'wait wtates' on MPC chip-select configuration?
> Or trere are some time settings in MTD

I don't know what an "MDC" is, mut whatever changes your bus timings

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

>
> I don't know what an "MDC" is, mut whatever changes your bus timings

I can only change wait-states in ORx (option register in MPC850).
But just mounting jffs2 still takes about 2 min :(

-Are thre any settings in JFFS2 code, or in MTD code?
-Maybe I can enlarge some buffers? But I don't know where.



--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Russ Dill]

On 29 Aug 2001 09:46:13 +0200, Wojciech Kromer wrote:
> >
> > I don't know what an "MDC" is, mut whatever changes your bus timings
> 
> I can only change wait-states in ORx (option register in MPC850).
> But just mounting jffs2 still takes about 2 min :(
> 
> -Are thre any settings in JFFS2 code, or in MTD code?
> -Maybe I can enlarge some buffers? But I don't know where.

jffs2 has to scan the entire medium at mount. Also, if there are
"unformatted" sectors, it erases them (so the first mount will be slower
than subsequent mounts). Did you look at you data sheets and see if that
is as tight as the timing can be?

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[David Woodhouse]

Russ.Dill@asu.edu said:
>  jffs2 has to scan the entire medium at mount. Also, if there are
> "unformatted" sectors, it erases them (so the first mount will be
> slower than subsequent mounts). Did you look at you data sheets and
> see if that is as tight as the timing can be? 

The erase of unclean sectors is done in the background after the mount has 
finished. One day we'll get round to fixing the drivers so that we don't 
busy-wait for erases to complete either.

--
dwmw2

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

>
> The erase of unclean sectors is done in the background after the mount has
> finished. One day we'll get round to fixing the drivers so that we don't
> busy-wait for erases to complete either.

Please anonuce it on the list.

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[David Woodhouse]

krom@dgt-lab.com.pl said:
> > The erase of unclean sectors is done in the background after the mount
> > has finished. One day we'll get round to fixing the drivers so that we
> > don't busy-wait for erases to complete either.

> Please anonuce it on the list. 

It won't make your mount any faster. You have a sane CPU which can handle 
having both a cached and uncached mapping of a physical region - try doing 
that in your map driver (see ocelot.c for inspiration) and see if it helps.

You may also want to investigate burst reads from the flash chips, if your 
hardware is capable of it. 

Another possibility is to work with the people who want XIP so you can give 
the JFFS2 code a direct pointer to the flash chips and avoid the 
out-of-line function calls on every read.


--
dwmw2

RE: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Joakim Tjernlund]

> krom@dgt-lab.com.pl said:
> > > The erase of unclean sectors is done in the background after the mount
> > > has finished. One day we'll get round to fixing the drivers so that we
> > > don't busy-wait for erases to complete either.
>
> > Please anonuce it on the list.
>
> It won't make your mount any faster. You have a sane CPU which can handle
> having both a cached and uncached mapping of a physical region -
> try doing
> that in your map driver (see ocelot.c for inspiration) and see if
> it helps.

Is this(both a cached and uncached mapping)possible on an MPC860?

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[David Woodhouse]

joakim.tjernlund@lumentis.se said:
>  Is this(both a cached and uncached mapping)possible on an MPC860?

Not sure, but I thought so - only Intel make processors which can't do 
that, don't they?

--
dwmw2

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

>
> It won't make your mount any faster. You have a sane CPU which can handle
> having both a cached and uncached mapping of a physical region - try doing
> that in your map driver (see ocelot.c for inspiration) and see if it helps.
>

OK, now I'm testing the ocelot's trick. But I do not understand it.

........................

        ocelot_flash_map.map_priv_1 =
        (unsigned long)ioremap_nocache(FLASH_WINDOW_ADDR, FLASH_WINDOW_SIZE);

        ocelot_flash_map.map_priv_2 =
         (unsigned long)__ioremap(FLASH_WINDOW_ADDR, FLASH_WINDOW_SIZE, 0);

^^^^^^^^ so we have chached version in map_priv_2

..........................


__u8 ocelot_read8(struct map_info *map, unsigned long ofs)
{
        return __raw_readb(map->map_priv_1 + ofs);
}

void ocelot_write8(struct map_info *map, __u8 d, unsigned long adr)
{
        cacheflush = 1;
        __raw_writeb(d, map->map_priv_1 + adr);
        mb();
}

^^^^^ and now we're using uncached version for reading and wrining
!!!!!!!!!!!!!!!!!!!!!!!!! ?????????????????

void ocelot_copy_from_cache(struct map_info *map, void *to, unsigned long from,
ss
{
        if (cacheflush) {
                dma_cache_inv(map->map_priv_2, map->size);
                cacheflush = 0;
        }
        memcpy_fromio(to, map->map_priv_1 + from, len);
}

^^^^^^^ and flushing chache after some writes !!!! ???


Q1 What is cahed version usef for?
Q2 Is it a bug?


--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[David Woodhouse]

krom@dgt-lab.com.pl said:
>  OK, now I'm testing the ocelot's trick. But I do not understand it.

The idea is that read{8,16,32} and write{8,16,32} are used for commands and 
reading status, and should be uncached. copy_from() is used for copying 
data from the flash, and can be cached. We have to flush the cache any 
time a command is sent, because it could be a write or erase command.

This means that we don't get a lot of benefit from storing data in the 
cache for long periods of time (except maybe on read-only flashes), but at 
least we can burst-read to fill a cache line, if the hardware can 
do it.

Flushing the cache on every write cycle to the flash chip may be a little
excessive - perhaps the chip driver itself should have to explicitly flush
the cache when the data are actually likely to change - I'm not sure if
that'd be a win though.

--
dwmw2

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

David Woodhouse wrote:

> krom@dgt-lab.com.pl said:
> >  OK, than You  for understanding it. My hardware dosen't support
> > burst-read
>
> If the kernel is reading from any part of the flash more than once between
> write cycles, you'll see a benefit from that too - and reading a whole
> cache line may improve matters even if it doesn't burst.

But mount time is still the same

sh-2.03# time mount /dev/mtdblock0 /mnt -t jffs2
real    1m55.648s
user    0m0.000s
sys     1m55.630s

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

> But mount time is still the same
>
> sh-2.03# time mount /dev/mtdblock0 /mnt -t jffs2
> real    1m55.648s
> user    0m0.000s
> sys     1m55.630s
>

Do You know any other file-system which give me:
-I can use it as root-fs
-fast reading from flash
-compresion
-writing could be slow

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[David Woodhouse]

krom@dgt-lab.com.pl said:
>  Do You know any other file-system which give me: -I can use it as
> root-fs -fast reading from flash -compresion -writing could be slow

You could use a cramfs root filesystem then mount a small jffs2 partition, 
or just implement checkpointing in JFFS2.

--
dwmw2

RE: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slo w:(

[Jonas Holmberg]

> Does the size of the output from mkcramfs exceed the size of 
> the partition 
> the kernel thinks it's in?

No, mkcramfs says: "Everything: 984 kilobytes"

And the image created is 1007616 bytes (984 * 1024).

/Jonas

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

Jonas Holmberg wrote:

> > Does the size of the output from mkcramfs exceed the size of
> > the partition
> > the kernel thinks it's in?
>
> No, mkcramfs says: "Everything: 984 kilobytes"
>
> And the image created is 1007616 bytes (984 * 1024).
>

OK. Now I have cramfs on one chip and some partitions on second chip.

But writing my user partition (/dev/mtdblock4) destroys data from the
begining of my chip !
What's wrong?

Some logs:

>From kernel booting:
..................................................................................................................................................

JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis
Communications AB.
ATMA Flash 0x800000 at 0x41000000
Filesystem flash: Found 1 x16 devices at 0x0 in 16-bit mode
 Amd/Fujitsu Extended Query Table v1.1 at 0x0040
number of CFI chips: 1
ATMA Flash 0x200000 at 0x40000000
Boot flash: Found 1 x16 devices at 0x0 in 16-bit mode
 Amd/Fujitsu Extended Query Table v1.0 at 0x0040
number of CFI chips: 1
0: offset=0x0,size=0x4000,blocks=1
1: offset=0x4000,size=0x2000,blocks=2
2: offset=0x8000,size=0x8000,blocks=1
3: offset=0x10000,size=0x10000,blocks=31
Creating 4 MTD partitions on "Boot flash":
0x00000000-0x00020000 : "ppcboot"
0x00020000-0x00030000 : "config"
0x00030000-0x00100000 : "kernel"
0x00100000-0x00200000 : "user"


In system:
............................................................................................................................................................

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00800000 00010000 "Filesystem flash"
mtd1: 00020000 00010000 "ppcboot"
mtd2: 00010000 00010000 "config"
mtd3: 000d0000 00010000 "kernel"
mtd4: 00100000 00010000 "user"
# ls -l /dev/mtd*
crw-rw-rw-    1 517      517       90,   0 Sep  5 08:30 /dev/mtd0
crw-r--r--    1 root     root      90,   2 Sep  6 10:02 /dev/mtd1
crw-r--r--    1 root     root      90,   4 Sep  6 11:11 /dev/mtd2
crw-r--r--    1 root     root      90,   6 Sep  6 11:11 /dev/mtd3
crw-r--r--    1 root     root      90,   8 Sep  6 11:11 /dev/mtd4
brw-rw-rw-    1 517      517       31,   0 Sep  5 08:30 /dev/mtdblock0
crw-r--r--    1 root     root      31,   1 Sep  6 09:36 /dev/mtdblock1
brw-r--r--    1 root     root      31,   2 Sep  6 11:12 /dev/mtdblock2
brw-r--r--    1 root     root      31,   3 Sep  6 11:12 /dev/mtdblock3
brw-r--r--    1 root     root      31,   4 Sep  6 11:12 /dev/mtdblock4
crw-rw-rw-    1 517      517       90,   1 Sep  5 08:30 /dev/mtdr0
crw-r--r--    1 root     root      90,   3 Sep  6 10:02 /dev/mtdr1
#


Mounting:

# mount /dev/mtdblock4 /jffs2/
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000:
0x2705 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004:
0x7070 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008:
0x6f6f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c:
0x302e instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010:
0x3320 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014:
0x7567 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018:
0x3920 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000001c:
0x3031 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000020:
0x2030 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024:
0x3333 instead
Further such events for this erase block will not be printed
JFFS2: Erase block at 0x00000000 is not formatted. It will be erased
...

???????????????????  ^^^^^^^^^^^ WHY
??????????????????????????????????????????????
--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[David Woodhouse]

krom@dgt-lab.com.pl said:
>  But writing my user partition (/dev/mtdblock4) destroys data from the
> begining of my chip ! What's wrong? 

Put printk statements in the glue functions which add the offset to the 
write request and pass it along. See if they're adding the correct offset. 

--
dwmw2

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

David Woodhouse wrote:

> krom@dgt-lab.com.pl said:
> >  But writing my user partition (/dev/mtdblock4) destroys data from the
> > begining of my chip ! What's wrong?
>
> Put printk statements in the glue functions which add the offset to the
> write request and pass it along. See if they're adding the correct offset.
>

Which funcion do You mean?

Another msgs:
# dd if=file of=/dev/mtdblock4
588+1 records in
588+1 records out
Last[3] is a79f, datum is 7c60
end_request: I/O error, dev 1f:04 (mtdblock), sector 128
Last[3] is a79f, datum is 7c60
.....

But /dev/mtdblock4 should be1024K (see my prev mail)



--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl

Re: JFFS2 on 8MB Flash-Chip conneted to MPC850 works extremly slow:(

[Wojciech Kromer]

>
> Another msgs:
> # dd if=file of=/dev/mtdblock4
> 588+1 records in
> 588+1 records out
> Last[3] is a79f, datum is 7c60
> end_request: I/O error, dev 1f:04 (mtdblock), sector 128
> Last[3] is a79f, datum is 7c60
> .....
>
> But /dev/mtdblock4 should be1024K (see my prev mail)

Sorry bothering You. This part was a hardware problem.

--
* * * * * * * * * * * *
* per pedes ad astra! *
* * * * * * * * * * * *    mailto:krom@dgt-lab.com.pl