gormih

И что это? Демонстрация умения искать в гугле, и ориентироваться на сайте TI?

JTAG нужен пригодится разве что для отладки загрузчика, такого как U-boot. После запуска ядра в 99% случаев для отладки вполне достаточно printk и debug level. Рабочую машину - рекомендую на базе ubuntu linux 12.04 64 bit. Чем мощнее процессор, тем лучше.

По опыту: Пока сам не напишешь пару драйверов на имеющееся в наличии рабочее ядро - о портировании новой версии ядра на свою борду думать рановато :-)

Все нужные вам устройства описываются тут: arch/arm/mach-omap2/board-am335xevm.c Для подробного вывода логов нужно подшаманить конфигурацию ядра в части например printk level =7 , и некоторые внести некоторые изменения в самые интересные модули ядра типа #define DEBUG (обязательно до объявления всех .h файлов)

Сам себе задал вопрос, сам и ответил. На beagleboneblack Android SDK 4.2.2 имеет следующие соответствия по i2c: В ядре i2c0, на борде i2c-1, i2c1 -> i2c-2 , i2c2-> i2c-3. При этом инициализация i2c-1 -> i2c2 изначально в ядре не прописана, если ваше устройство "висит" на этой шине - ее придется прописать.

Дело оказалось в snd_soc_dai_link am335x_evm_dai static struct snd_soc_dai_link am335x_evm_dai = { .name = "max98088", .stream_name = "HiFi", .cpu_dai_name ="davinci-mcasp.1", .codec_dai_name = "max98088.1-10", .platform_name = "davinci-pcm-audio", .codec_name = "max98088.1-0010", .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM, .ops = &am335x_evm_ops, }; Ключевыми является .stream_name и .codec_dai_name. Теперь осталось понять, в каком месте разработчики борды напутали, и какой из трех i2c в ядре выведен на пины отмеченные как i2c-1 :)

Вы не поверите - как правило в файле борды:-) Там все может быть сложнее завязано. Может, например вычислять по комбинации перемычек на выводах контроллера, и тому подобное...., Куча подводных камней. Если задача не стоит сделать универсальный файл борды под целый ряд девайсов - я лично блокирую все функции идентификации борды, дабы не тратить на них время. Единственное - нужно понимать, к каким последствиям это может привести например для подключаемых модулей ядра. Это не сложности. Это стиль программирования :) Только по началу тяжело освоить, потом становится легче, когда знаешь минимум того, что должно быть описано... Со временем понимая всю "навороченность" ядра начинаешь наоборот восхищаться некоторым решениям. Писать драйвера под linux гораздо проще по сравнению например с windows именно благодаря богатой инфраструктуре того что нужно на уровне ядра, и хорошо продуманным описательным моделям самих драйверов. Я вот чистым временем около недели потратил на освоение того, как примерно работает ALSA на уровне ядра, и еще далек от завершения поставленной задачи. Из документации, на скорую руку слепленой жалким подобием doxygen мало что понятно. :) Но из того, что всплыло становится ясно, что при хорошей документации у меня ушло бы максимум 1 день на решение задачи.

Вообщем имеем begleboneblack + max98089 EVKIT Висит кодек на i2c-1 Пишем драйвер для ALSA: На выходе имеем следующую фигню: по dmesg и далее No soundcards found. Хотя бы подскажите, куда копать.. Еще не пойму одной вещи - у меня вроде .ops не вызываются, и кодек не пишет отладочных собщений, хотя #define DEBUG в нем поставил, уровень отладки kprint 7, и есть еще живительное CFLAGS_max98088.o = -DDEBUG в Makefile. После всего этого отладочных сообщений нету.. P.S.: Скрыть под спойлер код не удалось. Что то не работает на форуме, сори.

Человек, который спрашивал о возможности применения Windows 100% воспримет Вашу рекомендацию как издёвку.

Какой вопрос, такой и ответ. MSP430 наплевать на файлы проекта, он тупо исполняет бинарный код. А вот файл проекта сильно зависит от среды, в которой проект разрабатывался. Если, например это gcc binutils + Eclipse, то вообще файл проекта не включает в себя список исходников. Если это Keil uVision или например CodeComposer - ситуация резко меняется. Вопрос о функции Main в данном случае сугубо риторический... с соответствующим ответом - "где то":-)

Все правильно. Linux + OpenCV. Плат под это - только ленивый не найдет.

Если что, то - diff -u ./kernel-3.14.1/ ./kernel-2.6.36/ >kernel-from-2636-to-3141.patch Сделает патч на все ядро целиком. Это для справки. Аналогичный патч можно сделать например на всю директорию arch/arm/plat-omap и sound/soc/omap - именно там основные отличия в части исходников интересных по Вашей теме. Конфигурацию u-boot не меняли? Такое бывает еще, когда например в u-boot не задана ttys, а в ядре по умолчанию не прописана, либо прописана но не правильно. И на всякий случай дайте вывод file ./uImage

З.Ы.: Ядро линукс проще и удобней все таки собирать под линуксом. Особо легче, если при этом знаешь что такое ls, grep, diff, patch, modprobe и прочее :-)

Кто нибудь цеплял max98088/9 к этому счастью на андроид? Если да - поделитесь опытом :)

Как вариант: 1) Находим любую борду под omap, которая есть в старой и новой версии SDK 2) Делаем diff 3) По примеру патча делаем патч/исправление под свою борду.

Все правильно, версии не совместимы. Придется править почти всё. А в новом SDK что, нет под Вашу плату файла? TI очень любят объеденять в один файл кучу процов и плат. Под OMAP там целая директория в arch/arm - поройтесь...

Потому что не все модули ядра поддерживают статический режим загрузки. Для начала его нужно пробывать загрузить через modprobe, и лишь потом при особом желании делать статическим. Забудьте :-) Это к слову. Я же не знаю, откуда Вы пытаетесь писать в регистры.

Так не пойдет. Сделайте (М) Вам не помешало бы изучить архитектуру ядра, в том числе что такое spinlock и.т.д. Для начала. Рекомендую книгу Роберата Лава. ISBN 5-8459-1085-1

Ну в данном случае я бы делал так: 1) Через конфиг ядра нашел бы, какие модули в него добавились. 2) В эти модули понатыкал побольше диагностических kprint И еще вопрос - там у вас это serial модулем включено в ядро? (M) или (*) ?

Можно пояснить? Что хочется добиться в конечном итоге? Сделать любой абы-какой usb-device, который лишь бы определялся в другой системе?

В Москве поболее зарплата, чем в Чехии как оказывается.

Тут по моему других вариантов не предвидится :-)

Что мешает воспользоваться отладкой на "железе"? В AVR STUDIO прекрасный интерфейс, показывающий состояние любого регистра в любой момент времени и точки останова. Этого вполне достаточно для отладки любой сложности. Если "ничего не выводит" - первое, что приходит на ум - поставить точку останова в функции void TxChar(char ch), и проанализировать состояние регистров контроллера во время ее работы, если она вообще вызывается. Если с регистрами норма - ищите проблемы в железе. Подключите осциллограф или логический анализатор на uart, посмотрите как дергаются / не дергаются пины. Причин может быть много - от ошибки в коде, до сгоревшего пина котроллера/ драйвера на плате, и здесь могут дать только советы а не выполнить за Вас работу:)

Читал Ваши посты на форуме... Если все так хорошо - возьмите да сделайте. При чем так, чтобы было или дешевле чем у китайцев, или первый вариант описанный выше. Если у Вас получится - преклоню колено перед Вашей великой квалификацией.

"И у нас вы получите гнилой хлеб, а там настоящий..." Как то так. Не думаю, что человек у которого родилась идея, изложенная в шапке темы полностью осознает все затраты и то, что он получит на выходе. Более серьезный подход подразумевает серьезную доработку схемы в части вставки в нее настоящего PCI-E, без левых переходников. Вопрос в том, зачем все это нужно... 1) если это какой то заказ, связанный с безопасностью/оборонкой и должен быть минимизирован в части исходников, отсуствию закладок и.т.д. - один вопрос... 2) Если же возникло желание тупо перещеголять китайцев в части цены - дохлый номер, не достойный внимания серьезных разработчиков в принципе. В любом случае, первая область применения не достойна такого решения, вторая не интересна. А делать халтуру, лишь бы платили - удел жуликов и воров (простите за откровенность)