在《GNU ARM汇编--(十五)linux下的printascii》中已经初步分析了自己写的bootloader在引导kernel时候出现的commandline在bootloader和kernel之间传递的问题,今天终于解决了,并对参数传递有一些研究:
传递的参数为:
前面两个参数是页的大小和页的数目,而问题出现在commandline这个字符串数组的传递上面:
dubug这个问题的第一步是在start_kernel函数的开头处添加
strlcpy(boot_command_line ,"noinitrd console=ttySAC0,115200 root=/dev/mtdblock2 init=/linuxrc mem=64MB" , COMMAND_LINE_SIZE);
不管传递与否,直接强制写入,这样kernel的printk就将什么打印信息都打出来了.
继续debug:
在start_kernel中:
printk(KERN_NOTICE);
printk(linux_banner);
setup_arch(&command_line);
值得注意的是linux_banner中的内容在执行到这里时并没有输出,而是先放在buffer里面,因为这个时候linux的串口还没有起来.
setup_arch(&command_line);在arch/arm/kernel目录下的setup.c文件中:
char *from = default_command_line;
在make menuconfig时,有Boot options-->() Default kernel command string
也就是.config配置文件中的CONFIG_CMDLINE=""
同样在setup.c中有:
static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
也就是说在make menuconfig的时候我们是可以设定默认值的.
继续往下看:
mdesc = setup_machine(machine_arch_type);
根据machine_arch_type来找到相应的machine_desc结构体,这个查找有很多汇编代码,没有详细看,暂且略过.
而我们的s3c2440的machine_desc结构体是在arch/arm/mach-s3c2440下的mach-smdk2440.c中定义的:
MACHINE_START宏定义如下:
这些machine_desc结构体在链接时都是放在.arch.info.init中的.
这里我们注意一下:
.boot_params= S3C2410_SDRAM_PA + 0x100, 也就是0x3000 0000 + 0x100,这个地址和bootloader中参数的地址是相一致的.
回到setup.c中:
因为这个时候kernel已经开了MMU,做物理地址到虚拟地址的转换.
因为bootloader还是使用param_struct这种老的格式,所以下面的代码做格式的转换:
convert_to_tag_list-->build_tag_list,在build_tag_list函数中有:
这里我们将这个字符串拷贝到了tag->u.cmdline.cmdline中,
回到setup_arch函数中,开始看pase这些tags:
parse_tags(tags);-->parse_tag-->t->parse(tag);
在setup.c中有:
__tagtable的定义如下
也就是说这里我们会调用parse_tag_cmdline
这里我们又将字符串从tag->u.cmdline.cmdline拷贝到了default_command_line中,覆盖了默认配置.
再往下就是memcpy(boot_command_line, from, COMMAND_LINE_SIZE);
因为from指针指的就是default_command_line,所以这时候boot_command_line就是从bootloader传来的值了.
到这里,commandline的就正确传递了,至于linux的串口驱动和console这些是如何利用console=ttySAC0来进行下一步工作,再做分析.
这个流程过了一次,我的问题自然就解决了,自己写的bootloader一切正常了.虽然没有uboot那么强大,但是写bootloader的过程带来的好处绝不比移植uboot的少,哈哈哈哈
今天有点幸运,在路上被三个蜂子蛰了,从6点痛到现在,睡不着也该上床了!!
转载于:blog.csdn.net/dndxhej