Bootloader的启动过程可以分为单阶段、多阶段两种。通常多阶段的 Bootloader能提供更为复杂的功能以及更好的可移植性。从固态存储设备上启动的 Bootloader大多都是两阶段的启动过程。第一阶段使用汇编来实现,它完成一些依赖于CPU体系结构的初始化,并调用第二阶段的代码;第二阶段则通常使用C语言来实现,这样可以实现更复杂的功能,而且代码会有更好的可读性和可移植性。 一般而言,这两个阶段完成的功能可以如下分类:
进入cmd_bootm.c,找到对应的bootm命令对应的do_bootm():
本篇的重点是讲解设备和驱动的启动流程,设备和驱动的流程是整个内核启动的核心,也是工作中最常面对的问题。出于知识点的系统性考虑,在进入主题之前我们先看下整个 Linux 在 ARM 中的启动流程如何。
uboot 属于bootloader的一种,是用来引导启动内核的,它的最终目的就是,从flash中读出内核,放到内存中,启动内核
首先要明确:uboot目标是从flash读出内核(nand read.jffs2 0x30007FC0 kernel;),启动它(bootm 0x30007FC0)。
目标: (1)创建Source Insight 工程,方便后面分析如何启动内核的 (2)分析uboot传递参数,链接脚本如何进入stext的 (3) 分析stext函数如何启动内核: (3.1
博客地址 : http://blog.csdn.net/shulianghan/article/details/42462795
这周又一段时间没怎么写文章了,这周上班接触的东西有点多,每天都在接受挑战。维护公司移动app界面,设计到的技术是css、html、javascript。然后把写好的app程序通过threadx和Linux两个系统的支持(Linux内核版本是在3.10版本的,在安霸和海思平台);第一次搭建编译环境(这里跟平时学的环境有比较大的出路,作者被骂了好几次,终于是成功了,呜呜。。。),然后实时在PC或者手机端采集实时视频监控。后期会不断学习和分享自己在工作当中的一些经验给大家,希望对大家有帮助。今天开始写Uboot的文章和Linux驱动的文章。之前Linux应用的文章全部在公众号后台有。以上学习过程中,作者是学习朱有鹏老师的嵌入式课程。
在去深入分析一款芯片的使用的时候,往往需要关注其启动的流程与底层初始化的代码。只有掌握了这些信息,做代码优化和裁剪才能游刃有余,在特定的环境下,以最佳的方式去使用好芯片。
嵌入式软件工程师听说过 u-boot 和 bootloader,但很多工程师依然不知道他们到底是啥。
编写目的:本文档作为Allwinner Tina Linux系统平台开发指南,旨在帮助软件开发工程师、技术支持工程师快速上手,熟悉Tina Linux系统的开发及调试流程。
如何阅读代码还要单独写一篇文章?难道不是随便用一个IDE就可以了吗?回到上一篇文章里介绍的那个问题,需要修改uboot里board_mmc_init函数里的writel(0x66666666,REG_MFP_GPD_L) ,对于初学者如何在uboot代码里找到这句话呢?当时问我这个问题的网友就有这个困惑。
从启动引导程序 bootloader(uboot)跳转到 Linux 内核后,Linux 内核开始启动,今天我们分析一下 Linux 内核启动入口。
最近有一些riscv的项目做,虽然以前也用过例如k210之类的riscv架构的芯片,但是都止于能够做一些应用,并未特别关注其芯片的体系架构方面的东西,但是随着接触的芯片架构的种类的逐渐的增加,发现要想使用一款好芯片的,仅仅做上层应用并不能完全发挥出特定架构芯片的全部优势。比如aarch64的el层级和虚拟化的模型,mips的mmu特性,以及sparc的窗口寄存器等等,芯片架构的特点要是能够完全的发挥出来,写起应用起来,那真是觉得很爽的事情。
atf基本启动流程为:BL1 – BL2 – BL31 – BL32 – BL33(uboot),即在bl32启动完成后再启动uboot,uboot作为启动链中作为最后一级镜像,用于启动最终的os。Atf是arm为了增强系统安全性引入,只支持armv7和armv8架构的可信固件。而uboot是通用的嵌入式系统引导程序,其可以支持包含arm在内的多种处理器架构,如mips、riscv、powerpc以及x86等,且其历史比atf更加久远。因此默认情况下uboot并不需要与atf共同启动,而其自身就被设计为支持完整的多级启动链,该启动链被设计为最多可包含spl、tpl和uboot三个阶段。接下来我们通过一些典型启动流程,来看下这些阶段的一些组合关系吧。
整个嵌入式系统的加载启动任务完全交给Bootloader完成,它的主要任务是将内核映象从硬盘读到RAM中,然后跳转到内核入口启动内核(操作系统)!通俗来讲,Bootloader的作用就是初始化硬件,启动操作系统。
一般嵌入式系统使用的都是对称多处理器(Symmetric Multi-Processor, SMP)系统,包含了多个cpu, 这几个cpu都是相同的处理器,如4核Contex-A53。但是在系统 启动阶段他们的地位并不是相同的,其中core0是主cpu(也叫引导处理器),其他core是从cpu(也叫辅处理器),引导cpu负责执行我们的启动加载程序如uboot,以及初始化内核,系统初始化完成之后主core会启动从处理器。
原文地址:http://www.cnblogs.com/jacklu/p/6226330.html
前一阵子在公司移植Linux2.6到一块ARM11的开发板上,下面粗略讲讲移植Linux的一般过程。
前进几篇文章,已经搞定了Linux移植三巨头:uboot、kernel(包含dtb)和rootfs,除了uboot是烧写在SD中的,其它的都是在ubuntu虚拟机的nfs服务器中,运行时必须通过网络将这些文件加载到开发板的内存中运行。
上电后,片上的 BootROM code 会将启动的 bin 文件拷贝到 ocram 中运行, ocram 通常只有4kb,甚至更小。所以将 uboot 中放到 ocram 中运行是不现实的。故 SPL 应运而生,SPL(Secondary Program Loader) 是一个非常小的 bin 文件,足以加载到 ocram 中运行。SPL 在 ocram 运行起来以后会将 uboot 加载到外部 DDR 中运行,uboot 运行在 DDR 中,则不受空间大小限制,可以进行复杂的操作。支持包括不同文件系统、脚本执行、多种操作系统加载等等操作。其中主要的工作是从存储设备中读取 kernel,解析后跳转到 kernel 执行。
我属于提前批拿到哪吒开发板的,兴奋之余开始研究如何去运行自己的裸机程序,美其名曰:操作系统.
因为嵌入式往往需要把程序放到板子上去运行,而再树莓派上做rt-thread开发调试的时候,通常有三种办法。
最新 Linux 内核是 5.15 版本。现在常用 Linux 内核源码为4.14、4.19、4.9 等版本,其中 4.14 版本源码压缩包大概 90+M,解压后 700+M,合计 61350 个文件。如此众多的文件,用 source insight 或者 VSCode 查看都会比较卡,所以可以采用在线查看的方式。
参考博文: http://blog.51cto.com/9291927/1791237
设备上一共有四个网口,一个是原生的mac,另外三个是USB扩展的RTL8152,为了生产时候方便mac地址统一,所以需要所有的mac地址都存在一个存储空间里,然后四个mac去获取设置。这里比较简单的是将ethaddr这些参数在uboot通过bootargs传递给内核驱动。设备上有一个eeprom,可以把mac存储在里面,uboot启动时候去读取,然后设置到环境变量,再传递给内核的mac驱动。
之前做过一次uboot的升级,当时留下了一些记录,本文摘录其中比较有意思的两个问题。
前一篇《第一款能运行Android11 的RK3399开发板tinkerboard2》已经对tinkerboard2的Android 11有个大致的介绍,这一期来聊聊tinkerboard2 Android11 SDK bootloader部分的编译与烧录验证。后续的文章会从多个方面详细介绍如何基于官方的SDK定制一套Android固件。
打开uboot.lds,发现链接地址为0,所以新的uboot只能在nor flash运行。运行开始文件为start.o。
上一篇我们讲了 Linux 系统的启动流程,本文讲解一下 Andorid 系统的启动流程。
摘要总结:本章节分析uboot阶段2的硬件初始化过程,包括启动kernel、进入菜单和进入u-boot界面等步骤。
启动速度是嵌入式产品一个重要的性能指标,更快的启动速度会让客户有更好的使用体验,在某些方面还会节省能耗,因为可以直接关机而不需要休眠。
在做嵌入式 Linux 开发的时候,经常会阅读大型工程源码,比如 uboot 源代码,Linux Kernel 源码等,所以,选择一个合适的工具来阅读源代码,变为了一个经久不衰的话题。
IIC EEPROM,采用的是IIC通信协议。 IIC通信协议具有的特点: 【1】简单的两条总线线路,一条串行数据线(SDA),一条串行时钟线(SCL); 【2】串行半双工通信模式的8位双向数据传输,位速率标准模式下可达100Kbit/s; 【3】一种电可擦除可编程只读存储器,掉电后数据不丢失,由于芯片能够支持单字节擦写,且支持擦除的次数非常之多,一个地址位可重复擦写的理论值为100万次,常用芯片型号有 AT24C02、FM24C02、CAT24C02等,其常见的封装多为DIP8,SOP8,TSSOP8等;
前面讲解的很多内容都很抽象,所以本次系列决定"接点地气",准备开始讲解大家熟悉的Activity了,为了让我以及大家更好的理解Activity,我决定本系列的课程主要分为4大流程和2大模块。 4大流程如下:
一个IoT设备,官方不提供固件包,网上也搜不到相关的固件包,所以我从flash中直接读取。因为系统是VxWorks,能看到flash布局,所以能很容易把uboot/firmware从flash中分解出来。
本文主要介绍了如何制作一个简单的U-Boot启动加载程序。首先介绍了U-Boot的架构和主要功能,然后详细描述了如何制作U-Boot的启动加载程序。最后,给出了一个示例代码和相关的工具链。
启动速度是嵌入式产品一个重要的性能指标,更快的启动速度会让客户有更好的使用体验,在某
内核最终目的:运行根文件系统的应用程序 内核做的事情: 处理uboot传入的参数 arch\arm\kernel /*启动内核:bi_arch_number机器ID。参数存放的地址 bd->bi_boot_params*/ theKernel (0, bd->bi_arch_number, bd->bi_boot_params); 判断是否支持单板(根据启动内核时传入的机器ID) /**/ ENTRY(stext) msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MOD
CodeQL是一个白盒源码审计工具,它以一种非常新颖的方式组织代码与元数据,使研究人员能够“像查询数据库一样检索代码”,并发现其中的安全问题。GitHub于去年收购了开发CodeQL的公司Semmel,并与其联合成立了GitHub Security Lab,Semmel在此前推出了面向开源社区和企业的源代码分析平台LGTM,这个平台能够自动化的发现并预警GitHub上开源软件的安全问题,同时,与CodeQL一样对开源社区与开发者保持免费。
Zynq的程序分为三部分,上电启动的引导程序(fsbl),FPGA的程序,arm程序。这里以arm程序存储位置为主进行讨论。
写的是Zynq 7000系列的,arm有两个核。主要有AMP和SMP两种方式,SMP是两个核运行一个操作系统,跑LINUX的话,使能SMP,资源会自动分配给两个核运行。AMP是两个核独立运行,每个核可以运行操作系统也可以裸机运行。
最先执行的是汇编文件start.S,这个文件跟架构有关,例如芯片架构是arm926ejs,那路径就在*arch/arm/cpu/start.S*。
领取专属 10元无门槛券
手把手带您无忧上云