1 前段时间在win下编译了xboot,因为手头没有fc100的板，于是在全志h2+芯片上测试
编译代码没有问题，并下载到了H2+上测试通过。
这次拿到fc100的板，然后编译fc100出2个错误，都是VFP对齐错误，
并且连编译器库里的库文件也显示链接VFP对齐错误。
没办法。返回去编译h2+,结果h2+也出现同样错误。
没办法。
重新把xboot代码和编译器eclipse-mars-for-arm-windows-x86_64 删掉。
重新按最开始通过的h2+的测试步骤走一遍。结果编译还是出现VFP对齐错误。
没办法。你说我的电脑还真牛逼，是把。
2 不玩xboot了，玩fc100 的教程
短接spi闪存 1-4脚
接入usb装驱动
执行fel ver
//显示版本
G:\xboot\xboot-master\output\tool>fel ver
Warning: no 'soc_sram_info' data for your SoC (id=1663)
AWUSBFEX soc=00001663(unknown) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
可以认到设备， 说明usb驱动没问题 ，我可用的时sunxi的官方fel 。
//下载boo0并执行
G:\xboot\xboot-master\output\tool>fel spl f1c100s.bin
Warning: no 'soc_sram_info' data for your SoC (id=1663)
Unexpected SCTLR (00052078)
看到了执行的错误
//读SRAM内存到文件
G:\xboot\xboot-master\output\tool>fel read 0x00010000 0x100 swsw.bin
swsw打开后全是0
//读ROM到文件
G:\xboot\xboot-master\output\tool>fel read 0x00000000 0x7fff sw.bin
sw 打开后全是有ROM的代码。
代码前面 0x0--0x3ff 全是0xff
代码后面 0x3ff -- 0x7fff 有一堆代码
由此可见这个f1c100s 的rom代码与其它全志的芯片有区别
因为在h2+上，不管是ddr,还是sram区域的内存,读取时都有代码在里面。
所以我估计，需要特殊的usb通讯协议。或是特殊的方法。
根据其它芯片的BROM程序判断这里没有头信息
还有个特别重要的事情说下。那个国产实时系统的开发环境。有个问题。
就是通过它的evn来做事的话要注意了。（其实完全可以不用那个evn）
只要打开evn，网络流量就有几M,不知道背景在跑什么东西。
所以你对安全有要求。就不要用。
最后啰嗦一句。用编译器的库，也要注意有没有后门。
所以对于小系统。尽量用自己的库。
3 ------------------- 最大的坑------------------------
当把spi闪存1-4脚连接后，连usb是可以进入FEL模式。
但是把1-4脚断开后，也还是在EFL模式。
不管是重新上电，还是重新连usb，都回不到正常的状态了。
估计闪存的程序丢了。
所以1-4脚不可靠。因为cS片选一直激活，闪存芯片很容易有误操作。
最近编辑记录 sunwei (2018-04-17 15:17:25)
离线
谢谢分享
离线
3 ------------------- 最大的坑------------------------
当把spi闪存1-4脚连接后，连usb是可以进入FEL模式。
但是把1-4脚断开后，也还是在EFL模式。
不管是重新上电，还是重新连usb，都回不到正常的状态了。
估计闪存的程序丢了。
所以1-4脚不可靠。因为cS片选一直激活，闪存芯片很容易有误操作。
这里完全说错了
100s上电后就会从spi flash里面读数据，此时100s输出cs信号。短接cs后，spi flash 就不会再响应。此时f1c100s就认为spi flash 不存在，再加上从sd也读不到信息，此时100s就自动进入了fel模式，等待烧录固件进来。
而断开1，4脚后，100s输出正常，spi flash反应正常，那么此时就可以正常启动或再次进入fel模式，不可能出现楼主说的什么cs一直激活这种事，绝对不可能！
之所以出现楼主说的这种事情，很可能此时插sd卡了，或者板子本身焊接不良，或者 短接不可靠
最近编辑记录 kgp0213 (2018-04-18 00:07:03)
离线