1.烧录群里的v3s-rtl8723bs(flash烧录镜像,wifi自动获取ip,可以上互联网).7z,这个文件可以正常启动和使用
2.使用我自己编译的uboot+zImage+squashfs+jffs,报错
一个
jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
很多个
jffs2: Newly-erased block contained word 0x0 at offset 0x00e40000
然后致命的问题就是jffs变成只读了,不能擦写
比如
cp 456.txt 123
cp: can't create '123': No space left on device
3、换成MX25L256使用我自己同样的固件又是正常的
最近编辑记录 a32425262 (2021-04-29 16:17:43)
离线
linux menuconfig 关闭4k sector的选项试一试
已经关闭了的
> Memory Technology Device (MTD) support > SPI-NOR device support
[ ] Use small 4096 B erase sectors
离线
那个步骤2, 最后把jffs读回来,和源文件比较,看是否一致?
不知道是不是sunxife的工具的问题
读出前16M都是对的额。后面16M不对的没感觉像是从前16M重新开始读取了
然后我又重新测试,
1.烧录群里的v3s-rtl8723bs(flash烧录镜像,wifi自动获取ip,可以上互联网).7z,
重新启动之后新建的文件夹和文件又不在了
2.使用我的自己的系统,直接就不能新建,也就是写
3.在我自己的文件系统打包时候随便修改一点东西,重新烧录之后,发现文件系统就是更新过的
测试结果猜测,应该就是我这个flash,跑系统的时候不能写,读取都是正常的,
使用sunxifel,烧写又是可以的,
所以我的猜测应该就是w25q256的驱动不对,
https://github.com/torvalds/linux/commit/e8aec15dd5842b5b11b0e621a2293348d3574a61#
我这里测试MX25q5645G w25q256jv都是正常的,但是我现在使用的是w25q256fvem,测试才会出现这种现象,
难道是w25q256jv,w25q256fv驱动里面写操作不一致?
离线
是的,默认没有处理32M flash后面16M的切换
试一试这个
编译、安装Windows版本sunxi-fel步骤 (32M spi flash补丁,支持W25Q256/MX25L256)
http://whycan.com/t_444.html
(出处:哇酷开发者社区)
我一直用的就是这个
读不出后面16M的数据
sunxifel.ex. -p spiflash-read 0x1000000 0x1000000 read.bin
实际读取的是前面16M的数据
sunxifel.ex. -p spiflash-read 0 0x2000000 read.bin
读取的前面16M的是正确的,后面16M的不正确
离线