|
|
Subject: Re: nandsim and mkyaffs2image problem - msg#00017
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
|
|