BBYR Achieve
返回信息流
这是一条镜像帖。来源:北邮人论坛 / embedded-system / #3490同步于 2009/1/6
该镜像源已超过 30 天没有更新,可能在源站已被删除。
Embedded_System机器人发帖

一个uboot引导zImage的问题

lester98
2009/1/6镜像同步11 回复
我的uboot是可以正确引导uImage的,现在为了节省时间,想用它引导zImage,捣鼓了半天以失败告终,情况是这样的 uImage用bootm命令来引导,这个命令会做许多事情,包括把启动参数拷贝到合适的位置,在把控制权交给内核的时候用theKernel(arg,arg1,arg2);三个参数会放在r0,r1,r2中,分别为0,machine number,存放bootargs的地址 zImage用go命令来引导,只是把pc设为内核入口地址,并不拷贝bootargs,而且只传递两个参数,我现在做了如下修改 1:拷贝内核参数到kernel中设定的地址 char *commandline = getenv("bootargs"); struct param_struct *lxy_params=(struct param_struct *)0x80000100; printf("setup linux parameters at 0x80000100\n"); memset(lxy_params,0,sizeof(struct param_struct)); memcpy(lxy_params->commandline,commandline,strlen(commandline)+1); printf("linux command line is: \"%s\"\n",lxy_params->commandline); 2:pc转向内核入口的时候传递三个参数,这三个参数应该是分别放在通用寄存器r0,r1,r2中供内核取用,bootm就是这样做的 rc = ((ulong (*)(int, ulong,ulong))addr) (0, gd->bd->bi_arch_number,gd->bd->bi_boot_params); 但是结果却总是在 Uncompressing Linux.............................................................................. done, booting the kernel. 之后停住没有输出 加了打印信息,看到传递给内核的参数应该没有问题 zImage the addr is 0x80700000 the machine number is:901 the param addr is 0x80000100 uImage the addr is 0x80008000 the machine number is:901 the param addr is 0x80000100
订阅后,新回复会通过你的通知中心匿名送达。
9 条回复
hobby机器人#1 · 2009/1/6
哦? 我仔细看看
hobby机器人#2 · 2009/1/6
你是ARM的CPU是吗?我现在弄得PPC的,看着不太一样 不过出错的情形很熟悉,我们当时也是卡在这里,就什么动静都没有了。因为打印不能用,几乎丧失了调试手段,一度非常郁闷。 后来慢慢找到一些方法继续推进,这里简单列一下,希望对你有用: 1、将控制权移交给内核是一句指针调用的形式,那么在调用前,uboot还活着的时候,把指针指向位置(也就是即将执行的二进制代码)打印出来,简单看看,是不是可以执行的二进制代码。补充:我们那时候曾经打印出来过字符(虽然是十六进制的,但是用文本工具看到了字符串),CPU当然不认识了…… 2、如果没有调试首选,可以使用LED协助调试。串口打印正常工作需要的条件相对比较高,先用LED看看程序到哪儿了?内核代码有否开始执行? 希望对你有帮助,如有谬误,欢迎纠正~
hobby机器人#3 · 2009/1/6
再补充一点吧,看着是到这儿就没反应了,其实可能不然,因为打印信息先是在缓冲区里的,串口初始化之后才会送到终端,在此之前,内核代码可能已经执行了很多了……
hobby机器人#4 · 2009/1/6
再补充一点吧,看着是到这儿就没反应了,其实可能不然,因为打印信息先是在缓冲区里的,串口初始化之后才会送到终端,在此之前,内核代码可能已经执行了很多了……
lester98机器人#5 · 2009/1/6
【 在 hobby 的大作中提到: 】 : 你是ARM的CPU是吗?我现在弄得PPC的,看着不太一样 : 不过出错的情形很熟悉,我们当时也是卡在这里,就什么动静都没有了。因为打印不能用,几乎丧失了调试手段,一度非常郁闷。 : 后来慢慢找到一些方法继续推进,这里简单列一下,希望对你有用: : ................... 那个地址是对的,就是内核的入口地址,对于zImage是0x80700000,是下载到的地址,对于uImage是0x80008000,其实都是一样的,uImage是后来拷贝过去的
lester98机器人#6 · 2009/1/6
【 在 hobby 的大作中提到: 】 : 再补充一点吧,看着是到这儿就没反应了,其实可能不然,因为打印信息先是在缓冲区里的,串口初始化之后才会送到终端,在此之前,内核代码可能已经执行了很多了…… 不是的,debug串口在Bootloader里就被初始化了,再说我用uImage就没有这个问题 感觉什么都对,找不出错误来,但是就是功能不行?
lester98机器人#7 · 2009/1/7
这个问题暂时不琢磨了,我把启动参数直接编到zImage里了,编了一大堆内核,适用于各种启动参数
hobby机器人#8 · 2009/1/7
【 在 lester98 的大作中提到: 】 : 不是的,debug串口在Bootloader里就被初始化了,再说我用uImage就没有这个问题 : 感觉什么都对,找不出错误来,但是就是功能不行? 串口是在uboot里面就初始化了,可是内核还会根据uboot传递过来的参数重新配置串口。也就是说如果传递的参数有误,那么uboot下串口还能用,但是内核再配置一下就搞的不能用了,起码在我们那里是这种情况。 我们当时的问题就是传参发生了错误导致内核重新配置串口后速率根本不对。结果症状就是:从打印上看就死了没动静了,实际上代码还跑着呢,串口输出的LED还在狂闪……
lester98机器人#9 · 2009/1/7
【 在 hobby 的大作中提到: 】 : 串口是在uboot里面就初始化了,可是内核还会根据uboot传递过来的参数重新配置串口。也就是说如果传递的参数有误,那么uboot下串口还能用,但是内核再配置一下就搞的不能用了,起码在我们那里是这种情况。 : 我们当时的问题就是传参发生了错误导致内核重新配置串口后速率根本不对。结果症状就是:从打印上看就死了没动静了,实际上代码还跑着呢,串口输出的LED还在狂闪…… 恩,有道理