大狗熊的博客

文章说明：calmarrow（lqm）原创 文章引自： http://piaoxiang.cublog.cn       制作了一些patch，方便自己的学习和开发。随着后面的学习，会更新此处。   1、消除make menuconfig时，lxdialog几处warning的patch   文件: vivi_lxdialog.patch.gz 大小: 0KB 下载: 下载   2、去除reset_handler功能的patch   文件: vivi_reset_handler.patch.gz 大小: 1KB 下载: 下载   3、改进vivi的延时机制的patch   文件: vivi_timer.patch.gz 大小: 1KB 下载: 下载   4、移植到EDUKIT-III的patch（s3c2410从nand flash启动）   文件: vivi_s3c2410_nand_basic.patch.gz 大小: 7KB 下载: 下载

文章说明：calmarrow（lqm）原创 文章引自： http://piaoxiang.cublog.cn       到今天，vivi源代码基本分析完毕。对bootloader有了更深层的认识。在此期间，仔细阅读了毛德操、胡希明先生编著的《嵌入式系统--采用公开源代码和StrongARM/XScale处理器》第七章：嵌入式系统的引导和装入。看了看出版时间，才明白牛人詹荣开或许也受惠于此书。他在IBM Development上发表的那篇《嵌入式bootloader技术内幕》一文，后来在sourceforge上的开源项目jtager，在此书中有详尽的描述。（当然，他们可能是独立研究的。）两者结合起来看，对自己的帮助非常大。       现在看来，bootloader主要的工作量有三个：一是根据开发板，确定硬件初始化部分；二是内存初始化，不过内存检测技术相对比较成熟了；三是读写存储介质，包括nor/nand flash或者其他。设置内核传递参数相对前面还是比较简单的。如果完成这些基本功能，一个比较简单的实现就是blob；vivi虽然也比较小，但是还是比blob大一些，也复杂一些。有了这个基本的框架，如果公司是为了推销自己的SoC，那么会做Demo板，也就是所谓的"公版"，为之开发bootloader，并不打算支持更多的SoC，比如blob，vivi都是这样。他们的功能并不完善，如果后来的维护者想要增强功能，一是在下载手段上下功夫，比如增加tftp下载或者usb下载，二是在支持文件系统方面做工作。另外有机构专门开发并维护bootloader，想要支持尽可能多的SoC，比如uboot，它就可以在软件架构方面更多的考虑可扩展性，可移植性，同时增强上述手段，另外，可以增加monitor功能，在内核尚未移植完成的阶段增加调试手段。       由此形成了对bootloader比较全面的认识。要想继续深入bootloader，那么有下面的工作：       ・提高阅读datasheet，提取有用信息的能力。能够更快的开发出硬件初始化代码。     ・掌握内存检测算...

文章说明：calmarrow（lqm）原创 文章引自： http://piaoxiang.cublog.cn       下面进入Linux kernel部分，分析与bootloader参数传递对应的部分。       移植Linux需要很大的工作量，其中之一就是HAL层的编写。在具体实现上，HAL层以arch目录的形式存在。显然，该层需要与bootloader有一定的约定，否则就不能很好的支持。其实，这个地方应该思考一个问题，就是说，boot loader可以做到Linux kernel里面，但是这样带来的问题就是可移植性和灵活性都大为降低。而且，bootloader的功能并非操作系统的核心范畴，Linux的核心应该始终关注操作系统的核心功能上，将其性能达到最优。所以，bootloader分离出来单独设计，是有一定的道理的。bootloader现在除了完成基本功能外，慢慢地变得"肥胖"了。在高性能bootloader设计中，可能会把调试内核等的一些功能集成进来，这样在内核移植尚未完成阶段，bootloader可以充当调试器的作用。功能趋于完善，也慢慢趋于复杂。废话不说，进入正题。   三、Linux kernel接受参数分析       这部分主要分析如下问题：       ・Linux kernel支持压缩映象和非压缩映象两种方式启动，那么这两种流程和函数入口有何不同？     ・如何使用非压缩映象？做一下测试。     ・zImage是如何生成的？其格式如何？     ・启动之后，Linux kernel如何接收参数？       这里不具体区分每个问题，按照理解和开发的思路来进行。    1、思考：前面做的基本实验中，并没有采用压缩映象。因为程序规模太小，压缩带来的时间开销反而降低了性能。但是对Linux kernel来说，映象还是比较大的，往往采用了压缩。但是，同样有需求希望Linux kernel...

文章说明：calmarrow（lqm）原创 文章引自： http://piaoxiang.cublog.cn       在上一部分提到过了，vivi作为bootloader，向内核传递启动参数是其本职工作之一。要把这个情景分析清楚，不仅仅需要分析vivi的参数机制，而且要分析Linux kernel的接收机制。因为这是一个简单的通信过程，比起本科所学习的TCP/IP来简单的多，但是因为简单，所以在协议上并不规范，理解上反而不如TCP/IP协议。下面就分为两个方面对此情景分析。   一、综述内核参数传递机制       现在内核参数传递机制有两种：一种是基于struct param_struct，这种已经比较老了。缺点是该结构每个成员的位置是固定的，受限比较大。另外一种就是新的struct tag way。说新是相对的，Linux kernel 2.4.x都希望采用这种tag的方式。关于这方面的资料，可以有如下参考（所给出的目录是基于linux-2.4.18的内核，以顶层Makefile所在目录为当前目录。这里基于ARM架构的S3C2410，其他的SoC可以类比很容易得到）：   1、关于bootloader的理解--【Documentation/arm/booting】       此文档详细的讲述了bootloader的作用，具体内容如下：   [ armlinux@lqm arm ] $ cat Booting                         Booting ARM Linux                     ...