Доброго времени суток всем!
Сейчас выпускается много плат на микроконтроллерах с поддержкой того или иного дистрибутива Linux. Насколько переносим код, например, для Linux Ubuntu при переходе к другой плате на таком же дистрибутиве? Существуют ли в Linux (и Ubuntu в частности) стандартные драйверы для LCD, GPIO, UART, USB, Ethernet? Для более специфических интерфейсов, таких как I2C, SPI, PWM? Как изменится ситуация, если придется переходить на другой дистрибутив?

Дистрибутив не причем (если и будут какие-то телодвижения, то они будут крайне минимальными).
Придется пересобирать ядро GNU/Linux и может быть подправлять платформ файл ядра (файл в котором описано как и какая периферия подключена к вашему МК).


Ну а как-же, только это не в дистрибутиве а в ядре

Отвечу так:
представьте себе поле. Большое. И там везде грабли, грабли, грабли..
До самого горизонта.

Гдето так.

ПыСы. Доходило до того, что сборка того же софта более новым gcc не работала. Казалось бы, да?
А вот он новую секцию добавлял, а тулзы его непонимали и кернел неправильно компонавали..

Тут нужно в первую очередь рассматривать ресурсы чипа и реализацию BSP а не тип дистритутива.


В порядке убывания стандартизированности:
Ethernet
USB
LCD
GPIO




+100500

Даже кернел с Торвальдсом пару раз доходил до этого.

"где-то так" бывает у всех новичков. Вы очевидно не исключение.



Отсюда вывод - не собирйте чем попало.

Причем тутта линкер-скрипт к "более новому" GCC ?

Вово.. И я так думал.

Могу покопать конкретно "при чем".
За пыво.
Просто так лень.

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

Можно ковырнуть современные тулзы. Секция чтото вроде build-id, введена по моему после 2.95.
Там, кажется, и CodeSourcery свои инициалы сейчас держит.
В общем, мне пришлось компилить objcopy с дебаг информацией, смотрел откуда он такой размер берет.
То ли аддресс там был нулевой, не сросталось чтото.

Ну что? Хайнекен?

Где-то так бывает когда начинаешь работать глубже чем Hello world. Например общаться с внешними устройствами. В драйверах ТАКОЕ обнаруживается что приходится кушать кактус.
Примеры:
imx28 linux2.6.35 от фрискейла. Драйвер i2c не поддеррживает Repeated Start (железо умеет). Ну и хрен бы с ним только мне надо подключить чип который в принципе не функционирует без Repeated Start. Ну в AD такие выдумщики. Хорошо хоть патч от коммюнити нашелся, он даже кое-как работает.
imx25 dma не поддерживается хотя в железе есть и работает. Ну кому такая фигня как dma может потребоваться. Коммюнити ниасилило потому как sdma там шибко накрученный.
imx6 на spi интерфейсе dma не поддерживается, ss программный. В железе dma поддерживается, ss аппаратный. Ну надо же чем то загрузить 1ГГц процессор.
Подобных косяков я могу нарыть сколько угодно

_Pasha,
нашел свой старый пост по теме:

Кийворд .note.gnu.build-id
В 2007 один хороший человек добавил эту секцию в бинарник,
"юникли айдентифиед билд".
В линкер скриптах про нее ничего нет, куда ложить.
Стрипать ее не стрипают.
В результате она в vmlinux ложится в секцию с аддресом 0х00000
Занимает 36 байт.
Все остальные секции располагаются там вверху гдето с 0хC000000..

В команде objcopy када из vmlinux делается бинарный образ мемори
секция не стрипается.
Он тупо находит секцию с самым маленьким стартовым адрессом, копирует,
затем берет следующую секцию, делает SEEK на 0хС000000 и получаем афигенный файл..


Референсес:
http://lists.linaro.org/pipermail/linaro-k...ary/000052.html
https://lkml.org/lkml/2011/12/15/162

Подобные "косяки" - это фигня полная. i2c, spi не ипользуются как скоростные интерфейсы - чисто сконфигурировать что-то или там тачскрины всякие где надо пару десятков байт передать/принять, на том же imx6 у SPI аппаратный FIFO - 64 байта, какой смысл для такой ерунды DMA заряжать если вся передача в FIFO целиком помещается ? GPIO в качестве SS - это очень распространенное явление чтобы реализовать все возможные варианты флагов у spi_message и spi_transfer на которые контроллер не сконфигурировать.

"Вон оно как, Михалыч" (с)..
Достал попкорн.
Сейчас "гуру" будут "новичков учить"

Для таких гуру как вы видимо трудно подправить драйвер и настрить так как нужно в конкретном случае ? Кушайте свой попкорн дальше.

Могу подтвердить, что он докопался до причин и устранил их.

Полгодика помучав драйвера Линя могу подтвердить, что писаны они левой ногой абы как.В оправдание — я буду писать с нуля дольше, хуже и дороже.

Честно говоря, я предполагал, что где-то так:


Но все же хотелось верить во все хорошее....


Насколько я понял, чем менее стандартный драйвер, тем более вероятны проблемы при каких бы то ни было переходах. Поэтому при использовании не очень стандартной аппаратуры (GPIO, I2C, LCD(?)) "светлого будущего" с полной переносимостью кода между разными embedded платформами на Linux пока нет. Может, конечно, повезет, но рассчитывать на это, наверное, не стоит. Такое вот впечатление...

Спасибо всем за ответы, жаль, что тема (как это часто бывает) перерастает во flame

Под более менее распространненые порты (GPIO, SPI, I2C) существуют фреймворки, которые обеспечивают стандартный интерфейс. Тут весь вопрос в реализации нижнего слоя драйвера, который непосредственно общается с аппаратурой. А именно кто и как его будет/должен реализовывать. Производители микропроцессоров этим как правило не занимается, а в комьюнити ветку тянут два-три человека, которым м.б. эти модули для своего проекта и не нужны совсем.
Так что это не флейм, скорее эмоции от путешествия по полю с граблями

Нельзя ли примерчик такого фреймворка?


В таком случае, если я использую такой фреймворк и перехожу, например, на OEM-модуль Colibri от Toradex для которого драйверы имеются, шанс на переносимость кода по работе с аппаратурой на другую платформу есть? (То, что грабли, в принципе, могут встретиться в любом месте я уже понял )

Они все описаны в документации к ядру
http://lxr.free-electrons.com/source/Documentation/



100%, нестандартные драйверы даже TI не пишет, в этом просто нет смысла. Будет разница в подключении поэтому потребуется корректировка - номера GPIO, интерфейсов, чипселектов и т.д.

Да, тут граблей меньше. Если уже есть драйвер, это большое дело.
Я так понял что драйвер есть, на Интеле пашет, надо на АРМ?
1. Посмотреть, чтоб версия кернела на Интеле поддерживалась бы производителем платы АРМа.
2. Читать документацию на плату, потому как там не редко еррата с "все хорошо, только 28я ножка на плате не работает".

Поищите в этом треде. Три фреймворка здесь обсуждались.

http://electronix.ru/forum/index.php?showtopic=113476

ZIO должен быть серьёзным. Один из авторов соавтор библии линуксовских драйверов.


Однако фреймворк не панацея от всех проблем и при переносе системы вы столкнетесь с проблемами, которых фреймворком не решить. Фреймворки работают для драйверов устройств, которые вы хотите подключить к работающей системе. Есть много драйверов, с которыми фреймворк вам не поможет.
Я бы вам посоветовал не переносить систему с платформы на платформу, а найти работающую платформу на том процессоре, что вы планируете использовать.
Следующим шагом научиться строить кернел для этой платформы.
Далее изучить индивидуальный файл для этой платформы, где определена только ее конфигурация
для ОМАП2 и ОМАП3 это файлы из:
arch/arm/mach-omap2/
Для Биглборда машинный файл board-omap3beagle.c лежит здесь. board-omap3evm.c для мистралевского борда на AM3715.
Здесь создаются все устройства, которые вы собираетесь использовать.

С дисплеем можно попасть в струю если есть возможность выбирать. Для проекта, что я работаю сейчас мы нашли дисплей,что обошлись без драйвера. Я только добавил видео моду для нужного разрешения (1024х600).
I2C, SPI, GPIO драйверы писать не надо. все уже есть. Правда если вы хотите подключить какой-нибудь чип, использующий скажем I2C, то вам придется писать драйвер (а то и не один) для поддержки всей остальной части чипа.
Хорошие новости. Множество драйверов уже реализовано. Иногда поддержка производителя чипа дает коды драйверов.

Задача следующая: выбираем вычислительную платформу для одного мобильного устройства, то есть как аппаратуру, так и ОС. Хотелось бы иметь возможность перехода на другую аналогичную аппаратуру, если выбранный OEM-модуль снимут с производства. Меня сейчас интересует выбор ОС: Linux, либо Android ( Windows будет тяжеловат). Android в наших экспериментах обеспечивал 100% переносимость (как и следовало ожидать). Программа работает на разных платах, устройствах, смартфонах одинаково. Минус - ограниченный набор интерфейсов и потери производительности на Java-машине.



Спасибо!

Разницы не будет. Проблема с портированием самого Линукса (ядра) на платформу. А юзерленду все равно фактически.
Ну у вас вариантов нет, что Линух, что Андроид придется портировать.

Причем в случае Андроида портировать тоже Линукс

А если предположить, что для обоих платформ существуют готовые дистрибутивы Android и Linux с необходимыми драйверами (про совместимость драйверов данных нет)? С андроидом, как я уже писал, наблюдаем очень хорошую переносимость: экранчик, USB, мышка/тачпад работают на всех протестированных устройствах без какого бы то ни было портирования нашего ПО. После обсуждения в данной теме складывается впечатление, что от Linux такого ожидать не стоит. Это так?

Ну если дистрибутивы готовы, то какие могут быть проблемы?
Все должно быть пучком. Хоть Линух, хоть Андроид

драйвер для Линукса и для Андроида будет один и тот же. Андроид формально неверно называть ОС, в качестве операционной системы он использует Линукс. Андроид это Линукс + надстройка. Я бы отдал предпочтение Андроиду.

У нас сейчас такая проблема. Портирую Ubuntu на iMX53 драйверы работают, но для использования хардверных видео декодеров и енкодеров скажем H264 надо использовать Gstreamer, который работает в пользовательской моде. Там элементы написаны с кучей недокументированых свойств. Получить поддержку от Фрискейла не удалось. Движемся методом проб и ошибок.
В Андроиде нет нужды обеспечивать работу енкодера и декодера на уровне Gstreamer. Там если нет харверной поддержки H264, то оно не работает и Фрискейл не может отрапортовать, что оно работает с Андроидом. Да к тому же сейчас все силы поддержки на Андроид нацелены.
Резюме: С Линуксом у вас будет больше проблем.

Линукс -- это не операционная система. Это ядро.

Значит если я переставлю кернел от Убунту на Красную Шапку, то Красная Шапка превратится в Убунту?

Я не постиг хода вашей мысли.

Это было доказательство ошибочности вашего предположения

http://www.gnu.org/gnu/linux-and-gnu.html


почитайте по ссылке выше.
Красная шапочка и ubuntu это варианты систем GNU/Linux (часто называемых ”дистрибутивами”).

Я могу найти много ссылок, где написано, что Линукс это операционная система. Мне интересно узнать что andrew_b имеет ввиду.

Не увидел никакого доказательства.

Я имел в виду то, что написал. Буквально. Могу повторить. Linux -- это только ядро. Не больше и не меньше. Операционная система на этом ядре может называться по-другому.

Мешанина в головах, однако. Linux определенно операционная система (и весь мир вроде так считает). Но существует еще понятие операционной среды, которых в операционной системе, вообще говоря, может быть несколько. Так вот Android - это Java-oriented операционная среда, поддерживаемая в определенных сборках (специально на это заточенных) операционной системы Linux. Ну, или если угодно, то комбинация Linux и Android-специфической операционной среды (или сред, если native вариант считать за отдельную суб-среду). Как бишь они там точно называются?

Другой пример - в Windows95 поддерживалось несколько операционных сред: Win16, Win32, DOS.

Если английская ссылка не помогает - прочитайте что такое GNU и Linux по-русски "Что такое GNU?"
http://www.gnu.org/home.ru.html

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

"Построй свой Линукс сам"


А то мы ушли в оффтопик