• JZ2440支持设备树(1)-添加设备树之后kernel的启动参数跟dts里面不一致


    在做之前参考了如下博客文章,再次非常感谢:

    http://www.cnblogs.com/pengdonglin137/p/6241895.html

    Uboot中需要在config中添加如下宏:

    #define CONFIG_FIT        1 
    

     在内核里面make menuconfig之后配置支持设备树:

    Boot options-> 
    [*] Flattened Device Tree support

    然后分别编译uboot和kernel,最后按照网上介绍制作dtb文件,将uboot通过jlink直接烧到nor flash的0地址处,然后用tftp将kernel下载到内存的30000000,将dtb文件烧到内存的31000000,然后用bootm 30000000 - 31000000启动系统,但只能看到:

    SMDK2440 # bootm 30000000 - 31000000
    ## Booting kernel from Legacy Image at 30000000 ...
       Image Name:   Linux-4.15.1-gc1aaab686-dirty
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3498656 Bytes = 3.3 MiB
       Load Address: 30108000
       Entry Point:  30108000
       Verifying Checksum ... OK
    ## Flattened Device Tree blob at 31000000
       Booting using the fdt blob at 0x31000000
       Loading Kernel Image ... OK
       Loading Device Tree to 33ba6000, end 33baa6ea ... OK
    
    Starting kernel ...

    因为之前使用tags内核能正确启动,所以目前就是怀疑dtb文件没有正确传到linux,但是在uboot的/include/common.h里面添加#define DEBUG将uboot的所以调试信息打开,能看到dtb文件已经被uboot识别并且拷贝到内存的另一个地方了,如果按下开发板上的reset按键再一次进到uboot的console,在用dm.w去看dtb,能正确的看到dtb的内容,所以目前怀疑2点:

    1.设备树不被kernel识别。

    2.设备树被正确识别,但bootargs没有被正确读取,到处串口没有正确配置。

    解决问题:

    1.刚开始无法定位在linux kernel哪里挂掉的,于是添加了led灯,在没有开启MMU之前,可以直接操作物理地址,一直查到:

    ENTRY(__turn_mmu_on)
        mov    r0, r0
        instr_sync
        mcr    p15, 0, r0, c1, c0, 0        @ write control reg
        mrc    p15, 0, r3, c0, c0, 0        @ read id reg
        instr_sync
        mov    r3, r3
        mov    r3, r13
        ret    r3

    这里的MMU被打开了,就不能直接操作物理地址了,再往后执行就是调用__mmap_switched,因为很早就有ldr r13, =__mmap_switched @ address to jump to after然后在__mmap_switched的最后就是执行C代码入口b start_kernel

    于是断定肯定执行到了c阶段,但此时MMU已经开启,不清楚如何调试,于是又想到了earlyprintk,不爽的就是earlyprintk需要添加到bootargs里面,因为kernel C代码里面回去解析,暂时还没分析为什么非要uboot传过来。

    我现在的问题就很有可能uboot的bootargs没有正确传过来,本来想动脑筋在代码里面写死bootargs里面有earlyprintk的,后来突然想到make menuconfig有一个默认的Default kernel command string,于是我配置如下:

    再次编译内核,烧到板子上运行,终于有进步了:

    SMDK2440 # bootm 30000000 - 31000000
    ## Booting kernel from Legacy Image at 30000000 ...
       Image Name:   Linux-4.15.1-gc1aaab686-dirty
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3498656 Bytes = 3.3 MiB
       Load Address: 30108000
       Entry Point:  30108000
       Verifying Checksum ... OK
    ## Flattened Device Tree blob at 31000000
       Booting using the fdt blob at 0x31000000
       Loading Kernel Image ... OK
       Loading Device Tree to 33ba6000, end 33baa6ea ... OK
    
    Starting kernel ...
    
    Uncompressing Linux... done, booting the kernel.

    我在misc.c里面添加了写打印信息,如下:
    static void puthex(const int dat)
    {
    	char c;
        unsigned char temp[4]={0};
        
    	temp[0] = dat/1000 + 0x30;
    	temp[1] = dat%1000/100 + 0x30;
    	temp[2] = dat%100/10 + 0x30;	
    	temp[3] = dat%10 + 0x30;
    	putc(temp[0]);	
    	putc(temp[1]);	
    	putc(temp[2]);	
    	putc(temp[3]);	
    	putc('
    ');
    	putc('
    ');    
    	flush();
    }
    
    void DispDeviceTree(int arch_id,unsigned long* dev_tree)
    {
        char temp_str[100];
    	
        sprintf(temp_str,"machid=%d",arch_id);
    	putstr(temp_str);
    	sprintf(temp_str,"devTree=%s",dev_tree);	
    	putstr(temp_str);
    }
    
    
    

    然后在head.s里面添加了加上这个函数

    /*
     * The C runtime environment should now be setup sufficiently.
     * Set up some pointers, and start decompressing.
     *   r4  = kernel execution address
     *   r7  = architecture ID
     *   r8  = atags pointer
     */
    		mov	r0, r4
    		mov	r1, sp			@ malloc space above stack
    		add	r2, sp, #0x10000	@ 64k max
    		mov	r3, r7
    		bl	decompress_kernel
    
            mov r0, r7
            mov r1, r8
            bl  DispDeviceTree
            mov r0, r4
            mov r1, sp

    居然打印出了,说明我破坏了寄存器里面的值,导致连设备树都找不到了,machine id的值不需要关心,因为我们是用dts来匹配的,现在的kernel是支持两种匹配方式的,所以在两种都找不到的情况下就报错了,相信以后kernel会完全删除tags的方式的。

    Starting kernel ...
    
    Uncompressing Linux... done, booting the kernel.
    Machid=0362
    
    dev tree:�
    
    Error: unrecognized/unsupported device tree compatible list:
    [ 'samsung,s3c2440' 'samsung,jz2440' ]
    
    Available machine support:
    
    ID (hex)        NAME
    00000400        AML_M5900
    0000014b        Simtec-BAST
    0000015b        IPAQ-H1940
    0000039f        Acer-N35
    00000290        Acer-N30
    000002a8        Nex Vision - Otom 1.1
    00000454        QT2410
    000000c1        SMDK2410
    000005b4        TCT_HAMMER
    000001db        Thorcom-VR1000
    000005d2        JIVE
    000003fe        SMDK2413
    000003f1        SMDK2412
    00000377        S3C2413
    00000474        VSTMS
    00000695        SMDK2416
    000002de        Simtec-Anubis
    00000707        AT2440EVB
    000007cf        MINI2440
    000002a9        NexVision - Nexcoder 2440
    0000034a        Simtec-OSIRIS
    00000250        IPAQ-RX3715
    00000518        GTA02
    000003b8        HP iPAQ RX1950
    0000043c        SMDK2443
    
    Please check your kernel config and/or bootloader.
    
    后来我将misc.c和head.S还原,还是打印了这些信息,挺好的。

    SMDK2440 # bootm 30000000 - 31000000
    ## Booting kernel from Legacy Image at 30000000 ...
       Image Name:   Linux-4.15.1-gc1aaab686-dirty
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3488904 Bytes = 3.3 MiB
       Load Address: 30008000
       Entry Point:  30008000
       Verifying Checksum ... OK
    ## Flattened Device Tree blob at 31000000
       Booting using the fdt blob at 0x31000000
       Loading Kernel Image ... OK
       Loading Device Tree to 33ba6000, end 33baa506 ... OK
    
    Starting kernel ...
    
    Uncompressing Linux... done, booting the kernel.
    bootcmd line:
    arch/arm/kernel/devtree.c:setup_machine_fdt __machine_arch_type=ffffffff
    bootcmd line:noinitrd console=ttySAC0,115200 root=/dev/mtdblock3 rootfstype=
    jffs2 earlyprintk
    
    find fdt,and tags
    r1=0xffffffff, r2=0x33ba6000
    machine name:Samsung S3C2440 (Flattened Device Tree)
    Booting Linux on physical CPU 0x0
    Linux version 4.15.1-gc1aaab686-dirty (kent@hu) (gcc version 4.4.3 (ctng-1.6.1
    )) #27 Mon Sep 3 22:21:31 CST 2018
    CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c000717f
    CPU: VIVT data cache, VIVT instruction cache
    OF: fdt: Machine model: JZ2440
    bootcmd line:
    arch/arm/kernel/devtree.c:setup_machine_fdt __machine_arch_type=ffffffff
    bootcmd line:noinitrd console=ttySAC0,115200 root=/dev/mtdblock3 rootfstype=
    jffs2 earlyprintk
    
    find fdt,and tags
    r1=0xffffffff, r2=0x33ba6000
    machine name:Samsung S3C2440 (Flattened Device Tree)
    bootconsole [earlycon0] enabled
    Memory policy: Data cache writeback
    CPU S3C2440A (id 0x32440001)
    DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map
    random: fast init done
    Built 1 zonelists, mobility grouping on.  Total pages: 16256
    Kernel command line: noinitrd console=ttySAC0,115200 root=/dev/mtdblock3 
    rootfstype=jffs2 earlyprintk
    Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
    Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
    Memory: 57764K/65536K available (5319K kernel code, 216K rwdata, 1164K rodata
    , 204K init, 203K bss, 7772K reserved, 0K cma-reserved)
    Virtual kernel memory layout:
        vector  : 0xffff0000 - 0xffff1000   (   4 kB)
        fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
        vmalloc : 0xc4800000 - 0xff800000   ( 944 MB)
        lowmem  : 0xc0000000 - 0xc4000000   (  64 MB)
        modules : 0xbf000000 - 0xc0000000   (  16 MB)
          .text : 0x(ptrval) - 0x(ptrval)   (5321 kB)
          .init : 0x(ptrval) - 0x(ptrval)   ( 204 kB)
          .data : 0x(ptrval) - 0x(ptrval)   ( 217 kB)
           .bss : 0x(ptrval) - 0x(ptrval)   ( 204 kB)
    NR_IRQS: 103
    _get_rate: could not find clock xti
    sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 
    21474836475000000ns
    Console: colour dummy device 80x30
    

    这里注意到,打印的command line不是我在dts里面定义的,我当时怀疑是不是kernel没识别dts里面的bootargs成员,因为打印出了OF: fdt: Machine model: JZ2440,说明确实是找到了设备树,于是我在archarmkerneldevtree.c中的setup_machine_fdt函数里面根据实际地址和虚拟地址将内存里面的设备树以08x的形式全部打印出来了,然后跟我编译出来的dts做对比,发现确实不一样,后来怀疑是uboot传错了,于是去查uboot。

    将uboot中的include/common.h里面的debug打开,这样就可以看到更多的信息,于是看到打印出了以下信息:

    SMDK2440 # bootm 30000000 - 31000000
    ## Current stack ends at 0x33ba7ba0 *  kernel: cmdline image address = 0x30000000
    ## Booting kernel from Legacy Image at 30000000 ...
       Image Name:   Linux-4.15.1-gc1aaab686-dirty
       Image Type:   ARM Linux Kernel Image (uncompressed)
       Data Size:    3489048 Bytes = 3.3 MiB
       Load Address: 30008000
       Entry Point:  30008000
       Verifying Checksum ... OK
       kernel data at 0x30000040, len = 0x00353d18 (3489048)
    ## Skipping init Ramdisk
    ## No init Ramdisk
       ramdisk start = 0x00000000, ramdisk end = 0x00000000
    *  fdt: cmdline image address = 0x31000000
    ## Checking for 'FDT'/'FDT Image' at 31000000
    *  fdt: raw FDT blob
    ## Flattened Device Tree blob at 31000000
       Booting using the fdt blob at 0x31000000
       of_flat_tree at 0x31000000 size 0x00001507
    Initial value for argc=3
    Final value for argc=3
       Loading Kernel Image ... OK
       kernel loaded at 0x30008000, end = 0x3035bd18
    images.os.start = 0x30000000, images.os.end = 0x30353d58
    images.os.load = 0x30008000, load_end = 0x3035bd18
    using: FDT
    ## initrd_high = 0xffffffff, copy_to_ram = 1
       ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
    ## device tree at 31000000 ... 31001506 (len=17671 [0x4507])
       Loading Device Tree to 33ba2000, end 33ba6506 ... OK

    Initial value for argc=3
    Final value for argc=3
    No alias for ethernet0
    ## Transferring control to Linux (at address 30008000)...

    Starting kernel ...

    Uncompressing Linux... done, booting the kernel.
    phys:33ba2000
    virt:c3ba2000

    最后两句是我加在archarmkerneldevtree.c中的setup_machine_fdt函数里面的:

    说明kernel是从uboot传给它的地址去取的dts,难道真是uboot传错dts了?

    于是在uboot里面的commonimage-fdt.c里的boot_relocate_fdt函数里添加打印信息,将dts全部打印出来,发现dts还是错的,而且很明显是跟在configs/smdk2440.h里面定义的CONFIG_BOOTARGS完全一样,于是猜想,是不是uboot优先取CONFIG_BOOTARGS定义的bootargs,于是将其屏蔽,将存在nand上面的环境变量全部删除,再次将编译出来的uboot.bin通过jlink烧到nor上启动,在uboot的界面下通过tftp下载kernel和dts到ddr,再次执行bootm 30000000 - 31000000

    这次kernel里面打印的bootargs跟我在dts里面定义的一致,至此才敢确定的说,我的JZ2440支持设备树了。

      

      

     
  • 相关阅读:
    Basic INFO InstallShield的版本区分
    月光博客 从软件保护到软件授权
    Basic INFO InstallShield Professional for AdminStudio版本中如何打开InstallScript工程类型
    Basic INFO InstallScript脚本编程的限制
    从软件加密到软件授权保护
    月光博客 再谈软件保护中软加密和硬加密的安全强度
    INFO:Visual Studio 11 Beta版本中去除对Visual Studio Installer的支持,只保留InstallShield LE版本
    android 抓包分析
    android 巧用 dimerns 分辨率
    android 抓包 2
  • 原文地址:https://www.cnblogs.com/kent-hu/p/9434168.html
Copyright © 2020-2023  润新知