ARMv7與ARMv5的編譯驅動程序

Question

我已經設法為基於ARM的設備編譯了驅動程序，但是當我嘗試加載該驅動程序時，該驅動程序崩潰了。 這是cpuinfo的輸出：

Processor       : ARMv7 Processor rev 2 (v7l)
BogoMIPS        : 999.42
Features        : swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc08
CPU revision    : 2

這是uname -r輸出

2.6.37

modinfo driver.ko

filename:       cp210x.ko
description:    Silicon Labs CP210x RS232 serial adaptor driver
license:        GPL
vermagic:       2.6.37 mod_unload ARMv7
vermagic:       2.6.37 mod_unload modversions ARMv5
parm:           debug:Enable verbose debugging messages

如您所願，我添加了一個額外的功能（2.6.37 mod_unload ARMv7），因此它將與目標系統匹配。

因此，如果我理解這是正確的，我已經為ARMv5 cpu編譯了該模塊，而目標是v7。 這可能是設備驅動程序崩潰的原因嗎？

該設備具有此驅動程序，但已嵌入到硬件生產商的其他驅動程序包中。 該軟件包還加載了一些我們無法使用的驅動程序。 該驅動程序包未加載，但我想這表明該驅動程序應在此硬件上以某種方式工作。

這是崩潰日志

modprobe cp210x.ko
Unable to handle kernel NULL pointer dereference at virtual address 0000000a
pgd = ca1fc000
[0000000a] *pgd=870dd031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in: dahdi_dummy dahdi cmemk syslink ipt_MASQUERADE nf_nat iptable_filter ip_tables ipt_LOG xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 xt_recent xt_mac xt_limit work_led reset_button ipv6
CPU: 0    Not tainted  (2.6.37 #1)
PC is at sys_init_module+0xfe0/0x1460
LR is at sys_init_module+0xe7c/0x1460
pc : [<c00836e8>]    lr : [<c0083584>]    psr: 20000013
sp : cc5e9ed0  ip : bf3828dc  fp : cc5e8000
r10: bf385ca8  r9 : cf3bcb4e  r8 : 000000c5
r7 : 00000027  r6 : bf382544  r5 : bf38266c  r4 : bf385ca8
r3 : 00000000  r2 : c7c9f000  r1 : 0000000a  r0 : 0000000a
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8a1fc019  DAC: 00000015
Process modprobe (pid: 2676, stack limit = 0xcc5e82e8)
Stack: (0xcc5e9ed0 to 0xcc5ea000)
9ec0:                                     bf382544 00000001 000ac048 bf382550
9ee0: 000000c5 cf3bd5a4 cf3b8000 000055f4 cf3bd20c cf3bd128 cf3bc2a0 c7c9f000
9f00: 0000266c 000028dc 00000000 00000000 00000017 00000018 00000010 0000000d
9f20: 00000009 00000000 6e72656b 00006c65 00000000 00000000 00000000 00000000
9f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9f60: 00000000 00000000 c9a19540 00000000 ca2403c0 00000006 c9a19540 00000000
9f80: ca2403c0 000055f4 00000000 00000006 00000080 c0037c28 cc5e8000 00000000
9fa0: 00000001 c0037a80 000055f4 00000000 000ac998 000055f4 000ac048 000ac978
9fc0: 000055f4 00000000 00000006 00000080 000ac008 000ac028 000ac998 00000001
9fe0: bebaf968 bebaf958 00017764 40214740 60000010 000ac998 c1e38bcc 03de8ad9
[<c00836e8>] (sys_init_module+0xfe0/0x1460) from [<c0037a80>] (ret_fast_syscall+0x0/0x30)
Code: e7923103 e1a03133 e3130001 15963128 (17d33000)
---[ end trace 6e8943127db36208 ]---
Segmentation fault

Answer 1

我不得不更改cp210x.c文件並注釋掉在哪里使用了互斥鎖。 這是唯一的地方：

static void cp210x_close(struct usb_serial_port *port)
{
        dbg("%s - port %d", __func__, port->number);

        usb_serial_generic_close(port);

        /* mutex_lock(&port->serial->disc_mutex);*/
        if (!port->serial->disconnected)
                cp210x_set_config_single(port, CP210X_IFC_ENABLE, UART_DISABLE);
        /* mutex_unlock(&port->serial->disc_mutex);*/
}

Answer 2

您是否正在嘗試將為一個內核編譯的內核模塊加載到另一個內核？ Linux模塊（所謂的驅動程序）僅應加載到為其編譯的內核中。 即使具有不同配置或編譯器設置的相同版本的內核也可能導致模塊不兼容。 因此，使用版本魔術非常危險。

驅動程序崩潰的原因是因為它試圖使用錯誤的布局訪問內核數據結構，因此它實際上並未讀取它認為應該讀取的屬性。

將架構從ARMv7更改為ARMv5是非常劇烈的配置更改，它將完全改變內核數據結構的內存布局。

與Windows等其他操作系統不同，Linux沒有抽象層或固定的內存布局，可讓您將相同的可加載模塊加載到內核的不同版本中。