[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: Speeding up the mounting of JFFS Device
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> > We have a bit of an issue. The node cache generates an oops when
> > the filesystem to the node cache. After enabling some debugging and
> > adding a few other messages, this is what I get:
> > ...
> > jffs_nc_write_name(): name_offset: 44480
> > jffs_nc_write_name(): filename: fail [c0321e20], off: 44480, size: 4
> > jffs_nc_write_name(): name_offset: 44488
> > jffs_nc_write_name(): filename: <NULL> , off: 44488,
> size: 0
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 00000000
> > current->tss.cr3 = 01cc3000, %cr3 = 01cc3000
> > *pde = 00000000
> > Oops: 0000
> > CPU: 0
> > EIP: 0010:[<c01a7f96>]
> > EFLAGS: 00010202
> > (etc)
> > We're trying to call
> > err = flash_safe_write(mtd, name_offset, (u_char*) f->name, f-
> >nsize+1 );
> > when f->name is null which corresponds to "/"
> > (from dumping out the system's hash table)
> > *** c->hash: "" (ino: 1, pino: 0)
> > Amy
> [ snip...]
> Hi Amy:
> Well, gosh darn it!!! All the builds I did with mkfs.jffs
> never put the root in flash. The virtual root was added
> after the return from jffs_scan_flash(). This meant that
> writing the node cache never hit the above condition.
> How do I get this inode in the flash ? If you can tell me
> I will debug it.
Here's a small little filesystem uuencoded. I dropped it on to flash
(rsync to be precise) and unmounted it, the next time I tried mounting
it read only, it went oops.
begin 644 t.tgz
> In a previous email, you write:
> > There's quite a few oops happening after it starts. What I've been
> > is just doing a head -c 65535 head.bin > /dev/mtd1 after doing an
> > eraseall on the partition and then writing data to it following by
> > mounting it read-only. Presumably the oops is happening in the
> > function
> > flash_safe_write. Is there any chances that tbl_len might be wrong?
> I did not know you could write directly to the device.
> I am assuming that your erasesize is 65536 not 65535.
> You can verify the erasesize in the partition data in
> drivers/mtd/nora.c:: mtds.
> I also noticed "eraseall" only works with char devices. mtdblock
> does not support the ioctl commands for erasing. Is /dev/mtd1 a
> block device or char device ?
> Upon entry to into jffs_scan_flash() the partition must look like
> 0x00000000: 'C' 'A' 'S' 'H' ff ff ff ff ff ff ff ff ff ff ff ff
> 0x00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0x00010000: Real JFFS data structures start here if your
> erasesize is 0x10000 or 65536. That is, the
> image that mkfs.jffs creates.
> How are you downloading your jffs image to the device ?
> Upon exit from jffs_scan_flash() the node cache is filled in.
> Again it is crucial that the partition be completely erased before
> putting in the cache+image.
Here's precisely what I did:
1. eraseall /dev/mtd1
2. head -c 65536 head.bin > /dev/mtd1
-- resulted in error: Invalid ioctl 5401 (MEMGETINFO = 80204d01)
3. mount -t jffs /dev/mtdblock1 <target>
4. put files on <target> -- rsync -xavP <source dir> <target dir>
5. umount <target>
6. mount -r -t jffs /dev/mtdblock1 <target>
I've been able to popular the flash using some trivial examples and then
mount it read only without any problems.
Now, when I try to use mkfs.jffs image using this directory followed by
head -c 65636 jffs_cash.bin > head.bin
cat head.bin jffs_image.bin > jffs_image_cache.bin
cat jffs_image_cache.bin > /dev/mtd1
mount -r -t jffs /dev/mtdblock1 <target>
resulted in the messages finding the nonde cache but was rather unable
to find any data at all.
> I will check my email tomorrow for your response?
The chip that I'm using is sbc mediagx, I'm assuming that an erase size
of 65536 is ok. The struct mtd_info forwhich add_mtd_device uses doesn't
have erasesize set.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com