Ну в общем я не так понял исходные данные. Я понял вопрос в том, чтобы поднимать на шине стандартные драйверы, написав ТОЛЬКО драйвер шины, и не трогая код "стандартных" драйверов девайсов, и не делая новых драйверов девайсов (и это основное в вопросе - не трогать ничего, связанного с девайсами, а писать только драйвер шины). Поэтому предложил статическое объявление, которое это позволяет, по крайней мере с драйвером уарта. А так да, выход один, писать некие "врапперы" на стандартные драйверы, которые пробуют себя на шине VLYNQ, зная, как с этой шиной работать, и патчить те драйверы, которые не умеют работать через функции ввода-вывода, заданные снаружи, чтобы они этому научились.

Да я думаю, что написать маленький минидрайвер не будет большой проблемой.

С драйвером UART вляпался в дурацкую проблему. Прерывания в VLYNQ передаются пакетом из одного 32-битного слова, которое предлагается писать в регистр установки флагов прерывания. То есть, реально можно только взвести прерывание, если соответствующий ему бит принятого слова установлен. Сейчас у меня слово передается только если произошло изменение в каком-либо сигнале прерывания внутри ПЛИС. Но реально работают только единички, они взводят биты в регистре VLYNQ контроллера внутри SOC. А драйвер UART 8250.c написан так, что он не пытается разгрести все прерывания порта за один раз. Он отрабатывает определенную последовательность действий и выходит, видимо рассчитывая, что если она не отобьет прерывание, то он снова зайдет в обработчик и его обработает. В итоге получается, что после первого захода он все не отрабатывает, прерывание от кора UART внутри ПЛИС не снимается, кор vlynq не видит изменения статуса и не шлет пакет в SOC. В итоге второго прерывания уже не возникает. Ну и много интересных эффектов возникает на этой почве... Теперь вот думаю, как это залечить наиболее грамотно. То ли прерывание от UART передергивать после чтения регистра статуса прерывания, чтобы фронт второй возник, то ли думать, как научить VLYNQ транслировать именно состояние линии прерывания.

Ну я в похожем случае когда-то именно на передергивании остановился, как на меньшей крови (это был процессор TMS 55xx, а у него нет физически прерываний по уровню)

А я извратился, сделал регулярную трансляцию всех флагов прерывания по VLYNQ. Вроде даже ничего получилось, только маскировать прерывание может только драйвер конкретного устройства, драйвер шины не может. Но я пока не вижу, чем это особенно плохо. В общем, работает UART, который подымается на старте системы через статическую регистрацию platform_device. Буду тогда потихоньку переводить на модульный вариант.

А вот еще совсем простой вопрос. Если я хочу собирать модуль для ядра, но в отдельном проекте, в отдельном каталоге (не в ядре). Но при этому у меня сам проект ядра есть уже развернутый. Как наиболее правильно настроить среду для сборки модуля? Ну, например, нужно прикрутить kernel headers и какие-то объектные модули ядра, которые линкуются в модуль .ko. Как правильно указать ссылку на это все? Просто тупо в каталоге проекта сделать симлинк, или можно как-нибудь "официально" разместить (экспортировать) все эти штуки в какой-нибудь общий путь рядом с кросс-компилятором? Подозреваю, что можно сделать и так и так, лишь бы Makefile правильно под это написать, но хочется сделать это так, чтобы можно было в одной машине в SCM положить, на другой достать и собрать. А из этого следует, что патчить ручками содержимое Makefile-ов (путей там всяких) - неправильно. Есть у кого-нибудь опыт подобного?

Ну у TI опыт есть... на примере graphics SDK для powervr - там дрова собираются модулями отдельно. там именно в makefile первой строчкой идут пути к хидерам ядра. А чтобы это стало официальным - об этом надо написать в README

у nvidia тоже опыт есть. у них скрипт сборки, а пути опцией указываются.

http://www.kernel.org/doc/Documentation/kbuild/modules.txt

=== 2. How to Build External Modules

это какие и зачем?


external modules, редко у кого нет - не патчами же держать

SM

Ну, так именно этого то хочется избежать. Хочется сделать так, чтобы в тех файлах, что попадут в архив (source control), не было никаких путей. У одного пользователя они одни, у другого другие. Нужно, чтобы в README было написано: настройте N переменных окружения: путь к кросс-компилятору, путь к ядру, путь, куда его собирать, путь к ..., и все. Дальше просто берем из репозитория срез и делаем make.

sasamy
Спасибо, почитал. Попробую-что-то слепить. К сожалению, сборка ядра от linux-c6x несколько отличается от того, что там написано. Несколько драйверов из родного дерева я собирал в виде модулей. Ни разу нет ничего похожего на /lib/modules/'uname -r'/extra. Зато нашел их примерно тут:

Пробовал искать по файлам проекта (Makefile искал) слово kernel-modules-c6x, так не нашел. Как так вышло, что они именно в rootfs залетают?
Зато заголовки живут прямо в Build:


Idle
Ну, я грешным делом подумал, что для оптимизации таблиц для динамического связывания на каждый вызов внешней функции геренрируется специальный код вида 'jmp <addr>', который статически линкуется с проектом, и в итоге в рантайме нужно править только один адрес. Так во всяком случае раньше делали с динамическими библиотеками. Или с .ko никто подобным не занимается, и тупо нужно править каждый конкретный вызов внешней функции?


Добавление. Не, нашел kernel-modules. В главном Makefile'е:

так makefile понимает переменные окружения, ну или типа:

make KERNEL_HEADERS=/xx/xx/xx CROSS_COMPILE=arm-unknown-linux-gnueabi
make install DESTDIR=/куды/впихнуть

хотя это тоже грубо переменные окружения

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

Например так

А, это не - не знаю как работает.

Там .fixup секция, она архитектурно-зависимая, где хранится весь список релокейшенов и внешних связей. Короче линковка как линковка...

А еще дурацкий вопрос. Как узнать строчку OS release для текущего собираемого ядра, если я делаю через кросс-компиляцию?
Добрые дяденьки из TI придумали вставлять в название ядра текущую дату сборки, в итоге у меня драйвер собрался с сегодняшней датой, и на вчерашнем ядре работать отказался. Пришлось ядро пересобрать и залить на TFTP. Я, наверное, этот идиотизм порежу и уберу дату из названия ядра. Но все же даже если даты в названии не будет, то как получить то название целиком? uname -r не прокатит, а полное имя там составное, из названия архитектуры, платы, размещения rootfs (initramfs vs jffs2) и endian. При таком раскладе как его узнать?

И еще, KERN_DIR в примере выше - это путь к сборке ядра или к исходникам?



А как линкер отличает, какие символы считать правильными unresolved external и помещать в .fixup, а какие - нет? Я так понимаю, что отличие .ko от .o только в том и состоит, что в нем должны остаться только правильные unresolved externals, которые объявлены как внешние, линкуемые при загрузке.

Как я понимаю, все unresolved external там есть. А правильный он или нет, разбирается insmod, и ругается, если что. А отличие от ".o" лишь в одной букве расширения.

А как это Вы такого добились, чтобы оно даты сравнивало? Я периодически вот собираю TI-шные powervr дрова как модули, никакой привязки. Даже как правило пересборка ядра при незначительных изменениях не приводит к тому, чтобы пересобирать модули. Это наверное какая-то особая доп. фича при сборке модуля.