最新消息:20190717 VPS服务器:Vultr新加坡,WordPress主题:大前端D8,统一介绍入口:关于

【转】u-boot 1.3.1移植,调试心得

Uboot crifan 723浏览 0评论

【转】u-boot 1.3.1移植,调试心得

公司的项目用的是扬创的2440开发板。此板仅有u-boot.bin提供,而没有u-boot的源码,我依照开发板提供的电路图,根据公司项目的要求,对其电路进行了修改,添加,并重新绘制了印制板,用的是扬创的核心板加自已的底板的构架。硬件调试完毕后,问题来了,我需要在硬件一启动时,就要对某些口线进行初始化,可是因为扬创没有提供U-boot的源码,只好自已动手去移植一套源码了。

移植过程主要是根据网上一名为tekkaman(日本动画,宇宙骑士的主角,看来,此兄是一动漫迷)的高手提供的方法进行的,他不仅提供了方法,还把移植好的u-boot 1.3.1放在网上供人下载,真是要感谢他了。移植过程基本顺利。不过还是有一些问题,我将这此记录下来,以供参考。

移植时,tekkaman提供的代码解压,用其中的文件拷贝到原版的u-boot1.3.1目录中,如提示是否覆盖原文件,选覆盖。按照他的方法,对其进行编译配置,这步顺利完成。然后,编译,我用的是arm-linux 3.4.1,编译报错,又试用了3.3.2,2.95.3,均报错。查了资料,知道这是u-boot的浮点数类型引起,于是自已编译了一新的arm-linux 4.1版,是用crosstool0.43编译的。编译过程很顺利。完了,再用新编译的arm-linux4.1版对u-boot1.3.1编译,顺利通过。因为我的板子上是可以正常运行u-boot1.2的(扬创公司提供的u-boot),为了方便u-boot1.3.1调试,我想将u-boot1.3.1用1.2下载到内存中运行。查了网上的相关资料,试了多次,总算可以在内存中运行了,方法很简单,将/root/u-boot-1.3.1/board/tekkaman/tekkaman2440目录下的u-boot.lds文件中的text_base改为0x33000000,再将/root/u-boot-1.3.1/cpu/arm920t中的start.s中

#ifndef CONFIG_SKIP_LOWLEVEL_INIT

       bl       cpu_init_crit

#endif

此段代码中的bl cpu_init_crit注释掉,即不进行CPU的初始化工作(此工作,当前在板子上运行的u-boot1.2已完成,故不能再次进行),即改为

#ifndef CONFIG_SKIP_LOWLEVEL_INIT

       @bl       cpu_init_crit

#endif

在下面一段代码中增加一些语句

#ifdef CONFIG_S3C2440_NAND_BOOT

       @ reset NAND

       mov r1, #NAND_CTL_BASE

       ldr   r2, =( (7<<12)|(7<<8)|(7<<4)|(0<<0) )

       str   r2, [r1, #oNFCONF]

       ldr   r2, [r1, #oNFCONF]

      

       ldr   r2, =( (1<<4)|(0<<1)|(1<<0) )       @ Active low CE Control

       str   r2, [r1, #oNFCONT]

       ldr   r2, [r1, #oNFCONT]

      

       ldr   r2, =(0x6)    @ RnB Clear

       str   r2, [r1, #oNFSTAT]

       ldr   r2, [r1, #oNFSTAT]

      

       mov r2, #0xff      @ RESET command

       strb r2, [r1, #oNFCMD]

      

       mov r3, #0       @ wait

nand1:

       add r3, r3, #0x1

       cmp r3, #0xa

       blt    nand1

nand2:

       ldr   r2, [r1, #oNFSTAT]       @ wait ready

       tst    r2, #0x4

       beq nand2

      

      

       ldr   r2, [r1, #oNFCONT]

       orr   r2, r2, #0x2       @ Flash Memory Chip Disable

       str   r2, [r1, #oNFCONT]

      

       @ get read to call C functions (for nand_read())

       ldr   sp, DW_STACK_START @ setup stack pointer

       mov fp, #0       @ no previous frame, so fp=0

      

    //增加的语句

       adr   r0, _start             /* r0 <- current position of code   */

       ldr   r1, _TEXT_BASE              /* test if we run from flash or RAM */

       cmp     r0, r1                  /* don’t reloc during debug         */

       beq     stack_setup

    //////////////////////////////

       @ copy U-Boot to RAM

       ldr   r0, =TEXT_BASE

       mov r1, #0x0

       mov r2, #0x30000

       bl       nand_read_ll

       tst    r0, #0x0

       beq       ok_nand_read

增加的语句是为判断是否是已在内存中运行u-boot,如是,则不进行下面一段将nand flash中的程序拷贝到内存中的操作(此操作在从nand flash中启动时,是必须的,而在内存中运行时,则不能使用,因为此时,nand flash中不一定是要调试的u-boot代码)

编译。完成后,使用tftp将u-boot.bin下载到板子的内存中,注意,内存地址一定是0x33000000,再用u-boot命令go 0x33000000,即可在内存中运行u-boot。解释一下为什么要这么做,u-boot的启动分两个阶段,第一阶段完成一些必须初始工作,此阶段是汇编写的,第二阶段则是进行一些较高级的操作,比如初始化板上的网卡芯片了,引导内核了什么的,这部分是用C写的。第一阶段的汇编程序在编写时,采用的是代码位置无关的方式,即无论代码的开头放在内存的哪一个地址,都可以从这个位置正常运行程序,而不管编译器在编译时认可的代码起始地址是什么。实际上,前面修改的text_base地址,就是编译器所认为的代码起始地址。U-boot中,第一阶段进入第二阶段是直接转入第二阶段的起始地址,而第二阶段的代码编写是与位置有关的,即代码起始地址必须与编译器认可的起始地址一至,才能正常运行。第二阶段的起始地址在编译完成后,即已确定,是相对于text_base的地址。那么我们将代码下载到text_base指定的地址中时,第二阶段代码的头就是在它应该在的位置上了。当我们从此text_base的地址处运行程序时,没有任何问题。而当此代码是从nand flash中运行时,第一阶段的起始地址为0,但因为第一阶段代码是位置无关,所以第一阶段代码可以正常运行,但第二阶段代码的头却不在它应该在的位置了,所以,第二阶段不能正常运行,因为,在第一阶段中,必须将u-boot自身拷贝到text_base的地址处,这样,第二阶段的代码就在它应该在的位置了,此时,第一阶段的程序可以顺利跳转到第二阶段运行了。这个过程,是我看了很资料后总结出来的。

完成此工作后,即可以在内存中运行u-boot了,但因为tekkaman的程序中,用的网卡芯片是DM9000,我用的是CS8900,所以要在tekkaman.h中,将DM9000的宏注释掉,将CS8900的宏开放。在此我犯了个错误,因为我一开始没有修改此处的宏编译的程序,而我在修改过宏以后,没有执行make clean就直接make,结果,网卡不能正常工作,总是报告cs8900 not found,试了多次不能解决,耽搁了一些时间。后来,在make clean后,再make,想不到问题解决了,想来是有些与cs8900想关的文件在修改过宏后没有重新编译所置。真是无语了。

这个问题解决后,就是要用u-boot引导linux内核了,我用的是扬创提供的linux2.6.13的内核,扬创提供的内核,loadaddress和entry都是30008000,我用u-boot1.2中的bootcmd参数,u-boot1.3.1 bootm却不能引导,报bad magic number,看了bootm的相关资料,得知,如果我们没用mkimage对内核进行处理的话,那直接把内核下载到0x30008000再运行就行,内核会自解压运行(不过内核运行需要一个tag来传递参数,而这个tag建议是由bootloader提供的,在u-boot下默认是由bootm命令建立的)。

2)如果使用mkimage生成内核镜像文件的话,会在内核的前头加上了64byte的信息,供建立tag之用。bootm命令会首先判断bootm xxxx 这个指定的地址xxxx是否与-a指定的加载地址相同。
(1)如果不同的话会从这个地址开始提取出这个64byte的头部,对其进行分析,然后把去掉头部的内核复制到-a指定的load地址中去运行之
(2)如果相同的话那就让其原封不同的放在那,但-e指定的入口地址会推后64byte,以跳过这64byte的头部。

Bootm在没有参数时,是采用tekkaman.h中的#define CFG_LOAD_ADDR 的地址的,而我用bootm就是没有使用参数,所以出错了。正确的做法应该是用nand read命令将内核从nand flash中读到内存的某一地址中(注意不要与其它已分配的内存冲突),然后再用bootm 加地址参数,即可引导,也可以在上述的文件中,将CFG_LOAD_ADDR的地址定义为此地址,再用bootm就可以了,我最终就是这么用的。

做完这此,内核可以引导了,但却停在starting kernel不动了,好在我以前做过vivi+linux2.6.22的移植,知道此问题多半是由于mach_type不同而造成的。在u-boot中,此mach_type是由tekkaman.c中的这段代码定义的

#if defined(CONFIG_S3C2440)

/* arch number of S3C2440 -Board */

       gd->bd->bi_arch_number = 5244 ; //改为和内核的MACH_TYPE一至

       //gd->bd->bi_arch_number = MACH_TYPE_S3C2440 ;

#endif

你可以象我一样直接在这里改数字,也可以在include/asm-arm/mach_types.h的文件中,改MACH_TYPE_S3C2440的数值。将数值改为和内核的mach_type一至。至于内核的mach_type可以在内核linux源代码下的arch/arm/tools中的mach_types文件查看到。

重新编译下载u-boot1.3.1后,内核正常引导了。到此,u-boot1.3.1的移植告一段落。下面,我要做的是移植yaffs,使u-boot1.3.1可以支持yaffs文件的烧写。

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/hugerat/archive/2008/10/28/3167903.aspx

转载请注明:在路上 » 【转】u-boot 1.3.1移植,调试心得

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
58 queries in 0.107 seconds, using 19.24MB memory