Новый проект на основе прототипа с AM/DM37xx, OMAP-L138, Понимание настроек Linux, uboot, драйверов и всего остального... Опции

[Petrovitch]

Здравствуйте, уважаемые участники форума!

У меня имеется новый проект, в реализации которого есть большие затруднения.

Некая система должна получать на входе видеосигнал по протоколу ВТ.656 (8 bin parallel + clk (27 MHz)). С полученной картинкой необходимо производить различные действия по изменению размеров, регулировкой яркости и т.д. с наложением поверх картинки простой графики. Далее, необходимо передать результирующее изображение на OLED (800х600) либо по тому же протоколу ВТ.656, либо RGB888. Грузиться система должна с FLASH. Это присказка.

На начальном этапе хотелось бы поэкспериментировать на готовом железе, максимально приближенным по архитектуре и возможностям для решения задачи. Речь идёт конечно же об оценочных платах от TI, Embest, LogicPD, CALIXTO, MENTOR. Во всех платах имеются видеовходы, выходы на LCD и кнопки. Но есть проблемы. Эти платы спроектированы под определённую периферию, немного не похожую по интерфейсу с моей. Управление камерой производится по UART, а управление дисплеем по I2C.

В частности, например, чтобы заработал дисплей, необходимо отправить ему серию кодов инициализации по I2C, иначе он не включится. На каком этапе производится инициализация? Я полагаю инициализацией должен заниматься u-boot. Тогда как его настроить?

Прошу знающих людей объяснить мне технологию адаптации нового оборудования в Linux от и до. Что прочитать и т. д. Хочется во всём разобраться самому. Ну и заодно может подскажите на каком конструкторе из выше названных лучше пробовать (с доработками или без).

[Tarbal]

В загрузчике это надо сделать отдельно. Фактически надо делать два раза (и по разному) в ядре и в загрузчике.
Для того чтобы работало в загрузчике вам надо подключиться к той же шине, к которой подключен PMIC. Я уже писал об этом.

после загрузки линукса, можно утилитой i2cdetect убедится, что экран подключен на i2c шину, и утилитами i2cset, i2cget - порулить регистрами вашего экрана через i2c интерфейс без всяких драйверов..

Утилит может не быть, но всегда сработает:
ls /sys/bus/i2c/devices/
покажет все устройства на шине и их адреса. Вот как это выглядит в моей системе.
0-0008 1-000a 1-0034 1-0054 2-0041 i2c-1
0-003c 1-0010 1-0039 2-0004 i2c-0 i2c-2

Три шины 0, 1 и 2. К ним подключены устройства.
Три шины 0, 1 и 2. К ним подключены устройства.
0-0008 означает , что к шине 0 подключено устройство с 7-битным адресом 0x08, чему соответствуют 8-битные адреса 0x11 и 0x10 для чтения и записи.

[SM]

В загрузчике это надо сделать отдельно.

В загрузчике это вообще не надо никак делать, загрузчику дисплей не нужен, как и его инициализация.

А порулить I2C-устройством можно и из юзерспейса для начала, используя i2c /dev interface (соотв. докуменатция живет в i2c/dev-interface), писать kernel driver можно уже потом, когда понимание придет, что именно писать.

[Petrovitch]

В загрузчике это вообще не надо никак делать, загрузчику дисплей не нужен, как и его инициализация.

А порулить I2C-устройством можно и из юзерспейса для начала, используя i2c /dev interface (соотв. докуменатция живет в i2c/dev-interface), писать kernel driver можно уже потом, когда понимание придет, что именно писать.

Если можно - поподробнее пожалуйста об этом.

А вообще давайте представим, что имеется BeagleBone (как прототип конечного устройства), подключенный к хосту через USB и Ethernet. С хоста мы можем увидеть процесс загрузки ВВ и наверное порулить I2C, и остановить загрузку после u-boot и ещё много чего, Но мы НИЧЕГО не увидим на OLED-е пока не отправим на него по I2C набор кодов настройки отображения. Что же тогда делать если хоста не было бы?! На целевой системе он мне не нужен!!!

Тогда на каком этапе "прикручивать" драйвер и как его писать? На этапе отладки ПО наверное как можно раньше, а на целевой системе пользователю точно не нужно видеть процесс загрузки, ему и заставки хватит!