首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

Uboot学习(一)之为啥要有Uboot这玩意

这周又一段时间没怎么写文章了,这周上班接触的东西有点多,每天都在接受挑战。维护公司移动app界面,设计到的技术是css、html、javascript。然后把写好的app程序通过threadx和Linux两个系统的支持(Linux内核版本是在3.10版本的,在安霸和海思平台);第一次搭建编译环境(这里跟平时学的环境有比较大的出路,作者被骂了好几次,终于是成功了,呜呜。。。),然后实时在PC或者手机端采集实时视频监控。后期会不断学习和分享自己在工作当中的一些经验给大家,希望对大家有帮助。今天开始写Uboot的文章和Linux驱动的文章。之前Linux应用的文章全部在公众号后台有。以上学习过程中,作者是学习朱有鹏老师的嵌入式课程。

02

dpdk 性能_第二系列什么意思

首先,DPDK和内核网络协议栈不是对等的概念。 DPDK只是单纯的从驱动拿数据,然后组织成数据块给人用,跑在用户态。功能相当于linux的设备无关接口层,处于socket之下,驱动之上。只不过linux协议栈的这部分在核心态。 你说的包处理器,很多时候是不用linux内核协议栈的,而是用专用包处理程序,类似于DPDK加上层应用处理。通常会有些硬件加速器,包处理效率更高些。缺点是一旦用不上某些功能,那些加速器就白费了。而纯软件处理就非常灵活,不过代价就是功耗和性能。 纯DPDK性能非常高,intel自己给出的数据是,处理一个包80时钟周期。一个3.6Ghz的单核双线程至强,64字节小包,纯转发能力超过90Mpps,也就是每秒9千万包。 不知你有没有看出来,80周期是一个非常惊人的数字?正常情况下,处理器访问一下ddr3内存都需要200个周期,而包处理程序所需要操作的数据,是从pcie设备送到ddr内存的,然后再由处理器读出来,也就是说,通常至少需要200周期。为啥现在80周期就能完成所有处理?我查了下文档,发现原因是使用了stashing或者叫direct cache access技术,对于PCIe网卡发过来的包,会存在一个特殊字段。x86的pcie控制器看到这个字段后,会把包头自动塞到处理器的缓存,无序处理器来干预。由于包头肯定是会被读取的,这样相当于提前预测,访问的时间大大缩短。 如果加上linux socket协议栈,比如跑个纯http包反弹,那么根据我的测量,会掉到3000-4000周期处理一个包,单核双线程在2.4Mpps,每秒两百四十万包,性能差40倍。 性能高在哪?关键一点,DPDK并没有做socket层的协议处理,当然快。其他的,主要是使用轮询替代中断,还有避免核心态到用户态拷贝,并绑定核,避免线程切换开销,还有避免进入系统调用的开销,使用巨页等。 还有很关键的一点,当线程数大于12的时候,使用linux协议栈会遇到互斥的瓶颈,用性能工具看的话,你会发现大部分的时间消耗在spin_lock上。解决方法之一是如github上面的fastsocket,改写内核协议栈,使包始终在一个核上处理,避免竞争等。缺点是需要经常自己改协议栈,且应用程序兼容性不够。 另外一个方法是使用虚拟机,每个特征流只在一个核处理,并用虚拟机隔绝竞争,底层用dpdk做转发,上层用虚拟机做包处理,这样保证了原生的linux协议栈被调用,做到完全兼容应用程序。不过这种方法好像还没有人做成开源的,最近似的是dpdk+虚拟交换机ovs的一个项目。 如果你只想要dpdk的高性能加tcp/ip/udp的处理,不考虑兼容性,那么还可以去买商业代码,我看了下供应商的网站介绍,纯转发性能大概在500-1000周期左右一个包。

01

DM368开发 — 毕设之硬件[通俗易懂]

TMS320DM368 是德州仪器公司(TI)于2010 年4 月推出的新一代基于Davinci 技术的高清视频处理器,内部集成了一颗 ARM 内核和两个视频图像协处理器,同时内部还集成了一个视频处理子系统和丰富的系统外设[31]。芯片采用的 65nm 的制造工艺技术,性能稳定,成本低,单片价格约为 100RMB。ARM 内核是基于 ARM926EJ-S 的 RISC处理器,是整个 TMS320DM368 处理器的核心,执行整个系统的控制功能。两个视频图像协处理器分别为高清视频编解码处理器 HDVICP(HD Video Imagging Co-Processor)和 MJCP(MPEG-4 JPEG Co-Processor),支持 H.264、MPEG-2、MPEG-4、MJPEG 以及 VC1 等视频格式的编解码[32],HDVICP 最高可支持 1080p@30pfs 的高清视频 H.264 格式编码,MJCP 最高支持 1080p@25pfs 的 MPEG4 格式编码,功能十分强大。视频处理子系统 VPSS(Video Processing Subsystem)中包括视频处理前端 VPFE(Video Processing Front End)和视频处理后端 VPBF(Video Processing Back End)。视频处理前端包含有图像传感器接口、图像管道接口、图像管道,支持噪声过滤、视频稳定、自动白平衡、自动对焦、自动曝光、人脸检测以及边缘增强等影像增强技术,可显著提升视频处理的智能化水平[33]。视频处理后端包括屏幕显示、视频编码器和数字LCD控制器,不仅可将多个窗口的视频数据混合显示,同时还支持模拟 SDTV、数字 HDTV 和数字 LCD 等多种形式的视频输出。DM368 内部集成了多种常用的外设控制器,提供了丰富的外设接口,可实现视频编解码应用中与大多数外设器件的无缝连接。DM368的结构功能框图如图3.1 所示。

02

基于ZYNQ非对称的ARM双系统,如何实现工业产品的低延时

现代工业设备系统要求越来越复杂,既要强大的多任务的事务处理能力,又需要低延时实时任务处理能力的需求,特别是工业自动化控制领域(如数控机床、机械臂)、电力监测领域(如DTU、继保设备、一二次融合设备)等应用场景尤为迫切。为了满足日益复杂的系统要求,基于Xilinx Zynq-7020/7010实现的双系统解决方案。 Xilinx Zynq-7020/7010是一款集成双核ARM Cortex-A9 + Artix-7 FPGA架构的单芯片SoC,它的OpenAMP框架可实现双核ARM Cortex-A9非对称使用方案,从而使双核ARM实现分别跑两个系统:一个ARM Cortex-A9跑Linux,一个ARM Cortex-A9作为实时核跑RTOS(FreeRTOS)或者裸机。实时核与FPGA端进行低延时的高速数据交换与实时通讯控制,低延时的实时任务要求。而跑Linux的 ARM核作为更上层应用,处理更复杂的业务事务。

03

ZCU102 休眠到内存(suspend-to-ram)对DDR复位信号的设计

Xilinx的开发板ZCU102支持休眠到内存(suspend-to-ram)。休眠到内存时,DDR进入自刷新,MPSoC被关电,完全不耗电。唤醒时,MPSoC根据外部输入信号判断出不是上电启动而是休眠,就从DDR读出系统状态,恢复系统。 MPSoC启动时,它的DDR控制器会驱动DDR的复位信号,有可能破坏DDR里的数据。为了避免这种情况,需要对DDR复位信号进行特殊设计。 在开发板ZCU102上,DDR复位信号由外部单片机MSP430和MPSoC联合控制,两个的控制信号经过SN74AUC1G32(2输入或)再连接到DDR内存条。MSP430的信号有下拉,缺省情况下只由MPSoC控制DDR复位信号。如果需要支持休眠到内存(suspend-to-ram),MSP430控制I2C芯片输出高,相当于屏蔽了DDR复位功能,使DDR内存条一直不被复位。

03
领券