jz2440-2023-10-25

1、一般提到分析kernel的启动流程就要从strart.s入手，这是为什么？线索在哪里？因为烧录kernel时会使用到uImage，所以接下来去找uImage是如何生成的，通过源码顶层Makefile可以找到uImage是从vmlinux得到的，还是在该Makefile，可以找到vmlinux依赖于start.s。

2、根据uboot的bootargs命令行参数传递的“root=”字符在start.s中进行追踪时，可能会遇到一些标号名（或变量名）在整个内核源码source insight工程中都搜索不到的情况，因为这些标号是由带#连接符的宏定义经过展开才能得到，所以遇到这种时一般需要到编译后生成的链接文件中查找并反推在哪个函数中被使用（或者被哪个宏所展开得到）。

3、编译busybox所根据的步骤和命令一般在其源码包底下的README文件或者INSTALL文件（多数在后者）。

4、编译完毕要安装busybox时，如果使用默认安装命令则将会其安装到PC的ubuntu中，这将破坏掉ubuntu原有的根文件系统，所以安装命令要附带上创建好的、指定的空目录。

5、需要开机自动执行的挂载命令，如果数量少可以使用rcS，数量多时可以使用fstab。

6、用mdev自动创建/dev目录节点可以避免大量节点需要创建时通过手工创建的麻烦，创建步骤在busybox源码包目录的mdev文件中查看。

7、jffs2一般用在norflash上，配置过程所用参数--share指生成动态库，--prefix=/usr指定配置到/usr目录下；如果烧录后jffs2不能成功启动需要查看启动信息打印内容，看开发板根文件系统默认启动类型是否为yaffs，若是就还需要修改uboot所传递的命令行bootargs参数，添加fstype来直接指定。

8、如果要配置uboot命令行bootargs的rootfs参数为nfs，其完整格式需要到内核源码包的doc目录下找nfs.txt查看；格式选项用中括号[]括起的一般可以省略，尖括号<>括起的一般都需要填写。

9、应用层（C库函数：open、read、write），VFS（virtual file system：介于应用层与驱动层之间），驱动层（xxx_drv_open、xxx_drv_read、xxx_drv_write）。

10、应用层要打开的设备其文件名（/dev/xxx）可以和驱动层设备对应的文件名不一致，因为从应用层调用到驱动层时是通过设备类型（即字符设备、块设备、网络设备）和设备号（主设备号和子设备号）来找到对应设备的。

11、由于在用busybox构建最小根文件系统时可以在fstab中配置好mdev自动创建设备（hotplug），即系统已创建设备列表已知（因此这时哪些设备号已被占用系统是知道的），所以在驱动程序中借助class_create()和class_device_create()可以返回得到系统为本设备所分配的主、子设备号（register_chrdev的第一个参数需要设为0，代表由系统自动分配设备号）。

12、在编写一个驱动程序时遇到陌生函数不知道如何调用，这时可以在内核源码的source insight工程底下搜索该函数名看一下别的板卡设备厂商对于该接口函数的传入参数、调用和使用情况以作参考，特别是调用之后往往容易忘记添加该陌生函数所对应的头文件而导致编译报错，但是该陌生函数所在的头文件一般也不太清楚叫什么，所以不太可能（而且不应该）依靠记忆力去记住用到的头文件，正确的做法应该是在一开始参考的别的板卡设备厂商代码文件最前面看一眼和该陌生函数相关的头文件；而在应用层测试文件编写时，往往是知道大概要用哪个函数，但是该函数具体的返回值、需要传入的参数以及所用的头文件都忘记，这时可以在ubuntu中直接man函数名进行查看。

13、在开发板使用insmod装载驱动模块后，可以使用top命令查看资源占用百分比情况（相当于在windows下调出资源管理器）。

14、应用层close调用到驱动层时对应的接口实际为release()函数。

15、通过ps命令查看到程序运行状态为D，说明陷入了僵死状态，即一种不可被打断的睡眠状态，譬如在驱动程序中调用了down()函数。