@whycan 你好，单独编译 boot-resource 的命令是什么呀？
C
chunzhang 发布的最新帖子
-
回复: pack 时 ERROR: unable to open file boot-resource.fex发布在 D1系列-RISC-V
-
回复: pack 时 ERROR: unable to open file boot-resource.fex发布在 D1系列-RISC-V
@whycan 这是 pack 之后的log
$ pack --==========-- PACK_CHIP sun20iw1p1 PACK_PLATFORM tina PACK_BOARD d1s-nezha PACK_KERN PACK_DEBUG uart0 PACK_SIG none PACK_SECURE none PACK_MODE normal PACK_FUNC android PACK_PROGRAMMER none PACK_TAR_IMAGE none PACK_TOPDIR /home/zc/tina-d1-h --==========-- No kernel param, parse it from d1s copying tools file copying configs file storage_type value is 5 rm /home/zc/tina-d1-h/out/d1s-nezha/image/sys_partition_nor.fex rm /home/zc/tina-d1-h/out/d1s-nezha/image/image_nor.cfg copying boot resource LZMA 4.65 : Igor Pavlov : Public domain : 2009-02-03 copying boot file make user resource for : /home/zc/tina-d1-h/out/d1s-nezha/image/sys_partition.fex handle partition user-res no user resource partitions APP_PART_DOWNLOAD_FILE = /home/zc/tina-d1-h/out/d1s-nezha/image/app.fex Need size of filesystem no data resource partitions don't build dtbo ... update_chip /home/zc/tina-d1-h/scripts/pack_img.sh: line 1354: /home/zc/tina-d1-h/out/host/bin/fsbuild: cannot execute binary file: Exec format error pack boot package GetPrivateProfileSection read to end content_count=3 LICHEE_REDUNDANT_ENV_SIZE config in BoardConfig.mk --mkenvimage create redundant env data!-- ---redundant env data size 0x20000--- packing for tina linux normal mbr count = 4 partitation file Path=/home/zc/tina-d1-h/out/d1s-nezha/image/sys_partition.bin mbr_name file Path=/home/zc/tina-d1-h/out/d1s-nezha/image/sunxi_mbr.fex download_name file Path=/home/zc/tina-d1-h/out/d1s-nezha/image/dlinfo.fex mbr size = 16384 mbr magic softw411 disk name=boot-resource ERROR: unable to open file boot-resource.fex update_for_part_info -1 ERROR: update mbr file fail ERROR: update_mbr failed -
回复: pack 时 ERROR: unable to open file boot-resource.fex发布在 D1系列-RISC-V
@whycan 你好。这个 boot-resource.fex 未生成是在编译 boot-resource 的时间出错了还是别的什么情况呀？能提供个解决的思路吗？我这边编译完了也没报错，pack 的时间也出现了这个问题。谢谢
-
回复: D1 fastboot烧写rootfs分区有问题发布在 D1系列-RISC-V
@uuuuid 你看这个帖子，问题就出在 erase 之后需要重启才能 flash 就是这样的
@chunzhang 在 D1 fastboot烧写rootfs分区有问题 中说：
@whycan 函数 spinand_mtd_write_ubi 的这段代码存在问题。
if (num == ubinfo->last_partno) { if (offset != ubinfo->last_offset) { pr_err("offset 0x%x smaller than last offset 0x%x\n", ubinfo->last_offset, offset); goto err; } }当PC端执行 fastboot erase rootfs 之后在执行 fastboot flash rootfs 时 ubinfo->last_partno 是上一次对 rootfs 擦除的的操作值 7，num 是本次对 flash 写的操作值 7；offset = 0，ubinfo->last_offset是上一次对 rootfs 擦除最后的偏移量 126000。此时就会进入 err。
但是在擦除操作之后重启再写 flash 可以正常写，避免这个错误，对目前 fastboot 更新 rootfs 的失败结果不造成影响。这个问题应该也需要修复。
-
回复: D1 fastboot烧写rootfs分区有问题发布在 D1系列-RISC-V
@chunzhang
1、跟文件系统 和 跟文件系统的数据 占了两块不连续的flash，一个rootfs区域，一个UDISK区域。
2、在 制作镜像 的时间，类似于/usr/bin/dbus-daemon 是在rootfs区域
3、启动之后，在跟文件下面 新创建 的文件夹 ( /home/root/test /usr/bin/temp） 是在UDISK区域 -
回复: D1 fastboot烧写rootfs分区有问题发布在 D1系列-RISC-V
@whycan 之前是认为跟文件系统的数据紧跟着跟文件系统存储的，这样执行1、fastboot erase rootfs 2、fastboot flash 就把跟文件系统的数据（在根目录下创建的test文件夹）干掉了。
但是 跟文件系统 和 跟文件系统的数据 是 分开存储 的，不知道数据放在那里了，所以更新跟文件系统之后数据依然存在（可以通过删除跟文件下的数据更新跟文件系统进行验证跟文件系统更新成功）
请问， 跟文件系统的数据 放在哪里了？
-
回复: D1 fastboot烧写rootfs分区有问题发布在 D1系列-RISC-V
@whycan 函数 spinand_mtd_write_ubi 的这段代码存在问题。
if (num == ubinfo->last_partno) { if (offset != ubinfo->last_offset) { pr_err("offset 0x%x smaller than last offset 0x%x\n", ubinfo->last_offset, offset); goto err; } }当PC端执行 fastboot erase rootfs 之后在执行 fastboot flash rootfs 时 ubinfo->last_partno 是上一次对 rootfs 擦除的的操作值 7，num 是本次对 flash 写的操作值 7；offset = 0，ubinfo->last_offset是上一次对 rootfs 擦除最后的偏移量 126000。此时就会进入 err。
但是在擦除操作之后重启再写 flash 可以正常写，避免这个错误，对目前 fastboot 更新 rootfs 的失败结果不造成影响。这个问题应该也需要修复。
-
回复: D1 fastboot烧写rootfs分区有问题发布在 D1系列-RISC-V
@whycan 你好，tina sdk默认编译的，用的就是spi nand，板子自带的flash，ubi也用了
-
回复: D1 fastboot烧写rootfs分区有问题发布在 D1系列-RISC-V
@sora1874 我目前是在使用fastboot更新跟文件系统，只更新跟文件系统，其他的不动。我不太明白更新跟文件系统和这个更新boot的关系，boot中对rootfs的大小，起始位置的描述都是对的