靠山
某个项目使用的介质是 spinor
, 其 bootloader
需要从 flash
中加载 os
。
启动速率是一个要害指标,需要深入优化。其他部门的优化暂且略过,此篇主要纪录对 nor
读速率的优化历程。
领会现状
接到启动速率优化的义务之后, 首先是领会情形。
当前的 bootloader
实测读速率只有约 4M/s
。
为了加快速率已经实验过
spinor
驱动改为使用四线读下令读取数据。速率并没有显著改善。待确认改动是否生效。spinor
驱动改为使用dma
搬运数据。尚未修改乐成。
盘算上限
既然是要深入优化,那知道终点在哪照样很有需要的。
整个读取历程,数据主要是从 spinor
到达 soc
的 spi
控制器,再由 cpu
或 dma
搬运到 dram
中的目的位置。
spinor --> spi控制器 --> cpu/dma --> dram
先来思量第一段的速率,这里对照好盘算。针对当前的 soc
和 flash
的组合,从规格书可得到最高的 spi
时钟频率为 100M = 100 * 10^6
,且读数据可使用 4
线读取,即 soc
和 flash
之间有 4
根数据线在并行传输数据。那么简朴算下 100 * 10^6 * 4bit = 400 * 10^6 bit/s = 47.68 MB/s
, 可知极限速率为 47.68 MB/s
。
固然较真一点,发送读下令给 flash
也需要时间,让我们来算下。
一样平常一个读下令需要 5 bytes
, 即 cmd + addr[3] + dummy
,以是现实的极限速率要思量每发一次读下令后读取若干数据。读下令是单线传输的,数据是四线传输。假设发一次下令读 nbytes
数据,则下令和数据所占时间的比例为 5:(n/4)
, 那么现实用于传输数据的 clk
就只有 (n/4) / (5 + n/4) * 100M
。4
线传输的情形下每个 clk
可传输 4bit
,从 bit
换算成 byte
再除以 8
,于是速率公式为 (n/4) / (5 + n/4) * 100M * 4 / 8
, 这里要注意对于巨细 1MB = 1024*1024 Byte
, 对于时钟 100M = 10^6
。
代入一些详细数据可得
每次读取bytes | 读速率 |
---|---|
64 | 36.33 MB/s |
256 | 44.23 MB/s |
1024 | 46.77 MB/s |
64k | 47.67 MB/s |
1M | 47.68 MB/s |
可以看出,若是每次读取数据量较小,那么发送读下令消耗的时间就不能忽视。每次读取的数据量越大,则读下令对速率造成的整体影响就越小。
后面的部门理论速率暂时没有很明确的盘算方式,那暂时先知道完整的数据是这么流动的就可以了。
确认瓶颈
看了下驱动打印出来简直实是 80M
的 clk
和 4
线的读下令,虽然还没调到最高时钟 100M
,但当前 4M/s
也完全对不上,到底是谁出了问题呢?时钟纰谬?四线没设置乐成?驱动存在 bug
? nor flash
物料的问题?
思索一下,要确认到底是谁的锅,最简朴明了的方式照样量下波形,不管软件驱动上怎么写,控制器的寄存器怎么配,最终照样得反映在波形上才是最真实的传输效果。接上示波器或逻辑分析仪,看看 spi
线上的情形,是谁的问题就一目了然了。
首先量一下 spi clk
线,可以发现读数据的历程中,clk
的信号不是延续的,在有信号时其频率是正常的,但大部门时间 clk
线上却是没有信号的。再量量数据线,可以确认到确实使用了 4
线读。
问题很显著,spi
控制器是在间歇性读数据,以是虽然读 nor
的时刻是 80M
的时钟频率举行读取,但把 spi
的空闲时间盘算进去,均摊下来的总的速率就只有 4M/s
了。
那为什么 spi
控制器会间歇性读取而不是一直在读取呢? 这就涉及到刚刚所说的数据流了,spi
控制器自己的 fifo
是有限的,当从 spinor
读取的数据填满 fifo
之后,就必须等着 cpu/dma
把数据取走,腾出 fifo
空间来,才气继续发送指令从 nor
取数据。那么这段空闲时间,应该就是在等 cpu/dma
取数据了。
验证 CPU
有了嫌疑偏向,那就得看下代码了。现在驱动中使用的是 cpu
来搬运数据,正常读取历程中,cpu
在执行以下代码
while 待读取数据计数值大于0
if (查询spi寄存器,判断到fifo中存在数据)
读取spi fifo寄存器数据,写到dram的buffer中
待读取数据计数值减1
若是是这里成为了瓶颈,那就有两个地方对照有嫌疑,一是读取 spi
寄存器,而是写 dram
。
做点实验确认下
实验一,实验下把写 dram
的操作去掉,使用如下操作,并由读取前后的 log
时间戳来判断耗时。
while 待读取数据计数值大于0
if (查询spi寄存器,判断到fifo中存在数据)
读取spi fifo寄存器数据
待读取数据计数值减1
重新测试下,发现速率没有显著转变。
实验二,实验下削减读 spi
寄存器的操作
while 待读取数据计数值大于0
读取spi fifo寄存器数据
待读取数据计数值减1
重新测试下,发现读速率翻倍了,达到了 8M/s
,看来果真是这里成为了瓶颈。没想到 cpu
读个 spi
寄存器竟然这么耗时。
改用 DMA
cpu
太慢,那就指望 dma
了。
先来解决 dma
驱动异常问题,领会下情形,原来这个 dma
驱动的支持是从另一个分支上移植过来的,原本事情正常,到了这个分支就翻车了。
这就是一个找差别的问题了,先对照下两个分支的差异,再将可疑的地方 checkout/cherry-pick
到另一个分支来验证。很快找到了要害因素 dcache
。
这个分支上是默认打开了 dcache
的,可见旧文 记一个bootloader的cache问题,而这就导致了 dma
驱动事情异常。
简朴点,关掉 dcache
试试,果真 dma
就正常了。测下速率,达到了 21M/s
。
再测试下不关 dcache
,在设置了 dma
描述符之后,刷一次 cache
再启动 dma
传输,也是正常的了。
优化设置
21M/s
的速率,看来瓶颈照样在 dma
这里。此时可以实验将 spi clk
从 80M
提高到 100M
,可以发现整体读速率没有转变,这也可以佐证当前瓶颈仍然不在 nor
的读取速率上面。
测个波形看看,果真 clk
线上照样间歇性的,不外空闲时间比之前少了许多。
dma
的速率能不能改善呢? 这就涉及到详细的芯片了,需要深究下 dma
控制器和 spi
控制器的设置。
优化 dma
和 spi
控制器的设置后,dma
从 spi
控制器取数据的速率,终于超过了 80M
时钟下的 spinor
读取速率,将 spi clk
修改为 100M
,测得读速率约 36M/s
。
优化驱动
前面说到,发送读下令给 flash
也需要时间,在 os
中受限于 buffer
巨细等,可能会限制每次读取和处置的数据量,但对于 bootloader
来说则完全可以一口气将所需的数据读入,无需分段。
另外可查看驱动中是否有无用的清空 buffer
之类的操作,一并优化掉。
提高时钟
驱动逻辑和寄存器上无法优化之后,还想提速,那么可以试试提高时钟。
提高 cpu
时钟和 dma
时钟,提高后测得速率约 47M/s
,基本就是理论极限了。
但详细能否提高时钟照样得郑重评估,单个板子可以正常运行,不意味能够稳固量产。
压缩镜像
在读取速率无法进一步优化的情形下,要提高启动速率,那就得削减读入的数据量了。
可以评估下使用压缩的镜像来削减读入的数据量,只要多出的解压时间不长于节省掉的读取 flash
时间,那就是划算的。
是否压缩,选择哪种压缩算法,就跟 io
速率,cpu
解压速率直接相关了,最好经由实测确认,综合启动速率和 flash
占用来选择。
其他
若是是带压缩的镜像,那启动速率就是读取时间+解压时间。
读取时主要是 io
操作,解压则主要是 cpu
操作。那么是否有可能实现边读取边解压,使得总的启动时间进一步缩短呢?这个待研究
blog: https://www.cnblogs.com/zqb-all/p/12824908.html
民众号:https://sourl.cn/4X3jE7
www.tggzfm.com展望2019年,将用完善的服务体系,创新的技术应用,雄厚的资金实力,贴心的服务品质,成为Sunbet会员、代理的首选平台。
网友评论
最新评论
申博sunbet:www.Lfstncnynmzyhzs.com信誉来源于每一位客户的口碑,Sunbet的服务在sunbet行业是出名的顶尖,广西禄福生态农业开发有限责任公司欢迎新老会员、代理的加入。还是有可读性
申博Sunbet: www.1888ss.com秉承以客为先的理念,多年运营、专业团队、专注服务、值得信赖。赞你一万年
诚信在线 :www.goldo.cn用诚信赢得信任、用服务赢得口碑、用技术赢得赞赏。新的一年到来,诚信在线将一如既往地服务好每位客户。坚持写下去,加油啊