osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: nandsim and mkyaffs2image problem -
msg#00017

List: linux.file-systems.yaffs

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

On Sunday 18 June 2006 12:26, eq wrote:
> Hi:
> I use mkyaffs2image to make the img,and use the nandsim tool to mount
> it on fake /dev/mtdblock/0,
> but the file is lost.Is there some one comfront the same problem?
> Here is my step :
> mkyaffs2image fsdir yaffs.img
> dd if=yaffs.img of=/dev/mtdblock/0
> mount -t yaffs /dev/mtdblock/0 /mnt/

dd to the nand mtd will not work because it does not handle the oob area
properly. Use mkyaffs for that purpose.

Also, you seem to be mixing yaffs (the original yaffs 1) and yaffs2

If you really want to be using yaffs2, be aware that the mkyaffs2image is just
for guidance only. It will not always work with all mtds due to different oob
placements.

Something like

mkyaffsimage fsdir yaffs.img
mkyaffs /dev/mtdblock/0 yaffs.img
mount -t yaffs /dev/mtdblock/0 /mnt

-- Charles


Thread at a glance:

Previous Message by Date:

nandsim and mkyaffs2image problem

Hi: I use mkyaffs2image to make the img,and use the nandsim tool to mount it on fake /dev/mtdblock/0, but the file is lost.Is there some one comfront the same problem? Here is my step : mkyaffs2image fsdir yaffs.img dd if=yaffs.img of=/dev/mtdblock/0 mount -t yaffs /dev/mtdblock/0 /mnt/ Regards.

Next Message by Date:

Re: yaffs2 on onenand

On Saturday 17 June 2006 01:00, Naushad K wrote: > Hi, > > Did any one tried to use yaffs2 on onenand ? > > When I looked at the onenand_base.c, the oobinfo is as per the > following format. > > > /** > * onenand_oob_64 - oob info for large (2KB) page > */ > static struct nand_oobinfo onenand_oob_64 = { > .useecc = MTD_NANDECC_AUTOPLACE, > .eccbytes = 20, > .eccpos = { > 8, 9, 10, 11, 12, > 24, 25, 26, 27, 28, > 40, 41, 42, 43, 44, > 56, 57, 58, 59, 60, > }, > .oobfree = { > {2, 3}, {14, 2}, {18, 3}, {30, 2}, > {24, 3}, {46, 2}, {40, 3}, {62, 2} } > }; > > > But I have not seen code in onenand_base.c for doing the autoplace > of the yaffs tags into the oobfree area as its there in nand_base.c > > Can the yaffs2 work with current onenand_base.c ? I don't think so. I am not sure about what goes on in the mtd for onenand, but it would have to make the oob free space available. The other problem is that the current yaffs_PackedTags2 requires approx 28 bytes for the tag area. The above only provides 20 bytes. It would be possible to make yaffs work on OneNAND by one of two possible routes: 1) Reduce the size of the packed tags structure to fit. This would require mtd to suport free oob bytes. 2) Use a differeeent chunk layout that places the tags in the page rather than in the oob. This would not require mtd to support free oob bytes. -- Charles

Previous Message by Thread:

nandsim and mkyaffs2image problem

Hi: I use mkyaffs2image to make the img,and use the nandsim tool to mount it on fake /dev/mtdblock/0, but the file is lost.Is there some one comfront the same problem? Here is my step : mkyaffs2image fsdir yaffs.img dd if=yaffs.img of=/dev/mtdblock/0 mount -t yaffs /dev/mtdblock/0 /mnt/ Regards.

Next Message by Thread:

Cannot delete file using Yaffs in ARM linux 2.6.14

Hello All, I am using Linux 2.6.14 kernel on ARM cpu and added Yaffs support. I can mount and umount nand flash using Yaffs file system. However, I receive a kernel bug message if I delete the files on yaffs mtd device. After the error message, I cannot umount the mtd device. What is the root cause? Below is the message: / $ Internal error: Oops: 817 [#1] Modules linked in: CPU: 0 PC is at __bug+0x40/0x54 LR is at 0x1 pc : [<c0029d80>] lr : [<00000001>] Not tainted sp : c1bcdebc ip : 60000093 fp : c1bcdec8 r10: 000a00a8 r9 : c1bcc000 r8 : c1bcdf44 r7 : c384f2b0 r6 : c00227a8 r5 : c04ac168 r4 : 00000000 r3 : 00000000 r2 : 00000000 r1 : 026a6ee7 r0 : 00000001 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user Control: C000717F Table: 328D0000 DAC: 00000015 Process rm (pid: 340, stack limit = 0xc1bcc194) Stack: (0xc1bcdebc to 0xc1bce000) dea0: c1bcdedc dec0: c1bcdecc c0091b40 c0029d50 c36a7000 c1bcdef8 c1bcdee0 c0101064 c0091af0 dee0: c00227a8 c0100ff4 c00227a8 c1bcdf10 c1bcdefc c0092c18 c0101004 c00227a8 df00: c285a000 c1bcdf2c c1bcdf14 c0092cac c0092b98 c00227a8 c285a000 c00227a8 df20: c1bcdf40 c1bcdf30 c0091db0 c0092c9c 00000000 c1bcdfa4 c1bcdf44 c0088aa8 df40: c0091d34 c384f090 c0394c60 643d0b71 0000000c c285a006 00000010 00000000 df60: 00000000 00000000 02c13c00 00000000 449182ff 00000000 44917637 be988f74 df80: 00000000 be988f74 00000000 00000000 0000000a c0025144 00000000 c1bcdfa8 dfa0: c0024fc0 c0088984 be988f74 c002be54 be988f74 00000002 00000000 00000000 dfc0: be988f74 00000000 00000000 00000002 000a0d7c 00000002 000a00a8 0000837c dfe0: 00000000 be988d88 0005cbc0 0007e65c 60000010 be988f74 00000000 00000000 Backtrace: [<c0029d40>] (__bug+0x0/0x54) from [<c0091b40>] (clear_inode+0x60/0xd4) [<c0091ae0>] (clear_inode+0x0/0xd4) from [<c0101064>] (yaffs_delete_inode+0x70/0x84) r4 = C36A7000 [<c0100ff4>] (yaffs_delete_inode+0x0/0x84) from [<c0092c18>] (generic_delete_inode+0x90/0x104) r6 = C00227A8 r5 = C0100FF4 r4 = C00227A8 [<c0092b88>] (generic_delete_inode+0x0/0x104) from [<c0092cac>] (generic_drop_inode+0x20/0x16c) r5 = C285A000 r4 = C00227A8 [<c0092c8c>] (generic_drop_inode+0x0/0x16c) from [<c0091db0>] (iput+0x8c/0xa0) r6 = C00227A8 r5 = C285A000 r4 = C00227A8 [<c0091d24>] (iput+0x0/0xa0) from [<c0088aa8>] (sys_unlink+0x134/0x184) r4 = 00000000 [<c0088974>] (sys_unlink+0x0/0x184) from [<c0024fc0>] (ret_fast_syscall+0x0/0x2c) r8 = C0025144 r7 = 0000000A r6 = 00000000 r5 = 00000000 r4 = BE988F74 Code: 1b004972 e59f0014 eb004970 e3a03000 (e5833000) _______________________________________________ yaffs mailing list yaffs@xxxxxxxxxxxxxxxxxxxxxx http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!