重新烧写一次，但烧写时需要注意，必须先erase掉整个partion，而不是image多大就erase多大。 ...
我是erase掉整个partion的。
而且我在跟踪中查看tags结构中的数据也都是正确的。
现在就是我扫描之后这些数据怎么处理的，是怎么cp出来的？ 现在就是我扫描之后这些数据怎么处理的，是怎么cp出来的？
这个不懂，这需要深入yaffs2才能明白。 lkm_unication 发表于 2013-8-16 08:42 static/image/common/back.gif
这个不懂，这需要深入yaffs2才能明白。
我跟踪了一下cp的时候的读函数过程如下：
int yaffs_file_rd(struct yaffs_obj *in, u8 * buffer, loff_t offset, int n_bytes)
|
static int yaffs_rd_data_obj(struct yaffs_obj *in, int inode_chunk, u8 * buffer)
|
int nand_chunk = yaffs_find_chunk_in_file(in, inode_chunk, NULL);
所有有问题的文件，这个nand_chunk都是不正确的。
int yaffs_find_chunk_in_file(struct yaffs_obj *in, int inode_chunk,
struct yaffs_ext_tags *tags)
{
/*Get the Tnode, then get the level 0 offset chunk offset */
struct yaffs_tnode *tn;
int the_chunk = -1;
struct yaffs_ext_tags local_tags;
int ret_val = -1;
struct yaffs_dev *dev = in->my_dev;
if (!tags) {
/* Passed a NULL, so use our own tags space */
tags = &local_tags;
}
tn = yaffs_find_tnode_0(dev, &in->variant.file_variant, inode_chunk);
//有的时候在这就跳出了，这块主要涉及就是in->variant.file_variant这个结构体，还不知道是写入有问题还是读出有问题
if (!tn)
return ret_val;
the_chunk = yaffs_get_group_base(dev, tn, inode_chunk);
ret_val = yaffs_find_chunk_in_group(dev, the_chunk, tags, in->obj_id,
inode_chunk);
//有的时候这地方返回0，这块还没分析。
return ret_val;
}
struct yaffs_file_var {
loff_t file_size;
loff_t scanned_size;
loff_t shrink_size;
int top_level;
struct yaffs_tnode *top;//这个结构是干什么用的？
};
wshini7316 发表于 2013-8-16 17:46 static/image/common/back.gif
我跟踪了一下cp的时候的读函数过程如下：
int yaffs_file_rd(struct yaffs_obj *in, u8 * buffer, loff_t ...
你研究得越来越深入了。
lkm_unication 发表于 2013-8-16 18:01 static/image/common/back.gif
你研究得越来越深入了。
没办法啊。总得把问题解决了啊！
还希望得到您的帮助啊！
周一我在测试一下看看到底是写入还是读出的问题。 lkm_unication 发表于 2013-8-16 18:01 static/image/common/back.gif
你研究得越来越深入了。
yaffs2文件系统的移植，除了更改oob区的格式还要更改其他的什么东西啊。我总感觉有什么参数没有更改造成的？ 其实oob的layout，yaffs2是不关心，这一切都由mtd driver来转换的。移植时，我记得一般就是不打开软件ecc，不让yaffs2计算ecc，其他的，都由mtd解决。但不知道新版本的会有什么区别了。 lkm_unication 发表于 2013-8-19 12:38 static/image/common/back.gif
其实oob的layout，yaffs2是不关心，这一切都由mtd driver来转换的。移植时，我记得一般就是不打开软件ecc， ...
我现在将原来system文件中挂载有问题的一个文件单独压缩，system/app/AccountAndSyncSettings.apk，unyaffs2加压正常，文件正确。
然后挂载测试，将存在一页读取错误，跟踪如下：
the_chunk = yaffs_get_group_base(dev, tn, inode_chunk);函数返回0
u32 yaffs_get_group_base(struct yaffs_dev *dev, struct yaffs_tnode *tn, unsigned pos)
{
u32 *map = (u32 *) tn;
u32 bit_in_map;
u32 bit_in_word;
u32 word_in_map;
u32 val;
pos &= YAFFS_TNODES_LEVEL0_MASK;
bit_in_map = pos * dev->tnode_width;
word_in_map = bit_in_map / 32;
bit_in_word = bit_in_map & (32 - 1);
val = map >> bit_in_word;
//打印val值
if (dev->tnode_width > (32 - bit_in_word)) {
bit_in_word = (32 - bit_in_word);
word_in_map++;
val |= (map << bit_in_word);
}
//打印val值
val &= dev->tnode_mask;
//打印val值
val <<= dev->chunk_grp_bits;
//打印val值
return val;
}
*************yaffs_file_rd**************
dev->tnode_width = 0x12
dev->tnode_mask = 0x3ffff
dev->chunk_grp_bits = 0
bit_in_map = 90
word_in_map = 2
map = 0x9500
val = 0
val = 39583744
val = 0
val = 0
----------the_chunk = 0---- ret_val = 0xffffffff lkm_unication 发表于 2013-8-19 12:38 static/image/common/back.gif
其实oob的layout，yaffs2是不关心，这一切都由mtd driver来转换的。移植时，我记得一般就是不打开软件ecc， ...
今天终于找到问题了，查了半天yaffs2的源码。没想到在freescale提供的nand写页函数中有一个判断，如果page中的数据都是0xff，就不去写此页，不去管spare区的数据。所以导致在镜像中如果page数据都是0xff，但是oob又有tags的结构的时候，就没有正确的写入到nand中。还都是0xff。
现在更改之后挂载system文件可以正常启动了。
谢谢您一直的帮助！ 终于完成了！{:biggrin:}{:biggrin:}{:biggrin:}{:biggrin:}{:biggrin:}
过程真是痛苦啊！ lkm_unication 发表于 2013-8-19 12:38 static/image/common/back.gif
其实oob的layout，yaffs2是不关心，这一切都由mtd driver来转换的。移植时，我记得一般就是不打开软件ecc， ...
再问您个问题，android的uboot中下面的宏定义是什么意思：
/*
* Android support Configs
*/
#define CONFIG_USB_DEVICE
#define CONFIG_FASTBOOT 1
#define CONFIG_IMX_UDC 1
#define CONFIG_FASTBOOT_STORAGE_EMMC
#define CONFIG_FASTBOOT_VENDOR_ID 0xbb4
#define CONFIG_FASTBOOT_PRODUCT_ID 0xc01
#define CONFIG_FASTBOOT_BCD_DEVICE 0x311
#define CONFIG_FASTBOOT_MANUFACTURER_STR"Freescale"
#define CONFIG_FASTBOOT_PRODUCT_NAME_STR "i.mx53 loco"
#define CONFIG_FASTBOOT_CONFIGURATION_STR"Android fastboot"
#define CONFIG_FASTBOOT_INTERFACE_STR "Android fastboot"
#define CONFIG_FASTBOOT_SERIAL_NUM "12345"
#define CONFIG_FASTBOOT_TRANSFER_BUF 0x80000000
#define CONFIG_FASTBOOT_TRANSFER_BUF_SIZE 0x8000000 /* 128M byte */
#define CONFIG_ANDROID_RECOVERY
#define CONFIG_ANDROID_RECOVERY_BOOTARGS_MMC \
"setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4"
#define CONFIG_ANDROID_RECOVERY_BOOTCMD_MMC\
"run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x1800;bootm"
#define CONFIG_ANDROID_RECOVERY_CMD_FILE "/recovery/command"
#define CONFIG_ANDROID_CACHE_PARTITION_MMC 6 wshini7316 发表于 2013-8-20 17:39 static/image/common/back.gif
今天终于找到问题了，查了半天yaffs2的源码。没想到在freescale提供的nand写页函数中有一个判断，如果pag ...
这个bug很隐蔽，但freescale的这个bug是不可原谅的。因为driver不能这么主观武断。
我其实没有什么实质性的帮忙，呵呵！
any way，还是要恭喜你啊！ wshini7316 发表于 2013-8-20 17:46 static/image/common/back.gif
再问您个问题，android的uboot中下面的宏定义是什么意思：
/*
* Android support Configs
这些宏有些是freescale移植fastboot所用的，android的fastboot是通过usb进行的；
有些是bootloader的加载参数，根据不同的情况加载不同的分区，比如说在kernel里应为某个原因需要重启，如需要恢复系统，那么就在CPU的重启也不会被reset的寄存器里致个标志，在bootloader里根据该标志加载不同的分区，还可以用于系统更新等，总之没有固定的用法，可以自己规划。 wshini7316 发表于 2013-8-20 17:40 static/image/common/back.gif
终于完成了！
过程真是痛苦啊！
你yaffs2文件系统里读取tags时的oob组织还是在yaffs2里做的吧，建议把它改在mtd的driver里，这样yaffs2就脱离硬件了，降低了耦合度。
可参考nand_base里的nand_fill_oob，我的nand_fill_oob是以下的内容：static uint8_t *nand_fill_oob(struct nand_chip *chip, uint8_t *oob,
struct mtd_oob_ops *ops)
{
size_t len = ops->ooblen;
switch(ops->mode) {
case MTD_OOB_PLACE:
case MTD_OOB_RAW:
memcpy(chip->oob_poi + ops->ooboffs, oob, len);
return oob + len;
case MTD_OOB_AUTO: {
struct nand_oobfree *free = chip->ecc.layout->oobfree; // 用分段free里的内容组合成连续的oob内容返回，这样tags就是连续的了
uint32_t boffs = 0, woffs = ops->ooboffs;
size_t bytes = 0;
for(; free->length && len; free++, len -= bytes) {
/* Write request not from offset 0 ? */
if (unlikely(woffs)) {
if (woffs >= free->length) {
woffs -= free->length;
continue;
}
boffs = free->offset + woffs;
bytes = min_t(size_t, len,
(free->length - woffs));
woffs = 0;
} else {
bytes = min_t(size_t, len, free->length);
boffs = free->offset;
}
memcpy(chip->oob_poi + boffs, oob, bytes);
oob += bytes;
}
return oob;
}
default:
BUG();
}
return NULL;
} lkm_unication 发表于 2013-8-21 08:51 static/image/common/back.gif
你yaffs2文件系统里读取tags时的oob组织还是在yaffs2里做的吧，建议把它改在mtd的driver里，这样yaffs2就 ...
好的。我看一下。
谢谢！ lkm_unication 发表于 2013-8-21 08:51 static/image/common/back.gif
你yaffs2文件系统里读取tags时的oob组织还是在yaffs2里做的吧，建议把它改在mtd的driver里，这样yaffs2就 ...
您这么一说，我这么一看，终于明白。原来只要把dev->param.inband_tags = 0 ；还有就是yaffs2的ecc关掉，yaffs2源码就不用改了。
只需要将nand的ecclayout就够写好就ok了。
真是走了不少冤枉路啊！
真是太感谢您了！这回是真的把yaffs2移植好了！ wshini7316 发表于 2013-8-21 17:37 static/image/common/back.gif
您这么一说，我这么一看，终于明白。原来只要把dev->param.inband_tags = 0 ；还有就是yaffs2的ecc关掉， ...
话虽然是这么说，但如果你不走一遍，会忽略很多细节的。
其实我在你这个主题里也学到很多关于yaffs2和mtd driver的细节。也感谢你的这个主题。 lkm_unication 发表于 2013-8-21 18:19 static/image/common/back.gif
话虽然是这么说，但如果你不走一遍，会忽略很多细节的。
其实我在你这个主题里也学到很多关于yaffs2和mtd ...
呵呵！共同进步！ lkm_unication 发表于 2013-8-21 18:19 static/image/common/back.gif
话虽然是这么说，但如果你不走一遍，会忽略很多细节的。
其实我在你这个主题里也学到很多关于yaffs2和mtd ...
您好！我想再问您个问题，我现在想android起来之后挂载ubifs文件系统（手动mount），但是原bin文件中没有ubiattach命令。我从网上下源码编译之后复制到bin目录下，每次运行都提示找不到这个命令。可是在这个文件下已经有这个命令了啊？
不知道还需要更改什么其他的东西吗?
还有一个问题，就是我现在更改了程序让他可以在启动的时候挂载ubifs文件，但是在ubiattach的时候VID偏移默认的总是512，我怎么将其改为2048.
页:
1
[2]