Решил я воспользоваться драйвером MMC/SD карты "немца" для uClinux.
Вот только беда, похоже что он для ядра 2.6.
Не подскажите как мне его с ядром 2.4 подружить.
Пока при компиляции получаю ошибки:

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

В версии 2.5.x и далее в 2.6 была переработана подсистема, отвечающая за работу с блочными устройствами -> изменилась процедура регистрации устройств. Действительно, register_blkdev теперь принимает не 3 параметра (как в 2.4), а только два. Кроме того, в 2.6 несколько изменился подход к обработке очереди запросов ввода-вывода в блочных устройствах.

Итого, нужно переписать bd_request, mod_init и mod_exit.

Чтобы разобраться как это сделать, могу посоветовать посмотреть на примеры к книжкам Linux Device Drivers, 3rd Edition и 2nd Edition. И сравнить описанные в них процедуры инициализации модуля и обработки очереди. Они похожи, но несколько отличаются.





Ключи компиляции и линковки не менялись?

Такая ругань идет на неразрешенные ссылки на функции, которые должно экспортировать ядро. Но либо они не экспортируются, либо ссылки некорректны, что может быть результатом неправильной линковки или компиляции.

Ключи компиляции не менял, порылся по скриптам, дополнил свои флаги компиляции, не помогло
Смущает меня строчка во флагах "-I/usr/Xilinx/EDK8.1/gnu/microblaze/lin/bin/../lib/gcc/microblaze/3.4.1/./include" своим ".."

Сейчас у меня вот такой makefile получился:

Нет, тут ничего страшного нет. ".." в пути - совершенно нормальная ситуация, т.к. это лишь ссылка на каталог уровнем выше и ничего больше.




Все на первый взгляд на месте. Могу посоветовать посмотреть с помощью mb-objdump списки символов, которые значатся relocatables в таблице символов adapter.o и сравнить эти списки с данными экспортов ядра, т.е. его symtab.

А как мне этот symtab посмотреть?
Еще, попробовал собрать драйвер EthernetLite, makefile такой же. На этапе insmod получаю:
# insmod ./ethlite.o
Using ./ethlite.o
insmod: unresolved symbol __umodsi3

И никаких " Unhandled relocation" ...

Обычно после сборки он лежит в корневом каталоге исходников ядра в файле System.map.
Но его можно с помощью того же mb-objdump получить из незапакованного бинарника ядра, если мне не изменяет память. Ну и в рантайме - файл /proc/ksyms.

Посмотрел /proc/ksyms, названий полученных из mb-objdump не нашел.
Еще, по поводу ethernetlite драйвера, чего-то я не пойму. Насколько я понимаю в драйвере отсутсвует функция (или переменная) __umodsi3, которая каким то макаром должна в нем появится из каких-то либ. Иду в директорию $(ROOTDIR)/linux-2.4.x/lib, в самом корне лежит libz.a (символическая ссылка куда-то) а в ней первым объявлением идет эта самая __umodsi3 ...

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



Эта функция выполняет вычисление целочисленного остатка от деления 32-х раздрядных чисел. И она действительно должна быть в одной из библиотек. Указанная ссылка libz.a - это статически линкуемая библиотека, подозреваю, что она аналогична libgcc. Т.е. эта функция при линковке может быть взята и из нее, хотя ее может предоставить ядро.

А каких именно функций нет в экспортах ядра, но есть в adapter.o?
Можно увидеть вывов mb-objdump для adapter.o?

Вот.

Думаю, что функции типа cfgaddr_read должны быть в одной из статических библиотек, которые где-то рядом лежат. Можно попробовать поискать в файлах cfgaddr_read и посмотреть, где она попадется. Если найдется либа, но слинковать с ней при помощи mb-ld с ключиком "-r" (relocatable).

Не понял, эта функция (cfgaddr_read) объявлена и описана в теле драйвера, разве она еще должна в какой то либе фигурировать?

Эх, мне бы еще исходник этого драйвера.

Кстати, а получаемый после компиляции и линковки бинарник через elf2flt прогонялся? Если мне не изменяет память, то без этого работать не будет...

Только не пугайся , это франкенштейн.

Я такие "слова" в первый раз слышу , ничего такого преднамеренно я не делал.

Вот, кстати, примерчик Makefile'a, который пользует опцию линкера за место elf2flt:






Франкенштейн красив и крив, но стоять должен. Может быть даже ходить.

Что касается elf2flt, то см. http://www.beyondlogic.org/uClinux/bflt.htm и здесь http://www.linux.org.au/conf/2004/eventrec...rer-uClinux.pdf

Блин, с этими makefile настоящая кроличья нора, пошел по путям "include $(ROOTDIR)/config.arch", там есть определение LDFLAGS = -Wl,-elf2flt
Как ты видел, я этот LDFLAGS в своем makefile не использовал, но тем не менее каким-то чудным образом это преобразование происходит (раньше то ведь они работали при этих же мейкфайлах).
Я попробовал добавить -elf2flt к своему CFLAGS, картины это не изменило.

Компиляция и линковка - два разных этапа. В приведенном выше Makefile'e это наглядно представлено. В результате компиляции (используется CFLAGS) получается test.o, а после линковки (используется LDFLAGS) - test. Без отдельной фазы линковки, где gcc (ld) будет вызван для объектника, ничего не получится и опция -elf2flt работать не будет, если я все правильно понимаю.

Надо было пропатчить, insmod.
Забавно, я на эти грабли уже наступал еще осенью (хотя синхронизировал исходники через CVS с неделю назад ) ...