flashloader的问题解决过程

1.问题:flashloader无法烧写qspi flash(自行生成的FSBL.out不能烧写,golden FSBL.out可以烧写)

解决过程:

最开始是比对ps_init.c,替换后发现问题并未解决;

然后通过proxxxx_jtag-debug.exe烧写qspi flash 判断fsbl load到了0xe8002800 而不是ocm (Proxxxx Console信息也有此信息)

进而定位到0326 proxxxx 导出的FSBL link文件有误,需要手动修改(新版已修复)

2.问题:解决了问题1后,可以烧写qspi flash但是无法启动

板上qspi flash

最大单口快速读速度:50MHz

最大双口读速度:33MHz

最大四口读速度:33MHz

结论是qspi降低频率

实际频率=设置的频率/BD系数 (默认BD系数为4)

如果设置频率为200MHz,那么实际频率为50MHz(默认就是200MHz,很显然50MHz处于临界状态,会出现一定概率不能正常启动的状态)

所以需要修改默认导出的频率到130MHz

但是还有几个疑点没有想明白

  • 还有在没有修改频率的情况下(200MHz)为什么可以烧写成功呢
  • 为什么烧写BOOT.bin(FSBL.out和helloworld)无法启动;烧写golden的BOOT.bin(FSBL.out和u-boot)可以启动

烧写过程是bootrom-->fsbl-->u-boot

全程bootmode在jtag方式,所以fsbl并不会初始化qspi,只会初始化ddr,qspi的初始化在u-boot中进行,

u-boot在devicetree中设置了spi-max-frequency,目前为50MHz,BD系数为2-32,实际工作频率最高为50/2=25MHz,

实际启动后用md显示的BD系数仍为4,所以频率为50/4=12.5MHz。

所以可以烧写成功

BOOT.bin中打包的是fsbl和裸机程序/u-boot

启动过程为bootrom引导fsbl,fsbl引导裸机程序/u-boot。在fsbl执行阶段会初始化qspi flash,然后从qspi flash中读取裸机程序/u-boot到ddr中执行。

经过反复试验,BOOT.bin(FSBL.out 50MHz和helloworld)可以烧写成功,但是有一定概率无法启动成功 (bootrom-->fsbl 50MHz-->helloworld  这时候bootmode在qspi方式,fsbl以50MHz初始化qspi flash,以这个频率从qspi flash中读取helloworld到ddr中执行)

golden的BOOT.bin 不确定是什么版本的 proxxxx 导出的,默认的qspi频率是多少并不明确(FSBL.out ??MHz和u-boot),于是重新做了一个BOOT.bin(FSBL.out 50MHz和u-boot)(bootrom-->fsbl 50MHz-->u-boot  这时候bootmode在qspi方式,fsbl以50MHz初始化qspi flash,以这个频率从qspi flash中读取u-boot到ddr中执行)

也出现了u-boot有时候可以正常启动,有时候只启动到一半就挂了的现象,板子断电久了,qspi flash温度低了,可以正常启动,如果一直开着板子,大概率启动不了(qspi flash温度高)

所以,可以烧写qspi flash但是无法启动的问题定位于频率问题,需要降低qpsi的频率。

原文地址:https://www.cnblogs.com/idyllcheung/p/12628367.html

时间: 2024-11-13 08:18:33

flashloader的问题解决过程的相关文章

CrossApp 0.3.1示例编译问题解决过程

1 AlertTest.h找不到 问题成因:HelloCpp工程中头文件搜索路径没有增加Classes目录,需要自己加进去.(另外由于这些文件都是在子目录中,用递归模式也行,逐个子目录添加也行) 2 CrossApp lib编译错误. (1) Unknown register name 'q0' in asm 按照网上说法,把对应的#if defined(__ARM_NEON__)替换成 #if defined(_ARM_ARCH_7)即可. (2) "Cast from pointer to

记录sqoop同步失败问题解决过程,过程真的是很崎岖。(1月6日解决)

记录sqoop同步失败问题解决过程,过程真的是很崎岖.事发原因:最近突然出现sqoop export to mysql时频繁出错.看了下日志是卡在某条数据过不去了,看异常.看sqoop生成的mr并未发现问题.最后把要export的原始数据拿notepad++打开发现中断的数据是奇怪的乱码,查了一下是二进制的数据. 乱码数据生成原因:我理解,api接口时接收流数据时长度和实际长度不符. 解决办法:两块要解决,一是接口时做好容错,二是同步时还是要对这种二进制做兼容,因为谁也无法保证二进制数据不会再出

局域网上网问题解决过程

前几天局域网改了ip之后就突然不能上网,以为是ip冲突,于是又换一个,这样换了n个,依然上不了,每次都是改了以后显示已连接,数秒之后显示受限,以为是网卡驱动的原因,卸了装卸了又装,重复n遍之后木有任何效果.后来又以为是硬件原因,ping了局域网中其它机器的ip,能ping通,这说明网卡应该还是可以收发数据应该没坏的,但为什么就是不能上网呢?启动windows自带的问题诊断,显示dns未响应,(后来发现,这尼玛坑啊太多原因能导致这个结果了),于是乎又开始查看dns服务有没有启动,又换了几个常用dn

一个测试问题解决过程

邮件提醒来了一个测试问题需要我分派,文本框输入a:b:c(业务需要,内容以英文冒号分隔),"系统提示xxx格式不规范,系统未将全角:转换为半角.",我看完未过多细想,flex前端没做过,易用性问题,直接分派给功能开发人员小王同学,接下来发生了一些事情. 小王开始抱怨,有病啊,没事开什么全角输入,怎么测试呢-: 小王找我这问题不改了,让把问题打回,有一个理由控制BUG数量: 咋一看,小王说的有道理啊,琢磨了一下,不对啊,(情绪上不能对立,测试也是为了产品质量)测试不至于这么测吧,问题里说

CRS-0184问题解决过程

近日,公司搭建的ORACLE 11G RAC 出现故障,整个故障的排错思路大概持续了一周左右,最终确定了问题原因,现在简介下ORACLE 11G RAC的环境: jbdb1 IBM P740  AIX 6100-08-02-1316 jbdb2 IBM P740  AIX 6100-08-02-1316 Oracle 11G 11.2.0.3 grid and database 当日,软件人员说无法连接数据库,我就很纳闷,于是就登录到系统,通过查看群集发现整个RAC有异常,正当我查看群集状态时候

shiro realm 注解失败问题解决过程

做为一名在.net混了八九年的老兵油子,转战java时间并不长,刚开始做项目完全是凭借对C#的认识来做,虽然遇到一些问题,但实际结果显示C#在语言上和java还是有很大相似度,而且微软的MVC与Spring MVC也是那么的神似,这也是为什么我在做项目前并未对java进行系统的学习也能做项目的原因.最近稍微有些空闲时间,所以决定从基础开始系统的学习java,这里并没有太多高深技术可分享的,本篇给大家分享我解决问题的一个经验:触类旁通或者叫举一反三,对了还有一点,对于存在可优化点的部分要不轻言放弃

一次网站停止访问的问题解决过程,原因令人崩溃

最近对单位网站进行了改版,在本机和测试服务器测试了很久都没有问题,于是今天就部署到服务器上线了.同时.net framework版本由2.0升级到4.0.部署完测试了一下,没问题,就放出来了.一公布,大家纷纷点击.不一会儿,有人报告说访问不了了.一试,果然.大家赶紧到服务器查看,没发现什么异常.过了一会又好了.正当大家莫名奇妙时,又访问不了了,大家首先判断是不是程序池满了,但是很快发现同一个服务器上的其他网站也打不开,这些网站并不是同一个程序池.然后在服务器上访问了一下,可以打开.又利用其他ip

Exchange 2013诡异问题解决过程分享

一.问题现象 我现在遇到一个问题,我的环境情况是:WIndows  server 2012 R2 + Exchange 2013 CU12(CAS使用NLB,Mailbox使用DAG)环境.我在外网用户使用Outlook 2013 配置Outlook Anywhere模式,在发送邮件过程中经常出现很久才能发送,发送到邮件一直保留在发件箱中.在客户端等待30分钟以上后邮件才能自动发出去,或者重启OUtlook也可将邮件发送出去.在计算机客户端的应用系统日志里面有Event ID Outlook 2

[mysql]一次主从数据不一致的问题解决过程

之前一篇: 主从更换ip之后重新建立同步 情况时这样的 昨天晚上主动2个机器都迁移了,然后今天才把主动重新连接上,但是从库的偏移量是从今天当前时刻开始的,也就是说虽然现在主动看似正常,其实是少了昨天的部分数据,由于从库的数据丢失了,早晚还是要填坑的. 问题 要解决问题就是怎么对比不一致,然后在不影响业务的情况下,修复数据不一致的问题,把从库缺少的数据补上 下面是能想到和找到的几个方案 1 从新从0开始同步,虽然对主库的使用没有影响,但是那么大的数据量,对性能,网络影响有点大,数据丢失的应该很少