关于MTK启动过程详解
时间：10-02
整理：3721RD
点击：
关于mtk启动过程详解是本文要介绍的内容，主要是来了解MTK在启动过程中的一些原理。MT6305上电给基带芯片供电，在一定时序条件后，给基带芯片复位信号，开始了ARM核的启动过程。要谈启动，我们必须熟悉Scatterfile、基带资料的memorymapping章节。Scatterfile定义了loadregion和excecuteregion，我们要关心系统运行时代码、数据的地址分布。
Bootarm.s是一个重要的文件，与启动过程有关，其中的INT_Initialize函数是ARM启动开始执行的代码。BSP所做的事情主要包括:
1、配置PLL，配置基带芯片的EMI参数，以让系统能够以最大的速度读取外部存储设备数据，让CPU以最大速度运行，从而缩短启动过程。
2、做好runtime代码及数据的准备，确保excecuteregion的代码及数据到位。
3、配置好ARM七种异常模式的堆栈，进入RTOSnucleus的初始化。
4、nucleus留给客户的初始化函数Application_Initialize，做了平台该做的初始化工作，比如外部控制器的初始化等等。
RTOS
在分析系统问题，开发跨线程应用时，必须熟悉RTOS。目前使用的RTOS是nucleus，尽管在BSP中看到了它对ThreadX的支持。不同的RTOS，实际上也是大同小异，但是具体的API或者参数会有不同，因此我们需要下载nucleus的API文档，在需要了解细节时，可以翻阅此文档。同时，TRACE32支持基于RTOS级别的调试，因此对RTOS的了解，有助于提高调试能力。
有点特殊的是，nucleus有LISR,HISR的概念，实际上它是一种给开发者的印象。它告诉开发者，中断处理函数LISR要尽量的耗时短，以确保其它中断能有机会及时响应。HISR再处理略为次要些的工作，但耗时也不能太长，因为HISR比任何TASK的优先级都高，我们应该让真正需要实时的工作获取CPU的机会。
Application_Initialize中的mainp函数，负责任务的创建。我们在代码中见不到任务创建的函数，只需要维护任务初始化参数数据结构。对于系统的那些task信息，都保存在sys_comp_config_tbl变量中，我们看不到。但是MTK提供给客户的custom_comp_config_tbl，客户是可以修改的，在这里用户可以定义自己的task。
关于任务，需要关心数据结构comptask_handler_struct。关于comptask_handler_struct成员的执行顺序，应该是：comp_init_func在系统还未schedule即在Application_Initialize中完成，然后taskschedule后执行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我认为无太多意义。
task和module有什么区别?可以肯定的是，task是操作系统层面的概念，module是软件平台设计者因为某种需要而设计的，可能大家比我更清楚，但这种概念在具体工作中可能还是需要弄清楚。
到此，基于RTOS的各个TASK应该都已经调度起来。首先毫无疑问，idletask必须是优先级最低的task。按照常理，系统会从最高优先级的任务开始调度，至于如何跑到MMI显示LOGO界面，在必要时，我们可以去研究。
GUI机制
至于MMIframewok，我未做太多了解，但任何GUI系统面对的都是最终的LCDbufffer。但不同的是，MTK的基带芯片搞了个LCD控制器，并加了layer的概念，从硬件上支持2Dfunction和加速LCD的刷屏。对于上层的GUI，要做的是选择哪个layer是active。
LCD控制器的刷屏机制。以6225为例，支持4layer。MTK资料对LCD控制器未做详细的描述，是其对LCD接口块图的描述。但通过LCD控制器驱动，我们可以对LCD控制器内部结构做更多的假设。图1中的Overlay，我们可以设想为一个专有的DMA控制器通道，目标地址为LCD，源地址是layerbuffer。系统通过配置要刷哪几层，配置alpha值来控制2D效果。这一目的的达到，硬件上有它的考虑，我们也没有必要做太多确定性的假想。
需要说明的是，仅仅是这样一张图，我们应该有更多的联想。Layerbuffer都是从外部RAM开辟的内存空间，LCD的访问时序完全决定于如何配置LCD控制器。对Layerbuffer的读写，需要占用系统总线，即使再做总线上的区域规划，外部RAM的数据总线是公共资源。对公共资源的访问，就意味着并发，意味着仲裁ARBITER。为什么在以前的项目中，出现一些关于LCD的莫名其妙的问题，不能说这里是根本原因，但我们应该从系统的角度去注意到这点。我对资源的占有，就意味着别人的失去。以往被掩盖的缺陷，可能会因为系统运行时的变化，暴露出来。这就是我认为，有些系统问题，不能从代码表面去分析，而要从ARM核的角度，从同cache,BUS,controller等外围设备之间的联系来系统的分析问题。
关注一下开机LOGO的显示，是在uem_poweron_timer_expiry_hdlr函数中，同时这里做了latchpower的动作。还有潜力，提前显示出LOGO。
内存分配机制
在MTK的资料中，介绍了它的内存管理机制，有3种：ADM、Controlbuffer、SystemMemory。后两个是系统使用的，与上层应用无关。但是我对kal_system_alloc也做了初步分析。
sys_mem_ptr,其估计应该指向的是System_Mem_Pool，debug_mem_ptr,其估计应该指向的是debug_Mem_Pool。经过初步分析，kal_system_alloc就是从System_Mem_Pool做简单的加法操作，sys_mem_left_size就是System_Mem_Pool还剩下多少。kal_system_alloc从sys_mem_ptr开始来计算要取的内存。ctrl_buf是通过kal_system_alloc的内存，然后再通过NU_Create_Partition_Pool创建POOL。系统的一些taskstack.等也都是通过kal_system_alloc来分配的。
也就是说，Controlbuffer、SystemMemory用的都是System_Mem_Pool的空间。而System_Mem_Pool可以查到，是在custom_configmem函数中配置。
ADM就完全没有使用操作系统提供的内存管理算法，是平台自创了一套。开发者，可以自己开辟一个POOL,自己在这个池用ADM提供的内存管理API完成内存的动态管理。具体的分配算法，就没有再细看，跟一些通用的内存分配算法应该一致。但是在以前调试一个问题的时候，应该是可以断定，ADM在每一个allocnode前后都加了GAP调试区，来判断是否被overwrite。
至于系统中，到底是用了多少块内存用于ADM，各块内存又是让哪些应用在共享，开发者可能更清楚。在系统中是否建立了对内存动态分配的监控机制，比如查询内存泄漏、动态内存使用效率等等。
文件系统
文件系统用的是FAT格式，最关键的是如何MOUNT存储设备，如何匹配文件系统读写接口。MTK通过表格的形式来让客户选择支持的flash，真的是很方便，考虑太周到。
编译机制
MTK的makefile,写的很复杂，有perl脚本，也有make脚本，但框架结构很好。虽然我对makefile结构通读了一遍，但没有仔细花时间对此形成文档。
方案印象
MTK软件平台，接触了一年，总体感觉其底层代码写的很工整，结构很清晰。越到上层，代码就显的庞大凌乱，结构性和可读性都不强。如果把芯片设计也说上，我觉得MTK的基带芯片设计很智慧，针对特定的多媒体手机应用，设计出专门的控制器嵌入芯片内部。像UART控制virtrualfifo和CAMERA的resizer以及lcdcontroller，用低成本控制器来快速完成逻辑，从而减轻CPU的负担，提高芯片的整体性能。在其他多媒体处理器中，都是不多见的。
与业界认为从事MTK平台开发的技术含量低恰恰相反，我认为MTK方案技术含量非常高。MTK软件平台的代码开放程度也不低，MTK的技术支持也非常有力而迅速，以MTK平台为基础的终端承载了最丰富多样的应用。MTK方案给希望对手机平台有深入而全面了解的同事提供了机会。
基于MTK平台的产品开发
有那么多的公司在做基于MTK平台的产品，竞争那么激烈，研发上如何在竞争中体现优势?硬件上，大家都一样。软件上，也是一样。你可以有，别人也可以有或者偷，别人可以有，我们也可以有或者偷。最多是差个把月，怎么办。一个中心两个基本点。以服务好客户为中心，保证两个基本点，一是要快，二是差异。
拉不到客户什么就不要做了。在大家都差不多的情况下，我们以客户为中心，快速的满足客户需求，提供产品。这样能拉住客户，让客户找不到离开的理由。第二是产品差异，是创新。如果有产品创新最好，要么降低了成本，要么吸引了消费者。但这两点中，还是快字最重要，这是可以通过团队专业实力和激情来保证的。但是创新，有运气的成分，需要研发同市场碰撞出火花。鼓励和激励创新，但不能只靠产品创新一定会出现。
小结：
关于MTK启动过程详解的内容介绍完了，希望通过本文的学习能对你有所帮助！
【编辑推荐】
Bootarm.s是一个重要的文件，与启动过程有关，其中的INT_Initialize函数是ARM启动开始执行的代码。BSP所做的事情主要包括:
1、配置PLL，配置基带芯片的EMI参数，以让系统能够以最大的速度读取外部存储设备数据，让CPU以最大速度运行，从而缩短启动过程。
2、做好runtime代码及数据的准备，确保excecuteregion的代码及数据到位。
3、配置好ARM七种异常模式的堆栈，进入RTOSnucleus的初始化。
4、nucleus留给客户的初始化函数Application_Initialize，做了平台该做的初始化工作，比如外部控制器的初始化等等。
RTOS
在分析系统问题，开发跨线程应用时，必须熟悉RTOS。目前使用的RTOS是nucleus，尽管在BSP中看到了它对ThreadX的支持。不同的RTOS，实际上也是大同小异，但是具体的API或者参数会有不同，因此我们需要下载nucleus的API文档，在需要了解细节时，可以翻阅此文档。同时，TRACE32支持基于RTOS级别的调试，因此对RTOS的了解，有助于提高调试能力。
有点特殊的是，nucleus有LISR,HISR的概念，实际上它是一种给开发者的印象。它告诉开发者，中断处理函数LISR要尽量的耗时短，以确保其它中断能有机会及时响应。HISR再处理略为次要些的工作，但耗时也不能太长，因为HISR比任何TASK的优先级都高，我们应该让真正需要实时的工作获取CPU的机会。
Application_Initialize中的mainp函数，负责任务的创建。我们在代码中见不到任务创建的函数，只需要维护任务初始化参数数据结构。对于系统的那些task信息，都保存在sys_comp_config_tbl变量中，我们看不到。但是MTK提供给客户的custom_comp_config_tbl，客户是可以修改的，在这里用户可以定义自己的task。
关于任务，需要关心数据结构comptask_handler_struct。关于comptask_handler_struct成员的执行顺序，应该是：comp_init_func在系统还未schedule即在Application_Initialize中完成，然后taskschedule后执行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我认为无太多意义。
task和module有什么区别?可以肯定的是，task是操作系统层面的概念，module是软件平台设计者因为某种需要而设计的，可能大家比我更清楚，但这种概念在具体工作中可能还是需要弄清楚。
到此，基于RTOS的各个TASK应该都已经调度起来。首先毫无疑问，idletask必须是优先级最低的task。按照常理，系统会从最高优先级的任务开始调度，至于如何跑到MMI显示LOGO界面，在必要时，我们可以去研究。
GUI机制
至于MMIframewok，我未做太多了解，但任何GUI系统面对的都是最终的LCDbufffer。但不同的是，MTK的基带芯片搞了个LCD控制器，并加了layer的概念，从硬件上支持2Dfunction和加速LCD的刷屏。对于上层的GUI，要做的是选择哪个layer是active。
LCD控制器的刷屏机制。以6225为例，支持4layer。MTK资料对LCD控制器未做详细的描述，是其对LCD接口块图的描述。但通过LCD控制器驱动，我们可以对LCD控制器内部结构做更多的假设。图1中的Overlay，我们可以设想为一个专有的DMA控制器通道，目标地址为LCD，源地址是layerbuffer。系统通过配置要刷哪几层，配置alpha值来控制2D效果。这一目的的达到，硬件上有它的考虑，我们也没有必要做太多确定性的假想。
需要说明的是，仅仅是这样一张图，我们应该有更多的联想。Layerbuffer都是从外部RAM开辟的内存空间，LCD的访问时序完全决定于如何配置LCD控制器。对Layerbuffer的读写，需要占用系统总线，即使再做总线上的区域规划，外部RAM的数据总线是公共资源。对公共资源的访问，就意味着并发，意味着仲裁ARBITER。为什么在以前的项目中，出现一些关于LCD的莫名其妙的问题，不能说这里是根本原因，但我们应该从系统的角度去注意到这点。我对资源的占有，就意味着别人的失去。以往被掩盖的缺陷，可能会因为系统运行时的变化，暴露出来。这就是我认为，有些系统问题，不能从代码表面去分析，而要从ARM核的角度，从同cache,BUS,controller等外围设备之间的联系来系统的分析问题。
关注一下开机LOGO的显示，是在uem_poweron_timer_expiry_hdlr函数中，同时这里做了latchpower的动作。还有潜力，提前显示出LOGO。
内存分配机制
在MTK的资料中，介绍了它的内存管理机制，有3种：ADM、Controlbuffer、SystemMemory。后两个是系统使用的，与上层应用无关。但是我对kal_system_alloc也做了初步分析。
sys_mem_ptr,其估计应该指向的是System_Mem_Pool，debug_mem_ptr,其估计应该指向的是debug_Mem_Pool。经过初步分析，kal_system_alloc就是从System_Mem_Pool做简单的加法操作，sys_mem_left_size就是System_Mem_Pool还剩下多少。kal_system_alloc从sys_mem_ptr开始来计算要取的内存。ctrl_buf是通过kal_system_alloc的内存，然后再通过NU_Create_Partition_Pool创建POOL。系统的一些taskstack.等也都是通过kal_system_alloc来分配的。
也就是说，Controlbuffer、SystemMemory用的都是System_Mem_Pool的空间。而System_Mem_Pool可以查到，是在custom_configmem函数中配置。
ADM就完全没有使用操作系统提供的内存管理算法，是平台自创了一套。开发者，可以自己开辟一个POOL,自己在这个池用ADM提供的内存管理API完成内存的动态管理。具体的分配算法，就没有再细看，跟一些通用的内存分配算法应该一致。但是在以前调试一个问题的时候，应该是可以断定，ADM在每一个allocnode前后都加了GAP调试区，来判断是否被overwrite。
至于系统中，到底是用了多少块内存用于ADM，各块内存又是让哪些应用在共享，开发者可能更清楚。在系统中是否建立了对内存动态分配的监控机制，比如查询内存泄漏、动态内存使用效率等等。
文件系统
文件系统用的是FAT格式，最关键的是如何MOUNT存储设备，如何匹配文件系统读写接口。MTK通过表格的形式来让客户选择支持的flash，真的是很方便，考虑太周到。
编译机制
MTK的makefile,写的很复杂，有perl脚本，也有make脚本，但框架结构很好。虽然我对makefile结构通读了一遍，但没有仔细花时间对此形成文档。
方案印象
MTK软件平台，接触了一年，总体感觉其底层代码写的很工整，结构很清晰。越到上层，代码就显的庞大凌乱，结构性和可读性都不强。如果把芯片设计也说上，我觉得MTK的基带芯片设计很智慧，针对特定的多媒体手机应用，设计出专门的控制器嵌入芯片内部。像UART控制virtrualfifo和CAMERA的resizer以及lcdcontroller，用低成本控制器来快速完成逻辑，从而减轻CPU的负担，提高芯片的整体性能。在其他多媒体处理器中，都是不多见的。
与业界认为从事MTK平台开发的技术含量低恰恰相反，我认为MTK方案技术含量非常高。MTK软件平台的代码开放程度也不低，MTK的技术支持也非常有力而迅速，以MTK平台为基础的终端承载了最丰富多样的应用。MTK方案给希望对手机平台有深入而全面了解的同事提供了机会。
基于MTK平台的产品开发
有那么多的公司在做基于MTK平台的产品，竞争那么激烈，研发上如何在竞争中体现优势?硬件上，大家都一样。软件上，也是一样。你可以有，别人也可以有或者偷，别人可以有，我们也可以有或者偷。最多是差个把月，怎么办。一个中心两个基本点。以服务好客户为中心，保证两个基本点，一是要快，二是差异。
拉不到客户什么就不要做了。在大家都差不多的情况下，我们以客户为中心，快速的满足客户需求，提供产品。这样能拉住客户，让客户找不到离开的理由。第二是产品差异，是创新。如果有产品创新最好，要么降低了成本，要么吸引了消费者。但这两点中，还是快字最重要，这是可以通过团队专业实力和激情来保证的。但是创新，有运气的成分，需要研发同市场碰撞出火花。鼓励和激励创新，但不能只靠产品创新一定会出现。
小结：
关于MTK启动过程详解的内容介绍完了，希望通过本文的学习能对你有所帮助！
【编辑推荐】
- 关于MTK平台列表控件使用方法
- 详解关于MTK开发入门学习文档
- 浅谈MTK平台下Android开发比较学习笔记
- 解析MTK层一些函数及应用
- 详解MTK手机软件开发过程
- 详解MTK平台驱动调试指南GPIO设置篇