Closed GoogleCodeExporter closed 8 years ago
Dear Gabor:
Thanks for your report.
I will double check this issue and reply to you in a few days.
Another question, is this issue as same as #14!?
Original comment by penguin.lin
on 19 Jul 2011 at 2:36
[deleted comment]
Could you ignore ecc?
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 4:31
this partition is created by linux os. i mounted an erased mtd partition and
write a text to file with echo command.
the oob part of partition is readed by MEMREADOOB ioctl, so you can see my real
oob layout.
i can attach a file what is dumped by nandread. nandread is a usual tool for
dumping flash with oob area. it's copy the 16 useful bytes of data to the
begining of 64 bytes area and the remains bytes are padded by 0xff.
see line 227:
http://lxr.post-tech.com/source/system/core/toolbox/nandread.c?v=android
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 5:10
Attachments:
Dear Gabor:
Would you also try to use "unspare2" to dump the oob layout of your device?
It is a tool in yaffs2utils used to dump the oob layout.
Thanks for your help.
Original comment by penguin.lin
on 19 Jul 2011 at 5:35
Dear Gabor:
Another question, is this image created by mkyaffs2?
The "unyaffs2" is NOT ready to extract the file content dumped directly from
the NAND device at this moment.
Original comment by penguin.lin
on 19 Jul 2011 at 6:09
My system's nand_ecclayout structure is differ than in your source. eccpos is
256 long.
struct nand_ecclayout {
uint32_t eccbytes;
uint32_t eccpos[256];
uint32_t oobavail;
struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES];
};
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 6:18
Attachments:
so please use mtd-abi.h instead of yaffs2utils_mtd.h if it possible.
//#include "yaffs2utils_mtd.h"
#include <mtd/mtd-abi.h>
but if you want see my oob layout i think this text is much informative for you:
/**
* msm_nand_oob_64 - oob info for 2KB page
*/
static struct nand_ecclayout msm_nand_oob_64 = {
.eccbytes = 40,
.eccpos = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
},
.oobavail = 16,
.oobfree = {
{30, 16},
}
};
Could you ignore whole ecc data?
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 6:23
After I check the unyaffs2 code, ECC info will NOT be used wile extracting the
image in the current version. The comment 2 will only occurred at mkyaffs2.
I found that there are two objects with the same name.
and the data organization may NOT be recognized by "unyaffs2".
Is this image dumped from the NAND device by nandread!?
If it is, I doesn't think unyaffs2 can extract it correctly since it can only
extract file made by mkyaffs2 at the this moment.
Original comment by penguin.lin
on 19 Jul 2011 at 6:42
I'm not sure it's ecc related problem because unyaffs2 is using
yaffs_unpack_tags2_tags_only function from yaffs_packedtags2.c what is don't
check ecc.
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 6:44
Could you extract the content of file if the unrecognized object ignored?
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 6:47
You could see the yaffs2 source on following url if you want any object id or
something.
https://github.com/arco/buzz-kernel-2.6.35/tree/master/fs/yaffs2
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 6:54
Dear Gabor:
For the comment 10: the function "yaffs2_unpack_tags2_tags_only" will only
unpack the tag info without calculating its ECC; another function
"yaffs2_unpack_tags2" will actually calculate it ECC result and unpack its tag.
For the comment 11: in the current implementation, the data origination is
fixed for a file. The data chunks for a object (file) must follow its object
header directly.
For example:
1. If a object header is at offset A;
2. its file content is located at A + (chunk_size + spare_size) to (A +
(chunk_size + spare_size)) + file block size.
If the "unyaffs2" want to support the dynamic image dumped from the NAND
device. it will make lots of changes.
Original comment by penguin.lin
on 19 Jul 2011 at 7:09
Could you drop the unnecessary object header? I see n_bytes is not zero there.
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 7:24
ok i see the second header is the good header after the file data.
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 8:12
At this moment,
"unyaffs2" in "yaffs2utils" does NOT support to extract a image dumped directly
from NAND.
I'm sorry to say that I cannot add this support in a short time.
And this issue will be closed later since this issue is noted in README file.
Original comment by penguin.lin
on 19 Jul 2011 at 9:53
Thanks.
Original comment by gabor.ma...@gmail.com
on 19 Jul 2011 at 9:58
Dear Gabor:
Thanks for your help.
In comment 8, I think your suggestion is right.
I will replace "yaffs2utils_ecc.h" with "mtd/mtd-user.h" in the next release.
Thanks a lot
Original comment by penguin.lin
on 19 Jul 2011 at 10:09
I create a new issue 16 for the runtime image extraction,
and close this one.
Original comment by penguin.lin
on 20 Jul 2011 at 3:48
Original issue reported on code.google.com by
gabor.ma...@gmail.com
on 18 Jul 2011 at 10:48Attachments: