我照着各帖子的方法准备 SPI NAND 的 uboot, 然后烧到 H3 板子,然后挂掉,一点输出都没有
用 sunxi-fel uboot xxx.bin 是可以工作的
请教各位, SPL 大概是怎么调的呢, 现在情况是一点打印都没有. 先在还不考虑 H3 跟 V3S 的 bom rom 差异
但是打印都没有, 身为 ruby 工程师, 这回只好默默吐血, 然后吞下了.
调这种东西, 是要 jtag 吗. 还是投降算了
离线
uboot的默认配置spl是有打印信息的。
恩恩,应该是有打印才对. 现在情况是烧好后重启没有打印, 估计是 spl 没有正确加载, 用 sunxi-fel uboot 加载启动后可以读取 1k/1k 间隔的数据(还没有逐个字节比对).
离线
uboot有打印，spl没有打印?
我说的不够清楚, 详细是这样的
我有 f1c200s , h3 两个板子, 用 TF 卡确定板子能够工作, 两块板子都焊接了 1Gb 的 WINBOND SPI-NAND
使用Jie Lei位同学的资料,代码 确定 f1c200s + spi-nand 正常工作,
Jie Lei 同学资料和代码: https://github.com/hcly/f1c100s
烧录方法: sunxi-fel uboot uboot-with-spl-usb.bin write 0x80000000 uboot-with-spl-spinand.bin
然后
- 针对h3修改编译出来 uboot.bin 及生成烧写 spi-nand 的 bin
- 使用 sunxi-fel uboot xxx 能成功烧写到 h3+spi nand 板子
这里是 fel 运行 uboot, 使用uboot 进行烧写, 烧写过程是有打印的,没有看出异常
- 重启后 板子没有串口输出. (目前想法是 brom 没有成功加载 spi-nand 里面的 spl)
h3 平台 spi-nand 里面的 spl+uboot 跟上述步骤用于烧写的 uboot 仅有很少改动, 这个改动已经在 f1c200s 平台验证
另外读取 spi-nand 里面数据跟用于烧写的 bin 比对, 格式和结构上大致未发现异常, 还没有逐个字节比对
针对 h3 平台尝试修改 下载地址但结果并无差异( 0x80000000 -> 0x40000000)
sunxi-fel uboot uboot-with-spl-usb.bin write 0x40000000 uboot-with-spl-spinand.bin
sunxi-fel uboot uboot-with-spl-usb.bin write 0x41000000 uboot-with-spl-spinand.bin
最近编辑记录 everlink (2020-06-14 19:50:45)
离线
这个不会了， 帮你up一下吧， 感谢你提供的 f1c200s + spi-nand 项目信息。
非常非常谢谢你 !!~~ ^_^ ^_^
离线
我说的不够清楚, 详细是这样的
我有 f1c200s , h3 两个板子, 用 TF 卡确定板子能够工作, 两块板子都焊接了 1Gb 的 WINBOND SPI-NAND
使用Jie Lei位同学的资料,代码 确定 f1c200s + spi-nand 正常工作,
Jie Lei 同学资料和代码: https://github.com/hcly/f1c100s
烧录方法: sunxi-fel uboot uboot-with-spl-usb.bin write 0x80000000 uboot-with-spl-spinand.bin然后
- 针对h3修改编译出来 uboot.bin 及生成烧写 spi-nand 的 bin
- 使用 sunxi-fel uboot xxx 能成功烧写到 h3+spi nand 板子
这里是 fel 运行 uboot, 使用uboot 进行烧写, 烧写过程是有打印的,没有看出异常- 重启后 板子没有串口输出. (目前想法是 brom 没有成功加载 spi-nand 里面的 spl)
h3 平台 spi-nand 里面的 spl+uboot 跟上述步骤用于烧写的 uboot 仅有很少改动, 这个改动已经在 f1c200s 平台验证
另外读取 spi-nand 里面数据跟用于烧写的 bin 比对, 格式和结构上大致未发现异常, 还没有逐个字节比对针对 h3 平台尝试修改 下载地址但结果并无差异( 0x80000000 -> 0x40000000)
sunxi-fel uboot uboot-with-spl-usb.bin write 0x40000000 uboot-with-spl-spinand.bin
sunxi-fel uboot uboot-with-spl-usb.bin write 0x41000000 uboot-with-spl-spinand.bin
分享点调试经验吧，之前调试F1C的SPINAND遇到的：
1. 建议先导出BSP的SPL部分代码对比下，全志的brom确实是按照1k的形式进行的，但是我不知道后1k滞后偏移了512，
机理未知但是确实会导致不启动。这个我的测试代码
if __name__ == '__main__':
args = sys.argv
if len(args) < 3:
print_usage()
exit(-1)
if not os.access(args[1], os.F_OK):
print 'input file %s is not exist' % (args[1])
exit(-1)
f_in = os.open(args[1], os.O_RDONLY)
f_out = os.open(args[2], os.O_RDWR | os.O_CREAT)
os.ftruncate(f_out, 0x80000)
for blk in range(0, 4):
for pos in range(0, os.stat(args[1]).st_size/0x400):
os.lseek(f_in, 0x400*pos, os.SEEK_SET)
temp = os.read(f_in, 0x800)
os.lseek(f_out, 0x20000*blk + 0x800*pos, os.SEEK_SET)
os.write(f_out, temp)
os.close(f_in)
os.close(f_out)2. 需要能启动的文件是spl/sunxi-spl.bin，不是其他什么东西，只需要配置好这个就行。
3. 如果写入成功并且能够引导，系统将不会进入FEL烧录模式，这个是最直接验证镜像格式正确与否的方法。
4. 如果以上还不能确认，建议抓取波形观察。
离线
分享点调试经验吧，之前调试F1C的SPINAND遇到的：
1. 建议先导出BSP的SPL部分代码对比下，全志的brom确实是按照1k的形式进行的，但是我不知道后1k滞后偏移了512，
2. 需要能启动的文件是spl/sunxi-spl.bin，不是其他什么东西，只需要配置好这个就行。
3. 如果写入成功并且能够引导，系统将不会进入FEL烧录模式，这个是最直接验证镜像格式正确与否的方法。
4. 如果以上还不能确认，建议抓取波形观察。
谢谢你! 再请教两个问题
- 你提到的 "后1k滞后偏移了512" 详细是指第二个 1k 再加 512 偏移吗?
- 另外, 您的脚本是将 spl/u-boot-spl.bin 转换后直接烧到 spi-nand 进行测试吗?
(加入 import os,sys 后脚本就顺利执行, 我生成 bin 后烧写, 重新上电后还进入 fel 模式)
离线
谢谢你! 再请教两个问题
- 你提到的 "后1k滞后偏移了512" 详细是指第二个 1k 再加 512 偏移吗?
- 另外, 您的脚本是将 spl/u-boot-spl.bin 转换后直接烧到 spi-nand 进行测试吗?
(加入 import os,sys 后脚本就顺利执行, 我生成 bin 后烧写, 重新上电后还进入 fel 模式)
spl/sunxi-spl.bin我提到了第二项，并非spl/u-boot-spl.bin。
离线
spl/sunxi-spl.bin我提到了第二项，并非spl/u-boot-spl.bin。
多谢你细心纠错,. 我等下试验看
更新:
改正了重新测试仍然没有能阻止进入fel模式
还尝试了
- 使用确定能够运行的 ( orangepi-zero 编译配置,之前在spi nor 试过 ok) sunxi-spl.bin 经由脚本转换后烧录
- 烧录确定能够在 f1c100s spi-nand 正常运行的 u-boot (https://github.com/hcly/f1c100s/blob/master/images/uboot-with-spl-spinand.bin)
都无法加载
还用 crc32 检查了烧录的数据没有问题
今天还反复看了好多遍这个 https://linux-sunxi.org/Bootable_SPI_flash#The_BROM_implementation_details
--
又另有想法,
1, 在 fel 加载 能运行的 uboot后查 ffff0000 地址,好像有code, 网上有说就是 brom. 或许dump出来用模拟器跑可慢慢查
2, 或者 用 jtag, attach 上去调 0xffff0000 地址运行跟踪看(在原厂工程师的环境,这个问题应该就是几分钟能确定的问题)
这两个方法对我来说有点折腾, 第一个是建环境有点花时间. 第二个是我没有jtag, 也不知道怎么连, 就算知道该怎么连我的板子可能还要改..
所以, 这个我得先放一放了... 搞不定.
最近编辑记录 everlink (2020-06-15 21:05:52)
离线
多谢你细心纠错,. 我等下试验看
更新:
改正了重新测试仍然没有能阻止进入fel模式
还尝试了
- 使用确定能够运行的 ( orangepi-zero 编译配置,之前在spi nor 试过 ok) sunxi-spl.bin 经由脚本转换后烧录
- 烧录确定能够在 f1c100s spi-nand 正常运行的 u-boot (https://github.com/hcly/f1c100s/blob/master/images/uboot-with-spl-spinand.bin)
都无法加载还用 crc32 检查了烧录的数据没有问题
今天还反复看了好多遍这个 https://linux-sunxi.org/Bootable_SPI_flash#The_BROM_implementation_details
--
又另有想法,
1, 在 fel 加载 能运行的 uboot后查 ffff0000 地址,好像有code, 网上有说就是 brom. 或许dump出来用模拟器跑可慢慢查
2, 或者 用 jtag, attach 上去调 0xffff0000 地址运行跟踪看(在原厂工程师的环境,这个问题应该就是几分钟能确定的问题)这两个方法对我来说有点折腾, 第一个是建环境有点花时间. 第二个是我没有jtag, 也不知道怎么连, 就算知道该怎么连我的板子可能还要改..
所以, 这个我得先放一放了... 搞不定.
我看了看，H3并没有说过它支持SPINAND启动阿，他只支持raw NAND启动，你可以看看brom介绍
离线
我看了看，H3并没有说过它支持SPINAND启动阿，他只支持raw NAND启动，你可以看看brom介绍
嗯,今天做了更多实验,现在基本确定了.应该不行
离线