2014-08-29 4 views
0

Я пытаюсь перекрестно скомпилировать модуль для ARM. Я использую Sabrelite как плату с версией ядра 3.0.35. Я использую open-embedded для создания образа ядра.Перекрестная компиляция модуля ядра ARM

У меня есть весь инструментарий, необходимый для кросса-компиляции, как приведено ниже:

echo $CC :

arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi

echo $CROSS_COMPILE: arm-oe-linux-gnueabi-

echo ARCH: arm

(Это просто какая-то часть моего набора инструментов.)

Это часть моего Makefile:

Когда я запускаю его с помощью команды make, я получаю модуль (.ko), но странно, что сгенерированный модуль скомпилирован с помощью моей основной машины, что означает, что makef ile вызывает собственный компилятор вместо кросс-компилятора. Что я делаю не так? Бинарные файлы кросс-компилятора находятся на моем пути.

Это часть продукции я получаю на терминале:

CC /home/user/script_emulation/AODV/aodv-uu/lnx/kaodv.mod.o

LD [M] /home/user/script_emulation/AODV/aodv-uu/lnx/kaodv.ko

Мы можем видеть, что там родной CC и LD используется вместо перекрестных инструментов компилятора

Может кто-нибудь предложить решение?

благодаря

Update:

$ readelf -h kaodv.ko

ELF Header: 
    Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
    Class:        ELF32 
    Data:        2's complement, little endian 
    Version:       1 (current) 
    OS/ABI:       UNIX - System V 
    ABI Version:      0 
    Type:        REL (Relocatable file) 
    Machine:       ARM 
    Version:       0x1 
    Entry point address:    0x0 
    Start of program headers:   0 (bytes into file) 
    Start of section headers:   13480 (bytes into file) 
    Flags:        0x5000000, Version5 EABI 
    Size of this header:    52 (bytes) 
    Size of program headers:   0 (bytes) 
    Number of program headers:   0 
    Size of section headers:   40 (bytes) 
    Number of section headers:   33 
    Section header string table index: 30 
+0

«CC», «LD» и т. Д. На выходе KBuild являются довольно печатными, они не обязательно являются фактическими командами. Используйте 'make V = 1 ...', чтобы узнать, что он на самом деле делает. Можете ли вы подтвердить, что файл .ko действительно неправильный формат, например. readelf? – Notlikethat

+0

Спасибо, это результат, который я получаю: echo "ERROR: Конфигурация ядра недействительна."; \t \t \ \t эхо "включают/сгенерированного/autoconf.h или включить/Config/auto.conf отсутствуют."; \ \t эхо "Run 'сделать oldconfig && сделать подготовить' на ядре ЦСИ, чтобы исправить это."; \t \ Это означает, что я должен перенастроить свое ядро ​​(что я уже сделал !!!) – scof007

+0

@Notlikethat да, файл .ko неправильный формат, потому что я тестировал его на цель, и он просто не работать как должно быть – scof007

ответ

1

Для быстрого исправления, измените Makefile, как показано ниже.

KERNEL_DIR=/home/user/script_emulation/AODV/kernel

KERNEL_INC=$(KERNEL_DIR)/include THIS_DIR=$(shell pwd)

obj-m += kaodv.o kaodv-objs := kaodv-mod.o kaodv-debug.o kaodv-netlink.o kaodv-queue.o kaodv-ipenc.o kaodv-expl.o

default:
$(MAKE) ARCH=arm CROSS_COMPILE=arm-oe-linux-gnueabi- -C $(KERNEL_DIR) SUBDIRS=$(THIS_DIR) modules

Кроме того, убедитесь установить перекрестный путь компилятор ToolChain перед запуском сделать использованием

export PATH = $PATH:PathToToolchain.

Также проверить, является ли ядро ​​вы собрали ранее также скомпилированы для архитектуры ARM.

0

Как видно из заголовка, на самом деле он отлично скомпилирован. Если оно было построено с помощью встроенной инструментальной цепочки, поле «Machine» будет содержать x86_64 (или любую вашу хост-систему), и попытка выполнить insmod, который на цель дал бы ошибку.

выход KBuild по умолчанию просто использует «CC», «LD», как удобные индикаторы - это только представитель которой шаг выполняется, а не конкретные команды линии будучи вызваны (см определения quiet_cmd_* в Makefile.build) ,

Тот факт, что код действительно не работает должным образом, представляет собой совершенно другую проблему. Учитывая, что вы переносите этот модуль из более старого ядра, скорее всего, ему потребуется обновление для учетной записи changes in some internal interface, которую он использует.

+0

На что вы можете сказать, что кросс-компиляция прошла нормально? Какой атрибут readelf -h вы ссылаетесь? Я постараюсь увидеть ваше предложение. – scof007

+0

@Notelikethat: Итак, я все еще нахожусь в этой проблеме, и я действительно не знаю, что такое решение. Я занимаюсь расследованием, но ничего не нашел. Итак, я хотел исследовать об этом обновлении внутренних интерфейсов, о которых вы говорили, но я не уверен, чтобы понять, что вы подразумеваете под этим. Можете ли вы дать некоторые подробности об этом. Должен ли я перекомпилировать ядро ​​и активировать некоторые параметры там или? – scof007

+0

Дело в том, что с 2.6.Необходимо, любая из внутренних функций или структур данных, используемых этим модулем, может тонко изменить их поведение, вещи могли быть перемещены в sysfs или что-то еще. Внедорожные драйверы/модули, скорее всего, потребуют работы, чтобы поддерживать их в актуальном состоянии с изменениями в магистрали. – Notlikethat

Смежные вопросы