Киньте, пожалуйста, работающий пример самого простецкого драйвера в сорцах. Когда-то делал драйвер для ISAшного символьного устройства.
Тут - труба. Задумал написать I2C мастер без обработчика прерываний. Все делаю в виртуальном RHEL4. В единственном C-файле функции работы с TWI закомментарил, оставил пока только загрузку-выгрузку модуля.
При "СС=gcc" драйвер компилится, но не загружается, ошибка "Invalid module format". Я перекомпилял с "CC=arm-none-linux-gnueabi-gcc", при попытке запуска на сабжевой борде - то же самое...

Вот Makefile, переделанный мною из своего ISAшного:

Код

CC = gcc
CFLAGS = -DMODULE -D__KERNEL__

SRC_FILES = i2c_driver.c
OBJ_FILES = $(SRC_FILES:.c=.o)

%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
i2c_drv.o: $(OBJ_FILES)
ld -r -o i2c_drv.o $(OBJ_FILES)

А вот мейк, переделанный из образца для Nandflash:

Код

CC=arm-none-linux-gnueabi-gcc
#CC = gcc
KERNELDIR = /usr/src/kernels/2.6.9-5.EL-i686
CFLAGS = -D__KERNEL__ -DMODULE -I$(KERNELDIR)/include

TARGET = i2c_driver.o

default: $(TARGET)

clean:
rm -f $(TARGET)

$(TARGET): %.o: %.c
$(CC) $(CFLAGS) -c $< -o $@

Ошибка insmod говорит о том, что модуль был скомпилен для другой платформы? Но где-то какой-то вариант должен был установиться нормально :-). Что я делаю не так ?

См. четвертое сообщение от начала поста.

Все, прощу прощения. Просто я не в курсе, что для ядра 2.6 правила мейкфайлов для ядра перелопатили полностью, гады, и теперь никаких там CFLAGS, -DMODULE и пр. заклинаний. Нашел пример Makefile, загрузка-выгрузка работает.
Теперь можно и HW-функции прикручивать. Как заработает - выложу, авось поможет начинающим :-).

Модули ядра работают только под x86, на плате insmod'иться отказываются. Посмотрел я cmd-файлы, построенные kbuild'ом, и увидел, что там обычный gcc и 'elf_i386'. Т.е. оно и не должно там работать. Так как же дать понять, что надо компилить под ARM? Если ключей CCFLAGS и LDFLAGS нету.
Я пробовал писать "make CROSS_COMPILE=arm-none-linux-gnueabi-" , но тогда вылезают ерроры. Я залез в исходники драйвера AT91_mci - там, кроме этих cmd-файлов, генерируемых в ходе make, нигде не упоминаются линкер и компилер. Что такое Kconfig и зачем, неясно, в инетовских мануалах толком не нашел.
Дайте, плз, простой примерчик модуля ядра с комментарием: как указать, что используется не простой gcc/ld.
GSM_power_driver не предлагать, он вообще непонятный!
А то плата лежит, а я бьюсь как рыба об лед .

В общем случае собирать как-то так:
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Вы пытаетесь собрать модули отдельно от ядра ? Или что ?
make (синоним make all) - собирает все и модули тоже... make modules собирает только модули, в общем все как обычно, НО не забывайте указывать таргет-архитектуру (ARCH) и префикс кросс-компилятора (CROSS_COMPILE)... никаких проблем с модулями не замечал...

Пример самодельного драйвера АЦП и сборочных файлов:
http://www.at91.com/samphpbb/viewtopic.php?f=12&t=4992

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 06.01.2009 г. в 15:59:44

Вот так можно этот модуль ядра собрать (стандартный для 2.6 ядра "make modules" с доп. опциями):

Код

[repman@repairman adc_driver]$ make ARCH=arm CROSS_COMPILE=armv5l- -C /home/repman/Build/AT91SAM9260-SK/src/linux-2.6.27.10_SK M=/home/repman/Build/AT91SAM9260-SK/src/adc_driver modules
make: Entering directory `/home/repman/Build/AT91SAM9260-SK/src/linux-2.6.27.10_SK'
CC [M] /home/repman/Build/AT91SAM9260-SK/src/adc_driver/at91adc.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/repman/Build/AT91SAM9260-SK/src/adc_driver/at91adc.mod.o
LD [M] /home/repman/Build/AT91SAM9260-SK/src/adc_driver/at91adc.ko
make: Leaving directory `/home/repman/Build/AT91SAM9260-SK/src/linux-2.6.27.10_SK'

В директории /home/repman/Build/AT91SAM9260-SK/src/linux-2.6.27.10_SK лежит откомпиленное ядро, на котором этот модуль будет работать.
В /home/repman/Build/AT91SAM9260-SK/src/adc_driver/ лежит исходник драйвера, здесь же получим *.ko

Как видите, с форматом все ок:

Код

[repman@repairman adc_driver]$ armv5l-objdump -f at91adc.ko

at91adc.ko: file format elf32-littlearm
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

p.s. в CROSS_COMPILE ставьте СВОЙ префикс, если он отличается от моего...

Установка модуля - может быть специфична для конкретного дистрибутива... На примере Fedora8-ARM:

1. Копируем at91adc.ko на плату в /lib/modules/2.6.27.10/misc каким-либо способом, я это делаю через ssh. Если директории нет - создаем, версия ядра должна быть Вашей (uname -r), depmod подскажет. Верия ядра на плате должна ТОЧНО совпадать с версией ядра с которой собирался наш драйвер, иначе Вас ждет облом.
2. Запускаем depmod, чем создаем служебные файлы системы модулей в /lib/modules/2.6.27.10/, в /lib/modules/2.6.27.10/modules.dep - видим, что наш драйвер найден системой.
3. Стартуем драйвер:

Код

[root@fedora-arm 2.6.27.10]# modprobe at91adc -v
insmod /lib/modules/2.6.27.10/misc/at91adc.ko

Ошибок нет - драйвер запущен.
4. Смотрим /proc/devices, ищем наш драйвер, запоминаем № устройства. (у меня 252).
5. Создаем ссылки на устройство в /dev (драйвер почему-то создавался для обслуживания только 2 каналов, хотя в SAM их 4... ну, что есть)
mknod /dev/adc0 c 252 0
mknod /dev/adc1 c 252 1

Имеем 2 канала ADC, можем работать... для проверки можно получить на экран результат ввода ADC в виде мусороподобного дампа, который меняется от прикосновения пальцем ко входам ADC на гребенке:

cat /dev/adc0

p.s. автозапуск модуля при старте ОС - отдельная история, специфичная для дистрибутива Linux, как вариант, можно использовать прилагаемый по ссылке выше shell script, который просто повторяет пп 2-5...

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 06.01.2009 г. в 16:36:13

Вот спасибо за ценную инфу! Попробую.
У мну 6-летний опыт работы с 8 и 16-битными контроллерами, а вот в Linux программил только на десктопе. Планов громадьё: драйвер опроса кнопок с использованием PIT почти доделал, на очереди драйвер к индикатору Winstar WG12864 с сырцами, портированными с ASMа MCS-51. Не хватает только опыта портирования под другую архитектуру...
В инетовских форумах мне с ключом ARCH встречалось и linux_arm, и armle, и пр. В embedded VC++ с PocketPC SDK, кстати, компилить под ARM архипросто - только выбрать в списке девайс "ARMv4".

Цитата

Копируем at91adc.ko на плату в /lib/modules/2.6.27.10/misc каким-либо способом

На вируталке я просто давал команду insmod прямо из каталога проекта и потом командой dmesg | tail убеждался, что драйвер подхвачен, и символьный драйвер установлен.

Надеюсь, теперь дела пойдут .

Цитата

На вируталке я просто давал команду insmod

В принципе везде аналогично - только insmod может ругнуться что файл не найден, а если задать его с путем, то проблем не будет - можете хранить где хотите.

Цитата

В инетовских форумах мне с ключом ARCH встречалось и linux_arm, и armle, и пр. В embedded VC++ с PocketPC SDK, кстати, компилить под ARM архипросто - только выбрать в списке девайс "ARMv4".

Вообще для AT91SAM9260 наиболее точно:

arch=armv5tej
tune=arm926ejs

Компилятор понимает эти параметры, НО не все программы имеют оптимизированные версии для сборки... поэтому можно использовать архитектуры вверх с уменьшением конкретики до первого совпадения... armv5te, armv5t, armv5, armv4, arm... НО следует иметь ввиду, что любые обобщения приводят к деградации быстродействия.

В отношении к сборке ядра допустимые архитектуры = просто именам поддиректориев в arch... Вот его содержимое для 2.6.28:

Код

[repman@repairman linux-2.6.28]$ ls -la arch/
итого 104
drwxr-xr-x 24 repman repman 4096 Дек 25 02:26 .
drwxr-xr-x 25 repman repman 4096 Янв 6 12:52 ..
drwxr-xr-x 9 repman repman 4096 Дек 25 02:26 alpha
drwxr-xr-x 63 repman repman 4096 Дек 25 02:26 arm
drwxr-xr-x 11 repman repman 4096 Дек 25 02:26 avr32
drwxr-xr-x 15 repman repman 4096 Дек 25 02:26 blackfin
drwxr-xr-x 8 repman repman 4096 Дек 25 02:26 cris
drwxr-xr-x 7 repman repman 4096 Дек 25 02:26 frv
-rw-r--r-- 1 repman repman 12 Дек 25 02:26 .gitignore
drwxr-xr-x 8 repman repman 4096 Дек 25 02:26 h8300
drwxr-xr-x 17 repman repman 4096 Дек 25 02:26 ia64
-rw-r--r-- 1 repman repman 2950 Дек 25 02:26 Kconfig
drwxr-xr-x 9 repman repman 4096 Дек 25 02:26 m32r
drwxr-xr-x 21 repman repman 4096 Дек 25 02:26 m68k
drwxr-xr-x 8 repman repman 4096 Дек 25 02:26 m68knommu
drwxr-xr-x 34 repman repman 4096 Дек 25 02:26 mips
drwxr-xr-x 11 repman repman 4096 Дек 25 02:26 mn10300
drwxr-xr-x 10 repman repman 4096 Дек 25 02:26 parisc
drwxr-xr-x 14 repman repman 4096 Дек 25 02:26 powerpc
drwxr-xr-x 13 repman repman 4096 Дек 25 02:26 s390
drwxr-xr-x 15 repman repman 4096 Дек 25 02:26 sh
drwxr-xr-x 10 repman repman 4096 Дек 25 02:26 sparc
drwxr-xr-x 9 repman repman 4096 Дек 25 02:26 sparc64
drwxr-xr-x 11 repman repman 4096 Дек 25 02:26 um
drwxr-xr-x 23 repman repman 4096 Дек 25 02:26 x86
drwxr-xr-x 8 repman repman 4096 Дек 25 02:26 xtensa

Самое близкое - arm

Где хранить модули - дело сугубо личное... Однако, если Вы имеете уже сложившийся дистрибутив, в котором несколько разных утилит, программ, скриптов и т.п. предполагают, что модули лежат ИМЕННО ТУТ и ИМЕННО ТАК, то логично придерживаться принятых правил... иначе, просто, не сможете в нем работать...

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Отредактированно repairman 07.01.2009 г. в 00:04:33

Цитата

Компилятор понимает эти параметры, НО не все программы имеют оптимизированные версии для сборки...

Программы вообще не должны заботиться об этом - это дело компилятора - использовать какой-либо набор инструкций, кроме, естественно, использования инлайн ассемблерных вставок или например оптимизированного хранении данных для использования simd инструкций. И не нужно путать опции компилятора (arch=armv5tej) с переменными окружения через которые сообщают архитектуру при кросскомпиляции ядра (make ARCH=arm).