marksalpeter / yaffs2utils

Automatically exported from code.google.com/p/yaffs2utils
GNU General Public License v2.0
0 stars 1 forks source link

can't extract htc buzz wildfire android yaffs2 filesystem flash image dump #15

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I created a filesystem with one file 'hello' with content 'hello'

I can't extract with unyaffs2. Ofcourse i changed the oob layout in 
yaffs2utils_ecc.h:

static struct nand_ecclayout nand_oob_64 = {
        .eccbytes = 0,
        .oobfree = {{.offset = 30, .length = 16}},
};

Unyaffs2 create a hello file but the content of those is bad.

Could you debug it, please?

Original issue reported on code.google.com by gabor.ma...@gmail.com on 18 Jul 2011 at 10:48

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Could you ignore ecc?

Original comment by gabor.ma...@gmail.com on 19 Jul 2011 at 4:31

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
Thanks.

Original comment by gabor.ma...@gmail.com on 19 Jul 2011 at 9:58

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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