OpenHarmony轻量设备Hi3861芯片开发板启动流程分析

csdn推荐

引言

OpenHarmony作为一款万物互联的操作系统,覆盖了从嵌入式实时物联网操作系统到移动操作系统的全覆盖,其中内核包括LiteOS-M,LiteOS-A和Linux。LiteOS-M内核是面向IoT领域构建的轻量级物联网操作系统内核,主要面向没有MMU的处理器,架构如图1-1所示。

图1-1 LiteOS-M架构图

Hi3861是一款高度集成的2.4GHz SoC WiFi芯片,采用高性能 32bit 微处理器,最大工作频率 160MHz,内嵌 SRAM 352KB、ROM 288KB、Flash 2MB。目前市面上的采用LiteOS-M的OpenHarmony开发板厂商有深开鸿、润和软件、小熊派,因为海思的SDK是以库文件的形式提供的,所以不同的Hi3861芯片开发板启动流程是一样的。

Hi3861 Boot介绍

Boot是操作系统启动之前的软件,通用叫法是bootloader,Hi3861的boot分为4部分:RomBoot、FlashBoot、LoaderBoot、 CommonBoot,如图2-1所示。

图2-1 Hi3861 Boot启动流程

● RomBoot功能包括:加载LoaderBoot到RAM,进一步利用LoaderBoot下载镜像到Flash、烧写 EFUSE, 校验并引导FlashBoot。FlashBoot分为AB面,A面校验成功直接启动,校验失败会去校验B面,B面校验成功会修复A面再引导启动,否则复位重启。

● FlashBoot功能包括:升级固件,校验并引导固件。

● LoaderBoot功能包括:下载镜像到Flash, 烧写EFUSE(例如:安全启动/Flash加密相关密钥等)。

● CommonBoot为Flashboot与LoaderBoot共用的功能模块。

相关文件介绍

Hi3861的LiteOS-M代码是SDK中以库文件的形式提供的,虽然我们无法看到源代码,但这不代表我们分析不了启动流程,我们可以从分析map文件和asm这两个文件入手。这两个文件都是编译链接工具生成的,其中asm文件是汇编程序源文件,可以查看函数之间的调用关系,map文件里包括全局符号、函数地址及占用的空间和位置。map和asm文件主要作用是当开发板崩溃时用于分析其崩溃的原因,我们分析函数跳转关系时并不需要知道太多汇编,只需要知道基本的跳转语句和赋值语句即可,这两个文件位于out目录下和操作系统固件平级的目录,如图3-1。

图3-1 Hi3861 asm和map文件位置图

一个编译完成的固件通常有以下几部分:

RO段包括只读代码段(code段/.text段)和常量段(RO Data段/.constdata段)。

RW段(.data段)指已被初始化成非0值的变量段。

ZI段(.bss段)指未被初始化或初始化为0的变量段。

我们源代码的函数和字符串常量都位于text段。

LiteOS-M启动流程介绍 嵌入式处理器和操作系统都具有类似的结构启动流程也大体相似,从芯片上电开始Boot把控制权交给操作系统,Hi3861从Boot跳转到操作系统代码如下:

这部分是将该地址当函数作为跳转,因为FlashBoot和kernel,是两套代码程序,他们之间没有依赖引用关系,但是他们在一个地址空间,所以直接地址跳转,这也是从Boot到kernel通用的跳转方式。

芯片启动是从中断向量表的复位中断处理程序开始,接着把数据从Flash复制到RAM、清空bss数据段、初始化时钟、跳转到main函数。我们通过查看asm文件的main函数,可以看出其中调用的函数如图4-1所示,从图4-1 我们可得知调用的函数包括设置串口、校验版本号、配置板子、Kernel初始化、应用初始化和操作系统的调度运转,其中main函数位于liblitekernel_flash.a(main.o)文件中。

图4-1 main函数调用关系

LOS_KernelInit是负责初始化内核数据结构的,如图4-2所示,主要函数有OsMemSystemInit(内存初始化)、OsHwiInit(中断初始化)、OsTaskInit(任务初始化) ,这些过程主要目的是把内核相关的变量初始化,准备好全局信息,方便API函数去调用,API函数调用必须在这些初始化完成后才可以。

从AppInit开始脱离了sdk,可以看到源代码了,AppInit函数位于libwifiiot_app.a(app_main.o)中,部分截图如图4-3,源代码为app_main.c,其中调用的函数包括获取sdk版本号,外设初始化,ipc初始化,flash分区,WiFi初始化,tcp/ip初始化,然后跳转到了OpenHarmony特有的函数OHOS_Main。

OHOS_Main位于libwifiiot_app.a(ohos_main.o)中,源代码为ohos_main.c,主要完成OpenHarmony系统相关和用户应用相关的调用,里边主要函数是OHOS_SystemInit,如图4-4,在其中调用了用户自己写的应用任务相关代码,如图4-5,从而实现了在LOS_start之前把任务列表填好,这样才能保证用户任务或定时等功能参与了系统调度。

图4-2 LOS_KernelInit函数调用关系

图4-3 app_main函数调用关系

图4-4 OHOS_Main函数调用关系

图4-5 OHOS_SystemInit函数调用关系

用户应用的启动原理 在图4-5中出现的函数MODULE_INIT(run),就是调用最终调用用户程序的代码。

这是个宏定义,展开的调用关系 :basestartupbootstrap_liteservicessourcecore_main.h定义,从MODULE_CALL、MODULE_BEGIN 、MODULE_END,最终调用的地址是__zinitcall_##name##_start,MODULE_INIT(run)调用的函数地址是__zinitcall_run_start。

通过查看链接文件得出__zinitcall_run_start包含.zinitcall.run0.init),如图5-1所示。

图5-1 __zinitcall_run_start链接关系

查看map文件发现我们自己的应用程序文件就在.zinitcall.run2.init中,如图5-2所示。

图5-2 led_exapmle文件在map中的位置

从运行角度看启动中调用到了应用程序led_exapmle,所谓位置为.zinitcall.run2.init,但我们在应用程序中的关联函数是SYS_RUN(LedExampleEntry),SYS_RUN的展开关系如图5-3所示,最终即是 zinitcall.run2.init,和程序运行时候的调用匹配在一起了。应用程序的调用关系就是编译链接阶段生成指定的段,初始化时调用指定段,这样实现了LiteOS-M的操作系统代码与应用程序代码的解耦。

图5-3 SYS_RUN的展开关系

总结

本文向大家讲述了在没有部分源代码的情况下,如何通过对map文件和asm文件的分析从而得出Hi3861芯片开发板LiteOS-M的启动流程。总体过程就是最小硬件系统的配置完成后,LOS_KernelInit负责初始化系统到一个合适的状态,AppInit调用OpenHarmony和应用相关代码,最后LOS_Start负责把操作系统运转起来。

为了帮助到大家能够更有效的学习OpenHarmony 开发的内容,下面特别准备了一些相关的参考学习资料:

OpenHarmony 开发环境搭建:

《OpenHarmony源码解析》: 系统架构分析:

OpenHarmony 设备开发学习手册:

OpenHarmony面试题(内含参考答案):

文章来源:https://blog.csdn.net/maniuT/article/details/139067584



微信扫描下方的二维码阅读本文

© 版权声明
THE END
喜欢就支持一下吧
点赞6 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容