• 【linux】linux内核移植错误记录


      

    欢迎转载,转载时请保留作者信息,谢谢。

    邮箱:tangzhongp@163.com

    博客园地址:http://www.cnblogs.com/embedded-tzp

    Csdn博客地址:http://blog.csdn.net/xiayulewa

      

    在内核下载运行后,会出现各种各样的问题,将遇到的问题和解决方案贴出来。

      

      

    No filesystem could mount root, tried: ext3 cramfs vfat msdos romfs(没有文件系统)

    问题分析:

    在make menuconfig时,没有配置文件系统类型。

    解决方案:

    : make menuconfig: 将M改为yes, 见下图

      

    Failed to execute /linuxrc. Attempting defaults...

      

    问题分析:

    程序不可执行或者没有权限执行,修改根文件系统里的linuxrc的组改为root。

    解决方案:

    # chown -R root:root '/home/tang/work/fs/ramdisk_fs', 或者制作文件系统时就以root身份来做

      

    ls输出乱码

    问题分析:

    ls是 busybox的命令,其输出加了一些格式输出。

    解决方案:.

        两种方式,或者重新配置busybox并编译,或者 改为用secureCRT 工具

        见http://blog.chinaunix.net/uid-26404477-id-3459315.html

      

    irq 57: nobody cared (try booting with the "irqpoll" option)

    问题描述:

    当开发板执行ifconfig eth0 192.168.1.3时,出错,现象如下:

      

    irq 57: nobody cared (try booting with the "irqpoll" option) (__report_bad_irq: Spurious.c (srckernelirq))

    CPU: 0 PID: 770 Comm: ifconfig Not tainted 3.10.53 #28

    [<c000d8ec>] (unwind_backtrace+0x0/0xf4) from [<c000bea4>] (show_stack+0x10/0x14)

    [<c000bea4>] (show_stack+0x10/0x14) from [<c005305c>] (__report_bad_irq+0x20/0xb4)

    [<c005305c>] (__report_bad_irq+0x20/0xb4) from [<c0053314>] (note_interrupt+0x224/0x288)

    [<c0053314>] (note_interrupt+0x224/0x288) from [<c00514d8>] (handle_irq_event_percpu+0xa8/0x1c0)

    [<c00514d8>] (handle_irq_event_percpu+0xa8/0x1c0) from [<c0051618>] (handle_irq_event+0x28/0x38)

    [<c0051618>] (handle_irq_event+0x28/0x38) from [<c0053aec>] (handle_edge_irq+0x7c/0x130)

    [<c0053aec>] (handle_edge_irq+0x7c/0x130) from [<c005107c>] (generic_handle_irq+0x34/0x40)

    [<c005107c>] (generic_handle_irq+0x34/0x40) from [<c019b528>] (s3c_irq_demux+0xb4/0x120)

    [<c019b528>] (s3c_irq_demux+0xb4/0x120) from [<c005107c>] (generic_handle_irq+0x34/0x40)

    [<c005107c>] (generic_handle_irq+0x34/0x40) from [<c00099fc>] (handle_IRQ+0x30/0x84)

    [<c00099fc>] (handle_IRQ+0x30/0x84) from [<c000855c>] (s3c24xx_handle_irq+0x90/0x140)

    [<c000855c>] (s3c24xx_handle_irq+0x90/0x140) from [<c0008e74>] (__irq_svc+0x34/0x40)

    Exception stack(0xc2f67ce8 to 0xc2f67d30)

    7ce0: 00000001 0000000a 00000000 20000013 00000002 00000002

    7d00: c04e4160 c2f66000 c04a4f5c c04e4140 c201d90c c04e4160 00400100 c2f67d30

    7d20: c001cf4c c001cfc0 20000013 ffffffff

    [<c0008e74>] (__irq_svc+0x34/0x40) from [<c001cfc0>] (__do_softirq+0x84/0x1cc)

    [<c001cfc0>] (__do_softirq+0x84/0x1cc) from [<c001d1b8>] (do_softirq+0x4c/0x58)

    [<c001d1b8>] (do_softirq+0x4c/0x58) from [<c001d218>] (irq_exit+0x54/0x90)

    [<c001d218>] (irq_exit+0x54/0x90) from [<c0009a00>] (handle_IRQ+0x34/0x84)

    [<c0009a00>] (handle_IRQ+0x34/0x84) from [<c000855c>] (s3c24xx_handle_irq+0x90/0x140)

    [<c000855c>] (s3c24xx_handle_irq+0x90/0x140) from [<c0008e74>] (__irq_svc+0x34/0x40)

    Exception stack(0xc2f67da0 to 0xc2f67de8)

    7da0: 00000000 00000039 c04aeab8 00000000 c04a7194 c2054d40 00000039 60000013

    7dc0: c04a71c4 00000000 c201d90c c2046cc0 235e5c8f c2f67de8 c0053ff8 c00523dc

    7de0: 40000013 ffffffff

    [<c0008e74>] (__irq_svc+0x34/0x40) from [<c00523dc>] (__setup_irq+0x194/0x428)

    [<c00523dc>] (__setup_irq+0x194/0x428) from [<c00528a8>] (request_threaded_irq+0xd8/0x158)

    [<c00528a8>] (request_threaded_irq+0xd8/0x158) from [<c02168c0>] (net_open+0x88/0x488)

    [<c02168c0>] (net_open+0x88/0x488) from [<c02bfa4c>] (__dev_open+0xb8/0x114)

    [<c02bfa4c>] (__dev_open+0xb8/0x114) from [<c02bc8e4>] (__dev_change_flags+0x8c/0x134)

    [<c02bc8e4>] (__dev_change_flags+0x8c/0x134) from [<c02bf95c>] (dev_change_flags+0x10/0x48)

    [<c02bf95c>] (dev_change_flags+0x10/0x48) from [<c0310cfc>] (devinet_ioctl+0x674/0x784)

    [<c0310cfc>] (devinet_ioctl+0x674/0x784) from [<c02abfdc>] (sock_ioctl+0x74/0x2a4)

    [<c02abfdc>] (sock_ioctl+0x74/0x2a4) from [<c009fab4>] (do_vfs_ioctl+0x80/0x5f4)

    [<c009fab4>] (do_vfs_ioctl+0x80/0x5f4) from [<c00a0064>] (SyS_ioctl+0x3c/0x60)

    [<c00a0064>] (SyS_ioctl+0x3c/0x60) from [<c00091c0>] (ret_fast_syscall+0x0/0x2c)

    handlers:

    [<c0216cc0>] net_interrupt

    Disabling IRQ #57 (Spurious.c (srckernelirq), 出现这个情况是中断次数99000过多,没有被处理)

    cs89x0: eth0: using half-duplex 10Base-T (RJ-45)

    cs89x0: net_open() succeeded

      

    问题分析:

        这与网络驱动有关,我的是cs8900a网卡,代码是内核自带的,就以此说明。

        网卡驱动相关文件为 cs89x0.c,cs89x0.h, cs89x0.txt。

        从栈最底处的net_interrupt, 可以看出内核在[<c0216cc0>] net_interrupt 处崩溃。而在net_open() 中有ret = request_irq(dev->irq, net_interrupt, 0, dev->name, dev); 可见net_interrupt为网卡中断处理函数。

        从上述的打印栈可以看出问题出现时的函数调用顺序,该调用顺序就是中断的处理流程,可以看我的另一篇文章,那里有中断非常详细的说明。

    s3c24xx_handle_irq→handle_IRQ→generic_handle_irq→s3c_irq_demux→ generic_handle_irq→

    handle_edge_irq→handle_irq_event→handle_irq_event_percpu→note_interrupt→__report_bad_irq→show_stack→unwind_backtrace;

    而在note_interrupt函数中有:

        if (unlikely(desc->irqs_unhandled > 99900)) {

            /*

             * The interrupt is stuck

             */

            __report_bad_irq(irq, desc, action_ret);

            …….

        }

    desc是中断数组某个元素,其irqs_unhandled > 99900了,就是说有99900个中断没有处理了?

    在note_interrupt→if (unlikely(action_ret == IRQ_NONE)) {…… desc->irqs_unhandled++; …….} 说明网卡中断返回值为IRQ_NONE,才会irqs_unhandled++。网卡中断返回值由handle_irq_event_percpu→res = action->handler(irq, action->dev_id)即net_interrupt得到,看该函数,可知while ((status = ioread16(lp->virt_addr + ISQ_PORT))) 循环必然条件为假,不然返回值不会是IRQ_NONE。

    分析到这里基本明白了,cs8900a的中断是硬件与s3c2440连接的,cs8900a只有实在产生了中断,才会导致cpu进入中断函数,但是网卡实际上是不可能产生那么频繁的中断的,那么猜想可能是中断触发类型设置不正确。

    配上原理图:

    看s3c2440手册:

    EXTINT1寄存器的[6:4]控制了lan口中断触发类型。

    在内核中添加代码,打印EXTINT1寄存器的值,发现其被配置为低电平触发中断了,而在cs8900a的datasheet中,明确说了高电平表明是一个中断。

      

        到这里问题原因定位。

      

    解决方案:

    . 在MACH_START中mini2440_map_io修改,添加中断支持

        s3c24xx_init_io(mini2440_iodesc, ARRAY_SIZE(mini2440_iodesc));

    //此处添加外部中断控制EINT9, 高电平触发,是cs8900中断    

        unsigned long tmp = ioread32(S3C24XX_VA_GPIO + 0x8c); // EXTINT1寄存器

        tmp &= ~0xf0;

        tmp |= 0x90;

        iowrite32(tmp , S3C24XX_VA_GPIO + 0x8c); // 设置为高电平触发中断

      

        然后ifconfig, ping等命令在应用层都正常执行了。

    感想:

        驱动移植时,本身最后改的代码就几句话,但是却要了解linux整个实现体系,包括设备总线驱动模型,platform driver,因为cs89x0驱动就是用这种架构,包括完整的中断处理流程,包括s3c2440芯片本身,cs8900a芯片本身资料,cs8900a驱动源代码,linux虚拟地址和物理地址映射等背景知识,真是折腾伤神啊,还好带来点成就感,开发从此后就可以使用nfs文件系统了,方便了很多,也值得了。

    • EEPROM is configured for unavailable media

    问题描述:

        执行ifconfig eth0 up时,出错。

    EEPROM is configured for unavailable media

    问题分析:

        在cs89x0.c中,查找,发现出在net_open函数中,发现是lp->adapter_cnf没有合适的赋值。

        如cs89x0.txt描述, 在网卡驱动作为模块加载时,在模块加载时,可以传递参数,insmod cs89x0.o io=0x200 irq=0xA media=aui,以此确定媒介,会对lp->adapter_cnf赋值。

         但是当make menuconfig,配置成CONFIG_CS89x0_PLATFORM=y时,网卡驱动作为非模块开机自动加载, 不会自动对lp->adapter_cnf赋值。

    解决方案:.

       如<<cs89x0.txt>> 6.5 Kernel module parameters描述,可采用u-boot向kernel传递命令的方式,如cs89x0_media=rj45等为lp->adapter_cnf赋值。

        另外就是直接修改源代码:当然这种方式不通用。

        在net_open中

        修改

        /* check to make sure that they have the "right" hardware available */

        switch (lp->adapter_cnf & A_CNF_MEDIA_TYPE) {

    为    lp->adapter_cnf = A_CNF_MEDIA_TYPE | A_CNF_10B_T;

        /* check to make sure that they have the "right" hardware available */

        switch (lp->adapter_cnf & A_CNF_MEDIA_TYPE) {

  • 相关阅读:
    [HihoCoder1259]A Math Problem
    [POJ1205]Water Treatment Plants
    [HDU5492]Find a path
    [USACO08JAN]Cell Phone Network
    [CodeForces-543D]Road Improvement
    [HAOI2012]外星人
    [CodeForces-869C]The Intriguing Obsession
    [CodeChef-CAPTCITI]Snakes capturing the Mongoose Cities
    CF741D Arpa’s letter-marked tree and Mehrdad’s Dokhtar-kosh paths
    Luogu P4095 [HEOI2013]Eden的新背包问题
  • 原文地址:https://www.cnblogs.com/embedded-tzp/p/4445035.html
Copyright © 2020-2023  润新知