uboot移植yaffs2写操作问题？
我现在已经移植了yaffs2的nand写操作，有一个问题，就是我再写nand的oob区的时候是将yaffs2镜像的oob数据直接写入还是要通过nand的硬件ecc重新计算ecc覆盖之后再写入呢？ 如果有硬件ecc的话，那么先写后写都可以。但要注意，先写，那么ecc出用0xFF填充，后写时，把oob读出来，计算ecc再写回去，由于nand flash只能把1改成0，因此，原来由于数据，用相同的数据复写oob，不会有问题，原来是0xFF的，用ecc去写，也能把正确的ecc写进去。 lkm_unication 发表于 2013-7-31 09:24 static/image/common/back.gif如果有硬件ecc的话，那么先写后写都可以。但要注意，先写，那么ecc出用0xFF填充，后写时，把oob读出来，计 ...
您好。yaffs2的镜像文件中有自己的oob数据也包括了制作yaffs2镜像工具产生的ecc。我再uboot烧写的时候是直接将这个oob数据写到nand的oob区吗？ lkm_unication 发表于 2013-7-31 09:24 static/image/common/back.gif
如果有硬件ecc的话，那么先写后写都可以。但要注意，先写，那么ecc出用0xFF填充，后写时，把oob读出来，计 ...
还有个问题。就是我可以挂载的时候能会显示lost+found文件，其他文件都没有，然后我创建文件夹，之后重启也可以显示，就是不能显示原来文件是什么原因？ yaffs2 工具在创建yaffs2 image时的ecc，取决于你的nand flash控制器和mtd 底层的实现，如果nand flash控制器有ecc功能，而mtd又是采用硬件算ecc的，那么yaffs2 工具计算的ecc可以忽略，一般最好用0xFF来填充。至于说mount了之后没有文件，首先得保证yaffs2 image的制作是正确的，还有就是在bootloader里烧写yaffs2 image的过程也是正确的，重点就是bootloader是怎样处理ecc的。其实一切都是跟实际情况相关，在一切都不清楚的情况下，我不知道怎么回答你的问题。 lkm_unication 发表于 2013-7-31 13:17 static/image/common/back.gif
yaffs2 工具在创建yaffs2 image时的ecc，取决于你的nand flash控制器和mtd 底层的实现，如果nand flash控制 ...
nand控制器将硬件ecc写到了8,9,10,11,12,13,14,15,
23,24,25,26,27,28,29,30,31，
39,40,41,42,43,44,45,46,47，
55,56,57,58,59,60,61,62,63，
我现在将yaffs2工具中ecc位置调整的和硬件ecc一样了，直接填充0xff。然后使用硬件ecc校验。
struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
struct yaffs_packed_tags2 {
struct yaffs_packed_tags2_tags_only t;
struct yaffs_ecc_other ecc;
};
默认的时候是把上面两个结构体的数据从0开始一次写入的，更改了ecc位置之后，上面结构体位置也要更改。
更改上面结构位置之后kernel中的文件系统需要更改什么吗？（修改之后还是没有原来文件）
是不是只有这个yaffs_packed_tags2_tags_only 结构是有用的数据，我怎么在kernel中查看读到的数据是否正确？ uboot烧写应该没有问题我查看nand中的数据和oob了，是一样的。 是不是kernel中只要正确的解析到struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
这个结构中的数据就可以正确显示文件。 已经被这个问题困扰了好久，无奈采用折中方法，先通过别的方式起Kernel，然后在Kernel里面格式化yaffs2分区 wshini7316 发表于 2013-7-31 17:48 static/image/common/back.gif
nand控制器将硬件ecc写到了8,9,10,11,12,13,14,15,
23,24,25,26,2 ...
nand控制器将硬件ecc写到了8,9,10,11,12,13,14,15,
23,24,25,26,27,28,29,30,31，
39,40,41,42,43,44,45,46,47，
55,56,57,58,59,60,61,62,63，
你的ecc这么离散的？难道使用的是美光带ecc的nand flash？
是不是kernel中只要正确的解析到struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
这个结构中的数据就可以正确显示文件。
没错，yaffs2就只关心这个结构体，必须构造回给yaffs2，Linux里只需修改oob的layout即可，不用修改其他的代码。 lkm_unication 发表于 2013-7-31 19:40 static/image/common/back.gif
nand控制器将硬件ecc写到了8,9,10,11,12,13,14,15,
23,24,25,26,2 ...
我用的是镁光的nand
cpu是imx53，imx53nand控制器就会把ecc放到8,9,10,11,12,13,14,15,
23,24,25,26,27,28,29,30,31，
39,40,41,42,43,44,45,46,47，
55,56,57,58,59,60,61,62,63，
不知道怎么才能改这个位置，但是我看imx53的手册好像就是这样定义的不知道怎么改？ lkm_unication 发表于 2013-7-31 19:40 static/image/common/back.gif
nand控制器将硬件ecc写到了8,9,10,11,12,13,14,15,
23,24,25,26,2 ...
没错，yaffs2就只关心这个结构体，必须构造回给yaffs2，Linux里只需修改oob的layout即可，不用修改其他的代码。
在哪里修改Linux oob的layout，是linux的还是移植的yaffs2文件系统的？ 有几个问题：
1 imx53的nand flash 和yaffs2文件系统的移植是全新的？bsp应该有提供的，为何会突然造成访问不了？
2 美光的nand flash芯片内部有没有硬件ecc？是否使能了或关闭了？
3 layout在driver/mtd/nand/与MCU芯片相关的nand flash driver.c里。
lkm_unication 发表于 2013-8-1 09:00 static/image/common/back.gif
有几个问题：
1 imx53的nand flash 和yaffs2文件系统的移植是全新的？bsp应该有提供的，为何会突然造成访问 ...
我用的是android的bsp是第三方提供的。里面没有对yaffs2文件的支持。uboot和kernel都没有yaffs2文件支持。
ecc校验我用的是mx53 nfc控制器的。
还有一个问题：就是我现在改了struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
这个结构数据在oob区存储的位置，那我的kernel中移植的yaffs2需要怎么更改才能找到我改后的数据。 还有我用的imx53 QSB开发板 干嘛用yaffs2,为什么不考虑ubi文件系统呢？ 有问题总是要解决的啊。 目前我跟踪函数显示读到的data和oob数据，其中data数据没有问题，但是oob的数据根本就不对，好像根本没有去读oob区。
过程：
static int yaffs_tags_marshall_read(struct yaffs_dev *dev,
int nand_chunk, u8 *data,
struct yaffs_ext_tags *tags)-----------------》》》》
static int yaffs_mtd_read(struct yaffs_dev *dev, int nand_chunk,
u8 *data, int data_len,
u8 *oob, int oob_len,
enum yaffs_ecc_result *ecc_result)---------------------》》》》》》》》》
retval = mtd_read_oob(mtd, addr, &ops);-------------------------》》》》》》》》》》》》》》
#define mtd_read_oob(m, addr, pops) (m)->read_oob(m, addr, pops)
不知道这个过程有没有什么问题，为什么调用read_oob函数，而且读到的数据怎么只有dada区而没有oob区？ lkm_unication 发表于 2013-8-1 09:00 static/image/common/back.gif
有几个问题：
1 imx53的nand flash 和yaffs2文件系统的移植是全新的？bsp应该有提供的，为何会突然造成访问 ...
我现在跟踪yaffs2读取data和oob的数据，data数据没有问题，但是oob的数据根本就不对，好像就没有区读oob。
if (dev->param.inband_tags || (data && !tags))
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
NULL, 0,
&ecc_result); else if (tags)//这块会执行，根本就没有去读oob啊？
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
spare_buffer, packed_tags_size,
&ecc_result);
else
BUG();
if (dev->param.inband_tags) {
if (tags) {
struct yaffs_packed_tags2_tags_only *pt2tp;
pt2tp =
(struct yaffs_packed_tags2_tags_only *)
&data;
yaffs_unpack_tags2_tags_only(tags, pt2tp);//这段也会执行，直接将yaffs_packed_tags2_tags_only 结构指向了data后面，可是都没有读数据，这有什么用吗？
} } else if (tags) {
memcpy(packed_tags_ptr, spare_buffer, packed_tags_size);
yaffs_unpack_tags2(tags, &pt, !dev->param.no_tags_ecc);
} 那有没有nand flash的driver？
yaffs2文件系统与底层无关，可以不用修改yaffs2的code；
建议，不要死守android bsp提供的kernel，可用看看标准kernel中mx53的nand flash driver是怎样实现的。 本帖最后由 lkm_unication 于 2013-8-1 12:38 编辑
还有一个问题：就是我现在改了struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
你是怎样修改的？不要人为去修改布局哦，应该通过oob的layout让程序自己去写。
/*
* new oob placement block for use with hardware ecc generation
*/
#ifdef CONFIG_MTD_NAND_AD6900_HWECC
#ifdef MICRON_NAND
static struct nand_ecclayout ad6900_nand_hw_eccoob = {
.eccbytes = 32,
.eccpos = {
8, 9, 10, 11, 12, 13, 14, 15,
24, 25, 26, 27, 28, 29, 30, 31,
40, 41, 42, 43, 44, 45, 46, 47,
56, 57, 58, 59, 60, 61, 62, 63
},
.oobfree = {
{ .offset = 4, .length = 4 },
{ .offset = 20, .length = 4 },
{ .offset = 36, .length = 4 },
{ .offset = 52, .length = 4 },
}
};
#else
static struct nand_ecclayout ad6900_nand_hw_eccoob = {
.eccbytes = 24,
.eccpos = {
40, 41, 42, 43, 44, 45, 46, 47,
48, 49, 50, 51, 52, 53, 54, 55,
56, 57, 58, 59, 60, 61, 62, 63},
.oobfree = {
{.offset = 2,
.length = 38}}
};
#endif
#endif
以上是根据不同nand flash的oob layout，你看看是否有帮助。
顺便提一下，mtd的nand flash driver支持软ecc和硬ecc的，需要告知程序，如：
#ifdef CONFIG_MTD_NAND_AD6900_HWECC
......
chip->ecc.mode = NAND_ECC_HW;
......
#else
nand_debug( "AD6900 MTD NAND ECC SOFT \n");
chip->ecc.mode= NAND_ECC_SOFT;
#endif lkm_unication 发表于 2013-8-1 12:30 static/image/common/back.gif
那有没有nand flash的driver？
yaffs2文件系统与底层无关，可以不用修改yaffs2的code；
建议，不要死守andr ...
nand driver是freescale官方提供的没有问题，mtd分区，jffs2就可以使用。 这样，你看看你的mkyaffs的工具，该工具中，
static void shuffle_oob(char *buf, struct yaffs_packed_tags2 *pt) 是根据oob的layout来填写tag的数据的。该工具是依赖linux kernel中nand flash的实际情况来生产image的。 lkm_unication 发表于 2013-8-1 12:35 static/image/common/back.gif
还有一个问题：就是我现在改了struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
...
kernel中oob区是static struct nand_ecclayout ad6900_nand_hw_eccoob = {
.eccbytes = 32,
.eccpos = {
8, 9, 10, 11, 12, 13, 14, 15,
24, 25, 26, 27, 28, 29, 30, 31,
40, 41, 42, 43, 44, 45, 46, 47,
56, 57, 58, 59, 60, 61, 62, 63
},
.oobfree = {
{ .offset = 4, .length = 4 },
{ .offset = 20, .length = 4 },
{ .offset = 36, .length = 4 },
{ .offset = 52, .length = 4 },
}
};
这样分配的，可是mkyaffs2image工具怎么改成这个结构啊？
他默认的是按顺序一致排下来。 看看mkyaffs2image里的shuffle_oob这个函数，看看其oob是在哪引用的。shuffle_oob在write_chunk里，函数名不一定完全一致。
lkm_unication 发表于 2013-8-1 12:43 static/image/common/back.gif
这样，你看看你的mkyaffs的工具，该工具中，
static void shuffle_oob(char *buf, struct yaffs_packed_tag ...
默认程序是这样：
static void shuffle_oob(char *spareData, struct yaffs_packed_tags2 *pt)
{
assert(sizeof(*pt) <= spareSize);
// NAND LAYOUT: For non-trivial OOB orderings, here would be a good place to shuffle.
memcpy(spareData, pt, sizeof(*pt));
}
我现在就是将这个改成我需要的ecc格式了，可是原来的8.9.10.11.12.13.14.15位放的是struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
这个结构体的数据，不知道这回引起什么问题？ wshini7316 发表于 2013-8-1 12:44 static/image/common/back.gif
kernel中oob区是static struct nand_ecclayout ad6900_nand_hw_eccoob = {
.eccbytes = 32,
...
也就是说，yaffs2的image中，mkyaffsimage的oob的数据不是mx的那个格式咯。那就修改修改。 wshini7316 发表于 2013-8-1 12:49 static/image/common/back.gif
默认程序是这样：
static void shuffle_oob(char *spareData, struct yaffs_packed_tags2 *pt)
{
跟你个mkyaffsimage看看，但该code只支持2Kpage，64byte oob。 lkm_unication 发表于 2013-8-1 12:49 static/image/common/back.gif
也就是说，yaffs2的image中，mkyaffsimage的oob的数据不是mx的那个格式咯。那就修改修改。 ...
默认的时候struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_id;
unsigned chunk_id;
unsigned n_bytes;
};
结构的数据放到了0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,
如果ecc占了8,9,10,11,12,13,14,15,
那我怎么安排这些数据，这里我重新更改了数据的位置，还需要改其他地方吗？ wshini7316 发表于 2013-8-1 12:55 static/image/common/back.gif
默认的时候struct yaffs_packed_tags2_tags_only {
unsigned seq_number;
unsigned obj_ ...
结构的数据放到了0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
第一，0，1是留给bad page作为标识的，不能占用；
第二，通过oob的layout，程序会自动调整，或自己写程序去调整，因为kernel里是通过oob的layout来读取的。 lkm_unication 发表于 2013-8-1 13:00 static/image/common/back.gif
结构的数据放到了0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
第一，0，1是留给bad page作为标识的，不能占 ...
好 我再看看您给我的程序。 lkm_unication 发表于 2013-8-1 13:00 static/image/common/back.gif
结构的数据放到了0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
第一，0，1是留给bad page作为标识的，不能占 ...
还是不行。
我把mkyaffs2image工具照着您给我的那个改了，可以生成yaffs2镜像。
kernel中我也把layout结构按照那个更改了。
效果和原来一样，不知道为什么?
附件是我用的一个yaffs2的源码，您帮我看看有什么问题？
还有就是在源码中有一个patch的文件，里面有个yaffs_mtdif2.c，需要使用这个还是yaffs2目录下的。
wshini7316 发表于 2013-8-1 17:57 static/image/common/back.gif
还是不行。
我把mkyaffs2image工具照着您给我的那个改了，可以生成yaffs2镜像。
kernel中我也把layout结 ...
修改后的mkyaffsimage生成的image是怎样的？我指的是oob。 大概看了一下，围绕yaffs_unpack_tags2展开，跟到yaffs_tags_marshall_read，
else if (tags)
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
spare_buffer, packed_tags_size,
&ecc_result)
可见static int yaffs_mtd_read(struct yaffs_dev *dev, int nand_chunk,
u8 *data, int data_len,
u8 *oob, int oob_len,
enum yaffs_ecc_result *ecc_result)
是研究的重点，看看retval = mtd_read_oob(mtd, addr, &ops); 读取的oob是怎样的架构。
而static int yaffs_mtd_write(struct yaffs_dev *dev, int nand_chunk,
const u8 *data, int data_len,
const u8 *oob, int oob_len)
是oob写的关键。
思路：在写前，先整理好oob，在读后再整理oob，当然mkyaffs2image里也要做好修改。 lkm_unication 发表于 2013-8-1 21:59 static/image/common/back.gif
修改后的mkyaffsimage生成的image是怎样的？我指的是oob。
修改后每16位中0~3没有用，4~7保存那个结构体数据，8~15硬件ecc lkm_unication 发表于 2013-8-1 22:50 static/image/common/back.gif
大概看了一下，围绕yaffs_unpack_tags2展开，跟到yaffs_tags_marshall_read，
else if (tags) ...
好我再跟一下看看读到的是什么数据。 不对啊，那样的话，tag里的ecc结构体保存在哪？
如果不要的话，就需要修改
struct yaffs_dev *dev
dev->param.no_tags_ecc，不要让它计算ecc，否则yaffs2会把ecc填写进oob，从而破坏了oob。 lkm_unication 发表于 2013-8-2 11:27 static/image/common/back.gif
不对啊，那样的话，tag里的ecc结构体保存在哪？
如果不要的话，就需要修改
struct yaffs_dev *dev
哦。
现在yaffs2工具中没用有ecc，直接把他们都写成0xff了。
struct yaffs_dev *dev
dev->param.no_tags_ecc，不要让它计算ecc，否则yaffs2会把ecc填写进oob，从而破坏了oob。
是修改内核中的是吗？ lkm_unication 发表于 2013-8-2 11:27 static/image/common/back.gif
不对啊，那样的话，tag里的ecc结构体保存在哪？
如果不要的话，就需要修改
struct yaffs_dev *dev
还有个问题：
dev->param.inband_tags这个数值是干什么用的？
static int yaffs_tags_marshall_read(struct yaffs_dev *dev,
int nand_chunk, u8 *data,
struct yaffs_ext_tags *tags)
这个函数中
if (dev->param.inband_tags || (data && !tags)){
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
NULL, 0,
&ecc_result);
} else if (tags){
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
spare_buffer, dev->param.spare_bytes_per_chunk,
&ecc_result);//packed_tags_size
} else
BUG();
dev->param.inband_tags这个数值好像一直是1，一直在读data。而没有读oob。
-------------------------------------------------------------------------------------------------------------------------------------------
if (dev->param.inband_tags) {//这个数值为1的时候，读出的就是data区，根本没在其后面跟oob数据，这是什么意思？
if (tags) {
struct yaffs_packed_tags2_tags_only *pt2tp;
pt2tp =
(struct yaffs_packed_tags2_tags_only *)
&data;
yaffs_unpack_tags2_tags_only(tags, pt2tp);
}
} else if (tags) {
memcpy(packed_tags_ptr, spare_buffer, packed_tags_size);
yaffs_unpack_tags2(tags, &pt, !dev->param.no_tags_ecc);
}
---------------------------------------------------------------------------------------------------------------------------------------------
我现在修改了 mtd_read_oob函数可以正确的读到data和oob的数据了。 wshini7316 发表于 2013-8-2 12:21 static/image/common/back.gif
还有个问题：
dev->param.inband_tags这个数值是干什么用的？
你提到的问题，我也是在看yaffs2时才注意到的，按其字面的意思就是读取数据时可以把oob一并读出来，当然，这要nand flash的读操作函数支持。
我刚才提到的ecc是yaffs2文件系统里的。
你最后说读取正确了，那能正常工作了吗？ lkm_unication 发表于 2013-8-2 12:46 static/image/common/back.gif
你提到的问题，我也是在看yaffs2时才注意到的，按其字面的意思就是读取数据时可以把oob一并读出来，当然 ...
这个函数中
/*if (dev->param.inband_tags || (data && !tags)){
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
NULL, 0,
&ecc_result);
} else */if (tags){
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
spare_buffer, dev->param.spare_bytes_per_chunk,
&ecc_result);//packed_tags_size
} else
BUG();
我把上面程序改成上面那样了保证我去读data和oob。
目前通过上述程序读到的data和oob数据是正确的，现在就是添加以下buf到tag结构的转换。 lkm_unication 发表于 2013-8-2 12:46 static/image/common/back.gif
你提到的问题，我也是在看yaffs2时才注意到的，按其字面的意思就是读取数据时可以把oob一并读出来，当然 ...
谢谢您一直的帮助，终于可以挂载了，可以正常使用了。 lkm_unication 发表于 2013-8-2 12:46 static/image/common/back.gif
你提到的问题，我也是在看yaffs2时才注意到的，按其字面的意思就是读取数据时可以把oob一并读出来，当然 ...
还有个问题：android的文件系统中，recovery system data使用什么样的文件格式在nand中？
我将system制作成yaffs2格式，android起来之后挂载没有问题，为什么去在启动的时候挂载到root/system目录下，用于启动，启动就说找不到一些bin文件，而且还显示我挂载成功了。 lkm_unication 发表于 2013-8-2 12:46 static/image/common/back.gif
你提到的问题，我也是在看yaffs2时才注意到的，按其字面的意思就是读取数据时可以把oob一并读出来，当然 ...
我添加oob格式调整的时候，添加如下函数
void nandmtd2_pt2buf(struct yaffs_dev *dev, char *buf, struct yaffs_packed_tags2 *pt, int is_raw)
{
struct mtd_info *mtd = yaffs_dev_to_mtd(dev);
struct nand_chip *this = mtd->priv;
__u8 *ptab = (__u8 *)pt; /* packed tags as bytes */
int i, j = 0, k, n;
//k = this->ecc.layout->oobfree.offset;
//n = this->ecc.layout->oobfree.length;
。
。
。
。
。
}
为什么我使用//k = this->ecc.layout->oobfree.offset;
//n = this->ecc.layout->oobfree.length;
的时候就会报错，error: dereferencing pointer to incomplete type。
是什么原因呢？
我现在改成下面的格式了
k = mtd->ecclayout->oobfree.offset;
n = mtd->ecclayout->oobfree.length;
但是我还是觉得上面的好点。可是就是报错。 本帖最后由 lkm_unication 于 2013-8-2 19:37 编辑
wshini7316 发表于 2013-8-2 17:45 static/image/common/back.gif
谢谢您一直的帮助，终于可以挂载了，可以正常使用了。
还是跟一些freescale的nand flash driver，看看MTD_OOB_AUTO是如何处理的，yaffs2文件系统是不用像现在那样修改的，当然，把那个inband_tag也去掉。
根据你的板子
recovery 是 ramdisk
system 和data是yaffs2
android正常运行时是要把system挂载到root/system目录下的，root是ramdisk；
“用于启动，启动就说找不到一些bin文件” 这个不太明白是什么意思，具体是怎样加载方式？
struct nand_chip *this = mtd->priv这个应该是yaffs2 里没有struct nand_chip的定义。 lkm_unication 发表于 2013-8-2 19:22 static/image/common/back.gif
还是跟一些freescale的nand flash driver，看看MTD_OOB_AUTO是如何处理的，yaffs2文件系统是不用像现在那 ...
我现在用nfs挂载root文件，之后再挂载nand上的system（yaffs2）和data（yaffs2），会出现下面的错误，然后重启。init: cannot open '/initlogo.rle'
yaffs: dev is 32505866 name is "mtdblock10" rw
yaffs: passed flags ""
yaffs: dev is 32505865 name is "mtdblock9" rw
yaffs: passed flags ""
yaffs: dev is 32505867 name is "mtdblock11" rw
yaffs: passed flags ""
init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
init: cannot execve('/system/bin/vold'): Exec format error
init: cannot execve('/system/bin/netd'): Exec format error
init: cannot execve('/system/bin/sh'): Exec format error
init: cannot execve('/system/bin/dispd'): Exec format error
init: cannot execve('/system/bin/servicemanager'): Exec format error
init: cannot execve('/system/bin/debuggerd'): Exec format error
init: cannot execve('/system/bin/installd'): Exec format error
init: untracked pid 2268 exited
init: cannot execve('/system/bin/dbus-daemon'): Exec format error
init: untracked pid 2269 exited
init: cannot execve('/system/bin/wlan_tool'): Exec format error
enabling adb
init: cannot execve('/system/bin/rild'): Exec format error
init: cannot execve('/system/bin/keystore'): Exec format error
init: cannot execve('/system/bin/app_process'): Exec format error
request_suspend_state: on (3->0) at 9846589022 (1970-01-01 00:00:08.165702890 UTC)
init: cannot execve('/system/bin/mediaserver'): Exec format error
init: cannot execve('/system/bin/sh'): Exec format error
init: untracked pid 2318 exited
init: cannot execve('/system/bin/mediaserver'): Exec format error
init: cannot execve('/system/bin/netd'): Exec format error
init: cannot execve('/system/bin/servicemanager'): Exec format error
init: cannot execve('/system/bin/vold'): Exec format error
init: cannot execve('/system/bin/netd'): Exec format error
init: cannot execve('/system/bin/dispd'): Exec format error
init: cannot execve('/system/bin/debuggerd'): Exec format error
init: cannot execve('/system/bin/app_process'): Exec format error
init: cannot execve('/system/bin/dbus-daemon'): Exec format error
init: cannot execve('/system/bin/installd'): Exec format error
init: cannot execve('/system/bin/keystore'): Exec format error
init: cannot execve('/system/bin/rild'): Exec format error
init: cannot execve('/system/bin/mediaserver'): Exec format error
init: cannot execve('/system/bin/sh'): Exec format error
init: untracked pid 2366 exited
init: untracked pid 2367 exited
init: cannot execve('/system/bin/app_process'): Exec format error
init: cannot execve('/system/bin/mediaserver'): Exec format error
request_suspend_state: on (0->0) at 15001221668 (1970-01-01 00:00:13.320335411 UTC)
init: untracked pid 2421 exited
init: cannot execve('/system/bin/mediaserver'): Exec format error
init: cannot execve('/system/bin/netd'): Exec format error
如果我直接把system的文件内容直接cp到root/systm目录下就可以正常启动。然后挂载nand上的system文件也是正常的，不知道为什么会出现上面的错误。
下面是*.rc中的挂载语句
mount yaffs2 /dev/block/mtdblock10 /data
mount yaffs2 /dev/block/mtdblock9 /system
#mount yaffs2 /dev/block/mtdblock9 /system ro remount
mount yaffs2 /dev/block/mtdblock11 /cache nosuid nodev wshini7316 发表于 2013-8-5 09:52 static/image/common/back.gif
我现在用nfs挂载root文件，之后再挂载nand上的system（yaffs2）和data（yaffs2），会出现下面的错误，然 ...
nit: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
init: cannot execve('/system/bin/vold'): Exec format error
init: cannot execve('/system/bin/netd'): Exec format error
init: cannot execve('/system/bin/sh'): Exec format error
init: cannot execve('/system/bin/dispd'): Exec format error
init: cannot execve('/system/bin/servicemanager'): Exec format error
init: cannot execve('/system/bin/debuggerd'): Exec format error
init: cannot execve('/system/bin/installd'): Exec format error
一堆的Exec format error， 先看看这是什么原因引起的。权限？ 执行属性？ 不是for 平台的bin，还是其他。 本帖最后由 wshini7316 于 2013-8-5 17:55 编辑
lkm_unication 发表于 2013-8-5 12:26 static/image/common/back.gif
nit: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
init: cannot execve ...
我的system文件是从源码生成的out文件中考出的，和默认生成的ext4格式的文件是一样，但是我生成的yaffs2格式就是有问题。
权限属性都没有问题啊。
实在是没有头绪，您帮我看看是什么问题。
我看了一下init源码，会调用如下函数
void service_start(struct service *svc, const char *dynamic_args)
此函数中调用如下打印错误信息
if (!dynamic_args) {//dynamic_args = NULL
if (execve(svc->args, (char**) svc->args, (char**) ENV) < 0) {
ERROR("cannot execve('%s'): %s\n", svc->args, strerror(errno));//errno为9 的时候打印上述错误，只有这一处这个格式的打印。
}
} else {
.
.
.
}
wshini7316 发表于 2013-8-5 17:40 static/image/common/back.gif
我的system文件是从源码生成的out文件中考出的，和默认生成的ext4格式的文件是一样，但是我生成的yaffs2 ...
你可以google一下。
以下是我查到的信息：
8 ENOEXEC - Exec format error
Description:
This error indicates that a request has been made to execute a file which, although it has the appropriate permissions, does not start with a valid magic number. A magic number is the first two bytes in a file, used to determine what type of file it is.
Solution:
Possible solutions are:
Check if the program name is correct and if you the correct options are used.
Check your available disk space. Make sure that you do not run out of disk space.
你mkyaffs时，参数是否是正确的？不如大小端等。建议使用android系统里的mkyaffs工具制作yaffs2 image。 建议：把yaffs2 image，在PC里用unyaffs2 image的工具解开，然后用file 查看那些可执行文件的信息。 lkm_unication 发表于 2013-8-6 09:01 static/image/common/back.gif
建议：把yaffs2 image，在PC里用unyaffs2 image的工具解开，然后用file 查看那些可执行文件的信息。 ...
我下载了YAFFS2IMG浏览器 只能查看oob默认格式的。
又下载了unyaffs_src.zip源码生成工具，解压出来的文件有问题。
不知道您有没有好用的unyaffs工具。 lkm_unication 发表于 2013-8-6 09:01 static/image/common/back.gif
建议：把yaffs2 image，在PC里用unyaffs2 image的工具解开，然后用file 查看那些可执行文件的信息。 ...
还有就是我启动起来之后把system文件挂载到/mnt/test目录下，然后运行bin文件夹下的vold程序，出现下面错误。
/mnt/test/bin/vold: 1: Syntax error: word unexpected (expecting ")") wshini7316 发表于 2013-8-6 17:53 static/image/common/back.gif
还有就是我启动起来之后把system文件挂载到/mnt/test目录下，然后运行bin文件夹下的vold程序，出现下面错 ...
Looks like you didn't set executable bits on vold executable, and shell tries to parse it as a shell script.
我的unyaffs2工具也是从网上下的,你修改过mkyaffs2image,那当然也得修改unyaffs2咯. lkm_unication 发表于 2013-8-6 22:41 static/image/common/back.gif
Looks like you didn't set executable bits on vold executable, and shell tries to parse it as a she ...
我用默认的oob格式生成的yaffs2镜像，通过默认的unyaffs解压出来的也有问题，主要是二进制文件一般只有4k大小，实际比这个大，还有就是shell脚本也不能打开，其他文本类的都正确。
修改unyaffs中oob格式之后得到的结论和上面是一样的。 lkm_unication 发表于 2013-8-6 22:41 static/image/common/back.gif
Looks like you didn't set executable bits on vold executable, and shell tries to parse it as a she ...
明天我再看看权限和属性的问题。
我在开发板上挂载之后看到的bin文件的大小和实际的是一样的。 本帖最后由 lkm_unication 于 2013-8-7 09:11 编辑
wshini7316 发表于 2013-8-6 23:06 static/image/common/back.gif
我用默认的oob格式生成的yaffs2镜像，通过默认的unyaffs解压出来的也有问题，主要是二进制文件一般只有4k ...
你用的mkyaffs2image的工具是在哪里编译的？ android源码树？ 还是yaffs2 文件系统的tools里？
传给mkyaffs2image的参数是什么？
现在看来，是yaffs2的image制作时有问题。
建议不要修改mkyaffs2image工具，就让其生产标准的oob，自己编写软件，yaffs2 image的oob读出来，重新布局，再写回image文件。 lkm_unication 发表于 2013-8-7 09:09 static/image/common/back.gif
你用的mkyaffs2image的工具是在哪里编译的？ android源码树？ 还是yaffs2 文件系统的tools里？
传给mkya ...
我用的是yaffs2文件系统中的。
传给mkyaffs2image的参数是：
mkyaffs2image 源文件镜像文件
我用默认的程序生成mkyaffs工具，然后生成的镜像文件使用 YAFFS2IMF 浏览器查看就是正确的，但是用unyaffs源码生成的工具解压就有问题。
生成的默认镜像应该没有问题，就是unyaffs源码不知道为什么解压出来的就不对。 lkm_unication 发表于 2013-8-7 09:09 static/image/common/back.gif
你用的mkyaffs2image的工具是在哪里编译的？ android源码树？ 还是yaffs2 文件系统的tools里？
传给mkya ...
我现在做了如下测试：
1.yaffs2源码生成mkyaffs2image工具，制作镜像文件，可以用网上下载的YAFFS2浏览器工具查看导出。
2.自己编写程序将上面可用的镜像文件中的oob修改成所需要的格式。
启动挂载之后的现象一样
还进行了如下测试：
将android使用kernel中的yaffs2文件系统移植到原来直接linux启动的kernel中，nand分区一样。
在linux的根文件系统中挂载yaffs2格式的system文件，可以正常挂载显示文件，
然后我将system文件下bin目录中的读出，放到xp下查看，发现所有的二进制文件都有问题，其中vold中内容变成了全0，所有elf格式的头都没有了。
还有shell文本也不正确。
用上面修改的镜像也得到同样的结果。
是不是挂载读文件的时候读到的数据有问题。 lkm_unication 发表于 2013-8-7 09:09 static/image/common/back.gif
你用的mkyaffs2image的工具是在哪里编译的？ android源码树？ 还是yaffs2 文件系统的tools里？
传给mkya ...
下面是我写该的内容：
static struct nand_oobinfo micron_oob_layout = {
.useecc = MTD_NANDECC_AUTOPLACE,
.eccbytes = 32,
.eccpos = {
8, 9, 10, 11, 12, 13, 14, 15,
24, 25, 26, 27, 28, 29, 30, 31,
40, 41, 42, 43, 44, 45, 46, 47,
56, 57, 58, 59, 60, 61, 62, 63
},
.oobfree = {
{ 4,4 },
{ 20, 4 },
{ 36, 4 },
{ 52, 4 },
},
};
#define PT2_BYTES (16)
void nandmtd2_pt2buf(struct yaffs_dev *dev, char *buf, struct yaffs_packed_tags2 *pt, int is_raw)
{
struct mtd_info *mtd = yaffs_dev_to_mtd(dev);
struct nand_chip *this = mtd->priv;
__u8 *ptab = (__u8 *)pt; /* packed tags as bytes */
int i, j = 0, k, n;
//k = this->ecc.layout->oobfree.offset;
//n = this->ecc.layout->oobfree.length;
/* Pack buffer with 0xff */
for (i = 0; i < mtd->oobsize; i++)
buf = 0xff;
if(!is_raw){
memcpy(buf,pt,sizeof(struct yaffs_packed_tags2));
} else {
j = 0;
k = mtd->ecclayout->oobfree.offset;
n = mtd->ecclayout->oobfree.length;
if (n == 0) {
yaffs_trace(YAFFS_TRACE_MTD,"No space in OOB for tags");
BUG();
}
for (i = 0; i < PT2_BYTES; i++) {
if (n == 0) {
j++;
k = mtd->ecclayout->oobfree.offset;
n = mtd->ecclayout->oobfree.length;
if (n == 0) {
yaffs_trace(YAFFS_TRACE_MTD,"No space in OOB for tags");
BUG();
}
}
buf = ptab;
k++;
n--;
}
}
}
void nandmtd2_buf2pt(struct yaffs_dev *dev, char *buf, struct yaffs_packed_tags2 *pt, int is_raw)
{
struct mtd_info *mtd = yaffs_dev_to_mtd(dev);
struct nand_chip *this = mtd->priv;
int i, j = 0, k, n;
__u8 *ptab = (__u8 *)pt; /* packed tags as bytes */
if (!is_raw) {
memcpy(pt,buf,sizeof(struct yaffs_packed_tags2));
} else {
j = 0;
k = mtd->ecclayout->oobfree.offset;
n = mtd->ecclayout->oobfree.length;
if (n == 0) {
yaffs_trace(YAFFS_TRACE_MTD,"No space in OOB for tags");
BUG();
}
for (i = 0; i < PT2_BYTES; i++) {
if (n == 0) {
j++;
k = mtd->ecclayout->oobfree.offset;
n = mtd->ecclayout->oobfree.length;
if (n == 0) {
yaffs_trace(YAFFS_TRACE_MTD,"No space in OOB for tags");
BUG();
}
}
ptab = buf;
k++;
n--;
}
}
}
static int yaffs_tags_marshall_write(struct yaffs_dev *dev,
int nand_chunk, const u8 *data,
const struct yaffs_ext_tags *tags)
{
struct yaffs_packed_tags2 pt;
int retval;
u8 spare_buffer;
int packed_tags_size =
dev->param.no_tags_ecc ? sizeof(pt.t) : sizeof(pt);
void *packed_tags_ptr =
dev->param.no_tags_ecc ? (void *)&pt.t : (void *)&pt;
yaffs_trace(YAFFS_TRACE_MTD,
"yaffs_tags_marshall_write chunk %d data %p tags %p",
nand_chunk, data, tags);
/* For yaffs2 writing there must be both data and tags.
* If we're using inband tags, then the tags are stuffed into
* the end of the data buffer.
*/
if (!data || !tags)
BUG();
else if (dev->param.inband_tags) {
struct yaffs_packed_tags2_tags_only *pt2tp;
/* xgl mask begin */
//pt2tp =
// (struct yaffs_packed_tags2_tags_only *)(data +
// dev->
// data_bytes_per_chunk);
/* xgl mask end */
pt2tp = (struct yaffs_packed_tags2_tags_only *)&(pt.t);
yaffs_pack_tags2_tags_only(pt2tp, tags);
} else {
yaffs_pack_tags2(&pt, tags, !dev->param.no_tags_ecc);
}
nandmtd2_pt2buf(dev, spare_buffer, &pt, 1);/* add by xgl */
/* xgl mask begin */
//retval = dev->drv.drv_write_chunk_fn(dev, nand_chunk,
// data, dev->param.total_bytes_per_chunk,
// (dev->param.inband_tags) ? NULL : packed_tags_ptr,
// (dev->param.inband_tags) ? 0 : packed_tags_size);
/* xgl mask end */
/* xgl add begin */
retval = dev->drv.drv_write_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
spare_buffer, dev->param.spare_bytes_per_chunk);
/* xgl add end */ return retval;
}
static int yaffs_tags_marshall_read(struct yaffs_dev *dev,
int nand_chunk, u8 *data,
struct yaffs_ext_tags *tags)
{
int retval = 0;
int local_data = 0;
u8 spare_buffer;
enum yaffs_ecc_result ecc_result;
struct yaffs_packed_tags2 pt;
int packed_tags_size =
dev->param.no_tags_ecc ? sizeof(pt.t) : sizeof(pt);
void *packed_tags_ptr =
dev->param.no_tags_ecc ? (void *)&pt.t : (void *)&pt;
yaffs_trace(YAFFS_TRACE_MTD,
"yaffs_tags_marshall_read chunk %d data %p tags %p",
nand_chunk, data, tags);
if (dev->param.inband_tags) {
if (!data) {
local_data = 1;
data = yaffs_get_temp_buffer(dev);
}
}
/* xgl mask begin */
/*if (dev->param.inband_tags || (data && !tags)){
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
NULL, 0,
&ecc_result);
} else */
/* xgl mask end */
if (tags){
/* xgl mask begin */
//retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
// data, dev->param.total_bytes_per_chunk,
// spare_buffer, packed_tags_size,
// &ecc_result);
/* xgl mask end */
/* xgl add begin */
retval = dev->drv.drv_read_chunk_fn(dev, nand_chunk,
data, dev->param.total_bytes_per_chunk,
spare_buffer, dev->param.spare_bytes_per_chunk,
&ecc_result);
/* xgl add end */ } else
BUG();
if (dev->param.inband_tags) {
if (tags) {
struct yaffs_packed_tags2_tags_only *pt2tp;
/* xgl mask begin */
//pt2tp =
// (struct yaffs_packed_tags2_tags_only *)
// &data;
/* xgl mask end */
/* xgl add begin */
pt2tp = (struct yaffs_packed_tags2_tags_only *)&(pt.t);
nandmtd2_buf2pt(dev, spare_buffer, &pt, 1);
/* xgl add end */
yaffs_unpack_tags2_tags_only(tags, pt2tp);
}
} else if (tags) {
printk("*******************************************");
memcpy(packed_tags_ptr, spare_buffer, packed_tags_size);
yaffs_unpack_tags2(tags, &pt, !dev->param.no_tags_ecc);
}
if (local_data)
yaffs_release_temp_buffer(dev, data);
if (tags && ecc_result == YAFFS_ECC_RESULT_UNFIXED) {
tags->ecc_result = YAFFS_ECC_RESULT_UNFIXED;
dev->n_ecc_unfixed++;
}
if (tags && ecc_result == -YAFFS_ECC_RESULT_FIXED) {
if (tags->ecc_result <= YAFFS_ECC_RESULT_NO_ERROR)
tags->ecc_result = YAFFS_ECC_RESULT_FIXED;
dev->n_ecc_fixed++;
}
if (ecc_result < YAFFS_ECC_RESULT_UNFIXED)
return YAFFS_OK;
else
return YAFFS_FAIL;
} wshini7316 发表于 2013-8-7 12:25 static/image/common/back.gif
我现在做了如下测试：
1.yaffs2源码生成mkyaffs2image工具，制作镜像文件，可以用网上下载的YAFFS2浏览器 ...
unyaffs也应该是有参数的，比如page size，oob size，大小端等。
一步步来，先用mkyaffs2image，把一个文件制作成yaffs2 image，然后用二进制查看器，看看其文件的内容是否与原文件一致，如果image没有问题，那么问题就在linux那边，可以把yaffs2文件系统读取的内容打印出来，看看问题出在哪。 lkm_unication 发表于 2013-8-7 12:32 static/image/common/back.gif
unyaffs也应该是有参数的，比如page size，oob size，大小端等。
一步步来，先用mkyaffs2image，把一个 ...
现在unyaffs可以将我制作的镜像解压出来了。
unyaffs中有参数已经设好如下：
#define CHUNK_SIZE 2048
#define SPARE_SIZE 64
我将int process_chunk()函数中：做如下更改
//s = (remain < pt->t.byteCount) ? remain : pt->t.byteCount;
s = (remain < (CHUNK_SIZE)) ? remain : (CHUNK_SIZE);
pt->t.byteCount 不知道表示什么含义？
这样改完之后就可以解压看我自己制作的镜像了，文件没有问题。
这样看来还是我再kernel中添加的yaffs2文件系统源码有问题了。
lkm_unication 发表于 2013-8-7 12:32 static/image/common/back.gif
unyaffs也应该是有参数的，比如page size，oob size，大小端等。
一步步来，先用mkyaffs2image，把一个 ...
我在static int yaffs_mtd_read(struct yaffs_dev *dev, int nand_chunk,
u8 *data, int data_len,
u8 *oob, int oob_len,
enum yaffs_ecc_result *ecc_result)
函数中打印nand_chunk、dev->param.total_bytes_per_chunk、addr
结果显示如下：
nand_chunk = 0---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 64---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 128---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 192---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 256---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 320---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 384---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 448---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 512---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 576---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 640---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 704---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 768---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 832---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 896---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 960---dev->param.total_bytes_per_chunk = 2048
nand_chunk = 1024---dev->param.total_bytes_per_chunk = 2048
.
.
.
.
.
每次读函数只是读取了一块中第一个页的数据。
这会是什么原因？
chunk在yaffs2中不就是page吗？
lkm_unication 发表于 2013-8-7 12:32 static/image/common/back.gif
unyaffs也应该是有参数的，比如page size，oob size，大小端等。
一步步来，先用mkyaffs2image，把一个 ...
我在网上看到如下资料，不知说的对不对。
扫描整个挂载设备的所有nand页。这一步是整个yaffs_mount的核心，下面我把这一步的工作分成几部分来叙述。
a) 扫描的工作会分成块扫描和页扫描两个层次来进行。
b) 首先进行块扫描，检查是否是坏块，如果是坏块，直接跳过页扫描步骤，进行下一块的扫描。
c) 如果块扫描的结果是好块，将进入页扫描步骤。页扫描将对一块的32页进行分析。通过读取每一页的oob区（也就是最后的16个字节）来判断这一页属于什么类型，基本的类型可以分为：已删除页，未使用页，数据页面，头页面。
如果上面说的正确的话，我是不是只更改了块扫描的部分。
那页扫描是在哪里进行的呢？
yaffs_tags_marshall_read
yaffs_tags_marshall_write 这两个函数是不是只是进行了块的扫描？ wshini7316 发表于 2013-8-7 17:46 static/image/common/back.gif
我在网上看到如下资料，不知说的对不对。
扫描整个挂载设备的所有nand页。这一步是整个yaffs_mount的核心 ...
你现在问的问题已经很深入yaffs2文件系统了，我对这方面也是一无所知，也是空白的，这只能靠你自己去摸索了。
建议：
1 在板子的linux系统里，用flash_eraseall将NAND FLASH分区擦除，然后做为yaffs2分区直接mount上来，相当于你在开发板上把一个分区"格式化"成yaffs2格式，然后把文件copy到该分区，看看是否正常；
2 制作只有一个文件的yaffs2 image，在板子的linux系统里测试； http://blog.csdn.net/stephen_yu/article/details/6546124
只看是不是yaffs2版本的问题，还有就是yaffs2的编译选项，至于他说的软件ECC，你就用你的硬件ECC即可。 lkm_unication 发表于 2013-8-7 19:07 static/image/common/back.gif
你现在问的问题已经很深入yaffs2文件系统了，我对这方面也是一无所知，也是空白的，这只能靠你自己去摸索 ...
我上午测试了直接将分区挂载成yaffs2格式，然后将system中文件cp到分区上，启动可以正常加载，没有问题。
这是什么原因呢？
为什么我制作的镜像可以用unyaffs解开，但是挂载之后有问题？
为什么直接cp的文件就能用，这与上面的镜像有什么区别？
lkm_unication 发表于 2013-8-7 19:07 static/image/common/back.gif
你现在问的问题已经很深入yaffs2文件系统了，我对这方面也是一无所知，也是空白的，这只能靠你自己去摸索 ...
还有我查看yaffs2源代码，这个函数是不是进行mount时候扫描的。
static inline int yaffs2_scan_chunk(struct yaffs_dev *dev,
struct yaffs_block_info *bi,
int blk, int chunk_in_block,
int *found_chunks,
u8 *chunk_data,
struct list_head *hard_list,
int summary_available)
而我设置打印信息在函数中，可这个函数都没有被执行。不知什么原因。还在分析中。 wshini7316 发表于 2013-8-8 12:20 static/image/common/back.gif
我上午测试了直接将分区挂载成yaffs2格式，然后将system中文件cp到分区上，启动可以正常加载，没有问题。 ...
系统自己做的能识别，你帮他做好的却不能识别。你看看系统自己在oob里都是怎么不局的，都有些什么内容？ wshini7316 发表于 2013-8-8 12:23 static/image/common/back.gif
还有我查看yaffs2源代码，这个函数是不是进行mount时候扫描的。
static inline int yaffs2_scan_chunk(st ...
你可以尝试着，先umount，在mount，看看是否被执行。 lkm_unication 发表于 2013-8-8 12:39 static/image/common/back.gif
你可以尝试着，先umount，在mount，看看是否被执行。
yaffs2文件系统在第一次挂载的时候会执行扫描函数，然后建立一个什么东西，没看太明白，checkpointed表示是否能正确读取这个结构。
我现在把程序改了一下让他每次挂载都去重新扫描。就可以每次挂载的时候都执行上面的程序了。 lkm_unication 发表于 2013-8-8 12:38 static/image/common/back.gif
系统自己做的能识别，你帮他做好的却不能识别。你看看系统自己在oob里都是怎么不局的，都有些什么内容？ ...
我查看了cp过来的分区中oob的格式和我使用的是一样。 lkm_unication 发表于 2013-8-8 12:39 static/image/common/back.gif
你可以尝试着，先umount，在mount，看看是否被执行。
现在有这个情况，我发现如果这个文件小于1.4kbytes就可以挂载之后正常显示。
当大于1.4kbytes的时候，使用vi命令查看的时候只会显示文件最后的一段内容，前面就显示乱码。
文件挂载之后的大小和原始文件一样。
是不是我再挂载之后建立文件的时候，没有把所有的数据都读过来啊?
只是读取了结尾的一段，所以导致前面显示乱码，而且文件大小还是正确的？
wshini7316 发表于 2013-8-8 17:47 static/image/common/back.gif
现在有这个情况，我发现如果这个文件小于1.4kbytes就可以挂载之后正常显示。
当大于1.4kbytes的时候，使 ...
建立文件是什么意思？
像linux这些大型的系统，其文件的操作都是有缓存的，需要通过sync同步命令，或umount卸载后，才能保证数据同步到存储设备里。 lkm_unication 发表于 2013-8-8 19:01 static/image/common/back.gif
建立文件是什么意思？
像linux这些大型的系统，其文件的操作都是有缓存的，需要通过sync同步命令，或umo ...
我是说，在mount yaffs2文件的时候，他不是要扫描所有的nand块吗？然后建立文件树。以及文件和数据直接的关系吗？
这个文件和数据是怎么关联到一起的呢？
是不是我关联到的文件数据有问题，所有我只能正确读取1.4kbytes的文件？ wshini7316 发表于 2013-8-9 09:46 static/image/common/back.gif
我是说，在mount yaffs2文件的时候，他不是要扫描所有的nand块吗？然后建立文件树。以及文件和数据直接 ...
文件与数据的关联应该是在page的内容里的，如果page的内容是正确的，那不应该有问题。 本帖最后由 wshini7316 于 2013-8-9 12:56 编辑
lkm_unication 发表于 2013-8-9 12:33 static/image/common/back.gif
文件与数据的关联应该是在page的内容里的，如果page的内容是正确的，那不应该有问题。 ...
这是我网上找到的一段资料：
7、scan flash
如果YAFFS2正常关闭，则它会将runtime context作为check point数据记录到flash上。而YAFFS2启动时，会扫描flash，找到记录着check point数据的block，并尝试着恢复runtime context。但是如果恢复出了问题，则YAFFS2不得不扫描整个flash，根据读出来的数据来尝试恢复runtime context，这就是本节的内容。
有两个版本的扫描策略，分别是：
yaffs_Scan()，这就是在上一节提到的YAFFS2的扫描策略，并用它解释了为什么要shrink flag。不过该策略已经被最新版本的YAFFS2放弃了，转而使用了下面的策略。
yaffs_ScanBackwards()，从名字看该策略是倒着扫描的，不错它的实现确实是如此。在扫描了整个flash后，得到需要扫描的block，按照bi->sequenceNumber排序。然后从seqence number最大的block开始往sequence number减小的方向扫描；不但如此，在block上该策略先扫描physical chunk index大的chunk，并向减小的方向扫描。用一句话总结就是，按照chunk的分配顺序反过来扫描。
由上面所说，我现在读文件只能读到小于1.4kbytes或是文件结尾的一段，是不是程序中有什么限定了我数据的大小。或是读取文件的size被中间什么改变了？
就像unyaffs中要做如下修改：
//s = (remain < pt->t.byteCount) ? remain : pt->t.byteCount;
s = (remain < (CHUNK_SIZE)) ? remain : (CHUNK_SIZE);
lkm_unication 发表于 2013-8-9 12:33 static/image/common/back.gif
文件与数据的关联应该是在page的内容里的，如果page的内容是正确的，那不应该有问题。 ...
您有yaffs2源码吗？能给我一份吗？
我现在用git下载的不知道怎么回事。
我kernel是2.6.35. lkm_unication 发表于 2013-8-9 12:33 static/image/common/back.gif
文件与数据的关联应该是在page的内容里的，如果page的内容是正确的，那不应该有问题。 ...
我现在在扫描数据的时候打印了下面结构体，
struct yaffs_file_var {
loff_t file_size;
loff_t scanned_size;
loff_t shrink_size;
int top_level;
struct yaffs_tnode *top;
};
通过mount之后然后cp的分区中， file_size、scanned_size、shrink_size都是对的，是对应文件的大小，三个数值一样。
而且在这种情况下根本就没有扫描到非数据区也就是目录什么的。
那么他这个结构中的数据值怎么保存的、
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
68084++++++68084+++++++68084
9792++++++9792+++++++9792
9792++++++9792+++++++9792
9792++++++9792+++++++9792
9792++++++9792+++++++9792
9792++++++9792+++++++9792
13892++++++13892+++++++13892
13892++++++13892+++++++13892
13892++++++13892+++++++13892
13892++++++13892+++++++13892
13892++++++13892+++++++13892
13892++++++13892+++++++13892
13892++++++13892+++++++13892
14992++++++14992+++++++14992
14992++++++14992+++++++14992
14992++++++14992+++++++14992
当我使用自己制作的镜像挂载的时候，file_size、scanned_size、shrink_size这三个数值都不对，前面两个都是0，最后一个是-2032，
所以每个文件只能读到小于2kbytes的数据（尾部）。
部分打印信息：
name = umount-----1-----1
file_size scanned_size shrink_size
0++++++0+++++++-2032
name = gdbjithelper----0----5612
0++++++0+++++++-2032
name = wpa_cli----0----31284
0++++++0+++++++-2032
name = qemu-props----0----5520
name = newfs_msdos-----1-----1
0++++++0+++++++-2032
name = sirius.ogg----0----26612
0++++++0+++++++-2032
name = SpaceSeed.ogg----0----26180
0++++++0+++++++-2032
name = CetiAlpha.ogg----0----26158 wshini7316 发表于 2013-8-9 12:52 static/image/common/back.gif
您有yaffs2源码吗？能给我一份吗？
我现在用git下载的不知道怎么回事。
我kernel是2.6.35. ...
我用的kernel版本是2.6.23的，很老了。
我从omap的kernel里导了一个出来，你看看是否能用吧。 wshini7316 发表于 2013-8-9 17:42 static/image/common/back.gif
我现在在扫描数据的时候打印了下面结构体，
struct yaffs_file_var {
loff_t file_size;
当我使用自己制作的镜像挂载的时候，file_size、scanned_size、shrink_size这三个数值都不对，前面两个都是0，最后一个是-2032
这就有问题了，由于file_size这些信息是保存在page里的，按理说mkyaffs2image的工具是不会错的，你先制作只有一个文件的image，然后看看第一个page的内容，该page是这个文件的信息，从第二个page开始才是文件的数据。 lkm_unication 发表于 2013-8-9 23:29 static/image/common/back.gif
当我使用自己制作的镜像挂载的时候，file_size、scanned_size、shrink_size这三个数值都不对，前面两个都 ...
我今天跟踪 了一下程序又，发现如下问题：
每次读取倒数第一个数据页之后就会进入如下程序：
else if (tags.obj_id > YAFFS_MAX_OBJECT_ID ||
tags.chunk_id > YAFFS_MAX_CHUNK_ID ||
tags.obj_id == YAFFS_OBJECTID_SUMMARY ||
(tags.chunk_id > 0 &&
tags.n_bytes > dev->data_bytes_per_chunk) ||
tags.seq_number != bi->seq_number) {
yaffs_trace(YAFFS_TRACE_SCAN,
"Chunk (%d:%d) with bad tags:obj = %d, chunk_id = %d, n_bytes = %d, ignored",
blk, chunk_in_block, tags.obj_id,
tags.chunk_id, tags.n_bytes);
dev->n_free_chunks++;
} else if (tags.chunk_id > 0) {
然后我查看判断条件，tags.n_bytes = 2048
dev->data_bytes_per_chunk = 2032 这个数值是2048-pt结构大小。
也就是(tags.chunk_id > 0 && tags.n_bytes > dev->data_bytes_per_chunk)这个条件成立。导致我读完最后一页数据之后，就不会在对有用的数据处理了。
查找程序看到如下赋值：
/* Sort out space for inband tags, if required */
if (dev->param.inband_tags)
dev->data_bytes_per_chunk =
dev->param.total_bytes_per_chunk -
sizeof(struct yaffs_packed_tags2_tags_only);
else
dev->data_bytes_per_chunk = dev->param.total_bytes_per_chunk;
又是dev->param.inband_tags = 1 造成的。
为什么要在一页的基础上-tags结构大小。tags又没有放到data区。
明天将这块程序更改一下看看会是什么效果。
实在是不理解为什么在2048的基础上减去16个字节，得到的2032有什么用吗？
要是在2048+64的基础上减去16个字节，这又有什么意思吗？
wshini7316 发表于 2013-8-12 18:08 static/image/common/back.gif
我今天跟踪 了一下程序又，发现如下问题：
每次读取倒数第一个数据页之后就会进入如下程序：
else if (ta ...
dev->param.inband_tags = 1 时，oob的数据是包含在data里的，而inband_tags=时，其chunk的大小应是2048+16=2064，而不是2048. 若2064-16就刚好是2048了。 lkm_unication 发表于 2013-8-12 19:05 static/image/common/back.gif
dev->param.inband_tags = 1 时，oob的数据是包含在data里的，而inband_tags=时，其chunk的大小应是2048+ ...
那dev->param.inband_tags 的数值是程序自己从nand中读到的还是要我自己设置呢？
wshini7316 发表于 2013-8-13 09:50 static/image/common/back.gif
那dev->param.inband_tags 的数值是程序自己从nand中读到的还是要我自己设置呢？
...
我看了一下yaffs的文档，发现我昨天说的，有inband_tags chunk size是2048+16是错误的，chunk size即使加上了16byte的tags，仍然是2048，inband_tags是用于oob不够空间保存tags信息时的一种挽救方法，就是把tags放在data（page）里，不够目前看来应该不会有这种情况出现了。参考：http://blog.chinaunix.net/uid-23141914-id-249371.html
inband_tags的初始化是通过mount 把 inband-tags 参数传给yaffs2的，不知道你的mount是否添加了inband-tags的参数。或则你在yaffs2的yaffs_parse_options里人为地修改。 lkm_unication 发表于 2013-8-13 12:57 static/image/common/back.gif
我看了一下yaffs的文档，发现我昨天说的，有inband_tags chunk size是2048+16是错误的，chunk size即使加 ...
这个问题我找到了。
就是在nand的mtd驱动的ecclayout结构体中定义oobfree的问题。
yaffs2在mount的时候会有如下判断：
if (mtd->oobavail < sizeof(struct yaffs_packed_tags2) ||
options.inband_tags)
inband_tags = 1;
options.inband_tags 在没有mount命令参数的时候为0
sizeof(struct yaffs_packed_tags2)= 28
mtd->oobavail 数值等于ecclayout结构体中oobfree的大小（好像是这样的） = 16
所以造成每次我mount的时候dev->param.inband_tags = 1.
我现在将oobfree的结构数据又增加了12个字节，这样就可以保证dev->param.inband_tags = 0；
现在可以挂载上，并且文件内容应该也是对的。我用原来linux的根文件系统将其挂载cp出来查看没有问题。 lkm_unication 发表于 2013-8-13 12:57 static/image/common/back.gif
我看了一下yaffs的文档，发现我昨天说的，有inband_tags chunk size是2048+16是错误的，chunk size即使加 ...
现在第一次挂载的时候显示正常。没有问题。
当我umount之后，再次用mount挂载的时候会出现下面的错误提示，但是文件挂载是正常的。
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
不知道有什么影响，为什么会出现这些提示。 lkm_unication 发表于 2013-8-13 12:57 static/image/common/back.gif
我看了一下yaffs的文档，发现我昨天说的，有inband_tags chunk size是2048+16是错误的，chunk size即使加 ...
现在我用nand上的yaffs2格式的system启动的时候会提示下面信息，而其一直打印，
init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
enabling adb
# warning: `rild' uses 32-bit capabilities (legacy support in use)
request_suspend_state: on (3->0) at 17731834253 (1970-01-01 00:00:16.051418001 UTC)
sgtl5000_hw_read: read reg error : Reg 0x0e
sgtl5000_write: write reg error : Reg 0x0e = 0x000c
init: untracked pid 2275 exited
sgtl5000_write: write reg error : Reg 0x02 = 0x0020
sgtl5000_write: write reg error : Reg 0x06 = 0x0130
init: untracked pid 2279 exited
request_suspend_state: on (0->0) at 20390580878 (1970-01-01 00:00:18.710165001 UTC)
sgtl5000_hw_read: read reg error : Reg 0x0e
sgtl5000_write: write reg error : Reg 0x0e = 0x000c
sgtl5000_write: write reg error : Reg 0x02 = 0x0020
init: untracked pid 2341 exited
sgtl5000_write: write reg error : Reg 0x06 = 0x0130
init: untracked pid 2340 exited
request_suspend_state: on (0->0) at 25058307379 (1970-01-01 00:00:23.377890877 UTC)
sgtl5000_hw_read: read reg error : Reg 0x0e
init: untracked pid 2352 exited
sgtl5000_write: write reg error : Reg 0x0e = 0x000c
sgtl5000_write: write reg error : Reg 0x02 = 0x0020
sgtl5000_write: write reg error : Reg 0x06 = 0x0130
init: untracked pid 2351 exited
.
.
.
.
一直打印也不死机也不重启。
此时还可以执行命令，可以cd到system目录下查看相应的文件都挂载上了。
这是什么问题呢？
正常启动的时候打印如下信息：
init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
enabling adb
# warning: `rild' uses 32-bit capabilities (legacy support in use)
pmem: request for physical address of pmem region from process 2347.
request_suspend_state: on (3->0) at 29824104251 (1970-01-02 00:00:05.815786376 UTC)
request_suspend_state: on (0->0) at 30302734876 (1970-01-02 00:00:06.294416626 UTC)
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2b530054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2b530054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2bb3e054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2bbdb054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2b971054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2ba0e054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2ba30054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2ba30054
Not all allocated memory blocks were freed. Doing it now.
Freeing list entry #0, gpuaddr=166000
Freeing list entry #1, gpuaddr=167000
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2ba30054
Freeing list entry #2, gpuaddr=177000
Freeing list entry #3, gpuaddr=1a9000
Freeing list entry #6, gpuaddr=1fa000
Freeing list entry #7, gpuaddr=1fc000
Freeing list entry #8, gpuaddr=21c000
Unhandled fault: external abort on non-linefetch (0x1018) at 0x2ba30054
Freeing list entry #100, gpuaddr=d7c000
上面红色的在yaffs2的时候没有执行，这是为什么？ wshini7316 发表于 2013-8-13 17:53 static/image/common/back.gif
现在我用nand上的yaffs2格式的system启动的时候会提示下面信息，而其一直打印，
init: cannot find '/sys ...
这应该是你的GPU和其他driver的问题，可能是yaffs2加载上了，就跑那些driver的daemon，从而触发了driver的问题，或其他关联的问题。 lkm_unication 发表于 2013-8-13 18:56 static/image/common/back.gif
这应该是你的GPU和其他driver的问题，可能是yaffs2加载上了，就跑那些driver的daemon，从而触发了driver ...
那和我挂着其他文件系统有什么不同吗？
应该都是一样的 啊？ wshini7316 发表于 2013-8-13 22:29 static/image/common/back.gif
那和我挂着其他文件系统有什么不同吗？
应该都是一样的 啊？
这个不太清楚，可以分析一下init.rc看看是否有区别，另外，那个unhandle的错误是谁报的呢？ lkm_unication 发表于 2013-8-14 08:51 static/image/common/back.gif
这个不太清楚，可以分析一下init.rc看看是否有区别，另外，那个unhandle的错误是谁报的呢？ ...
Unhandled错误一直都有，我从官方下的源码运行也会出现。
制作system镜像的时候，system的权限和属性有什么限制吗？ 制作system镜像的时候，system的权限和属性有什么限制吗？
没有！ lkm_unication 发表于 2013-8-14 11:50 static/image/common/back.gif
没有！
我查看了正常启动和yaff2启动的时候的ps，正常的时候比不正常的多如下进程：
root 22771 8344027188 800eb028 6fd0b844 S zygote
system 23412277225740 37404 ffffffff 6fd0b6fc S system_server
root 23522 0 0 8007db24 00000000 S z1xx_workq
system 23962277104348 20392 ffffffff 6fd0c51c S com.android.systemui
app_1 24092277100392 19548 ffffffff 6fd0c51c S com.android.inputmethod.latin
radio 24142277109012 19996 ffffffff 6fd0c51c S com.android.phone
app_23 24172277132144 21976 ffffffff 6fd0c51c S com.android.launcher
app_4 246022779777219448 ffffffff 6fd0c51c S android.process.acore
app_2 25102277105528 17388 ffffffff 6fd0c51c S com.android.mms
app_6 251522779530018096 ffffffff 6fd0c51c S android.process.media
app_7 254022779346817028 ffffffff 6fd0c51c S com.android.bluetooth
app_11 255022779590418428 ffffffff 6fd0c51c S com.android.email
app_26 256522779408817216 ffffffff 6fd0c51c S com.android.providers.calendar
app_29 257922779421616728 ffffffff 6fd0c51c S com.android.deskclock
app_14 258922779343615680 ffffffff 6fd0c51c S com.android.music
app_16 259822779392016424 ffffffff 6fd0c51c S com.android.quicksearchbox
app_22 260722779287215364 ffffffff 6fd0c51c S com.android.protips
app_13 261622779459617184 ffffffff 6fd0c51c S com.cooliris.media
root 26262 0 0 800faf20 00000000 S flush-179:0 lkm_unication 发表于 2013-8-14 11:50 static/image/common/back.gif
没有！
在system文件中什么程序会调用pmem的ioctl函数呢？ 在system文件中什么程序会调用pmem的ioctl函数呢？
这个我不清楚哦。 lkm_unication 发表于 2013-8-14 12:27 static/image/common/back.gif
这个我不清楚哦。
我下午将整个system文件全部cp出来然后用比较工具和原始文件比较，发现有个别的文件是不同的。而且每次的结果还不一样。
是不是出现UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
UnCorrectable RS-ECC Error
造成文件数据的问题。
UnCorrectable RS-ECC Error
先确认一下这个ecc是在哪里打印出来的，如果是nand flash controller，那么需要跟一下，是不是由于坏块没有被标记，或在uboot里做个程序，把nand flash都检查一遍，然后把坏块标记，再重新烧些image能否避开这些坏块。 lkm_unication 发表于 2013-8-15 08:52 static/image/common/back.gif
先确认一下这个ecc是在哪里打印出来的，如果是nand flash controller，那么需要跟一下，是不是由于坏块没 ...
我上午比对了一下挂载读出的system文件内容，查看与原文件不同的文件，发现读到的数据不是自己的，而是其他文件的数据，好像块和页的地址有什么问题。
现在还在查看具体的问题是什么造成的。
lkm_unication 发表于 2013-8-15 08:52 static/image/common/back.gif
先确认一下这个ecc是在哪里打印出来的，如果是nand flash controller，那么需要跟一下，是不是由于坏块没 ...
#define YAFFS_NOBJECT_BUCKETS 256
这个数值是干什么的。是不是我只能有256个object
下面这些宏定义有需要更改的吗？page=2048 oob=64
#define YAFFS_MAGIC 0x5941ff53
/*
* Tnodes form a tree with the tnodes in "levels"
* Levels greater than 0 hold 8 slots which point to other tnodes.
* Those at level 0 hold 16 slots which point to chunks in NAND.
*
* A maximum level of 8 thust supports files of size up to:
*
* 2^(3*MAX_LEVEL+4)
*
* Thus a max level of 8 supports files with up to 2^^28 chunks which gives
* a maximum file size of around 512Gbytees with 2k chunks.
*/
#define YAFFS_NTNODES_LEVEL0 16
#define YAFFS_TNODES_LEVEL0_BITS 4
#define YAFFS_TNODES_LEVEL0_MASK 0xf
#define YAFFS_NTNODES_INTERNAL (YAFFS_NTNODES_LEVEL0 / 2)
#define YAFFS_TNODES_INTERNAL_BITS (YAFFS_TNODES_LEVEL0_BITS - 1)
#define YAFFS_TNODES_INTERNAL_MASK 0x7
#define YAFFS_TNODES_MAX_LEVEL 8
#define YAFFS_TNODES_MAX_BITS (YAFFS_TNODES_LEVEL0_BITS + \
YAFFS_TNODES_INTERNAL_BITS * \
YAFFS_TNODES_MAX_LEVEL)
#define YAFFS_MAX_CHUNK_ID ((1 << YAFFS_TNODES_MAX_BITS) - 1)
#define YAFFS_MAX_FILE_SIZE_32 0x7fffffff
/* Constants for YAFFS1 mode */
#define YAFFS_BYTES_PER_SPARE 16
#define YAFFS_BYTES_PER_CHUNK 512
#define YAFFS_CHUNK_SIZE_SHIFT 9
#define YAFFS_CHUNKS_PER_BLOCK 32
#define YAFFS_BYTES_PER_BLOCK (YAFFS_CHUNKS_PER_BLOCK*YAFFS_BYTES_PER_CHUNK)
#define YAFFS_MIN_YAFFS2_CHUNK_SIZE 1024
#define YAFFS_MIN_YAFFS2_SPARE_SIZE 32
#define YAFFS_ALLOCATION_NOBJECTS 100
#define YAFFS_ALLOCATION_NTNODES 100
#define YAFFS_ALLOCATION_NLINKS 100
#define YAFFS_NOBJECT_BUCKETS 256
#define YAFFS_OBJECT_SPACE 0x40000
#define YAFFS_MAX_OBJECT_ID (YAFFS_OBJECT_SPACE - 1)
/* Binary data version stamps */
#define YAFFS_SUMMARY_VERSION 1
#define YAFFS_CHECKPOINT_VERSION 7
#ifdef CONFIG_YAFFS_UNICODE
#define YAFFS_MAX_NAME_LENGTH 127
#define YAFFS_MAX_ALIAS_LENGTH 79
#else
#define YAFFS_MAX_NAME_LENGTH 255
#define YAFFS_MAX_ALIAS_LENGTH 159
#endif
#define YAFFS_SHORT_NAME_LENGTH 15
/* Some special object ids for pseudo objects */
#define YAFFS_OBJECTID_ROOT 1
#define YAFFS_OBJECTID_LOSTNFOUND 2
#define YAFFS_OBJECTID_UNLINKED 3
#define YAFFS_OBJECTID_DELETED 4
/* Fake object Id for summary data */
#define YAFFS_OBJECTID_SUMMARY 0x10
/* Pseudo object ids for checkpointing */
#define YAFFS_OBJECTID_CHECKPOINT_DATA 0x20
#define YAFFS_SEQUENCE_CHECKPOINT_DATA 0x21
#define YAFFS_MAX_SHORT_OP_CACHES 20
#define YAFFS_N_TEMP_BUFFERS 6
/* We limit the number attempts at sucessfully saving a chunk of data.
* Small-page devices have 32 pages per block; large-page devices have 64.
* Default to something in the order of 5 to 10 blocks worth of chunks.
*/
#define YAFFS_WR_ATTEMPTS (5*64)
/* Sequence numbers are used in YAFFS2 to determine block allocation order.
* The range is limited slightly to help distinguish bad numbers from good.
* This also allows us to perhaps in the future use special numbers for
* special purposes.
* EFFFFF00 allows the allocation of 8 blocks/second (~1Mbytes) for 15 years,
* and is a larger number than the lifetime of a 2GB device.
*/
#define YAFFS_LOWEST_SEQUENCE_NUMBER 0x00001000
#define YAFFS_HIGHEST_SEQUENCE_NUMBER 0xefffff00
/* Special sequence number for bad block that failed to be marked bad */
#define YAFFS_SEQUENCE_BAD_BLOCK 0xffff0000 lkm_unication 发表于 2013-8-15 08:52 static/image/common/back.gif
先确认一下这个ecc是在哪里打印出来的，如果是nand flash controller，那么需要跟一下，是不是由于坏块没 ...
yaffs2文件挂载之后，我用cp命令复制的时候，是怎么读的文件数据？
mount的时候是怎么把数据关联在一起的？
现在错误文件的内容可以在镜像文件中找到，就是指不定是哪个文件的哪一部分。
没有按照正确的结构去读数据。
页:
[1]
2